Copiando 100 bilhões de registros por dia para a Oracle - como?

2

Recebi uma solicitação para disponibilizar um banco de dados de 100 bilhões de registros na Oracle. A otimização usando a replicação não é uma opção, infelizmente, então eu acho que a solução mais fácil é criar um novo banco de dados Oracle e copiar todos os dados, e fazer isso uma vez por dia.

Que tipo de servidor Oracle faria isso bem? Existe alguma coisa específica que eu preciso cuidar a esse respeito?

    
por Lars D 26.11.2009 / 11:14

6 respostas

5

Não há detalhes suficientes para dar uma resposta de qualidade, mas acho que 'servidor' vai ser 'servidores'.

Se você tiver 100.000.000.000 de registros em 100 bytes cada, serão 9.536.743 MB por dia sem qualquer E / S incidental para indexação, etc. Divida isso pelo número de segundos em um dia e obtenha 110 MB por segundo. Mesmo isso está assumindo distribuição uniforme e 24 horas completas. Isso está certo no máximo teórico para o GigE.

Em outras palavras, você estará maximizando a largura de banda 'normal' e a E / S de disco mesmo com essas suposições simples.

Algo me diz que você realmente quer pensar sobre esse design.

    
por 26.11.2009 / 11:38
3

Eu acho que para esse tipo de trabalho vale a pena chamar Oracle ...

    
por 26.11.2009 / 15:22
2

Eu compraria o seguinte:

HP DL795 G6 com Opterons 8 x 6 núcleos, 64 GB de memória, RedHat de 64 bits, NICs ethernet dual de 10 Gbps, 2 controladoras HP P800 SAS conectadas localmente a oito MSA70s, cada uma repleta de discos SAS de 25 x 146 GB 2,5 "6G 15krpm .

Eu gosto de corrigir problemas de desempenho com hardware:)

Se isso não acontecer, você terá que ir para algo muito mais caro e / ou fragmentar a coisa.

    
por 26.11.2009 / 11:31
1

Parece que o exadata v2 deve mais do que facilmente fazer o trabalho. Vejo link e link

    
por 26.11.2009 / 12:31
0
  1. Datapump. Paralelizar.

  2. Se não for replicação, que tal um banco de dados de reserva? Você faz uma cópia uma vez e, em seguida, aplica as alterações de maneira assíncrona, de modo que, em caso de falha, a principal não sente nada. Você obtém somente leitura, mas pode ser suficiente.

  3. Saiba mais sobre os dados - todos são atualizados ou adicionados apenas? Tente evitar a cópia de registros que não mudaram se a condição fosse fácil o bastante e o registro não fosse disperso ...

Apenas algumas ideias ...

    
por 26.11.2009 / 11:23
0

Quando você faz o processamento em massa, é sobre bytes e NÃO sobre o número de linhas. Seu apenas empurrando bytes ao redor.

Esta questão é um pouco vaga. Meu palpite a partir disso é que você precisa mover dados de um banco de dados para outro, certo?

Isto é o que eu faria (sem saber o tamanho real do seu banco de dados e outras coisas acontecendo)

  1. crie um banco de dados e um link. CREATE TABLE AS NO LOGGING no link e veja quanto tempo demora. se isso é bom o suficiente. seu feito. Esta é geralmente a maneira mais rápida de mover os dados. Certifique-se de usar NO LOGING ou será mais lento. se a tabela que você está lendo estiver particionada, consulte-a com a opção paralela, se não, não (não fará nada se você usá-la se ela não estiver particionada).

  2. Espaço de tabela transportável. Google isso. sua tabela precisará ser um esquema totalmente contido em um tablespace. Você também precisa acessar sysdba (isso deve ser feito pelo usuário oracle). isso requer scripts de shell e mais código que a opção 1.

  3. bomba de dados

nessa ordem. Visões materializadas sugam grandes quantidades de dados e são totalmente atualizadas. Criar a tabela é MUITO mais rápido. use somente a opção 3 se não puder atender aos requisitos de um espaço de tabela transportável.

Eu carreguei grandes quantidades de dados / dia. no intervalo de terabytes.

    
por 07.01.2010 / 20:59

Tags