主页 / dba / 问题 / 312877
Accepted
Lennart - Slava Ukraini
Asked: 2022-06-03 09:54:09 +0800 CST

admin_move_table，表卡在 CLEANUP

  • 772

我正在考虑将许多日志表转换为范围分区，主要目的是通过分离和归档历史数据来减小数据库的大小。过程如下：

CALL SYSPROC.ADMIN_MOVE_TABLE('S','T1','', '', '', '', '',
'(ACTION_TIME) (STARTING FROM (''2000-01-01-00.00.00.000000'') ENDING AT (''2029-12-31-23.59.59.999999'') EVERY 1 YEAR)', '', 'COPY_USE_LOAD', 'MOVE' );

...

CALL SYSPROC.ADMIN_MOVE_TABLE('S','T120','', '', '', '', '',
'(ACTION_TIME) (STARTING FROM (''2000-01-01-00.00.00.000000'') ENDING AT (''2029-12-31-23.59.59.999999'') EVERY 1 YEAR)', '', 'COPY_USE_LOAD', 'MOVE' );

为简单起见，在此测试期间，我没有对每个表 (pk + ts) 上的索引做任何事情，它们与以前保持在同一个表空间中。所有表都使用这个表空间作为它们的索引

似乎工作正常，虽然我收到了一些神秘的警告。对于我得到的每张桌子：

SQL0206N "STATSPROFTYPE" is not valid in the context where it is used.

对于一些临时表（似乎是带引号的名称以小写字母结尾的表），我收到了有关 runstats 的其他投诉。

做了一些测试，表格似乎可以访问。

然后我分离了旧分区，例如：

for t in $(db2 -x "select rtrim(tabschema) || '.' || rtrim(tabname) from SYSCAT.DATAPARTITIONS where tabname like '%_LOG' group by tabschema, tabname having COUNT(datapartitionname) > 1"); do
    for p in part{0..18}; do 
        db2 "alter table $t detach partition $p into ${t}_$p"; 
        db2 "drop table ${t}_$p"; 
    done 
    # db2 "reorg table $t";
    db2 "runstats on table $t with distribution and sampled detailed indexes all"
done

仍然可以访问所有表，但是如果我查询：

db2 "SELECT substr(tabschema,1,20), substr(tabname,1,60), substr(VALUE,1,10) FROM SYSTOOLS.ADMIN_MOVE_TABLE WHERE KEY='STATUS'"

所有表的值都是 CLEANUP。我离开了几个小时，数据库中没有任何活动，但表保持不变。平均而言，我可能删除了这些表中 50% 的行，但大小根据：

db2 "CALL GET_DBSIZE_INFO(?, ?, ?, -1)"
...
Parameter Name  : DATABASESIZE
Parameter Value : 769891516416

没有减少。

由于缺乏想法，我遍历了表并重新组织了每个表和所有索引，但它似乎没有改变任何东西。

表长时间处于这种状态是否正常？在迁移下一个表之前等待 CLEANUP 会有所帮助吗？

db2 db2-luw

1 个回答

  1. Best Answer

    事实证明，备份来源的数据库不 db2updv115正确。这反过来导致statsproftypeinsysibmadm.ADMINTABINFO不存在，并且当 ADMIN_MOVE_TABLE 尝试访问它时进程停止。

    恢复数据库、db2updv115 并重新绑定后，ADMIN_MOVE_TABLE 似乎按预期工作。

    • 0

相关问题