像这样从多种角度评估计划，缜密地研究工作流程，有时候很容易觉得项目胜券在握。认真做好WBS（Work Breakdown Structure，工作分解结构，即全面梳理并规划在项目中应当进行的活动），对工序间的依存关系做出定义，优化计划，评估风险……在完成这些之后，我们很容易产生计划必定能成功的想法。

但实际上，无论是多么天衣无缝的计划，也不能保证其万无一失。仅仅做好计划，并不意味着曾经做不到的事，现在突然能做到。一件事突然成功，其背后必定有不为人知的理由。

假设领导看过你精心制订的完美计划，说：“要是工期能再缩短一个月就更好了。”

这份计划已经被优化过并且被评估过，基本没有进一步缩短工期的可能了。即便有，也是用来应对突发情况的应急计划。但应急计划是在风险发生时采用的对策，不应当在项目开始时就被减除。取消应急计划将无法在发生该部分风险时采取恰当的措施。

但是，在认真制订计划之后，我们会有胜券在握的错觉，容易认为领导提出的缩短一个月的要求很容易满足，并在这种错觉的驱使下不合理地调整计划中的数值。生产率提高10%听上去很简单，但是实际上要将生产率提高10%是非常困难的。

与此相较，平时不怎么在意工作效率的人，更容易找出自己在工作中浪费的10%的时间并加以利用。因此本书力荐各位找出自己浪费的时间。

另外，还存在曲解“学习曲线”（Learning Curve）的情况。学习曲线是揭示“初次学习时，生产率无法提高，但在不断重复同一件事的过程中，生产率会提高”这一现象的曲线。但最重要的是，初次的生产率并不像当初想象的那么高，也不意味着后期生产率会节节攀升。后期生产率的提高，才最终使生产率达到初始目标值。但是有时候，人们会在计划中将后期较高的生产率作为项目整体的生产率。此外，要在后期达到较高的生产率，是需要经过一段时间的，如果时限过短，生产率尚未达到峰值，项目就结束了。

导致生产率下降的原因数不胜数。很多时候，即便项目组成员的生产率提高了，如果因为项目环境问题无法工作，或者器材未按计划送达，又或者客户未按约定履行自己的义务等，项目整体的生产率也无法提高。

另一方面，能提高生产率的因素却寥寥可数。

曾经做不到的事，现在突然能做到，这种情况寥寥无几。单纯地提高生产率很困难。

应当尽量避免曲解“学习曲线”（Learning Curve），将过高的生产率作为前提条件。生产率下降的原因数不胜数，但是能提高生产率的因素少之又少。

还有“试行项目（Pilot Project）”生产率的误用。

所谓试行项目，是指执行大型项目之前先提取其中一小部分实施，在实践过程中确认项目推进方式，进行技术性检验，有时也会将试行项目中得到的实际数据验证对后道工序的预估是否正确。但是我们在应用过程中必须注意试行项目的使用方法。

试行项目通常存在技术上的难度，往往是没有执行先例的，操作过程也未经打磨，面临的问题更不一定在掌握范围内。所以，很多人认为正式项目的生产率要高于试行项目的。

但是试行项目具有独立性相对较高、更容易在早期固定必要的条件的特点。此外，试行项目具备尝试使用新技术的特点，往往会引入尖端的技术。

因此，有时尽管试行项目在技术方面立足于新领域，但生产率较高。所以我们不应主观认定试行项目的生产率低，而应该冷静思考试行项目的数据到底是如何得出的。

将试行项目的生产率应用到其他方面时需要多加注意。其生产率的实现，是有其背后的原因的。

项目完全按计划推进的情况很少

我们制订了自己满意的计划且仔细检查了它的可执行性：预判了风险，考虑了规避问题发生的方案，想到了突发情况，也根据过往案例规划了一定的应急计划；研判了合同形态，在书面上明确规定了项目范畴（对象范围），让经验丰富的成员参与计划，也对推进项目的流程进行了定义。

但是，不管制订的计划多么完美，在实践过程中事情也不可能严丝合缝地按计划进行。每个人都会努力按计划推进工作，但鲜有比计划工期更短、成本更低的情况。

项目未能完全按计划推进的原因数不胜数，且存在于计划的各个阶段，比如项目组成员身体不适、供应商供货延迟、总公司效益不好致使项目预算被削减、根据竞争对手的动向调整战略方针、公司并购后新上任的总经理下调该项目的重要性、合作单位员工泄露项目信息，等等。

那么，项目未按计划进行时，什么方案是中策呢？

