Oracle数据库专家项目开发经验 之八(2006中国杰出数据库工程师评选)
项目简介（功能与用途）：
湖南移动通信公司业务运营支持系统（BOSS SYSTEM）系统是整合营业、计费、结算、账务、收费等业务，实现"以客户为中心、业务的开发和管理面向客户、网络管理面向业务"的运营原则，大大提高企业的营销和服务水平的核心业务支撑系统。
项目难点与解决方案：
BOSS系统从2003年初开始陆续上线，营帐系统在上线运行后出现性能问题。主要表现在对最终用户的交互响应不如预期，尤其在业务繁忙时更是无法得到及时的交互响应。从主机（AIX）系统上观察，主要表现在系统的I/O等待较大。营帐系统是由业务应用程序，Oracle数据库，AIX主机，IBM ESS存储多个部分组成，因此性能瓶颈的定位和性能的优化都比较复杂。
该项目的难点主要由以下几点：
1，湖南移动通信BOSS SYSTEM系统是一个大型的复杂系统。在这个系统中从上至下包括以下几个层次：应用程序、数据库、主机系统（操作系统）、SAN网络和ESS存储系统。在发生系统的性能问题时，性能问题的定位和调优就很复杂。
2，数据库容量大，整个数据容量有约2120GB，整个数据的迁移需要几十个小时的时间，而在生产系统上是不允许有很长的停机时间进行数据迁移。
3，湖南移动BOSS系统是7×24的应用，不允许停机。
4，应用中部分SQL语句非常复杂，而且SQL语句的写法和谓词等方面使用不当，直接造成低效率的SQL运行，占用系统I/O和内存，需要找出这些SQL语句并对之进行调整。
5，需要对Oracle数据库部分参数作出调整。
6，需要对操作系统内核参数作出调整。
7，需要对数据库的数据在ESS存储上的物理分布重新调整。
对于上述问题，分别采用了如下解决方案：
1，针对湖南移动BOSS SYSTEM系统出现的性能问题，根据湖南移动BOSS SYSTEM系统的实际应用, 借助ESS Expert和Precise等性能监测工具软件，对主机系统和存储进行了监控，调整和优化，同时对Oracle数据库和应用系统提出调优建议。
项目分为以下几个阶段：
· 检查BOSS SYSTEM系统中所有硬件系统，特别是SAN网络中的硬件。
· 检查SAN交换机的数据流量，观察是否有通道流量不对称、数据包丢失或数据传输过程中有效验错的问题。
· 分析ESS上的数据分布，安装和配置ESS Expert监测软件，观察是否存在有FC通道、cluster、SSA卡或SSA loop负载不平均的现象。
· 检查并优化主机系统上AIX运行的参数，使之适合SYSTEM系统的运行。
· 安装和配置Precise Indepth for Oracle软件，检查ORACLE数据库的参数设置，确定最影响性能的应用程序，协助软件开发商优化应用程序。
· 两次调整在ESS存储系统上的数据分布，并通过StorWatch EXPERT软件监测ESS存储系统的性能表现；
· 利用Precise软件监测数据库和应用对系统资源的占用，对主机系统作进一步的调优，并提出对Oracle 数据库和应用程序的调优建议；
· 性能瓶颈的定位
一般的调优策略如下：
在湖南移动的调优中，在数据库的设计和应用设计不做更改的前提下，首先，对IBM存储系统和主机系统作深入细致的参数和配置调整。同时，在湖南移动计费中心技术人员的全力配合下，对ESS存储系统上的数据分布作了大规模的调整，并且通过Precise软件对Oracle数据库性能参数的监控，定位对系统CPU, I/O等资源消耗严重的瓶颈，对Oracle数据库和应用系统提出性能调优建议。 2，针对应用的性能状况，修改Oracle的性能参数。
ü cursor_sharing的值从exact改为force, 减少internal lock wait.
ü spin_count的值从2000调整到5000。
· 根据Precise的监测和分析结果，检查资源消耗最大SQL语句的逻辑设计，将排名靠前SQL语句的表数据与索引分别存储，建立合适的分区索引，提高资源消耗靠前SQL语句的并行度。
· 通过StorWatch Expert软件持续监控ESS的使用，掌握ESS的性能表现和使用状况。
· 通过Precise软件对Oracle和应用有限数据的分析，确定当前应用系统并没有达到理想的运行状态，建议对应用系统作相应的检查和调整。同时，为了更准确定位应用问题所在，建议收集更长时间的数据，再进行更深入的分析。
3，调整数据在ESS上的分布。
首先将数据平均地分布在两个cluster上，之后将数据分布在尽可能多的通道上。
由于整个数据容量有约2120GB，整个数据的迁移需要几十个小时的时间，而在生产系统上是不允许有很长的停机时间进行数据迁移。
根据多个方案的论证对比，决定采用逻辑卷镜像的方案实施数据迁移。具体的步骤是先将所有的逻辑卷在目的的硬盘上建立镜像、同步数据、再将原硬盘上的镜像部分删除。整个数据迁移工作全部在系统的后台进行，共进行了60个小时，完成所有数据迁移。
4，对操作系统内核参数作出调整
· 对vmtune的参数进行调整如下：
-p -P -r -R -f -F -N -W
minperm maxperm minpgahead maxpgahead minfree maxfree pd_npages maxrandwrt
396414 792828 0 0 960 1024 65536 1
-M -w -k -c -b -B -u -l -d
maxpin npswarn npskill numclust numfsbufs hd_pbuf_cnt lvm_bufcnt lrubucket defps
3250555 65536 16384 16 2048 2656 9 131072 1
-s -n -S -L -g -h
sync_release_ilock nokilluid v_pinshm lgpg_regions lgpg_size strict_maxperm
1 0 0 0 0 0
-t -j -J -z
maxclient j2_nPagesPer j2_maxRandomWrite j2_nRandomCluster
792828 32 0 0
-Z -q -Q -y
j2_nBufferPer j2_minPageReadAhead j2_maxPageReadAhead memory_affinity
512 2 8 0
-V -i
num_spec_dataseg spec_dataseg_int
0 512
PTA balance threshold percentage = 50.0%
number of valid memory pages = 4063193 maxperm=20.0% of real memory
maximum pinable=80.0% of real memory minperm=10.0% of real memory
number of file memory pages = 1955960 numperm=49.3% of real memory
number of compressed memory pages = 0 compressed=0.0% of real memory
number of client memory pages = 0 numclient=0.0% of real memory
# of remote pgs sched-pageout = 0 maxclient=20.0% of real memory
· 对schedtune参数的调整如下：
THRASH SUSP FORK SCHED
-h -p -m -w -e -f -d -r -t -s
SYS PROC MULTI WAIT GRACE TICKS SCHED_D SCHED_R TIMESLICE MAXSPIN
0 4 2 1 2 10 16 16 1 8192
CLOCK SCHED_FIFO2 IDLE MIGRATION FIXED_PRI
-c -a -b -F
%usDELTA AFFINITY_LIM BARRIER/16 GLOBAL(1)
100 7 4 0
红色的为要调整的值。
5，检查资源消耗最大语句的逻辑设计。
l 建立合适的分区索引
l 将排名靠前语句的表数据与索引分别存储。
l 提高资源消耗靠前语句的并行度。
l Oracle 的参数cursor_sharing设为force减少internal lock wait
l 调整Latch的数量(如DB_BLOCK_LRU_LATCHES)或内存的一些参数(如SHARED_POOL_SIZE等)解决内部锁问题。
6，由于数据存储调整后，系统I/O性能状况良好，系统和存储端的性能表现已调整至最佳，系统和存储端的性能调优工作已经完成。建议客户下一步的工作重点是解决应用系统的性能瓶颈，结合Precise对应用的监控结果，检查应用的逻辑设计，数据索引的建立和分布。协助应用开发商修改应用。
7，调整操作系统交换空间（page space）。
项目成功与失败的经验归纳：
在湖南移动BOSS系统的性能调优中，项目的成功经验有以下几点：
1． 数据库前期的合理的架构设计（物理设计和逻辑设计）是整个项目成败的关键，合理的架构设计为整个项目稳定可靠高效运行打下了良好的基础，同时也起到了事半功倍的作用。在湖南移动BOSS系统中就是因为数据库在ESS物理存储的不合理分布而直接导致了系统的I/O瓶颈。
2． 根据系统的物理资源，对数据库的配置参数和操作系统内核参数做合理的调整，保证系统物理资源（CPU,I/O，内存和网络）和逻辑资源（裸设备，文件系统等）合理的分布和应用。
3． 要善于借助于第三方的监控软件（如：StorWatch Expert和Precise软件），这些软件的运用可以快速的定位性能瓶颈从而更快速的作出性能调整。
4． 检查资源消耗最大SQL语句的逻辑设计，将排名靠前SQL语句的表数据与索引分别存储，建立合适的分区索引，提高资源消耗靠前SQL语句的并行度。很多性能瓶颈往往是由于“恶劣”的SQL造成的。
5． 要有一个很好的性能调整流程和性能调整方法步骤，循序渐进，一步一步定位，逐步缩小范围，知道最后定位性能瓶颈。
6． 要善于团队合作，在整个性能调整中，我负责软件调整，要和硬件调整，网络调整的技术人员通力合作。
7． 性能调整是全局的工作，涉及应用开发，中间件，数据库，操作系统，存储，网络等。需要对全局的信息架构有清晰的认识。
你在项目中岗位与贡献：
在湖南移动BOSS系统的性能调整中，我是以IBM技术顾问身份参与性能调整的，主要负责对Oracle数据库配置参数的调整；负责完成数据库后期的性能监控，性能调优；负责检查资源消耗最大SQL语句的逻辑设计，将排名靠前SQL语句的表数据与索引分别存储，建立合适的分区索引，提高资源消耗靠前SQL语句的并行度。负责在操作系统层面定位性能瓶颈（CPU,内存，I/O和网络瓶颈）并调整操作系统内核参数。负责协助开发人员对应用开发作出修改和SQL性能调整。
留章兴项目一：计费联机详单导入 本文出自 51CTO.COM技术博客项目简介（功能与用途）：将某市全部手机用户批价后的通话详单实时导入到经营分析数据库(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操作，提高数据库的可用性 你在项目中岗位与贡献： 方案的研究，测试，确认与实施 |