O teste aqui descrito foi realizado na versão 11.10.

Parâmetro utilizado ONLIDX_MAXMEM

1. A tabela que terá o índice criado não pode ter nenhum lock exclusivo.
2. Realiza um checkpoint.
3. Identifica como está particionada (fragmentos) a tabela e cria threads/buffer chamados "pimage_<partnum>" e "ulog_<partnum>" onde:
   PIMAGE: Pré-Image, são as paginas Before Images dos dados modificados durante a criação do indice.
   ULOG: Updator Log, contém os buffers modificados (dirty) durante a criação do índice e aplica estas modificações na tabela após a finalizar o processo
   
4. Ao finalizar a criação do indice, as paginas atualizadas (ulog) são aplicadas ao novo indice.

Observações

Se a quantidade de memória alocada for insuficiente (ONLIDX_MAXMEM) o banco grava temporariamente todo o buffer em disco (dbspace do indice e da tabela) portanto tomar cuidado para não subestimar a quantidade de memória alocada e o espaço em disco.

Exemplos

• Exemplo A - testado na prática
  Situação: Memória configurada para 64K, tabela RAW no dbspace A, indice criado no dbspace B, update executado em paralelo.
  Resultado: Buffers do pimage e ulog extrapolaram os 64K, algumas páginas pimage (nomeadas com partnum da tabela) foram alocadas no mesmo dbspace da tabela e algumas páginas ulog foram alocadas no dbspace do índice (nomeadas com partnum do indice). Indice foi criado com vários extents quebrados e com espaço livre entre eles (provavelmente por causa do pequenos pedações alocado pelo ulog durante o processo)
  
• Exemplo B - testado na prática
  Situação: Idem exemplo A, porém sem rodar update em paralelo e com 5MB alocados para memória
  Resultado: Durante o processo alocou 4 paginas para o indice, 8 paginas pra o ulog_<partnum> no dbspace A e 8 paginas para o pimage no dbspace B. Finalizou o processo deixando o indice "quebrado" em 2 extents (um de 4 paginas e outro com o restante) sendo que ficou 8 paginas livre entre eles (que era do ulog).
  
• Exemplo C - testado na prática
  Situação: idem situação B, porém com a tabela em modo [i]Standard/[i] (utilizando log)
  Resultado: Idem situação B, mas o processo foi abortado devido erro de long transaction.
  

Média:

0

Ainda não votado

Sua avaliação: Selecione a avaliaçãoCancelar a avaliaçãoPoorOkayBomGreatAwesome

Sua avaliação: Nenhum