掌握计划延迟及预算超支的程度是重中之重。如果事先相对准确地掌握预算超支的程度，经营者就有充分的时间考虑如何挽回损失。但是，如果到项目最后阶段都不能把握预算超支的程度，就很可能无法挽回损失，这不仅会导致项目失败，也可能对经营产生影响。

项目经理必须从日程、预算、质量的角度时刻把握项目整体情况，比如到现阶段多少工序已经结束，使用了多少工时（金额），未来还需要多少时间、多少工时（金额），何时能够完成项目，总工时（金额）与预算相比大约相差多少，产品质量如何。没有客观依据的乐观心态很危险。

图9-9是一个项目的图表，我们仔细看看蓝色虚线和黑色虚线。蓝色虚线表示按最近的生产率执行项目的预期，黑色虚线表示按最初计划的生产率执行项目的预期。

左图表示了项目的实际成果与日期之间的关系。项目实际成果为100%意味着应当做的事情100%完成，也就是项目结束。

项目开始之初，经过了一段时间却没出什么成果，但是中途由于增加了人员，从期限来看，成果显著增加，到现在基本达到当初计划的效果（黑色实线和蓝色实线刚好重合）。如果继续按照目前的状态进行，将有可能提前完成项目。

另一方面，右图表示项目成本与项目实际成果之间的关系，目的在于预测项目实际成果达到100%时，项目成本为多少。如果继续按照目前状态进行，当项目成果达到100%时，成本将远远超出预算（见蓝色虚线）。

中途增加人员使得实际成果大幅增加，但是同时也导致成本远远超出最初的预算。我们需要以项目最初计划的期限与成本为目标缩小配置，让项目用时与成本二者均接近计划。

在这里，我们做个简单的测试，请按照第一感觉作答，从A和B中选择一项。

选择题

A. 100%保证拿到10万日元。

B.有80%的概率拿到15万日元。

选择题

A. 100%保证支付10万日元。

B. 有80%的概率支付15万日元。

我虽然不能百分百确定每一位读者的答案，但是据以往的经验来看，70%到80%的人在第一道选择题会选择A，在第二道选择题会选择B。这个结果与我的预测一致。

我们用概率和报酬计算一下期待值。选择题1中，A选项为增加10万日元（10万日元×100%），B选项为增加12万日元（15万日元×80%），因此，B为合理选项。而选择题2中，A为减少10万日元，B为减少12万日元，因此，A为合理选项。尽管如此，大多数人在这两个选择题上都没有做出合理的选择。

为什么这么多人会选择不合理的选项呢？

我推测，这是因为人们在对自己好的事情上倾向于选择更确定的选项，而在对自己不好的事情上则倾向于选择赌一把。

这正如在系统构建项目中，如果项目末期的测试阶段无法杜绝不良品，在决定是否按计划日期采用新系统时，人们通常毫无客观依据地选择延迟引进。

如果准确掌握客观情况，冷静地加以判断，本可以得出正确的结论，但是，如果人们没有准确把握现状，就很可能会做出不合理的决定。

应当随时掌握项目当前的情况，并对将来的发展做出准确的预期。没有客观依据的乐观心态很危险。

到这里，我们应该系统地理解了项目管理和时间管理的基本概念及流程。各位读者无论身处哪种行业、从事哪种工作，都可以应用这些基本的思维方式，让日常工作的效率变得更高。

不过，不同读者实际面临的项目各不相同，不可能遇到完全一样的问题。现实社会中也常常发生无法预测的事情，所以，遇到问题时，只能自己思考，不断前进。

为了让大家在遇到问题时能有所参考，我在本书最后附上了Q&A（问与答）部分，其中总结了研究生们提出的问题以及我的回答。庆应SDM里聚集了一批在各个企业和机构实习、工作的学生，他们提出的问题各有特点，其中不乏贴合实际工作的问题，希望它们能为大家提供帮助。

第二部分 Oracle DBA

第5章 数据库的创建

我们知道，一个数据库服务器包括实例和数据库两部分，其中数据库是存储在硬盘上的文件，而实例则是一组内存结构和后台进程的集合。数据库的创建意味着要创建实例和数据库两部分。

在安装Oracle 11g软件时，安装向导将引导用户创建一个数据库。此后，数据库管理员可以根据需要再创建一个数据库。在一台计算机上可以运行多个数据库服务器。

