SinoDB数据库运行分析

运维指南
1

  SinoDB数据库运行主要从数据库互斥资源等待、数据库写类型、备份文件有效性、Chunk状态等15个方向进行分析，具体说明如下：
一、数据库互斥资源等待

  • 检查项目
    数据库互斥资源等待

  • 检查命令
    onstat -g con |head -20

  • 说明
    onstat -g con 查看目前数据处于等待条件中的线程信息
    查看这两项资源等待项目，判断数据库是否存在资源配置上的性能瓶颈

二、数据库写类型

  • 检查项目
    数据库写类型

  • 检查命令
    onstat -F |head

  • 说明
    Fg Writes ，LRU Writes，Chunk Writes分别代表了Buffer不足时清仓的数量，检查点来临前由LRU控制的清仓数量以及检查点触发时的清仓数量

三、备份有效性检测

  • 检查项目
    检查备份文件有效性

  • 检查命令
    onstat -g arc

  • 说明
    确认各个DBSPACE包含有效的备份可供恢复使用

四、Chunk状态检查

  • 检查项目
    Chunk状态

  • 检查命令
    onstat -d | grep PD-

  • 说明
    如果chunk块的FLAG标识出现PD-状态，表示该chunk设备已经脱机

五、检查系统关键区信息

  • 检查项目
    检查系统关键区信息

  • 检查命令
    oncheck -cc
    oncheck -cr

  • 说明
    每个数据库包含它本身的系统目录，该目录包含关于数据库表、列、索引、视图、约束、存储过程和特权的信息。保留页是驻留在根数据库空间初始块开始处的页。这些页包含主数据库服务器开销信息。如果该命令检测到错误，请从存储空间备份执行数据恢复。

六、数据库实例概要信息

  • 检查项目
    数据库实例概要信息

  • 检查命令
    onstat -p

  • 说明
    1.%cached 是读取共享内存相对于磁盘读取百分比。OLTP 系统应该在95％以上。它是在系统中缓冲区太少的指标。

  1. seqscans & isamtot - 如果seqscans 和isamtot之间的比例大于1％，我们可以看看是否索引(index)使用少，顺序扫描(seqscans)使用太多。
  2. lokwaits & lockreqs - 是用户线程必须在锁定表发出请求/页/行锁的次数。如果与lokwaits/lockreqs 比率太高，那么应用程序可能单线程(single-threading)。
  3. ovlock 是数据库服务器试图分配锁15次数以上。ovlock 字段表明IDS 在使用了最大数量的锁之后尝试过再使用锁的次数。如果该数字非零，那么您可能需要提高配置文件中LOCKS 参数的值。
  4. ovbuff 字段表明IDS 在使用了最大数量的缓冲区之后尝试过再使用缓冲区的次数。如果该数字很大，比如说超过100000，那么表示我们需要提高BUFFERS 参数，以便用户在需要从磁盘访问数据
    时不必等待缓冲区。这会缩短响应时间，因而可以改善整体性能。我们还需要检查与LRU 有关的参数，将它们的值调整到较低的bufwait。
  5. commit & rollbk
    是回滚(rollback)和提交(commit)两者的比例。如果比例过高1％，那么应用程序可能设计不正确。需要研究为什么有这么多回滚，并采取纠正措施。

七、检查点持续时间

  • 检查项目
    检查点持续时间

  • 检查命令
    tail -100000 onstat -m | grep "Message Log File" | awk -F: '{print $2}' | grep duration | grep -v “0 seconds”

  • 说明
    检查点持续时间反映出了一定的数据库性能，如果出现持续的检查点时间超过20秒则需要引起关注，可通过设置LRU_MIN_DIRTY , LRU_MAX_DIRTY来缓解。

八、非连续物理分布的表

  • 检查项目
    非连续物理分布的表

  • 检查命令
    dbaccess [DBNAME] <<EOF
    select dbinfo(‘DBNAME’) dbname,t.tabname tabname,dbinfo(‘DBSPACE’,t.partnum) dbspace,count() extent_num, max(p.nrows) rows
    from sysmaster:sysptnext e, systables t,sysmaster:sysptnhdr p
    where e.pe_partnum=t.partnum
    and t.partnum=p.partnum
    and t.tabid>99
    and t.tabname not like “sys%”
    and t.tabname not like “tmp%”
    group by 1,2,3
    having count(    )>100
    order by 4 desc
    EOF

  • 说明
    如果除了大型分段表以外，表的扩展块超过了100个，那么应该考虑重新构建这些表以合并扩展块。通过指定表的extent size 和nextsize调整重建表来减少extent数量。同时我们还需要根据表的记录数
    来判断表的extent设置的问题。

