Início / dba / Perguntas / 307427
Accepted
jrdba123
Asked: 2022-02-14 10:14:38 +0800 CST

Oracle - Arquivamento de grandes tabelas

  • 772

Versão: Oracle 12cR2 EE

A tabela contém os seguintes tipos de coluna: NUMBER, CLOB, NVARCHAR2, TIMESTAMP, VARCHAR2

Tamanho da mesa: 95 GB

Contagem de linhas da tabela: 20 milhões

Tabela particionada? Não

Índices na tabela: existe apenas uma chave primária como índice na tabela.

Dependências: existe apenas um gatilho "antes de cada linha (inserir)" como dependência na tabela.

Restrições: existem 3 restrições (1 delas é chave primária e outras são checadas).

Queremos arquivar esta tabela. No entanto, não consegui decidir como o arquivamento deveria ser feito para uma tabela tão grande. Seria um pesadelo mover registros antes de uma determinada data para uma nova tabela com CTAS e, em seguida, excluir esses registros importados na tabela existente.

Acho que a melhor maneira seria fazer o intervalo da tabela particionado por mês (estou aberto a quaisquer ideias se você tiver soluções melhores).

Algumas perguntas pré-operação e sequência:

  1. Existe uma maneira de saber de antemão quanto arquivo irá gerar durante o particionamento de uma tabela desse tamanho?
  2. Temos a possibilidade de calcular antecipadamente a duração do processo?
  3. Seria uma boa opção interromper outros trabalhos de banco de dados que serão carregados durante o processo?
  4. É necessário fazer uma alteração no índice de chave primária para a operação ou outras dependências ou gatilhos?

Para após o processo:

  1. Causa carga pesada no banco de dados quando partições grandes são descartadas?

  2. Por exemplo, é possível configurar um pedido assim; podemos manter apenas os dados dos últimos 3 ou 6 meses na tabela principal e mover as partições mais antigas para a tabela de arquivo todos os meses? É correto usar apenas o método de importação de exportação ao migrar?

  3. A partição migrada será eliminada do processo de migração. Haverá um problema com base no arquivo gerado ao fazer isso?

Obrigada.

Cumprimentos.

oracle partitioning

1 respostas

  1. Best Answer

    O particionamento de intervalo deve ser o método apropriado para isso. Se você puder cuidar para que a maior parte do aplicativo também leve isso em consideração (ou seja: suas consultas devem SEMPRE conter os critérios de partição na cláusula WHERE), então isso acelerará as coisas.

    pré-operação

    1. Na verdade não. Eu criaria um banco de dados clone em outro sistema (semelhante) e o testaria lá - isso deve responder à maioria das suas perguntas.
    2. veja 1, veja v$session_longops. Não que essas previsões sejam 100% precisas, mas podem dar uma ideia.
    3. Se possível, sim. Desde 12.2 você pode particionar uma tabela diretamente online, então na verdade você ainda pode usá-la - mas isso não acelera as coisas, naturalmente
    4. Isso não deve ser necessário

    pós operação:

    1. sem chaves estrangeiras e gatilhos, não. Se você desligá-los, não vai.
    2. Com o particionamento de intervalo no nível do mês, isso não deve ser difícil. O método clássico é mover esses dados para um DWH e o acesso é via link de banco de dados, se necessário. Não use export (espero que você queira dizer expdp), consulte https://docs.oracle.com/en/database/oracle/oracle-database/12.2/vldbg/evolve-nopartition-table.html
    3. não, se você usar alter table drop partition update global indexes.
    • 1

relate perguntas