项目一：计费联机详单导入
项目简介（功能与用途）：将某市全部手机用户批价后的通话详单实时导入到经营分析数据库(Oracle)中。表中沉淀纪录数约为8亿条，列数约为60列，每天新增纪录数为300-350万条，每小时导入一次。导入文件通过ftp从远端下载。
项目难点与解决方案：
难点：表中原有数据量大，导入时要求尽量减小导入开销（主要是磁盘IO）避免对其他应用的影响。
解决： 对表按月份进行分区存储，仅在三个关键列建立分区索引。因为表纪录无变长的update和insert操作，将表的PCTFREE设置成0，将表置于32K的表空间中，使用RECYCLE池缓冲，在每个月初自动一次性分配足够的磁盘空间给该分区，减小导入时磁盘IO。将ftp下载下来的数据文件分批放到Linux的tmpfs(使用RAM存储)中，进一步减少系统磁盘IO。用SQLLDR导入时采用传统路径方式进行装载，并行度设置为2。月末对该月的分区索引进行重建。
项目成功与失败的经验归纳：
利用Linux系统的内存文件系统来存放要导入的数据文件，很大程度上减小了服务器的磁盘IO，数据从内存读入，速度大大加快了。
分区表，32K表空间，一次性分配磁盘空间，RECYCLE池，并行装载，重建分区索引等充分利用Oracle提供的特性，将不必要的资源开销减少到最低程度。不使用direct方式进行装载操作，是因为，综合重建索引的开销和对其他 应用的影响，用传统方式进行导入更加合适。
你在项目中岗位与贡献：
方案确定、测试与实施。
项目二：话务统计
项目简介（功能与用途）：以某市的手机用户的通话详单为数据，结合公司对各个区县的考核目标，
每天生成考核数据，并于历史数据进行累加、比较等操作，生成数据供前台随时查用。
项目难点与解决方法：
难点：数据量大，分类繁琐，考核规则的变动性大，规则复杂。且系统中还有其他应用，数据库资源紧张。
解决方法：对数据进行分层处理，第一层为原始的话单，根据纪录中的标示列（建位图索引）区分是否与访问过，每日只对新增数据进行扫描；第二层为按原始话单和蜂窝号等条件归类后的历史数据，存放到表中进行沉淀，这一层表的集以大大减小，主要按天和月份，利用Oracle 9提供的merge语句进行更新。第三层，结合业务规则与第二层数据，每天生成物理化视图，提供给应用使用。同时将主要操作的执行计划固定下来，以提高执行的稳定性。
项目成功与失败的经验归纳：
对数据进行分层处理，将对表数据的访问量减小到最小，以减轻数据库的压力。同时中间层稳定的数据与不同的规则结合，起到了很高的弹性作用。第三层通过物理化视图的应用，缩短具体应用的查询时间，也减轻的反复查询对数据库的压力。Oracle 9i提供的merger语句对于提高中间层更新效率起到很好的作用。如此处理每天的所用更新操作能在半个小时内完成，且配置新的规则时的弹性很大。
你在项目中岗位与贡献：
方案设计，测试和实施
项目三：数据库自动管理配置
项目简介（功能与用途）：对生产系统的数据库（DB2 V8.2)，进行自动管理配置，以提高数据库执行计划最优性。
项目难点与解决方法：
众多生产数据库（近100个仓库型数据库），数据更新的不确定性（客户自行更新）及对执行效率的严格要求性，导致无法准确地确定出执行Runstats和Reorg的时间。故对数据库进行自动管理配置，主要是针对Runstats和Reorg操作，启用数据库管理服务器DAS及数据库的自动管理功能，启用数据库自动维护，数据库表自动维护，Runstats自动维护，统计数据自动维护及Reorg自动维护功能，并定义好维护时间窗口和规则，进行低级别的维护，只在数据库相对空闲时进行自动维护。而后通过查询数据库字典，得知Runstats和Reorg的执行情况，并对配置进行分析。
项目成功与失败的经验归纳：
充分利用DB2的自我维护功能，能很大程度减少人工确认数据库统计信息及对象的维护工作，且DB2的统计信息能确定出何时该进行Runstats和Reorg操作，特别是在数据库多的情况下，对提高DBA的工作效率有很大帮助。而且可以减少不必要的Runstats和Reorg操作，提高数据库的可用性
你在项目中岗位与贡献：
方案的研究，测试，确认与实施
发表于 @ 2006年07月21日 11:19:00|评论(loading...)