一、参数调优的一般过程
二、参数调优的一般原则
三、WEB服务器调优的关注点
四、WEB服务器的相关参数解释
五、数据库服务器相关参数的解释
1。活动应用程序的最大数目(MAXAPPLS)
MAXAPPLS 是一个数据库配置参数，它指定了可以连接到数据库的并发应用程序(本地和远程)的最大数量。由于需要为连接到数据库的每个应用程序分配一些私有内存，因此，允许有更多并发应用程序将意味着用掉更多内存。该参数值必须大于等于，已连接应用程序的数量加上这些应用程序中完成提交或回滚过程中可能并发存在的数量的总和。
（1）. 建议
要运行 OLTP 应用程序，请确保MAXAPPLS的值设置正确(足够大但不能是没必要的大)以容纳最多的并发用户/连接。对于那些使用连接池的应用程序，我们建议将 MAXAPPLS的值设置成比连接池的大小大 1 或 2(这样做只是为了当需要调用命令行连接时来同时做一些事情)。
（2）. 如何更改该参数
要更改 MAXAPPLS的值，请运行下面的命令：
- db2 -v update db cfg for DB_NAME using MAXAPPLS a_number
- db2 -v terminate
（3）. 调优步骤
当应用程序尝试连接数据库，但是连接到数据库的应用程序数已经达到了 MAXAPPLS的值时，会向应用程序返回下面这个错误，表明连接到该数据库的应用程序数已达到了最大值。
2。 AVG_APPLS
- SQL1040N The maximum number of applications is already connected to the
- database. SQLSTATE=57030
只有在应用程序发出复杂的SQL(例如连接、函数、递归等)命令时才更改它，否则让它一直为1。这可以帮助您估计在运行时可以为一个访问计划提供多少缓冲池。该参数应该设为一个较低的值，即 "Applications connected currently"的平均数量乘以复杂 SQL命令的百分比。
3。maxagents ， max_coordagents和max_connections
（1）maxagents：最大代理程序数配置参数，此参数指示可在任何给定时间接受应用程序请求的数据库管理器代理程序（Agent）（无论是协调代理进程还是子代理进程）的最大数目
（2）max_coordagents：最大协调代理进程数配置参数，此参数用来限制协调代理进程数或控制数据库中的工作负载。（也就是内存分配之类的）
（3）max_connections：最大客户机连接数配置参数，此参数控制可以与实例相连的最大应用程序数
（4）maxagents >= 所有库的maxappls之和，如果数据库实例大于NUMDB参数，则可考虑使用具有最大MAXAPPLS数值的NUMDB。
（5）maxappls = 5 * (节点数） +（使用Ｄａｔａ Ｌｉｎｋｓ Ｍａｎａｇｅｒ的活动应用程序数的峰值）
（6）官网的公式：maxappls = (number of connections set for the data source + number of connections in the session manager) multiplied by the number of clones.数据源最大连接数可以在WAS上查到， 而session manager最大连接数也可以在 WAS控制台——应用程序服务器——（server x）——已安装的应用程序——（应用程序名称）——会话管理里面看到
（7）max_coordagents和maxagents可以配置的一样
（8）当MAX_connections等于MAX_COORDAGENTS时，MAX_COORDAGENTS用以确定在服务器上可同时存在的协调代理程序的最大数目；
（9）当MAX_connections大于MAX_COORDAGENTS时，可能有比协调代理程序多连接来为他们提供服务。仅当有协调代理程序在为应用程序提供服务时，应用程序才处于活动状态，否则，应用程序处于不活动状态。来自活动应用程序的请求将由数据库协调代理程序来提供服务。来自不活动的应用程序的请求将会进行排队等待，直到指定数据库协调代理程序来为该应用程序提供服务，此时，应用程序变成活动的。
（10）对于分区数据库环境和江INTRA_PARALLEL设置为YES的环境，MAX_COORDAGENTS = maxagents-NUM_INITAGENTS;否则MAX_COORDAGENTS = maxagents
（11）对于未分区的数据库，并且未启用INTRA_PARALLEL,则MAX_COORDAGENTS = maxagents
http://book.51cto.com/art/200906/129050.htm
4。LOCKLIST 和MAXLOCKS（4和5转自http://book.51cto.com/art/200906/129034.htm）
LOCKLIST表明分配给锁列表的存储容量。每个数据库都有一个锁列表，锁列表包含了并发连接到该数据库的所有应用程序所持有的锁。"锁定"是数据库管理器用来控制多个应用程序并发访问数据库中数据的机制。行和表都可以被锁定。
MAXLOCKS定义了应用程序持有的锁列表的百分比，在数据库管理器执行锁升级之前必须填充该锁列表。当一个应用程序所使用的锁列表百分比达到 MAXLOCKS时，数据库管理器会升级这些锁，这意味着用表锁代替行锁，从而减少锁列表中锁的数量。当任何一个应用程序所持有的锁数量达到整个锁列表大小的这个百分比时，对该应用程序所持有的锁进行锁升级。如果锁列表用完了空间，那么也会发生锁升级。数据库管理器通过查看应用程序的锁列表并查找行锁最多的表，来决定对哪些锁进行升级。如果用一个表锁替换这些行锁，将不再会超出 MAXLOCKS值，那么锁升级就会停止。否则，锁升级就会一直进行，直到所持有的锁列表百分比低于MAXLOCKS。MAXLOCKS参数乘以 MAXAPPLS参数的值不能小于100。
注意：
虽然升级过程本身并不用花很多时间，但是锁定整个表(相对于锁定个别行)降低了并发性，而且数据库的整体性能可能会由于对受锁升级影响的表的后续访问而降低。
使用下列步骤确定所需锁列表：
每个数据库都有一个锁列表，该列表包含所有同时连接到数据库的应用程序所持有的锁。在32 位的平台上，一个对象上的第一个锁要求占 64 字节，而其他的锁要求占 32 字节。在64 位平台上，第一个锁要求占 112 字节，而其他锁要求占 56 字节。
注意：
也可以这样理解，S锁占32或56字节；X锁占64或112字节。
当一个应用程序使用的LOCKLIST的百分比达到 MAXLOCKS 时，数据库管理器将执行一次锁升级(lock escalation)，在这个过程中会将行锁换成单独的一个表锁。而且，如果 LOCKLIST 快要耗尽，数据库管理器将找出持有一个表上行锁最多的连接，将这些行锁换成表锁，以释放 LOCKLIST 内存。锁定整个表可以大大减少并发性，但死锁和锁等待的几率也增加了。
(1) 计算锁列表大小的下限：(512 * 32 * MAXAPPLS) / 4096。其中，512是每个应用程序平均所含锁数量的估计值，32 是对象(已有一把锁)上每把锁所需的字节数。
(2) 计算锁列表大小的上限：(512 * 64 * MAXAPPLS) / 4096。其中，64是某个对象上第一把锁所需的字节数。
(3) 对于您的数据，估计可能具有的并发数，并根据您的预计为锁列表(locklist)选择一个初始值，该值位于您计算出的上限和下限之间。
使用数据库系统监视器调优 MAXLOCKS。
设置 MAXLOCKS 时，请考虑锁列表的大小(LOCKLIST)：
MAXLOCKS = 100 * (512 锁／应用程序 * 32 字节／锁 * 2) / (LOCKLIST * 4096 字节)
该样本公式允许任何应用程序持有的锁是平均数的两倍。如果只有几个应用程序并发地运行，则可以增大 MAXLOCKS，因为在这种条件下锁列表空间中不会有太多争用。
5。LOCKTIMEOUT
LOCKTIMEOUT指定了应用程序为获取锁所等待的秒数。这有助于应用程序避免全局死锁。
如果将该参数设置成0，那么应用程序将不等待获取锁。在这种情形中，如果请求时没有可用的锁，那么应用程序立刻会接收到-911。
如果将该参数设置成-1，那么将关闭锁超时检测。在这种情形中，应用程序将等待获取锁(如果请求时没有可用的锁)，一直到被授予了锁或出现死锁为止。
（1）. 建议
设置 LOCKTIMEOUT 以快速检测由于异常情形而出现的等待，例如事务被延迟了(可能是由于用户离开了他们的工作站)。将它设置得足够高，这样有效的锁请求就不会因为高峰时的工作负载而超时，在高峰时等待获取锁的时间将延长。
在联机事务处理(OLTP)环境中，这个值从 30 秒开始。在只进行查询的环境中则可以从一个更大的值开始。无论哪种情况，都可以使用基准测试技术来调优该参数。
（2）. 如何更改这些参数
要更改锁参数，请运行以下命令：
- Db2 -v update db cfg for DB_NAME using LOCKLIST a_number
- db2 -v update db cfg for DB_NAME using MAXLOCKS b_number
- db2 -v update db cfg for DB_NAME using LOCKTIMEOUT c_number
- db2 -v terminate
（3）. 监控步骤
一旦锁列表满了，由于锁升级会生成更多的表锁和更少的行锁，因此减少了数据库中共享对象的并发性，从而降低了性能。另外，应用程序间可能会发生更多死锁(因为它们都等待数量有限的表锁)，这会导致事务被回滚。当数据库的锁请求达到最大值时，应用程序将接收到值为-912的SQLCODE。如果锁升级造成性能方面的问题，则可能需要增大 LOCKLIST参数或 MAXLOCKS参数的值。可以使用数据库系统监视器来确定是否发生了锁升级，跟踪应用程序(连接)遭遇锁超时的次数或者数据库检测到的所有已连接应用程序的超时情形。
首先，运行下面命令以打开针对锁的DB2 监视器：
- db2 -v update monitor switches using lock on
- db2 -v terminate
然后收集数据库快照：
- db2 -v get snapshot for database on DB_NAME
在快照输出中，检查下列各项：
- Locks held currently = 0
- Lock waits = 0
- Time database waited on locks (ms) = 0
- Lock list memory in use (Bytes) = 504
- Deadlocks detected = 0
- Lock escalations = 8
- Exclusive lock escalations = 12
- Agents currently waiting on locks = 0
- Lock Timeouts = 0
- Internal rollbacks due to deadlock = 0
如果"Lock list memory in use (Bytes)"超过定义的LOCKLIST 大小的50%，那么就增加 LOCKLIST 数据库配置参数中的4KB 页的数量。如果发生了 "Lock escalations>0"或 Exclusive lock escalations>0，则应该增加 LOCKLIST或者MAXLOCKS，抑或同时增加两者。查看 "Locks held currently"、 "Lock waits"、 "Time database waited on locks (ms)"、"Agents currently waiting on locks"和 "Deadlocks detected"中是否存在高值，如果有的话，就可能是差于最优访问计划、事务时间较长或者应用程序并发问题的症状。如果要发现死锁，那么需要创建一个针对死锁的事件监视器。事件监视器带有详细信息，以便查看当前正在发生的事情。锁升级、锁超时和死锁将表明系统或应用程序中存在某些潜在问题。锁定问题通常表明应用程序中存在一些相当严重的并发性问题，在增大锁列表参数值之前应当解决这些问题。指定应用程序在获得一个锁之前所等待的秒数，这可以帮助避免全局死锁情况的发生。如果该值为-1，则应用程序将会出现锁等待。对于生产系统中的OLAP，一开始为60 (秒)比较好；对于OLTP，大约为10 秒比较好。对于开发环境，应该使用-1，以识别和解决锁等待的情况。如果有大量的并发用户，则可能需要增加 OLTP 时间，以避免回滚。
如果 "Lock Timeouts"是一个较高的数，那么可能由以下原因造成：
LOCKTIMEOUT的值太低
某个事务持有锁的时间有所延长
锁升级
下面是一些控制锁列表大小的建议：
经常进行提交以释放锁；
如果要执行大量更新，更新之前，在整个事务期间锁定整个表(使用 SQL LOCK TABLE 语句)。这里使用了一把锁，从而防止其他事务妨碍这些更新，但对于其他用户它却减少了数据并发性。
使用 ALTER TABLE 语句的LOCKSIZE参数控制如何在持久基础上对某个特定表进行锁定；
在业务逻辑允许的情况下确保应用程序正在使用最低的隔离级别；
查看应用程序使用的隔离级别。使用可重复读隔离级别在某些情况下可能会导致自动执行表锁定。当有可能减少所持有共享锁的数量时，可以使用游标稳定性(Cursor Stability)隔离级别。如果没有损害应用程序完整性需求，那么可以使用未提交的读隔离级别而不是游标稳定性隔离级别，以进一步减少锁的数量。尽量使用 Cursor Stability 隔离级别(默认情况)，以便减少被持有的共享锁的数量(如果应用程序能够承受脏读，那么 Uncommitted Read 可以进一步减少锁)。
关于锁和并发的问题，请参考"第7章 锁和并发"。
6。DBHEAP
每个数据库实例都存在一个数据堆，数据库管理程序使用此数据库对处理所有连接到数据库的应用连接。这个堆中包含表、索引、表空间、缓冲池的控制信息，还包含日志缓冲区空间（LOGBUFSSZ）、目录高速缓存（CATALOOGCACHE_SZ)和其它实用程序（Utility）使用的临时空间。因此，DBHEAP大小的设定取决于很多变量。控制信息保存在堆中直到所有的应用程序断开与数据库的连接为止。 第一个应用连接创建的时候，数据库管理起就分配最小值的数据堆大小，根据需要该数据库对可以不断扩充直到达道DBHEAP指定的最大值。当增大DBHEAP相关变量如CATALOOGCACHE_SZ和LOOGBUFSZ的时候，需要同时增大 DBHEAP 的大小。
7。BUFFPAGE
BUFFPAGE是作者最长调整的DB2参数之一。缓冲池（BUfferPool）是在内存中开辟的对数据页（主要包括表中的行和索引条目）进行临时读取和修改的存储空间。数据库管理程序具有代理进程，代理进程可以从磁盘中检索数据页，并将他们放入缓冲池（预取程序），以及将修改过的数据页从缓冲池写回到磁盘（页清除器）。
缓冲池的开辟是为了改进数据库的性能，因为内存中数据的存取比磁盘要快得多，数据库管理程序进行磁盘Ｉ／Ｏ的次数越少，数据库的性能就越高。提高数据库性能的主要方法是避免等待磁盘Ｉ／Ｏ。如何创建缓冲池、配置数据库管理程序以及与缓冲池相关联的代理进程，将会影响数据库的性能。通过ＳＱＬ和配置参数，可以控制缓冲池的大小、用来将数据页移入和移出缓冲池的预取程序和页清除器的数目、数据页的大小，以及一次可以移动的数据页数。
一个或多个缓冲池的配置数数据库调优中最重要的部分之一，因为连接到数据库（不包括大对象和长生命周期数据）的所有应用程序的绝大多数数据操作都发生在这些缓冲中。一个数据库必须始终至少具有一个缓冲池。ＤＢ２提供了默认缓冲池（ＩＢＭＤＥＦＡＵＬＴＢＰ）这个缓冲之在数据库创建的时候就已经建立，可以直接使用或者改变之后再使用它。在ＳＹＳＣＡＴ。ＢＵＦＦＥＲＰＯＯＬＳ目录表中，如果某缓冲池对应的ＮＰＡＧＥＳ值为－１则使用ＢＵＦＦＰＡＧＥ参数来指定该缓冲池的大小，否则，ＢＵＦＦＰＡＧＥ参数将被忽略，系统将按照ＮＰＡＧＥＳ所指定的页面数来创建该缓冲池。
8。UTIL_HEAP_SZ
该参数指定 BACKUP、RESTORE和LOAD 实用程序可以同时使用的最大内存数。如果正在使用 LOAD，那么对于每个CPU，建议将UTIL_HEAP_SZ 设置成至少 10000 页。 为了提高backup、restore和load的速度，建议增大该参数。
9。SORTHEAP和SHEAPTHRES
SORTHEAP 是一个数据库配置参数，它定义了私有排序或共享排序所使用的私有内存页的最大数目。每个排序都有一个独立的排序堆，这是由数据库管理器在需要的时候分配的。通常，大家都能理解得很好的是，当一个排序所需的内存量超过了SORTHEAP时，就会发生排序溢出；理解得不够好的一点是，如果统计信息已过时，或者数据有偏差，并且没有收集到发布的统计信息，此时一旦 DB2 请求一个太小的堆，而实际的排序操作超出了所请求的量，也会发生溢出。因此，使统计信息保持最新十分重要。此外，应确保排序不是一个丢失的索引的结果。如果排序是私有排序，那么该参数会影响代理程序的私有内存；如果排序是共享排序，那么该参数将影响数据库的共享内存。每个排序都有单独的由数据库管理器按需分配的排序堆。在排序堆中对数据进行排序。如果由优化器来指导排序堆大小的分配，那么用优化器提供的信息来分配的排序堆的大小要小于由该参数所指定的排序堆大小。
SHEAPTHRES也是一个数据库管理器配置参数。私有排序和共享排序所使用内存的来源不一样。共享排序内存区的大小是在第一次连接到数据库时根据 SHEAPTHRES值以静态方式预先确定的。私有排序内存区的大小则是不受限制的。对于私有排序和共享排序，应用 SHEAPTHRES参数的方式也不同：
对于私有排序，SHEAPTHRES 是对私有排序在任何给定的时间可以消耗的全部内存的实例级"软"限制。当实例的总私有排序内存消耗量达到这一限制时，为其他进入的私有排序请求而分配的内存会大大减少。
对于共享排序，SHEAPTHRES 是对共享排序在任何给定的时间可以消耗的全部内存的数据库级"硬"限制。当达到这一限制时，不允许有其他共享排序内存请求，直到总的共享内存消耗量回落到 SHEAPTHRES 所指定的限制之下。
使用排序堆的操作示例包括内存中表的哈希连接和操作。SHEAPTHRES的显式定义可以防止数据库管理器将过多数量的内存用于大量排序。
（1）. 建议
使用数据库系统监视器来跟踪排序活动；
使用合适的索引使排序堆的使用降到最低；
当需要频繁进行大型排序时，增加SORTHEAP的值；
如果增加 SORTHEAP，请确定是否还需要调整数据库管理器配置文件中的SHEAPTHRES参数；
优化器使用排序堆大小来确定存取路径。在更改该参数后请考虑重新绑定应用程序(使用 REBIND PACKAGE 命令)；
理想情况下，应当将排序堆阈值参数(SHEAPTHRES)合理地设置为在数据库管理器实例中设置的SORTHEAP参数最大值的倍数。该参数至少应当是实例中任何数据库所定义的最大 SORTHEAP的两倍。
（2）. 如何更改这些参数
要更改 SORTHEAP和SHEAPTHRES的值，请运行以下命令：
- -- SORTHEAP是数据库级别参数--
- db2 -v update db cfg for DB_NAME using SORTHEAP a_value
- -- SHEAPTHRES是实例级别参数--
- db2 -v update dbm cfg using SHEAPTHRES b_value
- db2 -v terminate
（3）. 调优步骤
对于OLTP 应用程序，不应该执行大型排序。大型排序在CPU和I/O 资源方面的消耗成本太高了。通常，SORTHEAP的默认大小(256个4KB 页)就足够了。事实上，对于高并发性 OLTP，您可能希望降低这个默认值。当需要进一步研究时，可以发出下面这条命令：
- db2 -v update monitor switches using sort on
然后，让您的应用程序运行一会儿，然后运行：
- db2 -v get snapshot for database on sample
查看如下输出结果：
- Total sort heap allocated = 0
- Total sorts = 1
- Total sort time (ms) = 0
- Sort overflows = 0
- Active sorts = 0
- Commit statements attempted = 1
- Rollback statements attempted = 0
- Dynamic statements attempted = 4
- Static statements attempted = 1
- Binds/precompiles attempted = 0
根据该输出，可以计算每个事务的排序数目，并计算溢出了可用于排序的内存的那部分排序的百分比。
- SortsPerTransaction = (Total Sorts) / (Commit statements attempted +
- Rollback statements attempted)
- PercentSortOverflow = (Sort overflows * 100 ) / (Total sorts)
经验：如果 SortsPerTransaction 大于5，它可能表明每个事务的排序太多。如果 PercentSortOverflow 大于3%，那么可能发生了严重的、未曾预料到的大型排序。发生这种情况时，增加 SORTHEAP 只会隐藏性能问题，却无法修正它。这个问题的正确解决方案是通过添加正确的索引来改进有问题的SQL 语句的存取方案。对于OLTP，一开始最好是设为128；对于OLAP，则设置在4096 - 8192 之间。如果有很多的"Sort overflows" (两位数)，那么很可能需要增加 SORTHEAP。如果 "Number of hash join overflows" 不为0，则按照 256 逐次增加 SORTHEAP，直到它为0。如果 "Number of small hash join overflows" 不为0，则按10%的比例逐次增加 SORTHEAP，直到小散列连接溢出数为0。
10。 STMTHEAP句堆用于在SQL 语句编译期间作为编译器的工作区。对于每一条要处理的SQL 语句，都要从该区域分配和释放空间。如果收到警告信息或错误信息，那么可以按 256 逐次增加该参数的值，直到错误消失。 此参数对数据库性能影响重大，建议合理调整，初始值建议为8192。
11。LOGPRIMARY、LOGSECOND和LOGFILSZ
（1）LOGPRIMARY指定要预先分配空间的主日志文件的数量，而LOGSECOND则是按照需要来分配空间的。LOGFILSIZ用于定义每个日志文件的大小。
如果 "Secondary logs allocated currently"的值很大，那么就可能需要增加 LOGFILSIZ 或 LOGPRIMARY (但要确保 LOGPRIMARY加上LOGSECOND的和不超过 256)。还可以使用 "Maximum total log space used (Bytes)"来帮助指出对日志文件空间(主日志加上从日志)的依赖性。
日志文件的大小对灾难恢复有一定的影响，因为在灾难恢复中要使用日志发送(log shipping)。日志文件比较大时，性能会更好些，但是会潜在地加大丢失事务的几率。当主系统崩溃时，最近的日志文件及其事务可能无法发送到从系统，因为在失败之前没有关闭该文件。日志文件越大，随着日志文件的丢失，丢失事务的可能性也越大。
（2）如果 LOGSECOND=-1(此时数据库将配置为具有无限活动日志空间），则 LOGPRIMARY应小于等于256（3）如果LOGSECOND！=-1，则LOGPRIMARY+LOGSECOND应小于等于256
12。LOGBUFSZ
LOGBUFSZ 是一个数据库配置参数，是用于日志缓冲区的参数。这个参数允许指定用作在将日志记录写到磁盘之前的缓冲区的数据库堆(DBHEAP)的数量。当提交一个事务或者日志缓冲区已满时，就要将日志记录写入磁盘。对日志记录进行缓冲将导致将日志记录写入磁盘的活动不再那么频繁，但每次要写的日志记录会更多。它允许您指定数据库共享内存的大小以用于在将日志记录写到磁盘之前这些记录的缓冲区。当下列事件之一发生时会将日志记录写入磁盘：
事务提交；
日志缓冲区已满；
其他某个内部数据库管理器事件发生。
将日志记录存在缓冲区将产生更加有效的日志文件 I/O，这是因为这样一来可以降低将日志记录写入磁盘的频率，同时每次可写更多的日志记录。如果对专用的日志磁盘有相当多的读操作，或者希望有较高的磁盘利用率，那么可以增加这个缓冲区的大小。当增加这个参数的值时，也要考虑 DBHEAP参数，因为日志缓冲区使用的空间由 DBHEAP参数所控制。
（1）. 如何更改该参数
我们发现该参数的默认值为8(4KB页)，这对于OLTP数据库而言通常不够大。LOGBUFSZ的最佳值为128或256个4KB 页。例如，可以使用下面的命令来更改该参数的值：
- db2 -v update database cfg for DB_NAME using LOGBUFSZ 256
- db2 -v terminate
（2）. 调优步骤
通过查看下面代码中所示各行，使用数据库快照来确定 LOGBUFSZ参数的值是否为最佳值：
- Log pages read = 0
- Log pages written = 12644
对于OLTP，一开始以至少256页为佳；对于OLAP，则以 128 页为佳。如果常常看到"Log pages read"大于0，那么可能需要增加这个值。如果发生了回滚，也可能要读取日志页。一般而言，"log pages read"和"log pages written"之比应当尽可能小。理想情况下，"log pages read"的值应为0，而"log pages written"的值应很大。当 log pages read 太多时，意味着需要一个较大的LOGBUFSZ。
如果在试图增加 LOGBUFSZ 时收到一个错误，那么可以按相同数量增加 DBHEAP，然后再次尝试。
13。 MAXFILOP这个参数用于指定每个数据库代理所能打开的最大文件数。如果打开一个文件时被打开的文件数超出了这个值，则要关闭该代理正在使用的一些文件。过度的打开和关闭都会降低性能。SMS 表空间和 DMS 表空间文件容器都被视作文件来对待。通常 SMS 使用的文件要更多一些。
增加该参数的值，直到 "Database files closed"为0。六、应用服务器相关参数的解释
1。ＳＱＬ语句缓存属性
一个语句是一个可以执行导入该语句的ＳＱＬ字符串的ＪＡＶＡ类。全局的动态语句缓存是在服务器内存中开辟的一块用于存储最常用的数据库访问计划的区域。在准备每个语句之前，服务器会自动地搜索缓存中是否已经由该访问计划创建和这个语句完全匹配的ＳＱＬ语句。如果已经存在这样的访问计划，服务器不再需要重新生产对应的访问计划，转而直接使用缓存中的访问计划。语句缓存的大小可以在WebSphre应用服务器的数据源属性中进行谁对那个。值为0意味着取消语句缓存功能。过大的语句缓存也会影响数据库的性能。
七、说明
1。本系列读书笔记主要来自构建高性能WebSphere企业级应用一书
2。部分内容来自http://book.51cto.com/art/200906/128983.htm
3。此文主要用于自己梳理知识点所用，如果侵犯了上述1，2的作者的权益，请告知，谢谢！
1109
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