九、全表扫描最多的表

  • 检查项目
    全表扫描最多的表

  • 检查命令
    select p.dbsname, t.tabname,
    sum(p.seqscans) seqscans , max(t.nrows) nrows
    from sysmaster:sysptprof p, systables t
    where p.tabname =t.tabname
    and t.nrows > 10000 and p.seqscans>10
    and p.dbsname not like “sys%” and p.tabname not like “sys%” and p.tabname not like “tmp%”
    group by 1,2
    order by 3 desc;

  • 说明
    对于大表的全表扫描操作会产生极高的开销，通过找出全表扫描最多的大表，并合理的建立相应的索引可以有效的避免额外的开销

十、DUMP目录检查

  • 检查项目
    DUMP目录空间及文件检查

  • 检查命令
    1.df -h $DUMPDIR
    2.ls -lrt $DUMPDIR|egrep ‘.af|.dmp|core’

  • 说明
    定期检查DUMPDIR剩余空间确保其在故障时可以产生完整的AF文件供诊断使用

十一、IO最多的表

  • 检查项目
    各个表上IO情况

  • 检查命令
    select a.dbsname, a.tabname,
    (isreads + pagreads) diskreads,
    (iswrites + pagwrites) diskwrites,
    (isreads + pagreads)+(iswrites + pagwrites) disk_rsws
    from sysptprof a,systabnames b
    where a.partnum=b.partnum
    and a.tabname != ‘TBLSpace’
    and a.tabname not like ’ %’
    and a.tabname not like ‘sys%’
    and a.dbsname not like ‘sys%’
    and isreads + pagreads + iswrites + pagwrites >50000
    order by 5 desc;

  • 说明
    根据表的繁忙程度可以帮我们找出最需要进行关注的表，如果该部分表很大，则需要考虑对其进行分区操作，此外该信息可以帮助我们更为合理的规划磁盘IO

十二、效率低下的索引

  • 检查项目
    索引层超过4层的表

  • 检查命令
    dbaccess [DBNAME] <<EOF
    select t.tabname,i.idxname, i.levels
    from sysindexesi,systables t
    where i.tabid = t.tabid
    and i.levels>=4
    order by 3 desc
    EOF

  • 说明
    层数在3层以上的索引性能将会严重降低，需考虑重建

十三、磁盘排序情况

  • 检查项目
    查看系统磁盘排序情况

  • 检查命令
    dbaccess sysmaster <<EOF
    Select *
    from sysprofile
    where name matches “sort”

  • 说明
    磁盘排序在性能上远低于内存排序，当内存排序空间不足时数据库则会使用磁盘进行排序，如果系统存在大量的磁盘排序，则应当考虑是否需要增加临时空间

十四、rootdbs上非系统表

  • 检查项目
    找出Rootdbs上非系统表

  • 检查命令
    dbaccess sysmaster <> $chkFile
    select distinct t.dbsname database,d.name dbspace,t.tabname
    from sysdbstab d,syschunks c,sysextents t
    where t.chunk=c.chknum
    and c.dbsnum=d.dbsnum
    and t.dbsname not like ‘sys%’
    and t.dbsname != ‘onpload’
    and t.tabname not like ‘sys%’
    and d.name = ‘rootdbs’
    EOF

  • 说明
    rootdbs中本身包含所有的系统表，如果附加业务表于其上则会产生IO和空间上的多种争用，如发现Rootdbs中存在业务表，则应考虑将其迁出至相应业务数据DBSPACE上

十五、表空间使用过高的表清单

  • 检查项目
    找出系统内空间使用过高的表

  • 检查命令
    set isolation to dirty read;
    select s.dbsname,s.tabname, p.npused from sysptnhdr p,systabnames s
    where p.partnum = s.partnum
    and p.npused >10000000 ;

  • 说明
    2k page Size数据库内若单一个partition 使用超过16775134 pages ,则该表会导致无法在新增数据的问题。若有该状况建议:
    1、将该表移至大Page Size的表空间
    2、将该表进行表分区或表分片。