LUSTERFACTOR=-1.000000, C
LUSTERRATIO=100, SEQUENTIAL_PAGES=0, DENSITY=0, AVERAGE_SEQUENCE_GAP=0.000000, A
VERAGE_SEQUENCE_FETCH_GAP=0.000000, AVERAGE_SEQUENCE_PAGES=0.000000, AVERAGE_SEQ
UENCE_FETCH_PAGES=0.000000, AVERAGE_RANDOM_PAGES=1.000000, AVERAGE_RANDOM_FETCH_
PAGES=0.000000, NUMRIDS=37, NUMRIDS_DELETED=0, NUM_EMPTY_LEAFS=0 WHERE INDNAME =
’NAME_IND’ AND INDSCHEMA = ’SKAPOOR ’ AND TABNAME = ’STAFF’ AND TABSCHEMA = ’SK
APOOR ’
DB21034E The command was processed as an SQL statement because it was not a
valid Command Line Processor command. During SQL processing it returned:
SQL1227N The catalog statistic "37" for column "FULLKEYCARD" is out of range
for its target column, has an invalid format, or is inconsistent in relation
to some other statistic. Reason Code = "8". SQLSTATE=23521
正如您可以看到的,上面用于索引 NAME_IND 的 UPDATE 语句失败了,因为 FULLKEYCARD 大于表的基数(CARD)。正如通过 db2look.out 文件中的下列更新语句可以看到的,CARD 是 35:
UPDATE SYSSTAT.TABLES
SET CARD=35,
NPAGES=1,
FPAGES=1,
OVERFLOW=0,
ACTIVE_BLOCKS=0
WHERE TABNAME = ’STAFF’ AND TABSCHEMA = ’SKAPOOR ’;
现在,再次以解释模式运行相同的查询:
db2 "select name from staff where id=10 order by name"
并生成访问计划。您将看到它是不同的:
Access Plan:
-----------
Total Cost: 12.972
Query Degree: 1
Rows
RETURN
( 1)
Cost
I/O
|
1
TBSCAN
( 2)
12.972
1
|
1
SORT
( 3)
12.9708
1
|
1
TBSCAN
( 4)
12.9682
1
|
35
TABLE: SKAPOOR
STAFF
该示例显示,如果在表上发生 WRITE 活动时运行 RUNSTATS,统计数据就可能与本示例中的不一致。因此,用于更新统计数据的 UPDATE 语句可能失败并产生 SQL1227N 错误消息。所有的 UPDATE 语句都运行成功十分重要,如果存在不一致性,就应该进行修理并重新运行。本例中,解决方案是将 KEYCARDS 和 NUMRIDS 从 37 重新修改为 35。
示例 3:
您需要在单分区的环境中模拟生产中的整个
数据库以进行测试。
注意:如果测试中的
数据库名与生产中的不同,那么可能需要修改每个 db2look 输出中的
数据库名。
步骤 1:使用 -l 选项收集 db2look,以收集表空间/缓冲池/数据库节点组信息。
db2look -d <dbname> -l -o storage.out
修改表空间信息以适应您的测试环境。例如,在生产中,您具有下列表空间:
------------------------------------
-- DDL Statements for TABLESPACES --
------------------------------------
CREATE REGULAR TABLESPACE DMS1 IN
DATABASE PARTITION GROUP IBMDEFAULTGROUP
PAGESIZE 4096 MANAGED BY
DATABASE
USING ( FILE ’/data/dms1’20000,
FILE ’/data/dms2’20000,
FILE ’/data/dms3’20000)
EXTENTSIZE 32
PREFETCHSIZE 32
BUFFERPOOL IBMDEFAULTBP
OVERHEAD 12.670000
TRANSFERRATE 0.180000
DROPPED TABLE RECOVERY ON;
如果测试上没有设置相同的路径,那么就要修改上面的位置。如果您仅仅计划模拟环境,而不要复制整个数据,那么就减小文件的大小,并在必要时使用较少容器。如果没有创建相同的缓冲池,那么您还可能修改缓冲池名称。缓冲池必须具有相同的页面大小(pagesize)。不要修改表空间的页面大小。一旦处理了这些并创建了
数据库,就运行 storage.out 文件:
db2 -tvf storage.out
如果需要,就重新定向输出以确保都成功运行了。例如:
db2 -tvf storage.out > storage_results.out
步骤 2:从生产中收集配置和环境变量信息,并在测试系统上运行它:
db2look -d sample -f -fd -o config.out
请记住,在 MPP 环境中,这将为运行该命令的节点收集该信息。如果不同的
数据库分区上的 DB2 注册表和
数据库以及
数据库管理器配置不同,您将需要为每个节点分别收集该信息。然而,如果测试中无法具有与生产中相同的分区,那么就从生产中执行该查询的节点中收集该信息,然后在测试中使用该信息。
请注意,如果测试中具有不同的分区数目,那么您的模拟将有所欠缺。
在测试系统上,运行 config.out 文件,如下:
db2 -tvf config.out
上面考虑到优化器将使用 db2fopt 信息来查看所分配的总的缓冲池和排序堆,现在将成为测试环境中的设置。而且,这也是在测试中由于内存约束而不具有与生产中相同的缓冲池以及排序堆时所使用的技术。同时,本文前面所讨论的配置参数以及环境变量也将进行更新。
步骤 3:当模拟整个
数据库时,从生产中收集所有对象的 DDL 信息,并在测试中运行 db2look。
在生产中:
db2look -d sample -e -a -m -o db2look.out
在测试中:
db2 -tvf db2look.out
为了看到输出结果,可发出:
db2look -tvf db2look.out > db2look.results
一旦完成了以上步骤,就请确保在测试中将 dbheap
数据库配置参数设置为与生产中相同的值。
步骤 4:使用 db2exfmt 从测试和生产中获得访问计划,并确保下列内容与生产中的相同:
Database Context:
----------------
Parallelism: None
CPU Speed: 4.762804e-07
Comm Speed: 100
Buffer Pool size: 128500
Sort Heap size: 128
Database Heap size: 5120
Lock List size: 12250
Maximum Lock List: 10
Average Applications: 4
Locks Available: 78400
Package Context:
---------------
SQL Type: Dynamic
Optimization Level: 3
Blocking: Block All Cursors
Isolation Level: Cursor Stability
---------------- STATEMENT 1 SECTION 201 ----------------
QUERYNO: 1
QUERYTAG: CLP
Statement Type: Select
Updatable: No
Deletable: No
Query Degree: 1
现在,查看访问计划。如果它们是相同的,那么您就成功地重新创建了访问计划。还请注意,您还应查看 db2exfmt 输出结尾以验证表空间配置是匹配的。
示例 4:
生产:MPP,4 个逻辑分区/ 16 个物理分区。
测试:MPP,4 个逻辑分区,每个逻辑分区中只有 4 台可用的物理机器。
查询中所涉及的表、视图/MQT。
本示例中,该模拟可能不会准确工作。测试和生产中的分区数目必须相同。然而,您仍可以尝试重新创建,只是它不会正确。
因此,您必须向测试环境添加 16*4=64 个分区,以便重新创建正确。测试环境中不需要 16 台物理机器;即您可以具有 4 台物理机器,每台物理机器具有 16 个逻辑分区。这由您来决定,但总共必须有 64 个逻辑分区,与生产中相同。
因此现在在进行修改向测试环境添加相同数目的逻辑分区之后,测试环境看上去将像原