通常所说的“创建数据库”实际上就是指创建一个新的数据库服务器。创建数据库服务器涉及两方面的内容，即创建实例和创建数据库。创建实例涉及创建参数文件、创建口令文件、指定SGA、启动实例等。而创建数据库则涉及创建数据文件、创建控制文件、创建重做日志文件等操作。数据库管理员应该首先创建实例，在实例启动后再创建数据库。考虑到数据库服务器运行的安全、高效等要求，在创建数据库之前需要进行详细、周密的规划。

Oracle提供了两种创建数据库的方式，一种是利用DBCA（Database Configuration Assistant）工具的方式，另一种是利用命令行的方式。其中DBCA是Oracle提供的一个图形化工具，利用这个工具可以方便地创建实例和数据库，而不必记忆复杂的命令，这个工具对初学者非常合适。命令行的方式比较复杂，需要用户执行大量的操作系统命令和SQL命令，这种方式要求用户对命令的用法十分熟悉。初学者可能会感到第二种方式很困难，但是只要读者能克服困难，坚持用命令行的方式创建数据库，直到成功，那么你对实例和数据库的结构将会有更深刻的理解，你所获得的成就感是用DBCA方式时所体会不到的。

5.1 数据库的规划

在创建数据库之前，应该进行详尽的规划，因为数据库一旦投入运行，很多信息是根本无法改变的，或者需要耗费大量的人力、财力和时间才能修改。实践证明，许多系统集成公司的工程师在创建数据库时仅仅凭一纸安装文档，虽然能够成功，但是这样的数据库由于缺少规划，在运行一段时间后，就会暴露出很多问题。因此，创建数据库之前的规划可以使数据库管理的工作更加轻松。

数据库的规划涉及多方面的内容，如内存的布局、硬盘空间的使用等，数据库设计人员需要在日常工作中不断积累经验，制定最佳的计划。

5.1.1 SGA的规划

SGA规划的内容包括为各个缓存区指定大小。SGA设置是否合理对数据库服务器的运行性能有很大的影响。

SGA是内存中的一段存储区域，而且这段存储区域只能由数据库服务器使用，这就意味着操作系统可以使用的内存减少了。由于现在的计算机硬件配置都比较高，所有可以将SGA的大小直接设置为物理内存的1/2，随后对数据库的运行情况进行监视，在不带来额外的内外存交换的情况下，逐步增加SGA的大小。

如果SGA太大，操作系统可以使用的内存将大大减少，这时系统将使用虚拟内存来弥补内存的不足，将SGA的一部分放在外存上，这时在内外存之间将进行频繁的交换，系统的性能将降低。这种做法显然违背了建立SGA的初衷。

在Oracle 11g中，有三种方法对SGA进行设置，所有的设置都是通过一些初始化参数来完成的。相关设置方法请参考第4章的相关内容。

SGA由数据库高速缓存、重做日志缓冲区、共享池、Java池、大池等组成，这几部分大小的总和就是SGA的大小。与这些存储区域有关的初始化参数如表5.1所示。

5.1.2 数据文件的规划

数据文件用来存储数据库中的所有数据，包括表、视图、索引、存储程序等数据库对象。数据文件规划的内容包括表空间的数目、数据文件在磁盘上的分布、数据库对象在表空间中的分布、数据块大小等内容。

数据块的大小对数据库的访问性能有很大的影响。如果数据块太小，那么一次数据访问可能需要读多个数据块，从而增加了硬盘读操作的次数。反之，如果数据块太大，用户真正需要的数据可能只占整个数据块的一小部分，大量无用的数据被读到SGA中，从而浪费了SGA的存储空间。Oracle建议在决策支持型（DSS）的数据库系统中，使用较大的数据块，而在联机事务处理型（OLTP）的数据库系统中，使用较小的数据块。

在创建数据文件时，应该综合考虑数据库服务器读写数据文件的效率。在一个数据库中可以创建多个数据文件。如果计算机中有多块硬盘，应该使这些数据文件分布在不同的硬盘上，这样在读写数据文件时，可以在多个硬盘之间同时进行读写，从而提高了数据库的访问性能。如果不同硬盘的读写速度有差异，应当把访问较频繁的数据文件放在速度相对较快的硬盘上，这样可以从整体上提高访问速度。当然数据文件并不是越多越好，因为数据文件越多，打开它们时就要消耗越多的内存空间。

与数据文件相比，重做日志文件的写操作是相对比较频繁的，所以应当把重做日志文件和数据文件分开存放在不同的硬盘上，而且把重做日志文件放在读写速度较快的硬盘上，以减少硬盘写操作时的冲突次数。从安全的角度来讲，这种做法也是可取的。如果一个硬盘损坏，重做日志文件和数据文件不会同时损坏，数据库管理员可以根据没有损坏的文件进行数据库恢复。

