| Quando uma tabela é movida de uma Storage Area para outra, é criada uma única transação, de maneira que, caso a ação sofra interrupção o gerenciador do banco pode retorná-lo automaticamente a um estado consistente.
Durante o processo de movimentação, todos os registros da tabela origem são lidos, e registros equivalentes são criados na tabela destino, e finalmente os registros da tabela origem são eliminados. Todos os registros de índice da origem são eliminados e novos registros são criados no destino, quando utilizada a opção de transferir também os índices da tabela. Além disso, também acontecem operações de alocação/liberação interna de espaço. Todas estas operações são registradas no before image e, se estiver habilitado, também no after image. Como conseqüência o arquivo de before image pode crescer bastante, algumas vezes mais que o tamanho ocupado pelos registros da tabela e seus índices. No caso do after image podem ocorrer inúmeras trocas entre as extensões disponíveis enquanto as notas são gravadas. Não existe no momento uma maneira fácil de calcular antecipadamente o espaço que será utilizado no processo. A maneira mais simples de investigar melhor a questão, nem sempre possível, é criar outra base, que contenha apenas um subconjunto de registros da tabela a ser movida, executar o processo e acompanhar o volume de informações registradas. Considerando que a base criada para efetuar o protótipo contenha 10% atual tamanho da tabela, realizar o processo sobre a tabela toda utilizará 10 vezes mais espaço, sendo esta, ainda assim, uma estimativa. Disponibilize espaço em disco para o seu arquivo de Before Image. Caso o After Image esteja habilitado, esteja certo de que no processo de transição entre as extensões esteja sendo efetuado o backup, liberando as que vão sendo preenchidas com a agilidade necessária. Isto evitará que o banco seja derrubado por falta de espaço onde gravar as notas de AI. Segue um exemplo que apresenta uma estimativa de quanto se espera que o BI cresça: Digamos que a tabela tenha 300MB e contém registros de 100 Bytes, em média. Portanto, existem na tabela 3.000.000 de registros. Para criar um registro na nova storage area é necessária a escrita de uma nota no BI de aproximadamente 200 Bytes. Para eliminar um registro na storage area antiga será escrita outra nota de BI de aproximadamente 200 Bytes, mais 100 Bytes para registrar uma nota de localização(placeholder). Adicionalmente, serão necessárias notas de alocação de espaço e de atualização da RM Chain. Considere que serão necessários outros 100 Bytes por registro para este armazenamento. Isto tudo soma 600 Bytes em notas de BI, por registro. 600 * 3.000.000 perfazem 1.800.000.000 Bytes. Este cálculo não inclui as entradas de índice. O número de notas necessárias para os índices depende do número de índices. Para cada índice, uma entrada é gravada no BI relativa à eliminação de um registro de dados na storage area origem, e uma nova gravação é feita relativa à nova entrada que aponta para o registro na nova storage area. Cada índice tem 3.000.000 de entradas. Considere a necessidade de gravar 100 Bytes no arquivo de BI para eliminar uma entrada de índice, e outros 100 Bytes para registrar a criação de uma nova. Com isto teremos: 200 *3.000.000, ou seja, mais 600.000.000 Bytes, por índice, gravados no BI. Estes números estimam o crescimento do arquivo de BI: 1.800.000.000 + 600.000.000 = 2.400.000.000 Bytes Utilize o comando a seguir para executar o tablemove: proutil db-name -C tablemove table-name table-area [index-area] onde, table-area – especifica o nome da storage area para onde a tabela será movida index-area – especifica o nome da storage area para onde os índices da tabela serão movidos. Nota: 1. considerar que o utilitário iniciará a movimentação após conseguir todos os locks necessários. 2. movimentar dados e índices no mesmo momento é mais rápido. 3. utilizar a VST _UserStatus para acompanhar o progresso da movimentação. | 
Assinar feeds (RSS)