调优DB2 v8.1及其数据库的非常好的实践-技术开发专区

调优DB2 v8.1及其数据库的非常好的实践

作者：IBM 编辑：晓熊 2008-11-21 10:04 来源：ITPUB.n

                          Database Snapshot
Database name                              = SAMPLE
Database path                              = C:\\DB2\\NODE0000\\SQL00002\\
Input database alias                       = SAMPLE
Database status                            = Active
Catalog database partition number          = 0
Catalog network node name                  =
Operating system running at database server= NT
Location of the database                   = Local
First database connect timestamp           = 02-20-2004 06:19:00.847979
Last reset timestamp                       =
Last backup timestamp                      =
Snapshot timestamp                         = 02-20-2004 06:23:17.252491
        High water mark for connections       = 1                (MAXAPPLS)
Application connects                       = 1
Secondary connects total                   = 0
        Applications connected currently      = 1                 (AVG_APPLS)
Appls. executing in db manager currently   = 0
Agents associated with applications        = 1
Maximum agents associated with applications= 1
Maximum coordinating agents                = 1
Locks held currently                       = 0
Lock waits                                 = 0
Time database waited on locks (ms)         = 0
        Lock list memory in 使用 (Bytes)       = 1000    (LOCKLIST and MAXLOCKS)
Deadlocks detected                         = 0
        Lock escalations                      = 0         (LOCKLIST and MAXLOCKS)
        

        Exclusive lock escalations            = 0          (LOCKLIST and MAXLOCKS)
Agents currently waiting on locks          = 0
        Lock Timeouts                         = 0                (LOCKTIMEOUT)
Number of indoubt transactions             = 0
        Total Private Sort heap allocated     = 0      (SHEAPTHRES and SORTHEAP)
        

        Total Shared Sort heap allocated      = 0    (SHEAPTHRES_SHR and SORTHEAP)
        

        Shared Sort heap high water mark      = 0   (SHEAPTHRES_SHR and SORTHEAP)
        

Total sorts                                = 0
Total sort time (ms)                       = 0
        Sort overflows                        = 0              (SORTHEAP)
Active sorts                               = 0
Buffer pool data logical reads             = 370
Buffer pool data physical reads            = 54
Buffer pool temporary data logical reads   = 0
Buffer pool temporary data physical reads  = 0
        Asynchronous pool data page reads     = 9           (NUM_IOSERVERS)
        

        Buffer pool data writes               = 3      (CHNGPGS_THRESH and NUM_IOCLEANERS)
        

        Asynchronous pool data page writes    = 0      (CHNGPGS_THRESH and NUM_IOCLEANERS)
        

Buffer pool index logical reads            = 221
Buffer pool index physical reads           = 94
Buffer pool temporary index logical reads  = 0
Buffer pool temporary index physical reads = 0
        Asynchronous pool index page reads    = 0         (NUM_IOSERVERS)
        

        Buffer pool index writes              = 0      (CHNGPGS_THRESH and NUM_IOCLEANERS)
        

        Asynchronous pool index page writes   = 0     (CHNGPGS_THRESH and NUM_IOCLEANERS)
Total buffer pool read time (ms)           = 287
Total buffer pool write time (ms)          = 1
Total elapsed asynchronous read time       = 0
Total elapsed asynchronous write time      = 0
Asynchronous data read requests            = 3
Asynchronous index read requests           = 0
No victim buffers available                = 0
LSN Gap cleaner triggers                   = 0
        Dirty page steal cleaner triggers     = 0            (CHNGPGS_THRESH)
        

        Dirty page threshold cleaner triggers = 0           (CHNGPGS_THRESH)
        

        Time waited for prefetch (ms)         = 0            (NUM_IOSERVERS)
Unread prefetch pages                      = 0
Direct reads                               = 86
Direct writes                              = 4
Direct read requests                       = 14
Direct write requests                      = 2
Direct reads elapsed time (ms)             = 247
Direct write elapsed time (ms)             = 56
        Database files closed                 = 0          (MAXFILOP)
Data pages copied to extended storage      = 0
Index pages copied to extended storage     = 0
Data pages copied from extended storage    = 0
Index pages copied from extended storage   = 0
Host execution elapsed time                = 0.000039
Commit statements attempted                = 6
Rollback statements attempted              = 1
Dynamic statements attempted               = 281
Static statements attempted                = 7
Failed statement operations                = 1
Select SQL statements executed             = 4
Update/Insert/Delete statements executed   = 0
DDL statements executed                    = 2
Internal automatic rebinds                 = 0
Internal rows deleted                      = 0
Internal rows inserted                     = 0
Internal rows updated                      = 0
Internal commits                           = 1
Internal rollbacks                         = 0
Internal rollbacks due to deadlock         = 0
Rows deleted                               = 0
Rows inserted                              = 0
Rows updated                               = 0
Rows selected                              = 336
Rows read                                  = 375
Binds/precompiles attempted                = 0
        Log space available to the database (Bytes)= 5095757   (LOGPRIMARY and LOGSECOND)
