浮躁：年轻不可避免的问题。在工作、生活中无法克制住这样的

心情，不能冷静客观的分析事情。
焦虑：对未来的焦虑。职业生涯的持续发展、工作的稳定性、收

入的提升。有压力就会有动力。可是有时我有一种莫名的焦虑，

为了生存而焦虑。
收获：我有了自己的下一代，我的女儿（儿子）就要出世了。希

望她（他）能带有感激心情来面对父母和这个世界。感谢父母给

了她（他）一次生命，一次为实现自己理想和愿望而奋斗的机会

。而不是过多的无偿索取，不奉献、不劳作。真的希望她（他）

有《洗澡堂家的男人们》这个电视剧中的主人公这样的心态。再

一个收获，今年我投资收益（80%）。

真的很感谢我的老婆！！！  可能她看不到这个文章，但是2006

年她为我做了不少，在有能力的情况下，一定要多实现她的愿望

。

我一直以《洗澡堂家的男人们》中家中长子作为自己孝敬父母的

榜样。希望父母能安度晚年。

2007年展望

1、性格和心态的培养
耐心和恒心。 做任何事情都需要耐心和恒心。只有这样你才能

成功。知道和做到是有很大差距的，不断告诫自己耐心、务实、

坚持。工作中耐心解决每一个问题，耐心对待同事和客户；耐心

对待家庭中每一人，使他们能感受到我的关心；耐心面对挫折、

失望、焦虑。找寻出路。
2、理财
将理财进行到底。说回来还是心态的培养。心态和性格决定你的

收益。‘投资’非‘投机’。确立一个有效的筛选机制，长期持

有，获取收益。2007年目标，投资收益（20%），截至2006年12

月31日前的资产价值。
3、责任
作为儿女承担的责任、作为丈夫承担的责任、作为父亲承担的责

任、作为兄弟承担的责任… …

都需要我耐心、耐心、再耐心

—-财务报表

—-业务分析

—-行业分析

—-企业盈利能力分析

—-基本面分析

———摘自《21世纪经济报道》

银行业：

1、资本充足率                  12%以上  （国际标准）

2、资产收益率 ROA        20%左右  （国际标准）

3、股权收益率 ROE       1.5~2         （国际标准）

银行的零售业务主要包括：消费信贷、个人理财、银行卡、零售类中间业务等

  ：）   答案是“梦”

  “股神”投资理财思路之一，一生只买卖12次股票。为什么这样说？

  投资和投机？怎样区分？

 我应该怎样选择，为什么做这样投资？为什么会买这样的股票？

 依据！！！

　　控制文件损坏：

　　控制文件记录了关于oracle的重要配置信息，如数据库名、字符集名字、各个数据文件、日志文件的位置等等信息。控制文件的损坏，会导致数据库异常关闭。一旦缺少控制文件，数据库也无法启动，这是一种比较严重的错误。

　　损坏单个控制文件：

　　1. 确保数据库已经关闭，如果没有用下面的命令来关闭数据库：

　　svrmgrl>shutdown immediate;

　　2. 查看初始化文件$ORACLE_BASE/admin/pfile/initORCL.ora,确定所有控制文件的路径。
　
　　3. 用操作系统命令将其它正确的控制文件覆盖错误的控制文件。

　　4. 用下面的命令重新启动数据库：

　　svrmgrl>startup;

　　5. 用适当的方法进行数据库全备份。

　　损坏所有的控制文件：

　　1. 确保数据库已经关闭，如果没有用下面的命令来关闭数据库：

　　svrmgrl>shutdown immediate;

　　2. 从相应的备份结果集中恢复最近的控制文件。对于没有采用带库备份的点可以直接从磁带上将最近的控制文件备份恢复到相应目录；对于采用带库备份的点用相应的rman脚本来恢复最近的控制文件。

　　3. 用下面的命令来创建产生数据库控制文件的脚本：

svrmgrl>startup mount;

svrmgrl>alter database backup controlfile to trace noresetlogs;

　　4. 修改第三步产生的trace文件，将其中关于创建控制文件的一部分语句拷贝出来并做些修改，使得它能够体现最新的数据库结构。假设产生的sql文件名字为createcontrol.sql.

　　注意：

　　Trace文件的具体路径可以在执行完第3步操作后查看$ORACLE_BASE/admin/bdump/alert_ORCL.ora文件来确定。

　　5. 用下面命令重新创建控制文件：

