建立大型ERP产品软件的数据库优化策略
创新性应用：
1、 通过工作实践，。
根据不同模块特性制定优化目标，如SQL运行时间/数据量、数据库资源占用率等优化指标。在不同数据量和软件模块完成阶段，利用跟踪测试工具分析运行结果。并且不断验证优化效果。将程序（外模式）响应时间和数据库（模式）响应时间进行综合考虑。将数据库表、存储过程优化与程序优化和程序开发方式相结合，从整体上优化软件性能。根据各阶段优化目标，有条不紊的开展数据库优化工作。
2、利用SQL Server 2005分区表特性处理历史数据。
分区表对于Oracle可能不算是新的概念，但是微软在最新推出的SQL Server 2005才开始支持这一功能。而且由于分区表的推出，SQL Server传统的表组织结构也发生了变化：每个普通表都默认是一个分区表。根据这一特性提出“滑动窗口”概念，在处理历史数据转移时只需要修改数据库字典即可实现实时和历史数据的分离，极大的提高了数据分离的效率，并且几乎不影响数据的物理存储结构。在工作过程中根据SQL Server 2005分区表特性制定历史数据管理策略，处理软件产生的历史数据。
3、利用SQL Server 2005 的数据库快照机制快速恢复数据。
当SQL Server数据达到100G以上时，对其进行备份恢复操作非常耗时。即使使用sp_attach_db也要等待数据文件长时间的拷贝。使用SQL Server 2005 的数据库快照机制可以快速的实现数据库恢复。并且操作非常简单。在工作中对要求一致性的报表统计和实验数据的恢复都使用了这一新技术，并且取得了良好的效果。
4、利用SQL Server 2005 的Ranking 函数集实现数据分页。
在SQL Server 2005之前的SQL Server实现分页都需要预先存储在表变量或临时表中，究其原因是因为没有类似Oracle的Rownum功能，只能通过建表语句中的identity功能实现，效率比较低下。在SQL Server 2005 的Ranking 函数集中已经支持了Rownum功能，在工作中的数据库记录分页也是通过这一特性实现的。
5、利用SQL Server 2005的索引附加字段功能提高查询效率。
当一次查询涉及到的表中字段总和超过900Bytes限制的时候，以前的SQL Server版本一般都是为where谓词中的字段建立非聚集索引。这样无法实现“索引覆盖”，需要重新定位到表中检索select谓词中的字段，效率较低。在使用新特性索引附加字段后，将select谓词字段作为附加字段存储在非聚集索引树的叶子节点上，既保持了索引键更“窄”的原则，而相对于表检索又减少了I/O，因此将很大的提高查询效率。通过日常使用过程中的观察，使用索引附加字段，相比传统的非“索引覆盖”索引效率平均提高20%-30%左右。
6、利用SQL Server 2005的T-SQL功能扩展实现更优雅的开发。
在利用SQL Server 2005的T-SQL中新提供的诸如Try-Catch错误处理、CTE、APPLY等机制，为T-SQL的开发提供了更优雅的实现。不光带来了现代开发语言的气息而且增加了程序可读性和严谨性。
行业借鉴经验：
1、数据库优化的关键在数据库设计。
数据库物理设计是影响数据库软件性能的重要因素，而在设计开发阶段优化数据库也是一个难点。数据库的优化工作应该在需求设计阶段就开始着手。请需求人员说明模块的主要应用场景和今后大致的数据量。在做数据库物理设计的时候充分考虑这些因素，并结合所使用的DBMS特性，设计性能优良的数据库。因为系统并没有经过用户的检验，无法得知存在的性能瓶颈。所以必须通过不同数据量的反复测试找出“热表”等性能瓶颈，并相应做出调整，再进行检验。整个数据库优化过程是一个迭代的过程，要求数据库优化人员不但要有丰富的数据库和软件开发经验而且要有足够的耐心和对细节的敏锐观察。在开发阶段解决大部分的数据库性能问题，不光节约了软件投入使用后的修改成本，而且对提升客户满意度也有着重要的意义。
2、OLTP和DSS应用中表的设计。
OLTP系统的主要特点是对表频繁的DML操作，而大规模统计查询较少。为了保证数据的逻辑完整性，会利用数据库锁频繁锁定表或其中的记录。根据这一特点，在设计表的时候应该尽量提高范式级别，使表更“窄”，以减少每次锁定的范围。必要的时候可以将一个完整的业务实体进行纵向分割，将频繁更新的字段分布到更多的表中存储。对于Oracle这种采用乐观锁事务隔离级别的DBMS系统，锁阻塞的几率会较少。但是对于早期SQL Server几乎全部是悲观锁事务隔离级别的DBMS系统，对表的纵向拆分就显得非常重要了。
DSS系统主要以查询统计为主。对于这种系统可以适当降低范式级别，将可能会频繁关联查询的表组合在一个表中，减少频繁关联查询所带来的CPU等资源消耗。并且可以根据DBMS类型的不同，适当的使用实体化视图（Oracle）或索引视图（SQL Server）来缓存统计结果，加快统计速度。
3、利用存储过程提高效率和方便DBMS迁移。
存储过程可以减少客户端与数据库之间的交互次数，提高批处理和数据库端业务算法的性能。而且存储过程作为DBMS的全局变量存储，相比常规SQL减少了SQL语句的解析编译时间。使用存储过程是提高数据库效率的重要手段，而且能够提高后期维护人员修改软件Bug的效率。
目前有的应用系统为了减少数据库移植带来的麻烦，尽量避免使用存储过程。这种做法是值得商榷的，其带来的直接后果就是系统性能低下。在工作负荷较轻的系统中可能影响并不明显，但是在需要频繁进行复杂数据库运算的系统中，这种负面影响是很容易暴露出来的。正确的做法是，在系统中如果使用到某种DBMS系统特定函数时，应该将其相关算法作为存储过程存储在数据库中，然后由前端程序调用该存储过程。程序代码（或O/R Mapping）中只包含符合SQL标准的SQL语句。当需要更换DBMS系统时，可以由DBA对存储过程进行集中翻译或者通过相关软件批量完成这一工作。在国外一些成熟的软件系统中存储过程的数量有时会超过数据库中表的数量。
4、杜绝数据库对象使用DBMS关键字命名。
在进行数据库物理设计之前，应该首先规范数据库对象的命名规则。表、视图等对象利用前缀能够很好的避免使用DBMS关键字。但是字段很少采用前缀命名，一般都是采用英文或其缩写命名。这种做法很容易导致字段命名使用到DBMS关键字或保留字。这将为今后系统的运行带来隐患。本人在至少三个软件系统中遇到过字段命名使用关键字所引发的Bug。而且一旦发生Bug很难查找，修改的时候也会带来很多连带修改。
应用难点技巧：
1、动态传入参数：
EXECUTE sp_executesql
N'SELECT * FROM AdventureWorks.HumanResources.Employee
WHERE ManagerID = @level',
N'@level tinyint',
@level = 109;
2、动态传出参数：
declare @OutCount int
EXECUTE sp_executesql
N'select @InCount=count(*)
from sys.tables',
N'@InCount int output',
@InCount=@OutCount output;
select @OutCount
3、使用表变量得到动态SQL结果集：
Declare @MinID bigint
Declare @MaxID bigint
Declare @strSelect NVarchar(255)
Declare @SourceTableName NVarchar(255)
Set @strSelect = 'Select Min(ID),Max(ID) From ' + @SourceTableName
--声明表变量，其效率要高于临时表
DECLARE @TempTable TABLE(MinCount BIGINT,MaxCount BIGINT);
INSERT INTO @TempTable(MinCount,MaxCount) execute SP_Executesql @strSelect;
select @MinID=MinCount,
@MaxID=MaxCount
from @TempTable;
项目一：项目名称
项目简介（功能与用途）：
用友新一代ERP产品U9。替代U8的下一代ERP产品。
后台数据库：SQL Server 2005/Oracle
项目难点与解决方案：
难点：开发产品软件，要求在产品上市之前必须保证产品的性能和健壮性。而作为综合性的大型ERP软件，其中表、存储过程等数据库对象众多，同时具有OLTP和DSS特性。要求数据库设计、优化人员在评审业务设计人员设计书时，要根据应用场景和今后可能发生的大数据量，应用数据库的特性进行优化设计，并且考虑今后业务的功能扩展和多数据库平台的支持。
解决方案：根据数据库设计理论和应用场景，对表进行优化设计。制定优化目标，通过不同数据量的迭代测试过程，观察数据库响应时间，做出相应调整。对OLTP和DSS应用部分分别设计。对数据量庞大的表采取历史、实时数据分别处理策略等。
项目成功与失败的经验归纳：
制定优化目标，通过不同数量级的应用Demo检验产品的健壮性和性能是最根本的方法。制定严格的规范，保证产品的规范性。优化工作最忌无目标的盲目优化。在保证性能的前提下，为了管理和开发工作提供最优雅的实现。
你在项目中岗位与贡献：
岗位：数据库专家
贡献：负责整个U9产品的数据库设计优化工作。制定数据库设计、开发规范。评审设计人员的数据库物理设计，并做出优化建议。为200人的专职开发团队提供数据库技术解决方案和数据库技术培训。管理核心开发数据库。
项目二：项目名称
项目简介（功能与用途）：
江西省发电监控系统。监控发电设备的实时运转情况。
后台数据库：Oracle9i
项目难点与解决方案：
难点：24*7不间断工作系统。数据量大，每天要入库1000万条以上的记录。并且要求较高的实时性统计汇总。
解决方案：采用Oracle Guard，将归档的重做日志从primary database数据库异步写到standby database数据库来使primary database数据库在极少损失性能的前提下，最小化地减少数据的丢失。在primary database数据库发生异常的时候，自动切换到standby database上。在standby database上进行统计汇总，减少primary database数据库的压力。
项目成功与失败的经验归纳：
由于项目初期对数据量估计不足，硬件环境较差。在用户要求扩展业务而数据量激增的时候，原有环境无法满足运营需求，再次增加硬件设备才使系统正常运转。
你在项目中岗位与贡献：
岗位：数据库优化人员
贡献：在无法从优化数据库设计角度改善性能的前提下，建议增加硬件设备。选择Oracle Guard作为解决方案。培训相关实施人员。
项目三：项目名称
项目简介（功能与用途）：
辽宁省电力CRM管理系统。从省级公司监控各地级市的CRM运转状况。属于典型的分布-集中式数据库系统。
后台数据库：Oracle9i/SQL Server 2000
项目难点与解决方案：
难点：从省级公司监控各地级市公司的CRM数据，由于数据库分处各市，集成商和数据库平台不同对数据集中存在很大的难度。其中的数据库涉及：SQL Server6.5-2000、Oracle8i-9i、sybase11.5。没有购买第三方软件，完全依赖数据库功能实现。
解决方案：对网络条件较差或Unix平台的地级市，采取自动ftp上传格式化文本文件，再使用Oracle的SQL Loader自动导入数据库；对网络条件较好并且数据量较少的地级市采用SQL Server 2000的DTS功能自动传输数据。
在省级公司（中央数据库）设计分区表，为了防止主键重复，对不同地区采取地区主键+地区号的复合主键策略。根据各地不同的统计规则，利用Oracle包提供的多态函数特性，实现参数多样，独立管理。对历史数据及时归档到历史数据库，保证实时数据库快速查询，缩短备份恢复时间。在SQL Server和Oracle之间建立异构数据库通讯机制。
项目成功与失败的经验归纳：
对分布集中式数据库的处理，要建立完备的文档管理，并且在对某个点集中数据前，要预估网络物理条件和需要传输的数据量大小。直接连接的数据库要规定好访问用户的权限、资源设定，防止数据集中对各点数据库的安全、性能带来影响。原来采用了SQL Server的复制\发布功能，但是由于健壮性不够，并且耗时过长，最后弃用。
你在项目中岗位与贡献：
岗位：数据集中策略设计者
贡献：对各点采用不同集中策略。评估可行性，并且应用不同数据库技术实现数据集中功能。
项目四：项目名称
项目简介（功能与用途）：
山西省电力公司MIS系统。主要用于控制管理电力设备，为管理人员提供最新的设备运营信息。
后台数据库：Oracle9i
项目难点与解决方案：
难点：数据量较大，业务功能算法比较复杂，使用PL/SQL实现比较复杂，即使满足也容易破坏算法的严谨性，同时与数据库数据交互较多。而且要求在数据库实现文件和网页的检索功能。
解决方案：由于业务实现需要堆栈、二叉树链表等高级数据结构较多，于是采用了Oracle提供的Java存储过程。虽然正确的评估了Java对象的运行需求内存，并相应的配置了Oracle的Java池。但是在Java存储过程达到一定的阀值后（根据Java对象的算法复杂程度）系统的CPU资源占用急剧升高，更新到最新的补丁也无济于事。查看Oracle的MetaLink没有找到相关答案。最后适当减少Java存储过程数量后，系统正常。
对数据库要求提供检索网页和文件的功能实现，主要依靠Oracle9i提供的UltraSearch功能。UltraSearch功能能够提供对文件和网页的检索功能，可以通过其自身的Web页面进行展现也可以自行编写展现程序。由于属于Oracle比较新的功能，Bug较多。需要至少升级到9.2.0.5才能正常使用。而且要求数据库是UTF8模式。
项目成功与失败的经验归纳：
在没有试用评估某种新功能之前就贸然用于生产系统是有很大风险的。对复杂功能的实现除非必要，不要大规模使用Java存储过程。目前新上市的SQL Server 2005所提供的.Net数据库对象也应该在压力测试通过的前提下谨慎使用。
在应用之前最好准备几种备选方案，当首选方案无法实现的情况下，采取其他方案进行弥补。
你在项目中岗位与贡献：
岗位：数据库DBA
贡献：主要负责数据库SGA参数配置，UltraSearch等新技术的配置实现。
项目五：项目名称
项目简介（功能与用途）：
鞍山市电力MIS系统。主要用于电力企业信息管理。
后台数据库：SQL Server 7.0
项目难点与解决方案：
难点：这个系统的并发性和数据量并不算大（百万级）。但是由于原来数据库设计人员过于遵循了数据库的范式理论，导致程序员在开发阶段需要频繁进行关联表操作。在数据量不大（百万级）的情况下，程序运行非常缓慢。
解决方案：通过调试较慢的存储过程和程序，发现在关联多表查询的时候，由于没有设定足够的where条件，导致查询语句产生笛卡尔积，原本应该得到百万级的记录，却返回了数亿级的重复记录。由于最后的语句进行了distinct过滤，程序开发人员没有发现在中间执行过程中的笛卡尔积问题。为查询语句加上足够的where过滤条件，消除了查询中的笛卡尔积。
笛卡尔积现象出现的根本原因是由于表设计过于分散，而且为程序开发人员开发上带来了很大的麻烦。将类似于档案表等静态信息表从3NF适当回退到2NF，冗于了需要频繁关联的字段。系统性能得到提升。
项目成功与失败的经验归纳：
数据库物理设计时一定要考虑是否能够方便前端的程序开发。应该将数据库设计和程序开发作为整体全盘考虑。
你在项目中岗位与贡献：
岗位：数据库DBA
贡献：解决Bug，修改原来的数据库设计。
1、 通过工作实践，。
根据不同模块特性制定优化目标，如SQL运行时间/数据量、数据库资源占用率等优化指标。在不同数据量和软件模块完成阶段，利用跟踪测试工具分析运行结果。并且不断验证优化效果。将程序（外模式）响应时间和数据库（模式）响应时间进行综合考虑。将数据库表、存储过程优化与程序优化和程序开发方式相结合，从整体上优化软件性能。根据各阶段优化目标，有条不紊的开展数据库优化工作。
2、利用SQL Server 2005分区表特性处理历史数据。
分区表对于Oracle可能不算是新的概念，但是微软在最新推出的SQL Server 2005才开始支持这一功能。而且由于分区表的推出，SQL Server传统的表组织结构也发生了变化：每个普通表都默认是一个分区表。根据这一特性提出“滑动窗口”概念，在处理历史数据转移时只需要修改数据库字典即可实现实时和历史数据的分离，极大的提高了数据分离的效率，并且几乎不影响数据的物理存储结构。在工作过程中根据SQL Server 2005分区表特性制定历史数据管理策略，处理软件产生的历史数据。
3、利用SQL Server 2005 的数据库快照机制快速恢复数据。
当SQL Server数据达到100G以上时，对其进行备份恢复操作非常耗时。即使使用sp_attach_db也要等待数据文件长时间的拷贝。使用SQL Server 2005 的数据库快照机制可以快速的实现数据库恢复。并且操作非常简单。在工作中对要求一致性的报表统计和实验数据的恢复都使用了这一新技术，并且取得了良好的效果。
4、利用SQL Server 2005 的Ranking 函数集实现数据分页。
在SQL Server 2005之前的SQL Server实现分页都需要预先存储在表变量或临时表中，究其原因是因为没有类似Oracle的Rownum功能，只能通过建表语句中的identity功能实现，效率比较低下。在SQL Server 2005 的Ranking 函数集中已经支持了Rownum功能，在工作中的数据库记录分页也是通过这一特性实现的。
5、利用SQL Server 2005的索引附加字段功能提高查询效率。
当一次查询涉及到的表中字段总和超过900Bytes限制的时候，以前的SQL Server版本一般都是为where谓词中的字段建立非聚集索引。这样无法实现“索引覆盖”，需要重新定位到表中检索select谓词中的字段，效率较低。在使用新特性索引附加字段后，将select谓词字段作为附加字段存储在非聚集索引树的叶子节点上，既保持了索引键更“窄”的原则，而相对于表检索又减少了I/O，因此将很大的提高查询效率。通过日常使用过程中的观察，使用索引附加字段，相比传统的非“索引覆盖”索引效率平均提高20%-30%左右。
6、利用SQL Server 2005的T-SQL功能扩展实现更优雅的开发。
在利用SQL Server 2005的T-SQL中新提供的诸如Try-Catch错误处理、CTE、APPLY等机制，为T-SQL的开发提供了更优雅的实现。不光带来了现代开发语言的气息而且增加了程序可读性和严谨性。
行业借鉴经验：
1、数据库优化的关键在数据库设计。
数据库物理设计是影响数据库软件性能的重要因素，而在设计开发阶段优化数据库也是一个难点。数据库的优化工作应该在需求设计阶段就开始着手。请需求人员说明模块的主要应用场景和今后大致的数据量。在做数据库物理设计的时候充分考虑这些因素，并结合所使用的DBMS特性，设计性能优良的数据库。因为系统并没有经过用户的检验，无法得知存在的性能瓶颈。所以必须通过不同数据量的反复测试找出“热表”等性能瓶颈，并相应做出调整，再进行检验。整个数据库优化过程是一个迭代的过程，要求数据库优化人员不但要有丰富的数据库和软件开发经验而且要有足够的耐心和对细节的敏锐观察。在开发阶段解决大部分的数据库性能问题，不光节约了软件投入使用后的修改成本，而且对提升客户满意度也有着重要的意义。
2、OLTP和DSS应用中表的设计。
OLTP系统的主要特点是对表频繁的DML操作，而大规模统计查询较少。为了保证数据的逻辑完整性，会利用数据库锁频繁锁定表或其中的记录。根据这一特点，在设计表的时候应该尽量提高范式级别，使表更“窄”，以减少每次锁定的范围。必要的时候可以将一个完整的业务实体进行纵向分割，将频繁更新的字段分布到更多的表中存储。对于Oracle这种采用乐观锁事务隔离级别的DBMS系统，锁阻塞的几率会较少。但是对于早期SQL Server几乎全部是悲观锁事务隔离级别的DBMS系统，对表的纵向拆分就显得非常重要了。
DSS系统主要以查询统计为主。对于这种系统可以适当降低范式级别，将可能会频繁关联查询的表组合在一个表中，减少频繁关联查询所带来的CPU等资源消耗。并且可以根据DBMS类型的不同，适当的使用实体化视图（Oracle）或索引视图（SQL Server）来缓存统计结果，加快统计速度。
3、利用存储过程提高效率和方便DBMS迁移。
存储过程可以减少客户端与数据库之间的交互次数，提高批处理和数据库端业务算法的性能。而且存储过程作为DBMS的全局变量存储，相比常规SQL减少了SQL语句的解析编译时间。使用存储过程是提高数据库效率的重要手段，而且能够提高后期维护人员修改软件Bug的效率。
目前有的应用系统为了减少数据库移植带来的麻烦，尽量避免使用存储过程。这种做法是值得商榷的，其带来的直接后果就是系统性能低下。在工作负荷较轻的系统中可能影响并不明显，但是在需要频繁进行复杂数据库运算的系统中，这种负面影响是很容易暴露出来的。正确的做法是，在系统中如果使用到某种DBMS系统特定函数时，应该将其相关算法作为存储过程存储在数据库中，然后由前端程序调用该存储过程。程序代码（或O/R Mapping）中只包含符合SQL标准的SQL语句。当需要更换DBMS系统时，可以由DBA对存储过程进行集中翻译或者通过相关软件批量完成这一工作。在国外一些成熟的软件系统中存储过程的数量有时会超过数据库中表的数量。
4、杜绝数据库对象使用DBMS关键字命名。
在进行数据库物理设计之前，应该首先规范数据库对象的命名规则。表、视图等对象利用前缀能够很好的避免使用DBMS关键字。但是字段很少采用前缀命名，一般都是采用英文或其缩写命名。这种做法很容易导致字段命名使用到DBMS关键字或保留字。这将为今后系统的运行带来隐患。本人在至少三个软件系统中遇到过字段命名使用关键字所引发的Bug。而且一旦发生Bug很难查找，修改的时候也会带来很多连带修改。
应用难点技巧：
1、动态传入参数：
EXECUTE sp_executesql
N'SELECT * FROM AdventureWorks.HumanResources.Employee
WHERE ManagerID = @level',
N'@level tinyint',
@level = 109;
2、动态传出参数：
declare @OutCount int
EXECUTE sp_executesql
N'select @InCount=count(*)
from sys.tables',
N'@InCount int output',
@InCount=@OutCount output;
select @OutCount
3、使用表变量得到动态SQL结果集：
Declare @MinID bigint
Declare @MaxID bigint
Declare @strSelect NVarchar(255)
Declare @SourceTableName NVarchar(255)
Set @strSelect = 'Select Min(ID),Max(ID) From ' + @SourceTableName
--声明表变量，其效率要高于临时表
DECLARE @TempTable TABLE(MinCount BIGINT,MaxCount BIGINT);
INSERT INTO @TempTable(MinCount,MaxCount) execute SP_Executesql @strSelect;
select @MinID=MinCount,
@MaxID=MaxCount
from @TempTable;
项目一：项目名称
项目简介（功能与用途）：
用友新一代ERP产品U9。替代U8的下一代ERP产品。
后台数据库：SQL Server 2005/Oracle
项目难点与解决方案：
难点：开发产品软件，要求在产品上市之前必须保证产品的性能和健壮性。而作为综合性的大型ERP软件，其中表、存储过程等数据库对象众多，同时具有OLTP和DSS特性。要求数据库设计、优化人员在评审业务设计人员设计书时，要根据应用场景和今后可能发生的大数据量，应用数据库的特性进行优化设计，并且考虑今后业务的功能扩展和多数据库平台的支持。
解决方案：根据数据库设计理论和应用场景，对表进行优化设计。制定优化目标，通过不同数据量的迭代测试过程，观察数据库响应时间，做出相应调整。对OLTP和DSS应用部分分别设计。对数据量庞大的表采取历史、实时数据分别处理策略等。
项目成功与失败的经验归纳：
制定优化目标，通过不同数量级的应用Demo检验产品的健壮性和性能是最根本的方法。制定严格的规范，保证产品的规范性。优化工作最忌无目标的盲目优化。在保证性能的前提下，为了管理和开发工作提供最优雅的实现。
你在项目中岗位与贡献：
岗位：数据库专家
贡献：负责整个U9产品的数据库设计优化工作。制定数据库设计、开发规范。评审设计人员的数据库物理设计，并做出优化建议。为200人的专职开发团队提供数据库技术解决方案和数据库技术培训。管理核心开发数据库。
项目二：项目名称
项目简介（功能与用途）：
江西省发电监控系统。监控发电设备的实时运转情况。
后台数据库：Oracle9i
项目难点与解决方案：
难点：24*7不间断工作系统。数据量大，每天要入库1000万条以上的记录。并且要求较高的实时性统计汇总。
解决方案：采用Oracle Guard，将归档的重做日志从primary database数据库异步写到standby database数据库来使primary database数据库在极少损失性能的前提下，最小化地减少数据的丢失。在primary database数据库发生异常的时候，自动切换到standby database上。在standby database上进行统计汇总，减少primary database数据库的压力。
项目成功与失败的经验归纳：
由于项目初期对数据量估计不足，硬件环境较差。在用户要求扩展业务而数据量激增的时候，原有环境无法满足运营需求，再次增加硬件设备才使系统正常运转。
你在项目中岗位与贡献：
岗位：数据库优化人员
贡献：在无法从优化数据库设计角度改善性能的前提下，建议增加硬件设备。选择Oracle Guard作为解决方案。培训相关实施人员。
项目三：项目名称
项目简介（功能与用途）：
辽宁省电力CRM管理系统。从省级公司监控各地级市的CRM运转状况。属于典型的分布-集中式数据库系统。
后台数据库：Oracle9i/SQL Server 2000
项目难点与解决方案：
难点：从省级公司监控各地级市公司的CRM数据，由于数据库分处各市，集成商和数据库平台不同对数据集中存在很大的难度。其中的数据库涉及：SQL Server6.5-2000、Oracle8i-9i、sybase11.5。没有购买第三方软件，完全依赖数据库功能实现。
解决方案：对网络条件较差或Unix平台的地级市，采取自动ftp上传格式化文本文件，再使用Oracle的SQL Loader自动导入数据库；对网络条件较好并且数据量较少的地级市采用SQL Server 2000的DTS功能自动传输数据。
在省级公司（中央数据库）设计分区表，为了防止主键重复，对不同地区采取地区主键+地区号的复合主键策略。根据各地不同的统计规则，利用Oracle包提供的多态函数特性，实现参数多样，独立管理。对历史数据及时归档到历史数据库，保证实时数据库快速查询，缩短备份恢复时间。在SQL Server和Oracle之间建立异构数据库通讯机制。
项目成功与失败的经验归纳：
对分布集中式数据库的处理，要建立完备的文档管理，并且在对某个点集中数据前，要预估网络物理条件和需要传输的数据量大小。直接连接的数据库要规定好访问用户的权限、资源设定，防止数据集中对各点数据库的安全、性能带来影响。原来采用了SQL Server的复制\发布功能，但是由于健壮性不够，并且耗时过长，最后弃用。
你在项目中岗位与贡献：
岗位：数据集中策略设计者
贡献：对各点采用不同集中策略。评估可行性，并且应用不同数据库技术实现数据集中功能。
项目四：项目名称
项目简介（功能与用途）：
山西省电力公司MIS系统。主要用于控制管理电力设备，为管理人员提供最新的设备运营信息。
后台数据库：Oracle9i
项目难点与解决方案：
难点：数据量较大，业务功能算法比较复杂，使用PL/SQL实现比较复杂，即使满足也容易破坏算法的严谨性，同时与数据库数据交互较多。而且要求在数据库实现文件和网页的检索功能。
解决方案：由于业务实现需要堆栈、二叉树链表等高级数据结构较多，于是采用了Oracle提供的Java存储过程。虽然正确的评估了Java对象的运行需求内存，并相应的配置了Oracle的Java池。但是在Java存储过程达到一定的阀值后（根据Java对象的算法复杂程度）系统的CPU资源占用急剧升高，更新到最新的补丁也无济于事。查看Oracle的MetaLink没有找到相关答案。最后适当减少Java存储过程数量后，系统正常。
对数据库要求提供检索网页和文件的功能实现，主要依靠Oracle9i提供的UltraSearch功能。UltraSearch功能能够提供对文件和网页的检索功能，可以通过其自身的Web页面进行展现也可以自行编写展现程序。由于属于Oracle比较新的功能，Bug较多。需要至少升级到9.2.0.5才能正常使用。而且要求数据库是UTF8模式。
项目成功与失败的经验归纳：
在没有试用评估某种新功能之前就贸然用于生产系统是有很大风险的。对复杂功能的实现除非必要，不要大规模使用Java存储过程。目前新上市的SQL Server 2005所提供的.Net数据库对象也应该在压力测试通过的前提下谨慎使用。
在应用之前最好准备几种备选方案，当首选方案无法实现的情况下，采取其他方案进行弥补。
你在项目中岗位与贡献：
岗位：数据库DBA
贡献：主要负责数据库SGA参数配置，UltraSearch等新技术的配置实现。
项目五：项目名称
项目简介（功能与用途）：
鞍山市电力MIS系统。主要用于电力企业信息管理。
后台数据库：SQL Server 7.0
项目难点与解决方案：
难点：这个系统的并发性和数据量并不算大（百万级）。但是由于原来数据库设计人员过于遵循了数据库的范式理论，导致程序员在开发阶段需要频繁进行关联表操作。在数据量不大（百万级）的情况下，程序运行非常缓慢。
解决方案：通过调试较慢的存储过程和程序，发现在关联多表查询的时候，由于没有设定足够的where条件，导致查询语句产生笛卡尔积，原本应该得到百万级的记录，却返回了数亿级的重复记录。由于最后的语句进行了distinct过滤，程序开发人员没有发现在中间执行过程中的笛卡尔积问题。为查询语句加上足够的where过滤条件，消除了查询中的笛卡尔积。
笛卡尔积现象出现的根本原因是由于表设计过于分散，而且为程序开发人员开发上带来了很大的麻烦。将类似于档案表等静态信息表从3NF适当回退到2NF，冗于了需要频繁关联的字段。系统性能得到提升。
项目成功与失败的经验归纳：
数据库物理设计时一定要考虑是否能够方便前端的程序开发。应该将数据库设计和程序开发作为整体全盘考虑。
你在项目中岗位与贡献：
岗位：数据库DBA
贡献：解决Bug，修改原来的数据库设计。