服务热线：4006-981-828
|
Oracle数据库健康检查手册
一、系统概况
天日志生成量高峰、时日志切换高峰:这里的高峰指的是redo生成高峰，非业务高峰。 全库export大小的计算方法是:统计全库中表的大小,这种方式计算出的表的大小包含了空的行记录,而export实际导出时不会导出空数据行,所以这里的export大小会大于实际的导出dmp文件的大小,具体误差多少取决与数据库中存在多少的空数据行(delete操作产生的空数据行). 全库rman备份大小(10.2.0.3)的计算方法是:统计全库中所有对象的大小.而rman备份集是备份所有曾经被对象暂用过的空间,所以此种统计方法统计的数据和rman备份实际的大小的差异在很大程度上取决于被放入回收站对象的多少. 二、数据库趋势分析n 数据缓冲区和库缓冲区命中率趋势[数据来源典型业务高峰时段statspack or awr] 建议: 目前数据缓冲区命中率指标良好,趋势良好。 n 数据量变化趋势[数据来源巡检脚本输出] 建议: 数据库文件目前容量充足，数据量变化不大，和一月份相比数据量增加了1G左右。 三、健康检查项目列表及结果操作系统[操作系统命令df-k 和 prstat,top,topas,glance,sar输出]n 磁盘空间[数据来源df -k]Filesystem kbytes used avail %used Mounted on /dev/vg00/lvol3 2097152 796800 1291128 38% / /dev/vg00/lvol1 2097152 142432 1939480 7% /stand /dev/vg00/lvol8 9633792 3504296 6081648 37% /var /dev/vg00/lvol7 6553600 2764232 3759824 42% /usr /dev/vg00/lvol6 4325376 23352 4269496 1% /tmp /dev/vg00/lvol5 17203200 3407096 13693672 20% /opt /dev/vg00/lvol4 8814592 5430881 3172258 63% /home /dev/vg00/back_vg 43024384 27079 40310045 0% /back_vg /dev/vg00/data_back 43024384 27015 40310041 0% /back_vg/data /dev/vg01/data1 90112000 65436519 23133314 74% /data/file1 /dev/vg02/data2 90112000 33471377 53100828 39% /data/file2 建议: 系统中各文件系统使用率都在正常范围内。 n 系统性能信息 [数据来源业务高峰时段 prstat]Load averages: 0.26, 0.25, 0.21 350 processes: 328 sleeping, 21 running, 1 zombie Cpu states: CPU LOAD USER NICE SYS IDLE BLOCK SWAIT INTR SSYS 0 0.34 22.5% 0.0% 3.0% 74.6% 0.0% 0.0% 0.0% 0.0% 1 0.18 17.3% 0.0% 6.6% 76.1% 0.0% 0.0% 0.0% 0.0% --- ---- ----- ----- ----- ----- ----- ----- ----- ----- avg 0.26 19.8% 0.0% 4.8% 75.4% 0.0% 0.0% 0.0% 0.0% Memory: 2823060K (1587904K) real, 5031872K (2948384K) virtual, 23900K free Page# 1/8 CPU TTY PID USERNAME PRI NI SIZE RES STATE TIME %WCPU %CPU COMMAND 0 ? 13629 oracle 154 20 1927M 4344K sleep 9:36 11.70 11.68 oracleSGEORA 1 ? 4646 oracle 154 20 1928M 5140K sleep 0:54 6.01 6.00 oracleSGEORA 0 ? 4971 oracle 154 20 1926M 3868K sleep 94:11 5.36 5.35 oracleSGEORA 0 ? 2150 root 154 20 9248K 804K sleep 7896:49 2.20 2.19 kcmond 1 ? 4662 oracle 154 20 1928M 5744K sleep 6:11 1.91 1.90 oracleSGEORA 1 ? 4692 oracle 154 20 1928M 5448K sleep 0:39 1.55 1.55 oracleSGEORA 0 ? 3046 oracle 154 20 1927M 3988K sleep 15:33 1.31 1.31 oracleSGEORA 0 ? 4969 oracle 154 20 1927M 4532K sleep 8:32 1.09 1.09 oracleSGEORA 0 ? 4822 oracle 154 20 1928M 4912K sleep 0:05 0.94 0.94 oracleSGEORA 0 ? 13627 oracle 154 20 1927M 4180K sleep 29:01 0.83 0.83 oracleSGEORA 1 ? 3048 oracle 154 20 1927M 4024K sleep 22:19 0.77 0.76 oracleSGEORA 1 ? 22240 oracle 148 20 1930M 3404K sleep 16:23 0.63 0.63 ora_dbw0_SGEORA 0 ? 8019 oracle 154 20 1928M 5228K sleep 0:00 0.43 0.40 oracleSGEORA 0 ? 4490 oracle 154 20 1927M 4300K sleep 3:40 0.39 0.38 oracleSGEORA 建议: 系统目前的系统硬件资源充足，CPU、内存、IO消耗都在正常范围内。 数据库系统n 安全性[数据来源和用户管理员的沟通、及部分备份脚本]建议: 1． 每天需要对备份情况进行检查,如有错误需要及时和相应厂商进行联系解决. 2． 定期进行备份的恢复测试,从而校验备份及恢复策略的有效性. n 稳定性[数据来源数据库alert、listener日志]建议: 数据库运行日志中没有需要关注的错误信息。 n 数据库性能[数据来源典型业务高峰时段statspack or awr]DB Name DB Id Instance Inst Num Release Cluster Host ------------ ----------- ------------ -------- ----------- ------- ------------ SGEORA 2394291967 SGEORA 1 9.2.0.8.0 NO dbsvr2 Snap Id Snap Time Sessions Curs/Sess Comment --------- ------------------ -------- --------- ------------------- Begin Snap: 5014 18-3? -08 13:31:41 192 13.6 End Snap: 5015 18-3? -08 14:02:51 196 14.8 Elapsed: 31.17 (mins) Cache Sizes (end) ~~~~~~~~~~~~~~~~~ Buffer Cache: 1,232M Std Block Size: 4K Shared Pool Size: 352M Log Buffer: 512K Load Profile ~~~~~~~~~~~~ Per Second Per Transaction --------------- --------------- Redo size: 284,068.25 20,116.17 Logical reads: 18,144.96 1,284.93 Block changes: 2,106.10 149.14 Physical reads: 780.75 55.29 Physical writes: 66.20 4.69 User calls: 449.74 31.85 Parses: 67.74 4.80 Hard parses: 8.84 0.63 Sorts: 6.12 0.43 Logons: 0.02 0.00 Executes: 2,035.35 144.13 Transactions: 14.12 % Blocks changed per Read: 11.61 Recursive Call %: 83.40 Rollback per transaction %: 14.77 Rows per Sort: 292.80 Instance Efficiency Percentages (Target 100%) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Buffer Nowait %: 100.00 Redo NoWait %: 99.99 Buffer Hit %: 96.09 In-memory Sort %: 100.00 Library Hit %: 99.18 Soft Parse %: 86.95 Execute to Parse %: 96.67 Latch Hit %: 99.99 Parse CPU to Parse Elapsd %: 85.23 % Non-Parse CPU: 97.43 Shared Pool Statistics Begin End ------ ------ Memory Usage %: 88.91 88.60 % SQL with executions>1: 7.59 25.97 % Memory for SQL w/exec>1: 9.17 32.25 Top 5 Timed Events ~~~~~~~~~~~~~~~~~~ % Total Event Waits Time (s) Ela Time -------------------------------------------- ------------ ----------- -------- CPU time 861 51.87 buffer busy waits 111 202 12.15 db file sequential read 105,326 140 8.44 log file switch (checkpoint incomplete) 131 125 7.54 log file sync 30,546 98 5.92 ------------------------------------------------------------- 建议: 对数据库在正常业务时段13：35～14：05进行监控，监控得到的数据库性能信息如上，从上述分析，虽然在top5中存在非空闲等待，但等待不良较少，暂时可以不予关注。 但对以下应用sql，由于每次执行时消耗资源严重，需要考虑做进一步的监控优化： CPU Elapsd Buffer Gets Executions Gets per Exec %Total Time (s) Time (s) Hash Value --------------- ------------ -------------- ------ -------- --------- ---------- 3,183,683 1 3,183,683.0 9.4 83.49 93.22 1878580116 INSERT INTO TMP_TBMARKETREPORT(SEQNO, MEMBERID, CLIENTID, INSTID , REGIONCODE, VOLUME, TURNOVER) SELECT 5, THDM.MEMBERID, THDM.CL IENTID, THDM.INSTID, TC.REGIONCODE, THDM.VOLUME*PK_QUERY_TRADE_M ANAGE.FN_QUERY_INSTUNITFORVOLUM('d', THDM.INSTID)/1000 AS VOLUME , THDM.PRICE*THDM.VOLUME*PK_QUERY_TRADE_MANAGE.FN_QUERY_INSTUNIT 2,203,459 1 2,203,459.0 6.5 57.20 65.75 758868869 INSERT INTO TMP_TBMARKETREPORT(SEQNO, MEMBERID, CLIENTID, INSTID , REGIONCODE, VOLUME, TURNOVER) ((SELECT 5, THSM.MEMBERID, THSM. CLIENTID, THSM.INSTID, TC.REGIONCODE, THSM.VOLUME*PK_QUERY_TRADE _MANAGE.FN_QUERY_INSTUNIT('s', THSM.INSTID)*FN_GENE(THSM.MATCHDA TE, THSM.INSTID)/1000 AS VOLUME, THSM.PRICE*THSM.VOLUME*PK_QUERY 2,037,188 2 1,018,594.0 6.0 38.64 43.79 318324973 INSERT INTO TMP_TBMARKETREPORT(SEQNO, MEMBERID, CLIENTID, INSTID , REGIONCODE, SELLVOLUME) SELECT 3, THDM.MEMBERID, THDM.CLIENTID , THDM.INSTID, TC.REGIONCODE, THDM.VOLUME*PK_QUERY_TRADE_MANAGE. FN_QUERY_INSTUNITFORVOLUM('d', THDM.INSTID)/1000 AS VOLUME FROM T_HISDEFERMATCH THDM, T_CLIENT TC WHERE THDM.BUYORSELL = 's' AND 2,036,713 2 1,018,356.5 6.0 36.08 44.85 2574352110 INSERT INTO TMP_TBMARKETREPORT(SEQNO, MEMBERID, CLIENTID, INSTID , REGIONCODE, BUYVOLUME) SELECT 1, THDM.MEMBERID, THDM.CLIENTID, THDM.INSTID, TC.REGIONCODE, THDM.VOLUME*PK_QUERY_TRADE_MANAGE.F N_QUERY_INSTUNITFORVOLUM('d', THDM.INSTID)/1000 AS VOLUME FROM T _HISDEFERMATCH THDM, T_CLIENT TC WHERE THDM.BUYORSELL = 'b' AND n 健康检查[数据来源健康检查脚本结果输出]l 数据库版本信息
l 数据库组件信息
l 目前数据库参数
上述参数设置暂时能够满足目前的应用需求。 l 数据库资源限制
上述系统资源消耗情况正常。 l 控制文件
状态正常 l 日志文件
从上述信息可以看到： 1，在归档日志产生高峰每天天产生的归档日志有5G左右，系统的归档压力较小。 2，每小时的归档日志生成高峰产生的归档文件数在23个左右，平均每3分钟一个，高峰时日志切换频繁； l 数据文件
上述数据文件状态正常。 l 临时文件
临时文件目前状态正常。 临时文件如果开启了自动扩展的操作，这对空间使用方面产生了隐患，容易在不良的大排序下极度消耗存储空间，造成目录填满或性能问题。 l 数据文件损坏情况
系统无损坏的数据文件。 l 表空间碎片情况
对于采用字典管理的表空间碎片超过500就考虑对表空间进行碎片整理，但此套数据库表空间都采用的是本地管理，无需关心碎片问题。 l 表空间使用率监控
上述表空间中部分表空间使用率较低，空间充足。 l 回滚表空间监控情况：
目前参数undo_management=auto 表明数据库处于回滚段自动管理模式下，只需要监控回滚表空间undo_tablespace=undotbs1的使用率即可，在回滚表空间使用率接近100％时及时添加数据文件。 l 数据库统计信息收集情况
此信息只在9i后的数据库中存在，对于9i数据库，此特性不适用。 l 存在行链接的表
数据库中不存在行迁移和行链接的现象。 如存在大量的行迁移和行链接现象，每次访问表需要消耗额外的IO操作，容易造成对于此张表访问操作的性能问题。建议消除此表的行迁移操作。具体做法为，修改表的PCTFREE属性，然后移动这张表，并重建索引： 例如： 1，alter table ILIFE. BAT_REP_PRINT_LOG pctfree 30%; 2, alter table ILIFE. BAT_REP_PRINT_LOG MOVE; 3, alter index ILIFE. IDX_BAT_REP_PRINT_LOG REBUILD; 4, alter index ILIFE. PK_BAT_REP_PRINT_LOG REBUILD; l 大于2G未分区的表
数据库中不存在大于2G的表。 上述表都是较大的表，对于超过2G以上的表，我们建议对表进行分区，从物理上将大表分成几个小的分区表，但在逻辑上还是一张表，对于应用透明。这样做的好处是： 1，性能的提高，可以尽量控制数据访问的粒度； 2，对数据的可用性提高； l Level较高的索引
数据库中无level较高的索引。 l 无效索引
目前系统中不存在失效的索引。 l 在同一表空间的表和索引
数据库中存在大量的表和基于此表的索引在一个表空间的现象，建议考虑数据和索引分开存放。 l 系统表空间中的非系统对象
数据库中不存在用户数据。 如用户数据存放在系统表空间中，建议对上述对象进行迁移到用户表空间中。 l 无效约束
数据库中不存在无效约束。 失效的约束无法保证表数据完整性，一旦存在无效约束，请开发人员进行确认是否需要启用此约束。 l 无效触发器
对上述无效的触发器进行确认是否仍然需要，对于不需要的触发器建议删除。 l 无效对象
上述失效的对象存在于数据库中，（用户trade_develp下存在大量失效对象）不利于日常的管理维护操作，建议和开发人员确认，对于不再需要的失效对象进行删除。 l 用户帐户情况
上述为目前系统中开启的帐户，对于上述数据库中的帐户需要进行确认是工作需要的帐户，对于不再使用的帐户建议lock或删除。 l 拥有数据库起停权限的用户
上述为拥有数据库起停权限的用户，这种类型的用户通常权利很大，注意此类用户的密码控制。 l 管理权限
上述用户拥有较高的管理角色权限，注意此类用户的密码控制。 l 系统权限
上述为拥有较高系统权限的用户，注意这些用户的监管。注意上述用户的密码口令控制。 四、巡检总结与调整建议Ø 数据安全性 目前数据库存在有效的联机热备策略。 Ø 稳定性 数据库运行日志没有需要关注的错误信息，软件运行问题，无需考虑升级及补丁程序。 Ø 性能 数据库目前各项性能指标都处于良好范围内，完全能够满足目前应用压力，但有一定的提升空间，详见数据库性能分析部分。 n 调整建议： Ø 建议1： 调整log_buffer的大小到10M。 Ø 建议2： 对于数据库中，用户trade_develop下存在的大量失效对象，请确认后删除，便于以后的维护操作。 n 对管理人员的提醒： 注意每天备份任务日志的检查，提高备份的有效性。
|
