quinta-feira, 11 de setembro de 2014

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!


BigFiles Tablespaces, Normal Tablespaces and Tablespaces Sizes – How and When to use them

Until Oracle version 9i you normally only could create tablespaces with datafiles up to 32G (near that). They're called “Smallfile Tablespaces”. Particularly I prefer to call them “Normalfile”, because Small gives an impression of a size up to 2G or 4G. With version 10g and further, Oracle lets you create tablespaces with larger datafiles, up to 128T depending on the OS architecture (64 bits) and block size (32k).

 With a Smallfile Tablespace, normally the database administrator can create up to 1024 datafiles with 32G each – which gives nearly 34T of data – using 8K block size. We know that nowadays this amount of data isn't significant for some systems/companies, like Google, VISA, etc. Specially those which store videos, high resolution images and audio.
 A BigFile Tablespace can store more then three times a hole database that uses smallfiles, in a unique tablespace. Using a 32K block size, the database can reach 8 exabytes.  It's a huge amount of data. Unfortunately this can also bring some problem. As bigger is the datafile, as longer will be the time to restore its backup or do some maintenance on it.
 Some of those maintenance must bring the system offline depending on what is stored in the datafile. A good practice to avoid it, is to design your database in a way that you can divide tables that store large data (e.g.: Tables with BLOB or CLOB data) into a big file tablespace while the others in a normal tablespace. Or also you can partioned the table putting the less accessed data into the big file tablespace. In doing this, only a part of your system will be inaccessible during a maintenance.
 For example, in an Hospital Informatics System you can divide the tables which stores videos and images for diagnosis in a big file, while the stock, billing and administrative routines can stay in a normal tablespace, making that the system become available for those routines while only the diagnosis part will be offline for a maintenance.


On another hand there are Appliances (closed servers with a factory made configuration ready and directed for an specified needing) built to deal with those necessities, like BigData or ExaData, from Oracle, InfoSphere and Watson Foundations, from IBM, the CISCO USC and many others.

 So, is better you have a bunch of small soldiers, that move faster and from many sides, or one big and strong soldier, moving slowly and in a unique direction, in your army? All depends on your strategy! 




Locations of visitors to this page
Côcos pelo Mundo