　　svrmgrl>shutdown abort;

　　svrmgrl>startup nomount;

　　svrmgrl>@createcontrol.sql;

　　6. 用适当的方法进行数据库全备份。

　　重做日志文件损坏：

　　数据库的所有增、删、改都会记录入重做日志。如果当前激活的重做日志文件损坏，会导致数据库异常关闭。非激活的重做日志最终也会因为日志切换变为激活的重做日志，所以损坏的非激活的重做日志最终也会导致数据库的异常终止。在ipas/mSwitch中每组重做日志只有一个成员，所以在下面的分析中只考虑重做日志组损坏的情况，而不考虑单个重做日志成员损坏的情况。

　　确定损坏的重做日志的位置及其状态：

　　1. 如果数据库处于可用状态：

　　select * from v$logfile;

　　svrmgrl>select * from v$log;

　　2. 如果数据库处于已经异常终止：

　　svrmlgr>startup mount;
　　svrmgrl>select * from v$logfile;
　　svrmgrl>select * from v$log;

　　其中，logfile的状态为INVALID表示这组日志文件出现已经损坏；log状态为Inactive：表示重做日志文件处于非激活状态；Active： 表示重做日志文件处于激活状态；Current：表示是重做日志为当前正在使用的日志文件。

　　损坏的日志文件处于非激活状态：

　　1. 删除相应的日志组：

　　svrmgrl>alter database drop logfile group group_number;

　　2. 重新创建相应的日志组：

　　svrmgrl>alter database add log file group group_number （’log_file_descritpion’，…） size log_file_size;

　　损坏的日志文件处于激活状态且为非当前日志：

　　1. 清除相应的日志组：

　　svrmgrl>alter database clear unarchived logfile group group_number;

　　损坏的日志文件为当前活动日志文件：

　　用命令清除相应的日志组：

　　svrmgrl>alter database clear unarchived logfile group group_number;

　　如果清除失败，则只能做基于时间点的不完全恢复。

　　打开数据库并且用适当的方法进行数据库全备份：

　　svrmgrl>alter database open;

　　部分数据文件损坏：

　　若损坏的数据文件属于非system表空间，则数据库仍然可以处于打开状态可以进行操作，只是损坏的数据文件不能访问。这时在数据库打开状态下可以单独对损坏的数据文件进行恢复。若是system表空间的数据文件损坏则数据库系统会异常终止。这时数据库只能以Mount方式打开，然后再对数据文件进行恢复。可以通过查看数据库日志文件来判断当前损坏的数据文件到底是否属于system表空间。

　　非system表空间的数据文件损坏

　　1. 确定损坏的文件名字：

　　svrmgrl>select name from v$datafile where status=’INVALID’;

　　2. 将损坏的数据文件处于offline状态：

　　svrmgrl>alter database datafile ‘datafile_name’ offline;

　　3. 从相应的备份结果集中恢复关于这个数据文件的最近的备份。对于没有采用带库备份的点可以直接从磁带上恢复；对于用带库备份的点用相应的rman脚本来恢复。

　　4. 恢复数据文件：

　　svrmgrl>alter database recover datafile ‘file_name’;

　　5. 使数据库文件online：

　　svrmgrl>alter database datafile ‘datafile_name’ online;

　　6. 用适当的方法进行数据库全备份。

　　system表空间的数据文件损坏：

　　1. 以mount方式启动数据库

　　svrmgrl>startup mount;

　　2. 从相应的备份结果集中恢复关于这个数据文件的最近的备份。对于没有采用带库备份的点可以直接从磁带上恢复；对于用带库备份的点用相应的rman脚本来恢复。

　　3. 恢复system表空间：

　　svrmgrl>alter database recover datafile ‘datafile_name’;
　
　　4. 打开数据库：

　　svrmgrl>alter database open;

　　5. 用适当的方法进行数据库全备份。

　　表空间损坏：

　　若非system表空间已经损坏，则数据库仍然可以处于打开状态可以进行操作，只是损坏的表空间不能访问。这样在数据库打开状态下可以单独对损坏的表空间进行恢复。若是system表空间损坏则数据库系统会异常终止。这时数据库只能以Mount方式打开，然后再对表空间进行恢复。可以通过查看数据库日志文件来判断当前损坏的表空间是否是system表空间.

　　非system表空间损坏：

　　1. 将损坏的表空间处于offline状态：
　
　　svrmgrl>alter tablespace ‘tablespace_name’ offline;