Log space used by the database (Bytes)     = 4243
Maximum secondary log space used (Bytes)   = 0
        Maximum total log space used (Bytes)  = 6498    (LOGPRIMARY and LOGSECOND)
        

        Secondary logs allocated currently    = 0      (LOGPRIMARY and LOGSECOND)
        

        Log pages read                        = 0              (LOGBUFSZ)
        

        Log pages written                     = 5              (LOGBUFSZ)
Appl id holding the oldest transaction     = 38
        Package cache lookups                 = 10        (PKGCACHESZ)
        

        Package cache inserts                 = 8         (PKGCACHESZ)
        

        Package cache overflows               = 0         (PKGCACHESZ)
        

        Package cache high water mark (Bytes) = 191140    (PKGCACHESZ)
Application section lookups                = 281
Application section inserts                = 6
        Catalog cache lookups                 = 18       (CATALOGCACHE_SZ)
        

        Catalog cache inserts                 = 9        (CATALOGCACHE_SZ)
        

        Catalog cache overflows               = 0        (CATALOGCACHE_SZ)
        

        Catalog cache high water mark         = 0        (CATALOGCACHE_SZ)
Workspace Information
 Shared high water mark                    = 0
 Corresponding shared overflows            = 0
 Total shared section inserts              = 0
 Total shared section lookups              = 0
 Private high water mark                   = 21102
 Corresponding private overflows           = 0
 Total private section inserts             = 6
 Total private section lookups             = 6
Number of hash joins                       = 0
Number of hash loops                       = 0
        Number of hash join overflows         = 0         (SORTHEAP)
        

        Number of small hash join overflows   = 0         (SORTHEAP)

有时候，为了某些问题使用 "grep" (UNIX) 和 "findstr" (Windows) 对快照输出执行初步的搜索非常方便。如果发现了什么东西，就可以通过打开快照输出并找到问题所在，以便作进一步调查。

例如，为了识别是否存在死锁：

UNIX:

grep -n "Deadlocks detected" snap.out | grep -v "= 0" | more

Windows:

findstr /C:"Deadlocks detected" snap.out | findstr /V /C:"= 0"

SHEAPTHRES (DBM)
这是实例中所有数据库的并发私有排序所消耗的内存总量。另外传入的排序只能得到更少量的可用内存。对于 OLTP，一开始最好是使用大约 20000，而对于 OLAP 40000-60000 会工作得更好一些。

当 "Piped sorts accepted"的值与 "Piped sorts requested" 比起来较低时，通过增加 SHEAPTHRES 的大小，常常可以提高性能。如果 "Post threshold sorts" （在 SHEAPTHRES 已经被超出之后，请求堆的排序）的值较高（也就是有两位数），应尝试增加 SHEAPTHRES 的大小。 "Total Private Sort heap allocated"应该小于 SHEAPTHRES。如果不是这样，则应增加 SHEAPTHRES。

MAXAGENTS (DBM)
这是可用于接受对实例中所有数据库的应用程序请求的数据库管理器代理的最多数量。在受限内存（memory constrained）的环境中，这个参数对于限制数据库管理器的总内存使用量很有用，因为每个附加的代理都需要附加的内存。

如果机器是受限内存的，那么可以增加 MAXAGENTS，直到 "Agents stolen from another application"为 0。此外， "Local connections"+ "Remote connections to db manager"将指出连接到实例上的并发连接的数量。 "High water mark for agents registered"将报告在某一次连接到数据库管理器的代理曾出现的最大数量。 "Max agents overflow"报告当已经达到 MAXAGENTS 时，所收到的创建一个新代理的请求的次数。最后， "Agents Registered"显示在被监控的数据库管理器实例中当前注册的代理的数量。

NUMDB (DBM)
指定可以同时激活的本地数据库的数量。在生产系统中，建议每个实例有一个数据库，因此应该将这个值设为 1。否则，将其设为同时激活的数据库的最大数量。如果不确定的话，使用 "Active local databases"。

NUM_INITAGENTS 和 NUM_POOLAGENTS (DBM)
NUM_INITAGENTS 指定在 db2start 上的池中创建的空闲代理的数量，它可以帮助加快在开始使用数据库时的连接。NUM_POOLAGENTS 也是相关的，但是如果数据库已经运行了一段时间，那么它对性能会有更大的影响。当 Connections Concentrator 为 OFF（缺省值；MAX_CONNECTIONS = MAX_COORDAGENTS）时，NUM_POOLAGENTS 指定代理池的最大大小。当 Concentrator 为 ON （MAXCONNECTIONS > MAX_COORDAGENTS）时，可以参考这个值来决定在系统工作负载较低时代理池应该有多大。

