Dado o seguinte cenário:
DB1:
EXPORT TO T.IXF OF IXF ... modified by codepage=... SELECT * FROM T;
DB2:
CREATE TABLE T (...) COMPRESS YES ADAPTIVE ORGANIZE BY ROW;
CREATE INDEX ... ON T (...) COMPRESS YES;
...
LOAD FROM T.IXF OF IXF INSERT INTO T (...);
Os índices são os mesmos no DB1 e no DB2, além de serem compactados no DB2, e a proporção do cluster parece boa no DB1 (não tenho certeza se isso importa). A página de código difere entre DB1 e DB2
Há algum ponto em fazer uma reorganização após o carregamento? Eu encontrei alguns artigos de Z que parecem sugerir que a maneira como os dados são exportados é importante (já que ZI não leu isso com atenção, então não sei se isso é mais relevante em Z e/ou LUW) .
Eu tentei em um número bastante grande de tabelas e fiz um REORGCHK após o carregamento e tudo parece bem. Comparando CALL GET_DBSIZE_INFO(?, ?, ?, 0)
antes e depois do REORG mostra uma ligeira diminuição no tamanho (<1%), mas não sei se isso é uma coincidência.
Existe alguma situação específica em que um REORG seria benéfico após o carregamento em uma tabela vazia?
Db2 para LUW
REORG
de tabelas compactadas comRESETDICTIONARY
pode ser benéfico após o carregamento inicial, porque durante o carregamento o dicionário de compactação em nível de tabela é construído usando uma amostra de dados de entrada, o que significa que, se seus padrões de dados estiverem distribuídos de forma desigual pelo arquivo de entrada, o dicionário pode não ser o ideal .REORG
usará uma amostra maior (se não todos os dados) para construir o dicionário.Fora isso,
REORG
depoisLOAD
é desnecessário.O Db2 para z/OS é diferente porque nele cada tabela teria um índice de clustering (definido implicitamente se não declarado explicitamente), e se seu arquivo de entrada não estiver ordenado de acordo com o índice de clustering da tabela de destino, o fator de clustering após o carregamento será ruim .