　　2. 从相应的备份结果集中恢复关于这个表空间最近的备份。对于没有采用带库备份的点可以直接从磁带上恢复；对于用带库备份的点用相应的rman脚本来恢复。

　　3. 恢复表空间：

　　svrmgrl>alter database recover tablespace ‘tablespace_name’;

　　4. 使表空间online：

　　svrmgrl>alter tablespace ‘tablespace_name’ online;

　　5. 用适当的方法进行数据库全备份.

　　system表空间损坏：

　　1. 以mount方式启动数据库

　　svrmgrl>startup mount;

　　2. 从相应的备份结果集中恢复system表空间最近的备份。对于没有采用带库备份的点可以直接从磁带上恢复；对于用带库备份的点用相应的rman脚本来恢复。

　　3. 恢复system表空间：

　　svrmgrl>alter database recover tablespace system;

　　4. 打开数据库：

　　svrmgrl>alter database open;

　　5. 用适当的方法进行数据库全备份。

　　整个数据库的所有文件损坏：

　　整个数据库所有文件的损坏一般是在共享磁盘阵列发生无法恢复的灾难时才发生，这种情况下只能对数据库进行恢复。若数据库的归档目录也已经丢失，则数据库不可能做完全恢复，会有用户数据的丢失。

　　没采用带库备份的现场：

　　1. 将最近的备份从磁带上把各个文件解包到相应的目录下。

　　2. 以mount方式打开数据库：
　
　　svrmgrl>startup mount;

　　3. 恢复数据库：

　　svrmgrl>recover database until cancel;

　　4. 打开数据库：

　　svrmgrl>alter database open resetlogs;

　　5. 用适当的方法进行数据库全备份。

　　采用带库备份的现场：

　　1. 以nomount方式打开数据库：

　　svrmgrl>startup nomount;

　　2. 通过相应的rman脚本进行数据库软恢复。

　　$rman cmdfile=hot_database_restore.rcv

　　3. 打开数据库：

　　svrmgrl>alter database open resetlogs;

　　4. 用适当的方法进行数据库全备份。

　　存在最近的数据库完整冷备份前提下的一些经典紧急情况的处理：

　　数据文件，归档重作日志和控制文件同时丢失或损坏：

　　无新增archives 时的状况：
　
　　条件和假设：自上次镜像备份以来尚未生成新的archive log(s); Archivelog Mode; 有同步的datafile(s) 和control file(s) 的镜像（冷）拷贝

　　恢复步骤：

　　1. 将镜像拷贝的datafile(s) 和control file(s) 抄送回原始地点:

　　$ cp /backup/good_one.dbf /orig_loc/bad_one.dbf

　　$ cp /backup/control1.ctl /disk1/control1.ctl

　　2. 以mount 选项启动数据库：

　　$ svrmgrl
　
　　svrmgrl> connect internal

　　svrmgrl> startup mount

　　3. 以旧的control file 来恢复数据库：

　　svrmgrl> recover database using backup controlfile until cancel;

　　*** 介质恢复完成
　　
　　（必须马上cancel ）

　　4. Reset the logfiles （对启动而言不可省略）：

　　svrmgrl> alter database open resetlogs;

　　5. 关闭数据库并做一次全库冷备份。

新增archives 时的状况：

　　条件和假设：自上次镜像备份以来已经生成新的archive log(s); Archivelog Mode; 有同步的datafile(s) 和control file(s) 的镜像（冷）拷贝；archive log(s) 可用。

　　恢复步骤：

　　1. 如果数据库尚未关闭，则首先把它关闭：

　　$ svrmgrl
　
　　svrmgrl> connect internal

　　svrmgrl> shutdown abort

　　2. 将备份文件抄送回原始地点：

　　所有Database Files

　　所有Control Files（没有archive(s) 或redo(s) 的情况下，control files 的更新无任何意义）

　　所有On-Line Redo Logs (Not archives)

　　init.ora file（选项）

　　3. 启动数据库：

　　$ svrmgrl

　　svrmgrl> connect internal

　　svrmgrl> startup

　　数据文件, 重作日志和控制文件同时丢失或损坏：

　　条件和假设：Archivelog Mode; 有同步的所有所失文件的镜像（冷）拷贝；archive log(s) 可用

　　恢复步骤（必须采用不完全恢复的手法）：
　　
　　1. 如果数据库尚未关闭，则首先把它关闭：