5.1.3 控制文件的规划

控制文件是数据库中一个至关重要的文件，它的功能是维护数据库的状态，并且在实例和数据库之间建立对应关系。数据库服务器在启动时，根据控制文件的内容查找数据文件，然后打开数据文件。如果控制文件损坏，数据库服务器将无法正常启动。

在一个数据库中可以只有一个控制文件，但是考虑到这个文件的特殊重要性，应当为它建立多个镜像文件，并且将它们存放在不同的硬盘上。如果一个控制文件损坏，数据库服务器可以通过其他控制文件启动。数据库中的多个控制文件互为镜像，它们的内容是完全相同的。数据库服务器在启动时，只要读其中一个文件即可，而在修改控制文件时，则同时写入所有控制文件。

5.1.4 重做日志文件的规划

重做日志文件的内容是对用户的DDL和DML操作所做的记录，它的功能是在系统出现故障时对数据库进行恢复。

由于重做日志文件的重要性，对重做日志文件有一些特殊的要求。首先，在数据库中需要定义多个重做日志文件组。其次，在每个重做日志文件组中应该包含多个重做日志文件，而且同一个重做日志文件组中的日志文件应该存放在不同的硬盘上。

确定重做日志文件组的合适数量的一个好方法是观察数据库服务器的运行情况，检查是否出现影响检查点和日志切换的故障。如果重做日志文件组太少，可能会影响检查点的发出，也可能会影响日志归档的正常进行。数据库管理员应当经常查看警告文件和跟踪文件，检查是否有这类信息产生，最后确定一个不产生任何不利影响的最小数目。

5.1.5 参数文件的规划

参数文件的功能是为实例提供初始化参数。实例在启动时，将读取参数文件的内容，并且进行一些初始化的工作，如获得数据库名称，设置SGA，设置数据库操作模式等。

Oracle 11g提供了200多个初始化参数，其中只有少数初始化参数需要明确指定参数值，其余大部分参数都有默认值，如果在参数文件中没有为某个初始化参数指定参数值，数据库服务器将自动采用它的默认值。

Oracle 11g提供了两种类型的参数文件，一种是服务器端的参数文件，一种是文本参数文件。在默认情况下实例启动时，数据库服务器将读取服务器端参数文件的内容。

服务器端的参数文件是一个二进制文件，用户不能直接编辑这个文件的内容，否则可能使数据库服务器下次无法启动。有些初始化参数可以在数据库服务器运行过程中动态修改，修改的结果保存在这个参数文件中，对初始化参数修改通过命令ALTER SYSTEM完成。使用服务器端的参数文件好处是，通过ALTER SYSTEM可以很方便地修改初始化参数，这样减少了数据库服务器重新启动的次数。

文本参数文件有两个功能，一是在创建实例时为其提供初始化参数，二是在启动实例时为实例提供初始化参数。在默认情况下数据库服务器不会读这个文件，所以需要在启动实例的命令行中通过pfile选项指定一个文本参数文件。在这个文件中修改一个初始化参数的值，然后再用这个文件重新启动实例，新的参数值将起作用。对于那些不能动态修改的初始化参数，可以在文本参数文件中进行修改，然后再用这个文件重新启动实例，最后再重新创建服务器端的参数文件。

在创建实例时尚不存在服务器端的参数文件，这时需要指定一个文本参数文件，利用这个参数文件创建实例，并启动这个实例。文本参数文件默认位于Oracle安装目录的dbs子目录（UNIX/Linux系统）中，或者位于database子目录（Windows系统）中，文件的命名规则为init＜SID＞.ora，其中SID为实例的名称。如果希望使用另外一个文本参数文件，而不是默认的参数文件，需要在启动实例时通过pfile选项明确指定。

获得文本参数文件的一个简单方法是根据一个标准参数文件的内容，修改必要的参数，或者添加自己需要的参数，最后用指定的文件名保存在指定的目录即可。Oracle提供了一个模板文件，用户可以修改其中的相关内容，构造自己的参数文件。这个文件位于Oracle安装目录下，文件名为init.ora。

在服务器端参数文件和文本参数文件中，Oracle推荐使用服务器端参数文件，而且这是默认使用的参数文件。但这个文件并不自动产生，需要根据一个文本参数文件的内容来创建，创建方法是首先构造一个文本参数文件，然后用这个参数文件创建实例，并启动这个实例，最后在SQL*Plus中执行CREATE命令创建服务器端的参数文件。