Tablespaces BigFile, Normais e seus tamanhos: Como e quando usá-los

Até a versão 9i do Oracle, você normalmente podia criar tablespaces com datafiles até 32G (aproximadamente). Eles eram (são) chamados "Smallfile Tablespaces". Particularmente prefiro chamá-los de "Normalfiles", porque "Small" me dá uma impressão de um tamanho até 2G ou 4G. Na versão 10g em diante o Oracle te deixa criar tablespaces com datafiles maiores, até 128T dependendo da arquitetura do SO (64 bits) e do tamanho dos blocos (32K).
Usando Tablespaces Smallfile normalmente um administrador de banco de dados pode criar até 1024 datafiles, cada um até 32G - o que nós dá aproximadamente 34T de dados - usando um block size de 8K. Bem sabemos que atualmente esse volume de dados é insignificante para alguns sistemas/empresas, como a Google, VISA, etc. Especialmente aquelas que armazenam vídeos, imagens de alta resolução e áudio.
Uma Tablespace BigFile pode armazenar mais de três vezes um banco de dados completo que utiliza apenas smallfiles, em uma única tablespace. Usando um block size de 32K o banco de dados pode atingir 8 Exabytes. É muito dado armazenado. Infelizmente isso também pode trazer problemas. Quanto maior for o datafile, maior será o tempo para restaurar seu backup ou realizar alguma manutenção nele.
Algumas dessas manutenções requerem que o sistema fique off-line, dependendo do que esteja armazenado nesse datafile. Uma boa prática para evitar isso seria desenhar o modelo de dados de modo que possa dividir as tabelas que guardariam dados grandes (ex.: tabelas com campos BLOB ou CLOB) em tablespaces BigFile, enquanto o restante dos dados permaneceria em tablespaces normais.. Ou ainda você pode particionar a tabela colocando os dados que são menos acessados em uma partição dentro do BigFile. Fazendo isso apenas uma parte do seu sistema ficaria inacessível durante uma manutenção.
Por exemplo, em um sistema de gestão hospitalar e diagnósticos. Você pode colocar as tabelas que armazenam vídeos e imagens para diagnósticos em um BigFile, enquanto o estoque, faturamento e outras rotinas administrativas podem ficar na tablespace normal. Desse modo apenas uma parte do sistema (diagnósticos) ficaria inacessível durante a manutenção.
Por outro lado já existem Appliances (máquinas fechadas com configuração de fábrica direcionada para ambientes e fins específicos) feitos para lidarem com essas necessidades, como o BigData e ExaData da Oracle, InfoSphere e Watson Foundation da IBM, o CISCO USC (da CISCO, claro) e muitos outros.
Então, é melhor você ter um conjunto de pequenos soldados, que movem-se mais rápido e distribuem-se de vários lados, ou um único enorme soldado, movendo-se lentamente e de uma única direção? Tudo depende da sua estratégia!


Comentários

Postagens mais visitadas deste blog

CPF pra Estelionatário Ver!

Data Protector Cannot connect to the SCM (Service Control Manager)

Puff Power Daneryes