1、状况
    现有的各套系统运行较为稳定。但随着数据的不断增长，应用的增加，有一个比较突出的问题，就是运行速度不够理想。特别是在县公司数据合并到分公司之后，这个问题会更为突出。个人认为，从硬件的角度来看，现有的设备（MEM、CPU、磁盘阵列）可以满足目前的这些应用。从福州分公司合并数据的经验来看，在其它分公司陆续合并县公司数据后，我个人认为数据库负载过重导致速度变慢的相似情形也会随之出现。从客户的使用角度考虑，运行速度的降低，会引起客户满意度的降低，甚至对更多的新的应用系统的抵触心理。
    当然，引入J2EE架构后，公司充分注意到了优化的重要性，在新的应用（如IQS等）中，也较充分地考虑了优化的因素。
    目前我个人认为有以下几个方面可以考虑优化：
    a、现有应用的SQL优化
    b、数据存取在oracle存储方面的调整、优化
    c、数据库存储、备份的优化
    d、各应用系统接口及计划任务的优化
    e、新应用在设计阶段的优化
2、建议
    与上述状况相对应，分别有以下建议：
    a、调整、优化现有应用的SQL。现有的CRM、销售、报表等系统的SQL均存在优化余地。表的大小对SQL的执行速度是有直接的影响的。原来的应用程序开发时，并未预见到大的表（百万条记录以上）对SQL执行速度的影响。合并县公司数据后，表记录的急速增长，导致这个矛盾激化，并直接体现为应用程序运行速度的明显下降。而调整、改善现有应用程序的SQL可以减轻数据库主机的负担，起到立杆见影的效果。这个方面可以先考虑测试、调整现有应用程序的存储过程，然后再考虑优化应用程序代码。
    b、存储方面的优化。这个方面主要考虑大表的分区、频繁更新的表和静态表、临时表、索引等在存储介质上的分布，以达到更佳的I/O负载均衡。
    c、数据库存储、备份的优化。其一主要是考虑根据oracle的自身特点，调整存储参数以达到更佳的性能；其二是调整当前的全数据库导出/导入的备份策略，用更好的方案来保证数据的有效、健壮、可快速恢复。
    d、接口、计划任务的优化其实应该是第一条的一小部分。目前的应用系统繁多，接口、计划任务随之复杂。并且接口、计划任务的运行十分关键，如果非正常中断、终止，直接影响到业务上的流转。对其单独进行整理、优化很有必要。
    e、设计阶段的优化是最直接、最有效、并一劳永逸的。在设计的阶段充分考虑优化因素，并贯彻到设计的每一个环节，避免事后弥补，这是优化的重点和核心。          --==[20050308@龙岩阳光假日酒店]==--[@more@]