　　$ svrmgrl

　　svrmgrl> connect internal

　　svrmgrl> shutdown abort

　　2. 将备份文件抄送回原始地点：

　　所有Database Files

　　所有Control Files

　　所有On-Line Redo Logs(Not archives)

　　init.ora file（选项）

　　3. 启动数据库然而并不打开：

　　svrmgrl>startup mount

　　4. 做不完全数据库恢复，应用所有从上次镜像（冷）备份始积累起来的archives：

　　svrmgrl> recover database until cancel using backup controlfile;

　　……
　　……

　　cancel

　　5. Reset the logfiles （对启动而言不可省略）：

　　svrmgrl> alter database open resetlogs;
　
　　6. 关闭数据库并做一次全库冷备份。

　　数据文件和控制文件同时丢失或损坏：

　　条件和假设：Archivelog Mode; 有同步的datafile(s) 和control file(s) 的冷拷贝；archive log(s) 可用

恢复步骤：

　　1. 将冷拷贝的datafiles(s) 和control file(s) 抄送回原始地点:

　　$ cp /backup/good_one.dbf /orig_loc/bad_one.dbf

　　$ cp /backup/control1.ctl /disk1/control1.ctl

　　2. 以mount 选项启动数据库：

　　$ svrmgrl

　　svrmgrl> connect internal

　　svrmgrl> startup mount
　　
　　3. 以旧的control file 来恢复数据库：

　　svrmgrl> recover database until cancel using backup controlfile;

　　*** 介质恢复完成

　　（须在应用完最后一个archive log 后cancel ）

　　4. Reset the logfiles （对启动而言不可省略）：

　　svrmgrl> alter database open resetlogs;

　　重作日志和控制文件同时丢失或损坏时：

　　条件和假设：Control Files 全部丢失或损坏；Archivelog Mode; 有Control Files 的镜像（冷）拷贝。
　　
　　恢复步骤：

　　1. 如果数据库尚未关闭，则首先把它关闭：

　　$ svrmgrl

　　svrmgrl> connect internal

　　svrmgrl> shutdown abort

　　svrmgrl>exit

　　2. 以Control File 的镜像（冷）拷贝覆盖损坏了的Control File:

　　$ cp /backup/control1.ctl /disk1/control1.ctl

　　3. 启动数据库然而并不打开：

　　$ svrmgrl

　　svrmgrl> connect internal

　　svrmgrl> startup mount

　　4. Drop 坏掉的redo log （排除硬件故障）：

　　svrmgrl> alter database drop logfile group 2;

　　5. 重新创建redo log:

　　svrmgrl> alter database add logfile group 2 ‘/orig_loc/log2.dbf’ size 10M;
　　
　　6. 以旧的control file 来恢复数据库：
　　
　　svrmgrl> recover database until cancel using backup controlfile;

　　（必须马上cancel ）

　　7. Reset the logfiles （对启动而言不可省略）：

　　svrmgrl> alter database open resetlogs;

　　8. 关闭数据库并做一次全库冷备份

　　只发生归档重作日志丢失或损坏时：

　　根据不同环境和情况，选择下述手段之一：

　　a. 马上backup 全部datafiles （如果系统采用一般热备份或RMAN 热备份）

　　b. 马上正常关闭数据库并进行冷备份（如果系统采用冷备份）

　　c. 冒险前进！不做备份而让数据库接着跑，直等到下一个备份周期再做备份。这是在赌数据库在下一个备份周期到来之前不会有需要恢复的错误发生。

　　注意:冒险前进的选择：如果发生错误而需要数据库恢复，则最多只能恢复到出问题archive log 之前的操作现场。从另一个角度讲，archive log(s) 出现问题时，数据库若不需要恢复则其本身并没有任何问题。

　　Oracle逻辑结构故障的处理方法：

　　逻辑结构的故障一般指由于人为的误操作而导致重要数据丢失的情况。在这种情况下数据库物理结构是完整的也是一致的。对于这种情况采取对原来数据库的全恢复是不合适的，我们一般采用三种方法来恢复用户数据。
　　　
　　采用exp/imp工具来恢复用户数据：

　　如果丢失的数据存在一个以前用exp命令的备份，则可以才用这种方式。

　　1. 在数据库内创建一个临时用户：

　　svrmgrl>create user test_user identified by test;

　　svrmgrl>grant connect，resource to test_user;

