Posto isso, vamos à novidade de maior impacto no Oracle Database desde... desde... bem, desde sempre, eu acho. Trabalho com Oracle desde a versão 7.1 e não consigo me lembrar de nada tão radical. Objetos, Java, Flashback, ASM, Editions, Replay... Nada mexeu tanto com a estrutura do software como este novo sistema de Containers e Plugged Databases. RAC, talvez ? Talvez, pois RAC trouxe o cenário "N instâncias e 1 database", e esta nova feature traz algo que poderia ser interpretado como "1 instância e N databases".
Introdução: O Problema
O que o mercado chama vulgarmente de "Banco Oracle" é tipicamente uma estrutura monolítica, criada para suportar aplicações grandes, enormes ou gigantescas. Você tem uma instância, que é um conjunto de processos no sistema operacional associado a algumas áreas de memória; você tem um database, que é um conjunto de diversos arquivos em disco. Os dois juntos formam um "Oracle Server", que é o nome correto. Vou manter esse nome em inglês para que não haja confusão com a palavra "servidor", que normalmente significa hardware. Uma variação dessa estrutura é a solução de alta disponibilidade RAC (Real Application Clusters), em que temos várias instâncias para um mesmo database.
Criar um Oracle Server é uma atividade planejada, que envolve diversas decisões; o cenário mais comum em produção é ele que ocupe totalmente o hardware que o abriga, e muitos sistemas baseados em Oracle foram projetados com essa premissa. Um Oracle Server precisa ser administrado. Precisa de políticas de backup, previsão de crescimento, acompanhamento de seus logs de alerta, atualização de estatísticas, entre dezenas de outras coisas.
Para aplicações pequenas e médias, existem dois cenários comuns:
- Criar diversos Oracle Servers no mesmo hardware (com ou sem virtualização).
- Colocar diversas aplicações no mesmo Oracle Server, uma em cada "schema/owner/usuário".
A primeira opção cria um desperdício enorme de recursos, tanto de hardware quanto humanos. É comum ver um DBA administrando 200 Oracle Servers, o que deixa todos mal administrados. É comum uma aplicação sofrer quedas de desempenho porque outra aplicação está processando algo pesado ou fazendo backup, e é difícil apurar isso porque as ferramentas de diagnóstico tratam de Oracle Servers, elas não conseguem olhar para fora desse escopo.
A segunda opção nem sempre é viável, pois muitas aplicações foram desenhadas para ocupar seu próprio Oracle Server. Quando é viável, existe a questão da segurança: não é trivial garantir que uma aplicação não terá acesso aos dados de outra (afinal de contas, privilégios "ANY" e roles como "DBA" dão acesso a todos os schemas). É comum que o departamento ou a empresa cujos dados estão em jogo simplesmente não aceite a consolidação.
Agora vamos pensar no cenário da TI corporativa nesta segunda década do século XXI: Exadata, Consolidação, Virtualização, Nuvem. O mundo mudou e todos os sistemas têm que compartilhar recursos. Dentro de uma Exadata, sistemas grandes são automaticamente rebaixados a médios ou pequenos. Como lidar então com o desperdício de recursos ?
Pluggable Databases
Olhando de fora, entretanto, a coisa é bem diferente: a partir do sistema operacional, a impressão que se tem é que existe apenas uma instância. Você verá apenas um processo SMON, um PMON, um CKPT. A mesma coisa acontece com a memória: SGA e PGA são dimensionadas no CDB, para atender a ele e a todos os seus PDBs. Undo e Redo ? Também. As mesmas tablespaces de UNDO e os mesmos redo logs online atendem ao CDB e a todos os seus PDBs.
Segundo a Oracle, a economia de recursos permite um ganho de 5x ou mais em comparação com múltiplos Oracle Servers. Em outras palavras, esse mesmo hardware que hoje no 11g suporta 10 instâncias poderia suportar 50 delas no 12c. Digo "instâncias" porque esse fator se aplica obviamente aos recursos de memória. O storage ainda precisará ser cinco vezes maior.
Administração
A administração promete ser facilitada. Por exemplo, o RMAN poderá ser configurado para fazer o backup do CDB e tudo o que estiver abaixo em uma só operação, mas este backup servirá para recuperar qualquer PDB individualmente.
Outro exemplo, muito mais interessante: PDBs podem ser desplugados de um container e plugados em outro container !!! Isso facilitará a migração de databases para outra plataforma, para outro hardware e mesmo para novas versões. Imagino o que processo de upgrade para o 12cR2 será assim: instalar o novo software, criar um novo container e então trazer cada um de seus PDBs para plugar neste novo container.
Cópias de databases também serão mais simples. Veja como fica este cenário típico na vida de qualquer DBA: existe um Oracle Server chamado "app01", onde roda uma aplicação específica. A equipe de QA precisa de uma cópia por alguns dias, para fazer testes de uma nova funcionalidade. Hoje em dia precisamos criar um novo server "app02" e utilizar RMAN ou "data pump" para levar os dados de um para outro. Se "app01" fosse um PDB, o processo seria assim: conectado ao container, executar:
alter pluggable database app01 close;
alter pluggable database app01 open read only;
create pluggable database app02 from app01
file_name_convert = ('/app01', '/app02');
alter pluggable database app02 open;
Feito. Tablespaces da aplicação, tabelas, objetos, roles, usuários, diretórios e tudo mais foram copiados e estão prontos para o uso. A cláusula "file_name_convert" faz a tradução dos caminhos dos datafiles; se os originais estavam em "/u04/oradata/app01" os novos estarão em "/u04/oradata/app02".
Outros Detalhes
Sistema de Arquivos
Na instalação default, os datafiles dos PDBs ficam em diretórios abaixo de seu CDB:
CDB1: /u04/oracle/oradata/cdb1/system01.dbf
PDB1: /u04/oracle/oradata/cdb1/pdb1/system01.dbf
PDB2: /u04/oracle/oradata/cdb1/pdb2/system01.dbf
PDB3: /u04/oracle/oradata/cdb1/pdb3/system01.dbf
Processos de Background
Como já vimos, os processos tradicionais no sistema operacional (pmon, smon, ckpt) aparentam ser todos do CDB. É muito provável que tenhamos novos processos para cuidar de aspectos que esta nova dimensão apresenta.
Segurança
Os privilégios dentro de um PDB se aplicam somente a este PDB. Aparentemente, o privilégio de SYSDBA em um CDB dá poder total sobre os PDBs. Podemos esperar novos privilégios, mais restritivos, no nível do container.
Dúvidas
- Como serão divididos os recursos ? Será que teremos um novo Resource Manager que permita distribuir a carga entre os PDBs ?
- Como ficam os parâmetros ? Se existe apenas um conjunto de processos, é razoável supor que haverá parâmetros que não podem ser alterados nos PDBs e assumem o valor de seu container ? Mais ainda, será que teremos parâmetros que só existem em CDBs ou em PDBs ?
- Será que o padrão será deixar o Container Database vazio, sem dados de nenhuma aplicação ?
- Como será o RAC 12c ? Clusters de CDBs, de PDBs ou ambos ?
Veja Também:
Nenhum comentário:
Postar um comentário