项目经验-冯皓洁

项目一：中国移动某省分公司

项目简介（功能与用途）：

移动网络管理，业务涉及网元设备的命令发送，和数据采集，报告分析入库，配置和性能数据的分析和汇总统计。另外还有业务数据展现，性能告警处理等。

 

项目难点与解决方案：

数据量大，每次操作的增，删，改，查的数据量都比较大，而且操作很频繁，最长间隔是1小时

 

项目成功与失败的经验归纳：

对不同操作类型的表分别对待，对于查询比较多，而增删改相对较少的表，建立适当的索引，并定期的重建索引。

合理的索引的建立和维护是一个相当重要的性能调整的手段。

对操作频繁的表采取临时表的方式，以减少日志的产生，操作完成后再将处理后的结果拷贝到固定表内。

对于不同操作性质的表，应该集中存放于独立的表空间内，并且保存在不同的物理设备上，并且根据操作性质的不同，选择不同类型的RAID

 

你在项目中岗位与贡献：

整个数据库管理都由自己独立完成，包括逻辑，物理的设计和实现，日常管理。

 

 

 

 

 

项目二：中国移动某省分公司的某地市公司

项目简介（功能与用途）：

移动网络管理，业务涉及网元设备的命令发送，和数据采集，报告分析入库，配置和性能数据的分析和汇总统计。另外还有业务数据展现，性能告警处理等。

 

项目难点与解决方法：

系统运行速度很慢，无法完成按时的性能数据的采集，并且由于删除一个大表导致数据库服务器cpu100％系统1－2天长时间无法正常使用。并且机器上空闲空间不多。

解决办法是：分批导出数据库（因为数据量很大，几百GB，并且服务器上空间很紧张），后重建数据库，导入数据，优化采集数据库表为临时表，将临时表空间移动到RAID0＋1的物理设备上。重写提取数据，和处理数据的存储过程的结构，优化存储过程里的SQL语句，使之更高效的运行。

 

项目成功与失败的经验归纳：

大数据量的数据库频繁的增删改的数据应该用临时表。

数据库表空间的建立应该选择本地化管理方式，避免字典管理的维护而导致的大量递归操作，而使数据库瘫痪。

业务逻辑里的数据处理结构和顺序，还有SQL语句的写法在很大程度上影响着执行效率。

在对存储系统的物理RAID选择上也要考虑经费和效率的兼顾，不应该只考虑保护投资而把所有磁盘只做一个大RAID5这样一个物理设备。这样将导致物理设备的竞争，和增删改方式操作数据的效率。

你在项目中岗位与贡献：

整个解决问题，和性能调整工作均自己一人完成。

 

 

 

 

 

项目三：项目名称

项目简介（功能与用途）：

某国家大型港口（前三大港口）

港口业务调动系统，管理码头货物，集装箱和货轮管理

 

项目难点与解决方法：

OPS系统，用户反应适应效率低，速度很慢。

解决办法是重新设计了数据库的物理设计，将访问性质相同的数据表归整到同一表空间。分配了数据库文件不同的锁。并将应用的不同部分的表放置到不同的数据文件。这样就实现了各实例间访问各自不同的数据，不会发生ping现象，即不会发生由于两个实例挣用一个数据是发生的磁盘交换现象，从而提高了系统运行效率

 

项目成功与失败的经验归纳：

实际情况是程序开发的时候没有考虑到应用，和不同访问性质的数据的隔离问题。OPS的应用开发和设计和单数据库实例的设计是不同的。要尽可能的将应用分开到不同的表空间，和不同的数据文件，并要给不同访问性质的数据文件分配不同数量的访问锁。并且要将不同访问类型的数据表集中在同一个表空间内。从逻辑设计，到物理设计都要避免ping的发生。而且同一个应用要固定的在固定的实例上运行，同样是保证一个实例只做一件事情，当一个实例做多个事情的时候，即做我的应用，我也做你的应用的时候就很容易发生ping的现象，从而是效率下降。

 

 

你在项目中岗位与贡献：

整个调整过程均自己独立完成