　　2. 从以前exp命令备份的文件中把丢失数据的表按照用户方式倒入测试用户：

$imp system/manager file=export_file_name tables=(lost_data_table_name…) fromuser=lost_data_table_owner touser=test_user constraint=n;

　　3. 用相应的DML语句将丢失的数据从测试用户恢复到原用户。

　　4. 将测试用户删除：

　　svrmgrl>drop user test_user cascede;
　　
　　采用logminer来恢复用户数据：

　　Logminer是oracle提供的一个日志分析工具。它可以根据数据字典对在线联机日志、归档日志进行分析，从而可以获得数据库的各种DML操作的历史记录以及各种DML操作的回退信息。根据这些用户就可以将由于误操作而丢失的数据重新加入数据库内。

　　1. 确认数据库的utl_file_dir参数已经设置，如果没有则需要把这个参数加入oracle的初始化参数文件，然后重新启动数据库。下面例子中假设utl_file_dir=’/opt/oracle/db01’；

　　2. 创建logminer所需要的数据字典信息，假设生成的数据字典文本文件为dict.ora：

svrmgrl>execute dbms_logmnr_d.build(dictionary_filename=>’dict.ora’， dictionary_location=>’/opt/oracle/db01’);

　　3. 确定所需要分析的日志或者归档日志的范围。这可以根据用户误操作的时间来确定大概的日志范围。假设用户误操作时可能的日志文件为/opt/oracle/db02/oradata/ORCL/redo3.log和归档日志’/opt/oracle/arch/orcl/orclarc_1_113.ora’。

　　4. 创建要分析的日志文件列表，按日志文件的先后顺序依次加入：

　　svrmgrl>execute dbms_logmnr.add_logfile(logfilename=>’/opt/oracle/arch/orcl/orclarc_1_113.ora’，options=>dbms_logmnr.NEW);

svrmgrl> execute dbms_logmnr.add_logfile(logfilename=>’ /opt/oracle/db02/oradata/ORCL/redo3.log’，options=>dbms_logmnr.ADDFILE);

　　5. 开始日志分析，假设需要分析的时间在’2003-06-28 12:00:00’和’2003-06-28 13:00:00’之间：

