informix系统管理维护手册.docx
《informix系统管理维护手册.docx》由会员分享，可在线阅读，更多相关《informix系统管理维护手册.docx（85页珍藏版）》请在冰豆网上搜索。
informix系统管理维护手册
Informix系统管理维护手册
监控实例活动
IDS实例是指Informix共享内存、Informix处理器、Informix数据库以及分配给Informix的物理设备。
以下是部分需要监控的最重要的实例活动。
操作方式
第一个也是最重要的实例活动当然是IDS的操作方式。
IDS运行正常还是有问题，或是已当机了？
onstat-p命令捕获了IDS的当前操作方式，如下所示：
InformixDynamicServer2000Version9.21.UC4--On-Line--Up01:
01:
17--
1654784Kbytes
Profile
dskreadspagreadsbufreads%cacheddskwritspagwritsbufwrits%cached
86923101304311656597.211651150222619693.70
isamtotopenstartreadwriterewritedeletecommitrollbk
258587911850028663110329671972914220
gp_readgp_writegp_rewrtgp_delgp_allocgp_freegp_curs
0000000
ovlockovuserthreadovbuffusercpusyscpunumckptsflushes
000478.1171.631326
bufwaitslokwaitslockreqsdeadlksdltoutsckpwaitscompressseqscans
350207065882000126611280
ixda-RAidx-RAda-RARA-pgsusedlchwaits
10120516938779557482
也可以查询sysmaster数据库中的sysprofile表来获取同样的统计信息。
输出的第一行显示了当前的IDS操作方式。
本例中，Informix引擎是“On-Line”。
总共有六种操作方式，其中三种特别重要：
Off-Line、Quiescent和On-Line。
Off-Line方式表明IDS当前没有在运行。
Quiescent方式表明IDS正在以单用户方式运行，在这种方式下，只有DBA可以进行管理和维护工作。
On-Line方式表明IDS正在正常运行，所有用户都可以连接到数据库服务器，并可以执行各种数据库操作。
在大多数情况下，IDS应该始终处于On-Line方式。
如果因为种种原因IDS当机了或处于Off-Line方式，那么上面的命令将显示下面的消息：
SharedmemorynotinitializedforINFORMIXSERVER'cassprod_shm'
在这种情况下，您需要检查消息日志或Informix联机日志，以进一步确定问题的根源，
除了当前的操作方式以外，上面的输出还提供了一些重要的Informix实例性能统计信息。
两个%cache字段表明IDS目前使用内存高速缓存的效率。
第一个%cache字段显示了读高速缓存比例的百分比，而第二个则显示了写高速缓存比例。
读高速缓存比例和写高速缓存比例会随应用程序及正在操作的数据的类型和大小而动态变化。
但读高速缓存比例和写高速缓存比例一般都应该在80到90个百分点之间。
这是十分保守的数字，应该根据具体环境加以调整。
如果这些比例始终低于80%，那么您需要考虑提高Informix配置文件中BUFFERS参数的值，以获取较高的读写高速缓存比例。
较低的读写高速缓存比例表明IDS正在进行的磁盘读写操作比它应该进行的要多得多，这会大大降低数据库引擎的整体性能。
输出的seqscan字段表明自数据库启动或联机以来执行了多少次顺序扫描。
如果这个数字相当大，比如说超过了100000，并且还在不断增加，那么这可能表明性能有问题，当系统处于OLTP环境时更是如此。
因而，您需要做进一步的调查以搞清楚出现过多顺序扫描的根源。
在本文的后面我们将更详细地讨论这一问题。
ovlock字段表明IDS在使用了最大数量的锁之后尝试过再使用锁的次数。
如果该数字非零，那么您可能需要提高配置文件中LOCKS参数的值。
ovbuf字段表明IDS在使用了最大数量的缓冲区之后尝试过再使用缓冲区的次数。
如果该数字很大，比如说超过100000，那么您需要提高BUFFERS参数，以便用户在需要从磁盘访问数据时不必等待缓冲区。
这会缩短响应时间，因而可以改善整体性能。
我们还需要检查与LRU有关的参数，将它们的值调整到较低的bufwait。
请参考Administrator'sGuideforInformixDynamicServer以获取更多详细信息。
另一组重要字段包括ixda-RA、idx-RA、da-RA及RA-pgused。
这些字段组合在一起表明IDS使用Informix预读机制的效率。
预读是这样一种操作：
它在顺序扫描或索引读期间提前将数据页的数目从磁盘读入内存。
理想情况是，预读的页数（即ixda-RA、idx-RA和da-RA之和）等于顺序扫描或索引读期间所使用的页数（即RA-pgused）。
这表明预读的页百分之百地用于顺序扫描和索引读。
如果二者之间存在显著的差异，比如正负差值达到10000以上，那么IDS目前就没有很有效地使用预读，而您可能需要调优您的预读参数（即RA_PAGES和RA_THRESHOLD）以获取更好的性能。
请参考Administrator'sGuideforInformixDynamicServer（本文称为Administrator'sGuide）以获取有关如何调优这些参数的详细信息。
消息日志
消息日志也称为联机日志。
它含有各种有关关键实例活动的信息，如检查点的时间和持续时间、实例启动和停止、备份和恢复状态、逻辑日志备份状态以及对主要配置参数的更改。
消息日志还包含关键的错误（Informix称之为断言失败），如磁盘I/O错误、镜像错误、当机块、数据完整性错误以及共享内存错误等等。
在发生断言失败时，消息日志通常会将我们引向有关断言失败的（“af.xxx”）文件，该文件会记录在数据库引擎当机时有关实例活动的更详细信息，还会就如何解决这一问题给我们提供一些建议。
以下内容摘自消息日志：
00:
57:
53
00:
57:
53AssertFailed:
Unexpectedvirtualprocessortermination,pid=586,exit=0x9
00:
57:
53Who:
Session（13709,omcadmin@nvlsys,6538,654709000）
Thread（13740,sqlexec,2704a558,1）
00:
57:
53Results:
FatalInternalErrorrequiressystemshutdown
00:
57:
53Action:
RestartOnLine
00:
57:
53SeeAlso:
/var/tmp/af.35acfee1
00:
57:
53Stackforthread:
13740sqlexec
上面的输出告诉我们：
某个Informix虚拟处理器终止了，并毁坏了数据库引擎。
当用户“omcadmin”登录到名为nvlsys的机器并执行了一些数据库操作（大部分是未正确执行的SQL查询），该机器上发生了这一错误。
文件/var/tmp/af.35acfeel记录了出错时有关数据库引擎状态的详细统计信息。
块状态
块是物理存储设备。
它们应该始终联机。
如果有任何块当机了，那么这表明数据遭到毁坏，需要立即引起注意。
onstat-d命令监控当前的块状态，以下是该命令的输出：
InformixDynamicServer2000Version9.21.UC4--On-Line--Up7days23:
35:
56--
1654784Kbytes
Dbspaces
addressnumberflagsfchunknchunksflagsownername
6510c7d010x111Ninformixrootdbs
6586646820x124Ninformixairgen_idx_dbs
658665b030x133Ninformixspare
658666f840x145Ninformixlogs
6586684050x152Ninformixpm1
6586698860x171Ninformixpm_gen
65866ad070x200181NTinformixtemp_dbspace2
65866c1880x1102Ninformixpm2
65866d6090x1113Ninformixairgen_main_dbs
65866ea8100x1141Ninformixmso_meta
65867018110x1162Ninformixpm3
65867160120x2001181NTinformixtemp_dbspace3
658672a8130x2001201NTinformixtemp_dbspace1
658673f0140x1252Ninformixpm4
65867538150x2001291NTinformixtemp_dbspace4
15active,2047maximum
Chunks
addresschk/dbsoffsetsizefreebpagesflagspathname
6510c9181106306951985PO-/usr/informix/dblink
6514b5f022650007500001PO-/usr/informix/dblink
6514b760338150006000059747PO-/usr/informix/dblink
6514b8d0448750001250004947PO-/usr/informix/dblink
6514ba405501000000299290PO-/usr/informix/dblink1
6514bbb06201000000207877PO-/usr/informix/dblink2
6514bd20760200000179043PO-/usr/informix/dblink3
6514be9087200000250000249939PO-/usr/informix/dblink3
6510ca8893450000250000249997PO-/usr/informix/dblink3
6510cbf810801000000299086PO-/usr/informix/dblink4
6510cd68119010000004PO-/usr/informix/dblink5
6513c830129050000010PO-/usr/informix/dblink6
6513c9a0138500000300000299997PO-/usr/informix/dblink6
6513cb10141080000020000027596PO-/usr/informix/dblink6
6513cc8015901000000782331PO-/usr/informix/dblink7
6513cdf0161101000000296827PO-/usr/informix/dblink8
6586501817404000009997PO-/usr/informix/dblink9
658651881812400000250000249947PO-/usr/informix/dblink9
658652f81950300000299997PO-/usr/informix/dblink10
658654682013300000250000249947PO-/usr/informix/dblink10
658655d821455000015000014997PO-/usr/informix/dblink10
6586574822403500004997PO-/usr/informix/dblink11
658658b82311350000300000299997PO-/usr/informix/dblink11
65865a2824201000000999997PO-/usr/informix/dblink12
65865b98251401000000299014PO-/usr/informix/dblink13
65865d082620750000749997PO-/usr/informix/dblink14
65865e7827475000025000039997PO-/usr/informix/dblink14
6586601828140300000299997PO-/usr/informix/dblink15
658661882915300000250000249939PO-/usr/informix/dblink15
658662f83035500005000049997PO-/usr/informix/dblink15
30active,2047maximum
上面的输出包含两部分。
第一部分列出了所有的dbspace，第二部分则列出了所有的块。
在块（Chunk）部分中，我们需要特别注意flags字段。
该字段的第一个字符表明块是主（P）块还是镜像（M）块。
第二个字符表明块的当前状态，是联机（O）还是脱机（D）。
由于O和D看起来很相象，尤其是您匆匆一瞥时，因此您可能想将结果用管道输入到grepPD，即onstat-d|grepPD，以确保您不会遗漏任何当机块。
如果有任何主块当机，那么您需要立即从备份磁带执行冷或暖恢复，以确保数据完整性。
我们也可以查询sysmaster数据库中的syschunks和sysdbspaces表来获取类似的统计信息。
检查点
检查点是使磁盘上的页与共享内存缓冲池中的页同步的过程。
在检查点期间，IDS阻止用户线程进入临界会话，并阻止所有的事务活动。
因此，如果检查点持续时间过长，那么用户可能会经历系统挂起。
在存在几千个事务并且响应时间至关重要的OLTP环境中，情况尤其如此。
正如上面所解释的那样，可以通过查看消息日志来监控检查点持续时间，但更好更快的方法是使用onstat-m命令。
以下是该命令的样本输出：
15:
25:
10CheckpointCompleted:
durationwas0seconds.
15:
25:
10Checkpointloguniq231,logpos0x1bb2018
15:
35:
30CheckpointCompleted:
durationwas19seconds.
15:
35:
30Checkpointloguniq231,logpos0x31b9018
FriDec2011:
48:
022002
11:
48:
02CheckpointCompleted:
durationwas7seconds.
11:
48:
02Checkpointloguniq231,logpos0x32e5018
14:
27:
37LogicalLog231Complete.
14:
27:
40Processexitedwithreturncode142:
/bin/sh/bin/sh-c
/usr/informix/etc/log_full.sh223"LogicalLog231Complete.""LogicalLog231
Complete."
14:
28:
24CheckpointCompleted:
durationwas22seconds.
14:
28:
24Checkpointloguniq232,logpos0x458018
14:
38:
46CheckpointCompleted:
durationwas7seconds.
14:
38:
46Checkpointloguniq232,logpos0x10f5018
如果检查点持续时间始终超过10秒，那么您可能需要减少LRU_MIN_DIRTY和LRU_MAX_DIRTY配置参数的值以获取更短的检查点持续时间。
同样，如果onstat-F的输出显示极高的块写（比如高于10000），并且这个数字还在不断增加，那么这可能表明出现了以下两个问题中的一个：
要么检查点时间间隔太短，从而在检查点之间清除程序没有足够的时间将所有经过修改的缓冲区写入磁盘，要么AIOVP太少，无法在检查点期间共享繁重的磁盘写。
这样，您需要重新检查CKPINTVL、LRUS、CLEANERS和NUMAIOVPS配置参数的设置，并相应地增加它们的值。
我们可能还需要查看onstat-F的输出来作为确定那些参数值的参考。
有关如何调优那些参数的详细信息，请参考Administrator'sGuide。
dbspace使用情况
Informix数据库管理员要不断了解各个dbspace中的空间，这一点十分重要。
如果某个dbspace缺少空间或把空间用完了，那么IDS会碰到麻烦。
各种问题都可能出现：
无法导入任何数据库，无法创建任何表和索引，甚至无法对任何表和索引执行插入和更新操作。
这一点对于生产数据库至关重要。
我们需要监控每个dbspace的增长，以便能够对这些问题采取更主动的方法。
下面的脚本报告了各个dbspace的当前空间使用情况，并计算其百分比。
selectnamedbspace,sum（chksize）allocated,sum（nfree）free,
round（（（sum（chksize）-sum（nfree））/sum（chksize））*100）pcused
fromsysdbspacesd,syschunksc
whered.dbsnum=c.dbsnum
groupbyname
orderbyname
输出如下所示：
dbspaceallocatedfreepcused
airgen_idx_dbs100000076340524
airgen_main_dbs150000029578980
llog1000000994799
rootdbs500003622028
temp12500002499470
temp22500002499390
上面的输出有助于我们确定哪些dbspace已把空间用完了。
要取得主动，请考虑在某个dbspace的磁盘使用情况接近90%时向该dbspace分配额外的磁盘空间；本例中，我们需要特别注意llogdbspace，并且可能的话，就给它分配更多空间，以防止它把空间用完。
dbspaceI/O
DbsapceI/O是由磁盘读和磁盘写来衡量的。
如果某些dbspace有繁重的磁盘读写操作，而另外一些dbspace几乎不进行任何读写操作，那么系统可能会出现一些磁盘I/O瓶颈。
平衡得较好的dbspaceI/O将减轻系统磁盘I/O负载，从而会改善系统的整体性能。
以下脚本将显示各个dbspace的当前I/O统计信息：
selectd.name,fname[15,25]path_name,sum（pagesread）diskreads,
sum（pageswritten）diskwrites
fromsyschkioc,syschunksk,sysdbspacesd
whered.dbsnum=k.dbsnum
andk.chknum=c.chunknum
groupby1,2
orderby1
输出如下所示：
namepath_namediskreadsdiskwrites
airgen_idx_dbsuild95/ltmp36727964
airgen_main_dbsuild95/ltmp1354532903
lloguild95/ltmp1951633
rootdbsuild95/ltmp21143117
temp1uild95/ltmp30153122
temp2uild95/ltmp32183317
我们的目标是要使所有的dbspace都有平衡的磁盘读写操作。
在大多数情况下，这是不现实的，但上面的输出至少让您对dbspaceI/O的分配方式有了一个概念，可以帮助您标识“最热门的”dbspace—那些磁盘读写最多的dbspace。
如果有些dbspace的磁盘读写操作相当繁忙而另外一些的读写操作则相当空闲，那么您可能需要为Informix引擎调整甚至重新安排物理磁盘布局。
我们可以使用onstat-D和onstat-gioq获得类似的信息，前者显示各个块的磁盘读和写，而后者显示磁盘I/O等待队列信息。
您可以通过查询sysmaster数据库中的sysptprof表来进一步标识哪些表具有最多的磁盘读写操作：
selectdbsname,tabname,（isreads+pagreads）diskreads,（iswrites+pagwrites）
diskwrites
fromsysptprof
orderby3desc,4desc
输出类似于：
dbsnametabnamediskreadsdiskwrites
airgen_10_0fanout_param845673094
airgen_cm_dbsysindices783810
airgen_10_0ne_nmo_i758195
airgen_10_0ne_nmo75440297
airgen_cm_dbsysprocbody6261028322
airgen_10_0sys
升级会员 