Estou procurando converter várias tabelas de log para particionamento de intervalo, o objetivo principal é reduzir o tamanho do banco de dados desanexando e arquivando dados históricos. Processo se parece com:
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' );
Por questões de simplicidade durante este teste, não fiz nada sobre o índice em cada tabela (pk + ts), eles permanecem no mesmo tablespace de antes. Todas as tabelas usam este tablespace para seus índices
Parece funcionar bem, embora eu receba vários avisos misteriosos. Para cada tabela eu recebo:
SQL0206N "STATSPROFTYPE" is not valid in the context where it is used.
e para algumas das tabelas temporárias (que pareciam ser tabelas com nomes entre aspas terminando com letras minúsculas), recebi outras reclamações sobre runstats.
Fiz alguns testes e as tabelas pareciam acessíveis.
Então eu separei partições antigas como:
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
Ainda assim, todas as tabelas são acessíveis, mas se eu consultar:
db2 "SELECT substr(tabschema,1,20), substr(tabname,1,60), substr(VALUE,1,10) FROM SYSTOOLS.ADMIN_MOVE_TABLE WHERE KEY='STATUS'"
Todas as tabelas têm um valor de CLEANUP. Deixei por algumas horas, não há atividade no banco de dados, mas as tabelas permanecem as mesmas. Em média, provavelmente removi 50% das linhas nessas tabelas, mas o tamanho de acordo com:
db2 "CALL GET_DBSIZE_INFO(?, ?, ?, -1)"
...
Parameter Name : DATABASESIZE
Parameter Value : 769891516416
não é reduzido.
Por falta de ideias, dei um loop nas tabelas e reorganizei cada tabela e todos os índices, mas isso não parece mudar nada.
É normal que as tabelas permaneçam nesse estado por um longo período de tempo? Ajudaria esperar pelo CLEANUP, antes de migrar a próxima tabela?
Descobriu-se que o banco de dados de onde o backup se originou não foi
db2updv115
corretamente. Isso, por sua vez, levou a questatsproftype
nãosysibmadm.ADMINTABINFO
existisse, e o processo parou quando ADMIN_MOVE_TABLE tentou acessá-lo.Após restaurar o banco de dados, db2updv115 e religar, ADMIN_MOVE_TABLE parece funcionar conforme o esperado.