　　svrmgrl>execute dbms_logmnr.start_logmnr(dictfilename=>’ /opt/oracle/db01/dict.ora’，starttime=>to_date(’ 2003-06-28 12:00:00’，’YYYY-MM-DD HH:MI:SS’)，endtime=>to_date(to_date(‘2003-06-28 13:00:00’，’YYYY-MM-DD HH:MI:SS’));

　　6. 获取分析结果：

　　svrmgrl>select operation，sql_redo，sql_undo from v$logmnr_contents;
　
　　7. 根据分析结果修复数据。

　　8.结束logmnr:

　　svrmgrl>dbms_logmnr.end_logmnr;

　　9. 用适当的方法对原数据库进行数据库全备份。利用备份恢复用户数据：

　　采用这种方法时并不是在原数据库进行恢复，而是利用数据库备份在新的机器上重新建立一个新的数据库。通过备份恢复在新机器上将数据库恢复到用户误操作前，这样就可以获得丢失的数据将其恢复到原数据库。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　1. 在新的机器上安装数据库软件。

　　2.　 对于采用带库备份的现场，需要在新的数据库服务器上安装调试相应的备份管软件。

　　3. 根据用户误操作的时间点进行基于时间点的数据库恢复操作。对于没有采用带库备份的现场，可以选取用户误操作前最近的备份磁带进行恢复；对于才用带库备份的点可以通过基于时间恢复点恢复的rman脚本来进行恢复。

　　4.重新打开数据库：

　　svrmgrl>alter database open resetlogs;

　　5. 从新的数据库中获取丢失的用户数据，通过DML操作将其恢复到原数据库中。

　　6. 用适当的方法对原数据库进行数据库全备份。

2．     恢复
        磁盘出现故障，数据库自行关闭。
（1）     将驻留在磁盘上的备份拷贝到其他磁盘或磁带上
（2）     执行  
        SVRMGR> connect internal
        SVRMGR> startup mount
        SVRMGR> alter database open;
  会出现错误信息，提示需要恢复
（3）     执行
            SVRMGR> recover database
        根据提示，自动恢复
（4）     执行
            SVRMGR>alter database open
        恢复完成，数据库打开。
Oracle DBA的工作列表

　　理解现有的和新兴的技术

　　所有数据库专业人士需要的一个最基本的能力便是对他们的基本技术技能进行深度和广度的拓展。如果用马斯洛的需求层次来比喻，那么这种能力应该属于食物和水的层次，你必须有这些才能满足基本的生存。上课、阅读文章、研究产品，参加一个专业性质的组织，你需要掌握你正在使用的技术领域的所有信息，而且你还需要有实践机会去应用这些知识。

　　如果你参加一些技术资格或职称的考试，你应该经常提醒自己，你的目标并不单纯是为了在自己的名字后面加上许多的头衔，而是实现你所受教育的价值最大化。

　　西方有句谚语，赢得游戏胜利不仅仅需要你将眼睛盯在正在击打的球上，而且也要能预计到下一个球的方向。历史经验已经证明，任何系统的平均生命周期大约为16个月，因此为未来做好规划很有必要。当你充分了解你正在做的事情后，实施的效率会更高。

　　设计技术性架构

　　任何自己修建的一个系统作为个体的功能都是自以为精妙和可执行的。但如果将它放进一个大一点的系统，它可能就会出现问题，也许你的技能还不是很高妙。无论你是负责全面的应用与网络设计，还是部分营建一个系统部件，支持一个企业架构，你都需要知道什么是良好的、扎实的架构设计法则。

　　一套有效率的技术性架构设计将零件拼接在一起，它应该就像一台容易操控、价格合理的机器一样。我已经发现，架构设计如果基于“奥卡姆剃刀原理”（Occam’s Razor），那么它往往是最棒的，奥卡姆剃刀原理这个词语源于拉丁语，意为“如无必要，勿增实体”（Ent数据库ies should not be multiplied unnecessarily），即简单就是最好的。当考虑设计之时，要记住每个组织都有一些独特的程序，大部分的组织性程序都相当的普通，它们能够用可配置的通用解决方案来解决问题。很多架构可以利用购买以及将一些很小数量的部件组合在一起的方式来完成，而不是要重新发明一种结构。通过这种方法，你能够在很短的时间内，利用更少的成本，为你的客户提供一种优质、容易操控的产品。同样理念还适用于个体应用与架构的设计与开发。

系统集成

　　技术为很多的目的服务，最重要的能力便是使程序的自动化。不是使用传统的供应商订单、库存管理以及产品市场推销手段，而是使用供应链程序，流程通过允许供应商和生产者来进行复杂地沟通控制，从而完成原材料进入生产流程到产品抵达消费者手中的整个过程。

　　Sarbanes-Oxley和其他监管法则都要求企业达到内部控制的标准，它们在系统设计领域相当常见。随着产品和平台继续地增生扩散，随着企业日渐将自己的系统和其他的系统相连，高质量的协同工作能力是必须的。

　　了解企业

　　企业实体是复杂的组织，没有哪个企业是与别的企业完全相同的，就像雪花一样，没有两片雪花是完全相同。这种推动特定业务运转的灵活性不太容易被掌握。很多时候，尤其是在大型企业当中，多种文化是并存的——有一个文化是企业层面的，而别的存在于部门层面。当你认为是安全下水的时候，你对企业运行的细微直觉会因为合并或者管理性质的巨变失去灵光，一切都发生了改变。

　　当我们认为自己能够在企业文化的风浪当中驾轻就熟，而无需在乎浪潮或者风向之时，我们不可以自鸣得意。同样的，尽管企业灵活性的东西当中，很多是普通的，可以传授的知识，那种认为在一个企业环境当中取得成功的做法同样适用于另外一个企业的想法是愚蠢的。我们必须学习我们身处的每个新环境的特质。

　　规划管理项目

　　Joe Torre被视为是一位非常优秀的经理。很难想像，如果他没有一套相当周全的比赛规划，这位纽约人能够在10次比赛中9次取得胜利，并且获得6个AL锦标赛以及4个世界性系列比赛的冠军。这种计划不是针对年度比赛的，而是每一场比赛。

　　无论你是一位经理或者是一位选手，一名超级明星或者是一位业余玩家，你都要为自己近期和远期的比赛制定规划。你如何为今天进行规划？为这周？为今年？你如何完成这些目标？你应该问自己很多“做什么”以及“如何做”的问题。如果你是一名开发人员或者是一名网络管理员，你现在就需要培养自己的规划能力。如果你无法管理自己，你当然就会在管理别人或者复杂项目之时捉襟见肘。

　　注重沟通与倾听

　　任何东西都可以平庸，除了一种能力你不能不做到完美：沟通。这是两个最重要能力当中的一种，沟通对数据库专业人士尤显重要。良好的沟通是双向性的事情，你来我往同等重要。数据库行业是锻炼你雅量的完美地方，因为这一行业需要沟通的时刻太多了。

　　无论你怎样看待工作和生活，每个数据库专业人士实际上都是一名顾问。作为顾问，你有责任去为你的客户提供最大的价值。这样做意味着你至少了解你客户的业务，客户业务运转的情况，这意味着你要去倾听。你的客户有资格知道他们付给你的钱获得了怎样的回报，这意味着你必须主动的、有规律的让他们知道你正在为他们的利益而奔忙。

　　这一点对传统的数据库人员来讲很难。我们大部分进入这一行业的人认为自己接触代码和电线的机会大于与人的接触。我们以为最好的方法便是坐在我们的桌子面前，埋头苦干。这些都是致命的错误，尽管沟通做起来很不容易，也或许会和我们的个性背道而驰，但你别无选择，只能培养这些能力。幸好人人都能够学习，经过一定时间的锻炼，沟通将会变得容易一些。

专注结果

　　另外一个绝对重要的能力便是执行的能力。计划再棒，也只是空谈而已。归根结底，你需要用东西来证明你的努力。

　　最好的方法是了解你客户的一些重要信息，比如他们是谁，他们想做什么？作为一名数据库专业运营顾问，你有责任向你的客户提供建议，这种建议建立在你的知识与经验之上。

　　但别忘了，最终是你的老板或同事、团队领导、你工作的最终客户进行决策。有时候，这些决策并不是你推荐的。你需要认真思考其中的缘由，但不要让任何分析将你麻痹，也不要让自己陷入唐吉柯德式的盲动之中。80-20定律在这里起作用：80%的结果能够通过20%的努力来完成，超出这一范畴的多余价值经常不值得耗费成本。

　　进行战略性的思考

　　这是一个竞争日渐激烈的世界，今天的数据库专业人士必须每天去证明，他们能够增加战术与战略价值；他们要在自己组织的任何一次会议上，成为受欢迎的人。在过去十几年的时间里，企业已经开始意识到数据库的战略重要性，企业认为数据库不仅仅是会计账目上的死水一潭，而是能够给企业带来价值的部门。

　　大部分的数据库部门是被动式的进行工作，他们等待自己的业务客户。高性能、高度成功的数据库部门是积极的，在完成公司总体目标的过程当中，他们以咨询式的态度与自己的业务客户共事。

　　影响和说服

　　上个世纪50年代那种命令式、军队式的组织管理模式已经让位于更加平行的组织管理模式。直接管理和影响管理已经相辅相成。我们不再命令别人做事情。我们会用说服、协商、沟通等等方式去解决问题。这是你训练沟通能力的好机会。有了沟通能力，其他的能力问题才能迎刃而解，像战略性思维、业绩挂钩等等。能够影响他人的数据库专业人士总是代表着高效、富有能力、受人尊敬的人士。不要错误地认为这只是经理们该具备的能力。影响和说服是推动协同性工作环境完成的重要技能。

　　有适应能力

　　一名技术专业人士意味着具有某个特殊开发环境的专长或者有能力开发、支持一个网络，但是在现在，别以为你仍然能够靠这些东西过好日子，如果你和其他提供某一类数据库服务的专家一样，你就是一个没有优势的普通职员。你应该成为一个真正的数据库多面手，需要不断地进行技能扩展工作。这样才能在众多的技术人员当中显示出你的优秀。

　　有些能力，比如技术技能与知识，相对来说比较容易掌握。但类似业务知识一类的知识，则需要你花更多的时间掌握。个人和团队的管理、领导艺术以及和同事、用户共事的能力，这些能力需要你调整自己的个人态度以及个性才能获得。

　　如果你选择在数据库行业就业，你也选择了让自己成为变化的适应者。我们的专业变化很快也很深刻，我们必须认真地对待这种变化。无论你喜欢与否，都要尽快适应业务变化。竞争的压力、新手的进入、管理的变革、战略的调整、产品的开发，任何这些因素都会导致变化。现在，几乎没有一个行业没有被数据库技术所影响，作为一个可以信赖的专业人士，我们必须让我们的企业适应这种变化。