监控 Inix Dynamic Server 以获取更高能.doc

监控 Informix Dynamic Server 以获取更高性能简介不少书籍和文章都对 Informix Dynamic Server（IDS）及其体系结构和性能调优进行了详尽论述，但专门讨论监控这一主题的却很少。但在 IDS 管理中有效的监控却至关重要。它能帮助我们收集系统和数据库性能方面有价值的统计信息，还能帮助我们很早就确定问题，以便我们能够在故障诊断和性能调优方面取得主动。在成功地安装和配置 Informix Dynamic Server 并实现了 Informix 数据库以后，对 Informix Dynamic Server 进行监控就成为了数据库管理员的头等大事。本文将详细讨论如何在各个级别有效地监控 Informix Dynamic Server，同时会就确定 Informix 引擎和数据库问题提供一些常规技巧。文章将同时涵盖故障诊断和性能调优这两个方面。监控工具Informix 提供了两个主要的工具来监控系统和数据库性能：onstat 实用程序。 sysmaster 数据库中众多的系统监控接口（SMI）表，该数据库是在 IDS 首次初始化时自动创建的。 onstat 实用程序和 SMI 表都通过检查 IDS 共享内存活动来监控 IDS 性能，但它们给出那些统计信息的方式却有所不同。onstat 实用程序总是以固定的方式给出统计信息，而使用 SMI 表则允许您以更有意义、更可读的格式重新组织那些统计信息。需要注意的一点是，无论是通过 onstat 收集还是在 SMI 表中收集，这些统计信息都是从系统重新引导或 IDS 初始化开始累积而来的。因此，对于那些统计信息我们必须格外小心，并且总是要考虑 IDS 运行时间。例如，服务器运行超过一个月所累积的 100000 条 bufwait 与一天所累积的 100000 条 bufwait 就完全不同。要获取当前的统计信息，我们必须执行 onstat -z 以清除旧值。Informix 还提供了一个图形监控工具 onperf。onperf 收集 IDS 服务器的性能统计信息，并将它们描绘成度量值。它还可以将那些统计信息保存为文本文件以供日后分析。请参考 Performance Guide for Informix Dynamic Server以获取更多有关 onperf 实用程序的详细信息。IDS 活动可以分为三类：实例活动 数据库活动 会话活动 通过使用上面讨论的工具，我们可以有效地监控所有那些 IDS 活动。监控实例活动IDS 实例是指 Informix 共享内存、Informix 处理器、Informix 数据库以及分配给 Informix 的物理设备。以下是部分需要监控的最重要的实例活动。操作方式第一个也是最重要的实例活动当然是 IDS 的操作方式。IDS 运行正常还是有问题，或是已当机了？onstat -p 命令捕获了 IDS 的当前操作方式，如下所示：Informix Dynamic Server 2000 Version 9.21.UC4 - On-Line - Up 01:01:17 - 1654784 KbytesProfiledskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached86923 101304 3116565 97.21 1651 15022 26196 93.70 isamtot open start read write rewrite delete commit rollbk2585879 118500 286631 1032967 1972 914 2 2 0gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs 0 0 0 0 0 0 0 ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes 0 0 0 478.11 71.63 13 26 bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans3502 0 7065882 0 0 0 1266 11280 ixda-RA idx-RA da-RA RA-pgsused lchwaits10120 51 69387 79557 482 我们也可以查询 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 方式，那么上面的命令将显示下面的消息：Shared memory not initialized for INFORMIXSERVER 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。请参考 Administrators Guide for Informix Dynamic Server以获取更多详细信息。另一组重要字段包括 ixda-RA、idx-RA、da-RA 及 RA-pgused。这些字段组合在一起表明 IDS 使用 Informix 预读机制的效率。预读是这样一种操作：它在顺序扫描或索引读期间提前将数据页的数目从磁盘读入内存。理想情况是，预读的页数（即 ixda-RA、idx-RA 和 da-RA 之和）等于顺序扫描或索引读期间所使用的页数（即 RA-pgused）。这表明预读的页百分之百地用于顺序扫描和索引读。如果二者之间存在显著的差异，比如正负差值达到 10000 以上，那么 IDS 目前就没有很有效地使用预读，而您可能需要调优您的预读参数（即 RA_PAGES 和 RA_THRESHOLD）以获取更好的性能。请参考 Administrators Guide for Informix Dynamic Server（本文称为 Administrators Guide）以获取有关如何调优这些参数的详细信息。消息日志消息日志也称为联机日志。它含有各种有关关键实例活动的信息，如检查点的时间和持续时间、实例启动和停止、备份和恢复状态、逻辑日志备份状态以及对主要配置参数的更改。消息日志还包含关键的错误（Informix 称之为断言失败），如磁盘 I/O 错误、镜像错误、当机块、数据完整性错误以及共享内存错误等等。在发生断言失败时，消息日志通常会将我们引向有关断言失败的（“af.xxx”）文件，该文件会记录在数据库引擎当机时有关实例活动的更详细信息，还会就如何解决这一问题给我们提供一些建议。以下内容摘自消息日志：00:57:53 00:57:53 Assert Failed: Unexpected virtual processor termination, pid =586, exit = 0x9 00:57:53 Who: Session(13709, omcadminnvlsys, 6538, 654709000) Thread(13740, sqlexec, 2704a558, 1)00:57:53 Results: Fatal Internal Error requires system shutdown00:57:53 Action: Restart OnLine00:57:53 See Also: /var/tmp/af.35acfee100:57:53 Stack for thread: 13740 sqlexec上面的输出告诉我们：某个 Informix 虚拟处理器终止了，并毁坏了数据库引擎。当用户“omcadmin”登录到名为 nvlsys 的机器并执行了一些数据库操作（大部分是未正确执行的 SQL 查询），该机器上发生了这一错误。文件 /var/tmp/af.35acfeel 记录了出错时有关数据库引擎状态的详细统计信息。块状态块是物理存储设备。它们应该始终联机。如果有任何块当机了，那么这表明数据遭到毁坏，需要立即引起注意。onstat -d 命令监控当前的块状态，以下是该命令的输出：Informix Dynamic Server 2000 Version 9.21.UC4 - On-Line - Up 7 days 23:35:56 - 1654784 KbytesDbspacesaddress number flags fchunk nchunks flags owner name6510c7d0 1 0x1 1 1 N informix rootdbs65866468 2 0x1 2 4 N informix airgen_idx_dbs658665b0 3 0x1 3 3 N informix spare658666f8 4 0x1 4 5 N informix logs65866840 5 0x1 5 2 N informix pm165866988 6 0x1 7 1 N informix pm_gen65866ad0 7 0x2001 8 1 N T informix temp_dbspace265866c18 8 0x1 10 2 N informix pm265866d60 9 0x1 11 3 N informix airgen_main_dbs65866ea8 10 0x1 14 1 N informix mso_meta65867018 11 0x1 16 2 N informix pm365867160 12 0x2001 18 1 N T informix temp_dbspace3658672a8 13 0x2001 20 1 N T informix temp_dbspace1658673f0 14 0x1 25 2 N informix pm465867538 15 0x2001 29 1 N T informix temp_dbspace415 active, 2047 maximumChunksaddress chk/dbs offset size free bpages flags pathname6510c918 1 1 0 63069 51985 PO- /usr/informix/dblink6514b5f0 2 2 65000 750000 1 PO- /usr/informix/dblink6514b760 3 3 815000 60000 59747 PO- /usr/informix/dblink6514b8d0 4 4 875000 125000 4947 PO- /usr/informix/dblink6514ba40 5 5 0 1000000 299290 PO- /usr/informix/dblink16514bbb0 6 2 0 1000000 207877 PO- /usr/informix/dblink26514bd20 7 6 0 200000 179043 PO- /usr/informix/dblink36514be90 8 7 200000 250000 249939 PO- /usr/informix/dblink36510ca88 9 3 450000 250000 249997 PO- /usr/informix/dblink36510cbf8 10 8 0 1000000 299086 PO- /usr/informix/dblink46510cd68 11 9 0 1000000 4 PO- /usr/informix/dblink56513c830 12 9 0 500000 10 PO- /usr/informix/dblink66513c9a0 13 8 500000 300000 299997 PO- /usr/informix/dblink66513cb10 14 10 800000 200000 27596 PO- /usr/informix/dblink66513cc80 15 9 0 1000000 782331 PO- /usr/informix/dblink76513cdf0 16 11 0 1000000 296827 PO- /usr/informix/dblink865865018 17 4 0 400000 9997 PO- /usr/informix/dblink965865188 18 12 400000 250000 249947 PO- /usr/informix/dblink9658652f8 19 5 0 300000 299997 PO- /usr/informix/dblink1065865468 20 13 300000 250000 249947 PO- /usr/informix/dblink10658655d8 21 4 550000 150000 14997 PO- /usr/informix/dblink1065865748 22 4 0 350000 4997 PO- /usr/informix/dblink11658658b8 23 11 350000 300000 299997 PO- /usr/informix/dblink1165865a28 24 2 0 1000000 999997 PO- /usr/informix/dblink1265865b98 25 14 0 1000000 299014 PO- /usr/informix/dblink1365865d08 26 2 0 750000 749997 PO- /usr/informix/dblink1465865e78 27 4 750000 250000 39997 PO- /usr/informix/dblink1465866018 28 14 0 300000 299997 PO- /usr/informix/dblink1565866188 29 15 300000 250000 249939 PO- /usr/informix/dblink15658662f8 30 3 550000 50000 49997 PO- /usr/informix/dblink1530 active, 2047 maximum上面的输出包含两部分。第一部分列出了所有的 dbspace，第二部分则列出了所有的块。在块（Chunk）部分中，我们需要特别注意 flags 字段。该字段的第一个字符表明块是主（P）块还是镜像（M）块。第二个字符表明块的当前状态，是联机（O）还是脱机（D）。由于 O 和 D 看起来很相象，尤其是您匆匆一瞥时，因此您可能想将结果用管道输入到 grep PD，即 onstat -d |grep PD，以确保您不会遗漏任何当机块。如果有任何主块当机，那么您需要立即从备份磁带执行冷或暖恢复，以确保数据完整性。我们也可以查询 sysmaster 数据库中的 syschunks 和 sysdbspaces 表来获取类似的统计信息。检查点检查点是使磁盘上的页与共享内存缓冲池中的页同步的过程。在检查点期间，IDS 阻止用户线程进入临界会话，并阻止所有的事务活动。因此，如果检查点持续时间过长，那么用户可能会经历系统挂起。在存在几千个事务并且响应时间至关重要的 OLTP 环境中，情况尤其如此。正如上面所解释的那样，可以通过查看消息日志来监控检查点持续时间，但更好更快的方法是使用 onstat -m 命令。以下是该命令的样本输出：15:25:10 Checkpoint Completed: duration was 0 seconds.15:25:10 Checkpoint loguniq 231, logpos 0x1bb201815:35:30 Checkpoint Completed: duration was 19 seconds.15:35:30 Checkpoint loguniq 231, logpos 0x31b9018Fri Dec 20 11:48:02 200211:48:02 Checkpoint Completed: duration was 7 seconds.11:48:02 Checkpoint loguniq 231, logpos 0x32e501814:27:37 Logical Log 231 Complete.14:27:40 Process exited with return code 142: /bin/sh /bin/sh -c /usr/informix/etc/log_full.sh 2 23 Logical Log 231 Complete. Logical Log 231Complete. 14:28:24 Checkpoint Completed: duration was 22 seconds.14:28:24 Checkpoint loguniq 232, logpos 0x45801814:38:46 Checkpoint Completed: duration was 7 seconds.14:38:46 Checkpoint loguniq 232, logpos 0x10f5018如果检查点持续时间始终超过 10 秒，那么您可能需要减少 LRU_MIN_DIRTY 和 LRU_MAX_DIRTY 配置参数的值以获取更短的检查点持续时间。同样，如果 onstat -F 的输出显示极高的块写（比如高于 10000），并且这个数字还在不断增加，那么这可能表明出现了以下两个问题中的一个：要么检查点时间间隔太短，从而在检查点之间清除程序没有足够的时间将所有经过修改的缓冲区写入磁盘，要么 AIO VP 太少，无法在检查点期间共享繁重的磁盘写。这样，您需要重新检查 CKPINTVL、LRUS、CLEANERS 和 NUMAIOVPS 配置参数的设置，并相应地增加它们的值。我们可能还需要查看 onstat -F 的输出来作为确定那些参数值的参考。有关如何调优那些参数的详细信息，请参考 Administrators Guide。dbspace 使用情况Informix 数据库管理员要不断了解各个 dbspace 中的空间，这一点十分重要。如果某个 dbspace 缺少空间或把空间用完了，那么 IDS 会碰到麻烦。各种问题都可能出现：无法导入任何数据库，无法创建任何表和索引，甚至无法对任何表和索引执行插入和更新操作。这一点对于生产数据库至关重要。我们需要监控每个 dbspace 的增长，以便能够对这些问题采取更主动的方法。下面的脚本报告了各个 dbspace 的当前空间使用情况，并计算其百分比。select name dbspace, sum(chksize) allocated, sum(nfree) free,round(sum(chksize) - sum(nfree)/sum(chksize)*100) pcusedfrom sysdbspaces d, syschunks cwhere d.dbsnum = c.dbsnumgroup by nameorder by name输出如下所示：dbspace allocated free pcusedairgen_idx_dbs 1000000 763405 24airgen_main_dbs 1500000 295789 80llog 1000000 9947 99rootdbs 50000 36220 28temp1 250000 249947 0temp2 250000 249939 0上面的输出有助于我们确定哪些 dbspace 已把空间用完了。要取得主动，请考虑在某个 dbspace 的磁盘使用情况接近 90% 时向该 dbspace 分配额外的磁盘空间；本例中，我们需要特别注意 llog dbspace，并且可能的话，就给它分配更多空间，以防止它把空间用完。dbspace I/ODbsapce I/O 是由磁盘读和磁盘写来衡量的。如果某些 dbspace 有繁重的磁盘读写操作，而另外一些 dbspace 几乎不进行任何读写操作，那么系统可能会出现一些磁盘 I/O 瓶颈。平衡得较好的 dbspace I/O 将减轻系统磁盘 I/O 负载，从而会改善系统的整体性能。以下脚本将显示各个 dbspace 的当前 I/O 统计信息：select , fname15,25 path_name, sum(pagesread) diskreads,sum(pageswritten) diskwritesfrom syschkio c, syschunks k, sysdbspaces dwhere d.dbsnum = k.dbsnumand k.chknum = c.chknumgroup by 1, 2order by 1输出如下所示：name path_name diskreads diskwritesairgen_idx_dbs uild95/ltmp 3672 7964airgen_main_dbs uild95/ltmp 13545 32903llog uild95/ltmp 19 51633rootdbs uild95/ltmp 211 43117temp1 uild95/ltmp 3015 3122temp2 uild95/ltmp 3218 3317我们的目标是要使所有的 dbspace 都有平衡的磁盘读写操作。在大多数情况下，这是不现实的，但上面的输出至少让您对 dbspace I/O 的分配方式有了一个概念，可以帮助您标识“最热门的”dbspace 那些磁盘读写最多的 dbspace。如果有些 dbspace 的磁盘读写操作相当繁忙而另外一些的读写操作则相当空闲，那么您可能需要为 Informix 引擎调整甚至重新安排物理磁盘布局。我们可以使用 onstat -D 和 onstat -g ioq 获得类似的信息，前者显示各个块的磁盘读和写，而后者显示磁盘 I/O 等待队列信息。您可以通过查询 sysmaster 数据库中的 sysptprof 表来进一步标识哪些表具有最多的磁盘读写操作：select dbsname, tabname, (isreads + pagreads) diskreads, (iswrites + pagwrites) diskwritesfrom sysptproforder by 3 desc, 4 desc输出类似于：dbsname tabname diskreads diskwritesairgen_10_0 fanout_param 84567 3094airgen_cm_db sysindices 78381 0airgen_10_0 ne_nmo_i 75819 5airgen_10_0 ne_nmo 75440 297airgen_cm_db sysprocbody 62610 28322airgen_10_0 systables 37342 466airgen_10_0 syscolumns 34539 4609airgen_10_0 457_484 32838 42airgen_10_0 453_480 30009 1airgen_10_5_old syscolumns 29531 4550airgen_10_5 syscolumns 28824 4552airgen_10_0 456_483 25448 14airgen_10_0 458_485 23278 177airgen_10_5_old 452_483 22412 31根据从这个查询获得的输出，您可能需要在 dbspace 间移动一些表以使磁盘 I/O 平衡得更好。共享内存段太多的虚拟共享内存段（通常多于三个）表明：最初的虚拟共享内存段太小，数据库引擎必须不断分配额外的虚拟共享内存段。这反过来影响了 IDS 性能，并且最终会损害系统的性能。onstat -g seg 命令显示了 Informix 数据库引擎目前拥有多少共享内存段：Informix Dynamic Server 2000 Version 9.21.UC4 - On-Line - Up 28 days 15:49:33 - 205824 KbytesSegment Summary:id key addr size ovhd class blkused blkfree 0 1381386241 a000000 177209344 220688 R 42984 280 1 1381386242 14900000 8388608 856 V 2048 0 2 1381386243 15100000 1048576 632 M 164 92 3 1381386244 15200000 8388608 856 V 2048 0 4 1381386245 15a00000 8388608 856 V 2008 40 5 1381386246 16200000 8388608 856 V 50 1998 Total: - - 211812352 - - 49302 2410 (* segment locked in memory)如果输出显示虚拟共享内存段多于三个，那么您需要提高配置文件中 SHMVERSIZE 参数的值。其思想是，让 IDS 在初始化时分配足够的虚拟共享内存，以便在用户登录到系统并执行数据库操作时无需分配更多的虚拟共享内存。您可能还想使用 UNIX ipcs 命令来查看 Informix 共享内存的大小。有关如何计算 IDS 虚拟共享内存段大小的详细信息，请参考 Administrators Guide。操作系统的整体性能由于 Informix 数据库引擎总是安装在某个操作系统（主要是 UNIX）上，以准确地监控或评估 IDS 性能，因此我们需要将操作系统的行为作为一个整体来考虑，在数据库引擎驻留在非专用数据库服务器上时尤其要这样考虑。如果 IDS 占用了太多 RAM（例如，如果系统有 512MB RAM，而 IDS 占用了 400MB 或更多作为其共享内存），那么当用户执行内存密集型操作时，操作系统可能会经历频繁的交换和挂起。当内存不足时，系统必须将一些数据页从内存交换到磁盘，以便为新数据腾出更多空间。如果系统内存不足，那么 CPU 可能也会遭殃。有不少 UNIX 实用程序可以监控操作系统 CPU 和内存的整体利用率。以下是来自“top”实用程序的输出：load averages: 1.12, 1.02, 1.07 10:17:30123 processes: 120 sleeping, 1 zombie, 2 on cpuCPU states: 70.5% idle, 26.5% user, 2.8% kernel, 0.3% iowait, 0.0% swapMemory: 3072M real, 76M free, 588M swap in use, 440M swap freePID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND28349 omcadmin 4 0 0 86M 55M cpu10 970:25 6.85% CS_App.prt17782 informix 5 30 -10 1631M 1594M sleep 50.0H 4.66% oninit.exe17784 informix 5 59 -10 1631M 1594M sleep 102.9H 4.12% oninit.exe17786 informix 5 59 -10 1631M 1591M sleep 25.5H 2.53% oninit.exe571 root 1 58 0 361M 129M sleep 19.0H 1.36% em_mis17785 informix 5 59 -10 1631M 1592M sleep 57.8H 1.05% oninit.exe5470 omcadmin 1 0 0 1960K 1408K cpu15 0:00 0.26% top上面的输出包含两部分。第一部分为您汇总了操作系统的 CPU 和内存的整体使用情况，第二部分则提供了有关每个处理器的详细信息。其它实用程序（如 vmstat、iostat、ps -ef 和 sar）在收集操作系统当前的性能统计信息方面也很有用。vmstat 显示目前操作系统交换了多少内存；iostat 和 sar 显示了当前在所有物理磁盘中磁盘 I/O 的分配；而 ps -ef 打印出当前各个处理器的登录时间、CPU 及内存使用情况的详细信息。此外也有许多图形工具可用，这些工具使您能够绘制操作系统资源利用率和性能的动态变化。监控数据库活动对数据库活动进行监控的目的在于确保每个数据库时刻都将其能力发挥到了极致。这意味着：您必须留意潜在的性能问题，确定其根源并将其消灭在萌芽状态。以下是要留意的几个方面。表扩展块扩展块是一块物理上连续的页。然而，如果一个表有多个扩展块，那就不能保证这些扩展块是连续的；扩展块可能会散布在表所驻留的整个 dbspace 上。物理页的连续性对于性能十分重要。当数据页连续时，访问磁盘数据所用的时间就最短，而数据库也能连续地读取行。如果表有太多扩展块，那么那些扩展块极有可能相互交错。这极大地影响了性能，因为当您检索某个表的数据时，磁头需要对属于该表的多个非连续扩展块进行寻道，而不是对具有连续物理页的一个大扩展块进行寻道。这会显著地降低磁盘寻道速度。下面的脚本检测具有多个扩展块的数据库表：select t.tabname, count(*) num_extfrom sysmaster:sysextents e, airgen:systables twhere e.tabname=t.tabnameand dbsname = airgenand t.tabname not like sys%group by 1having count(*) 1order by 2 desc输出如下所示：tabname num_extnmoattrclassmap 14attrclass 11networkmoclass 3fanout_param 3fanout_comp 2ne_nmo 2nenmoclassmap 2join_map 2如果除了大型分段表以外，任何表的扩展块超过了 10 个，那么您应该考虑重新构建这些表以合并扩展块。对于较大的数据库或者大小设置不是很好的数据库，我们可能还会关注扩展块的最大数目，或者会担心针对索引的 32GB 限制。有关如何对表估计和分配数据块大小的详细信息，请参考 Performance Guide。索引层索引的层数也可能会对性能产生不利影响。索引层越多，IDS 到达索引叶节点所需的探测也就越多。而且，如果叶节点被拆分或合并，那么整个索引对这一变化进行调整将要花费更多的时间。例如，如果索引只有两层，那么只需要调整两层，但如果索引有四层，那么相应地就需要对所有四层进行调整。用于这一调整的时间当然也就长得多。在 OLTP 环境中会进行频繁的插入、删除和更新，这些操作会导致不断地对索引进行拆分和合并，因此上述问题也就格外明显。下面的脚本标识每个索引的层数：select idxname, levels from sysindexesorder by 2 desc输出如下所示：idxname levelsobjdesc 3fanout_param_i 3458_485 3457_484 3idxname 2tabgtor 2tabgtee 2如果哪个索引超过了 4 层，您可能就需要考虑删除和重新构建该索引，从而合并其层，以获取更好的性能。索引唯一性索引的重复程度很高会严重地影响更新和删除的性能。假定表 customer 的 customer_type 列上有一个索引，而可能的 customer_type 代码只有五种。如果这个表有一百万行，那么可能有 200000 行具有相同的 customer_type 代码。B-树存储键值，其后跟一个指向每个物理行的指针列表。在必须删除或更新任何键值时，问题出现了。IDS 必须找遍所有的重复内容，直到找到要删除或更新的正确键为止！下面的脚本用来标识重复程度很高的索引：select tabname, idxname, nrows, nuniquefrom systables t, sysindexes Iwhere t.tabid =i.tabidand t.tabid 99and nrows 0and nunique 0 输出如下所示：tabname idxname nrows nuniquebsc_dte bscdte_i 6 6omcgttready 231_413 1 1systemrelease 451_478 3 3neclass 452_479 31 12sysrelneclassmap 453_480 33 3proxynemgrmap 454_481 1 1networkmoclass 455_482 362 199nenmoclassmap 456_483 492 12attrclass 457_484 1191 924nmoattrclassmap 458_485 2901