NUM_INITAGENTS 和 NUM_POOLAGENTS 应该设为预期的并发实例级连接的平均数量，对于 OLAP 这个值通常比较低，而对于 OLTP 就要高一些。对于存在大量 ramp up 连接情况下的性能基准，将 NUM_INITAGENTS 设置成预期的连接数量（这将减少资源争用，从而显著地减少 ramp up 连接所需的时间）。在使用了连接池的 3 层环境中，NUM_INITAGENTS 和 NUM_POOLAGENTS 对性能的影响很小，因为即使在应用程序空闲的时候，应用服务器也会连续不断地维护连接。

"Idle agents"显示了在代理池中空闲代理的数量，而 "Agents assigned from pool"则显示从代理池中将一个代理分配出去的次数。 "Agents created from empty pool"显示在空池情况下必须创建的代理的数量，这可能会让人误解为刚好在 db2start 之后。而在 db2start 之后，它只是显示被创建的代理的数量。如果 "Agents created from empty pool"/ "Agents assigned from pool"的比例比较高（5:1 或更大），则可能表明应该增加 NUM_POOLAGENTS。这也可能表明系统的总体工作负载太高。这时可以通过降低 MAXCAGENTS 来调整工作负载。如果这个比例较低，则暗示着 NUM_POOLAGENTS 可能被设得太高，有些代理就会浪费系统资源。

FCM_NUM_BUFFERS (DBM)
只在有多个逻辑分区的 DPF 环境中使用。它指定用于内部通信的大小为 4 KB 的缓冲区的数量。如果没有使用 DPF，那么这个值甚至不会出现在快照输出中。此外，该信息将来自其上运行了快照的分区。例如，在 DBM 快照之前的那个快照中， "Node FCM information corresponds to"显示了一个值 2，因此它是从 2 号分区那里得来的。"Get snapshot for dbm global" 可用于获得所有分区值的群集。

DBM 快照的 FCM Node 部分可用于查看主要的分区间通信发生的地点，以用于调查的目的。如果通信量很大，则表明需要更多的 FCM 缓冲区内存，需要不同的分区键，或者需要不同的表来分派表空间。如果 "Free FCM buffers low water mark"小于 FCM_NUM_BUFFERS 的百分之 15，那么可以增加 FCM_NUM_BUFFERS，直到 "Free FCM buffers low water mark"大于或等于 FCM_NUM_BUFFERS 的百分之 15，以确保总有足够的 FCM 资源可供使用。

AVG_APPLS (DB)
只有在应用程序发出复杂的 SQL（例如连接、函数、递归等等）时才更改它，否则让它一直为 1。这可以帮助估计在运行时可以为一个访问计划提供多少的缓冲池。它应该设为一个较低的值，即 "Applications connected currently"的平均数量乘以复杂 SQL 的百分比。

LOCKLIST 和 MAXLOCKS (DB)
对于每个数据库都有一个锁列表，该列表包含所有同时连接到数据库的应用程序所持有的锁。在 32 位的平台上，一个对象上的第一个锁要求占 72 字节，而其他的锁要求占 36 字节。在 64 位平台上，第一个锁要求占 112 字节，而其他锁要求占 56 字节。

当一个应用程序使用的 LOCKLIST 的百分比达到 MAXLOCKS 时，数据库管理器将执行一次锁升级（lock escalation），在这个操作中将使得行锁换成单独的一个表锁。而且，如果 LOCKLIST 快要耗尽，数据库管理器将找出持有一个表上的最多行锁的连接，并将这些行锁换成表锁，以释放 LOCKLIST 内存。锁整个表可以大大减少并发性，死锁的几率也增加了。

如果 "Lock list memory in 使用 (Bytes)"超出了定义的 LOCKLIST 大小的 50％，那么应增加 LOCKLIST 4 KB 大小的页面的数量。如果发生了 "Lock escalations"或 鈥淓xclusive lock escalations鈥_，则应该或者增加 LOCKLIST，或者增加 MAXLOCKS，抑或同时增加两者。

关于锁的数据库快照部分包含大量有价值的信息。看看 "Locks held currently"、 "Lock waits"、 "Time database waited on locks (ms)"、 "Agents currently waiting on locks"和 "Deadlocks detected"中是否存在高值，如果有的话，就可能是差于最优访问计划、事务时间较长或者应用程序并发问题的症状。如果要发现死锁，那么需要创建一个针对死锁的事件监视器，事件监视器带有详细信息，以便查看当前正在发生的事情。

关注我们