Oracle Database 12c R1 - Database Multitenant

Por Carlos Henrique Yakithi Furushima ,
Postado em Maio 2015

Revisado por Marcelo Pivovar - Solution Architect

Em 2013 foi lançado ao mercado o Oracle Database 12c R1, ele trouxe novas funcionalidades para infra-estrutura deste banco de dados. Neste artigo abordaremos uma dessas novidades, que é denominada pela Oracle como Database Multitenant. Esse conceito introduzido neste release é uma "nova arquitetura" alternativa, ou seja, ainda existirá a tradicional que conhecemos em release anteriores ao 12c, sendo facultativo ao DBA e/ou instituição decidir pela implementação.

O surgimento deste novo conceito nasceu da necessidade de seguir as tendências mercadológicas, como por exemplo o cloud computing. O modelo multitenant estimula uma forma de comercialização e distribuição software computacional conhecido como SaaS (Software as a service - Software como serviço). Segundo a Oracle, multitenant é uma nova option do Oracle Database que surge no release 12c somente para Enterprise Edition.

A ideia de consolidação fundamenta a estrutura do Oracle Database Multitenant. Com objetivo de melhorar o gerenciamento dos recursos computacionais e reduzir de custos, o multitenant propõe um compartilhamento de recursos na estrutura de banco de dados e isso resulta na consolidação de entidades que necessitam usar o recurso computacional, com isso elimina-se a necessidade de estruturas redundantes no banco de dados Oracle. Segundo o Prof. Dr. Aaron J. Elmore da Universidade de Chicago, SGBD Multitenant é utilizado para hospedar diversos bancos de dados independentes dentro de um único sistema, permitindo o compartilhamento eficaz de recursos em diferentes níveis de abstração e isolamento.

O grande desafio deste conceito é a garantia de desempenho dos múltiplos bancos de dados residentes na estrutura multitenant, e para isso é necessário compreender como o workload de um banco de dados pode influenciar nos demais e o funcionamento do mecanismo de isolamento entre banco de dados.

Este artigo também mostra em detalhes o funcionamento do conceito multitenant no Oracle database. Para tanto, foram utilizados diferentes materiais acadêmicos que abordam o tema cloud computing, em especial o conceito de multitenant em banco de dados que tem como fundamento a consolidação de diversas estruturas de banco de dados, compartilhando os recursos computacionais a fim de obter economia de escala.

O que é Multitenant? Multitenant é um modelo arquitetônico contido em cenários de cloud computing, onde se emprega uma estratégia de compartilhamento de recursos computacionais. A proposta deste modelo é ter um banco de dados central suportando múltiplos bancos de dados secundários, chamados de tenants (É possível que em algumas literaturas esse termo seja traduzindo para o português como inquilinos). Um tenant é definido de acordo com o contexto onde se encontra inserido, neste caso trataremos um tenant como um banco de dados secundário que está hospedado sobre um alicerce central. O Prof. Dr. Andy Zaidman, da Universidade de Tecnologia de Delft na Holanda, definiu multitenant como aplicações que permitem o compartilhamento dos mesmos recursos de hardware, através do compartilhamento da aplicação e da instância do banco de dados, enquanto permite-se configurar a aplicação para atender às necessidades do cliente como se estivesse executando em um ambiente dedicado. Segundo Zaidman entende-se por tenant uma entidade organizacional que aluga uma aplicação em arquitetura multitenant. É fundamental entender de forma clara o conceito de multitenant, é comum as pessoas confundirem com outros conceitos já existentes, uma vez que este tema é relativamente novo. Multitenant não é multiusuário, em aplicações multiusuário assume-se que os usuários estão usando a mesma aplicação, em aplicações multitenant assume-se que os tenants tem um algo grau de configuração, dependendo da definição dessas configurações, dois tenants pode possuir aparência e workflows diferentes. Muitos autores de diversas literaturas relacionados ao tema cloud computing defendem a ideia de que o alicerce central que hospedam os tenants sejam classificados quanto a criticidade do serviço, ou seja, cria-se diferentes SLA (Service Level Agreement) para cada tenant, onde a classificação de criticidade está definida no alicerce central que hospedam os tenants. Como todos nós sabemos qualquer modelo computacional traz consigo alguns entraves em certas situações, como citado na introdução, o multitenant explora intensamente a busca por uma situação de consolidação tendo como premissa o compartilhamento de recursos computacionais. Em uma situação como esta é imprescindível a garantia do isolamento lógico entre os tenants, no contexto deste artigo entende-se por tenant o banco de dados secundário que está hospedado sobre um alicerce central. Conforme vimos anteriormente, todas as camadas computacionais são compartilhadas, desde o hardware até o alicerce central, isso implica dois cuidados primordiais. São eles:

  • O desenvolvimento de software deve convergir com a arquitetura multitenant, mecanismos de hierarquias por exemplo, devem ser usado com os devidos tratamentos e cuidados, a fim de não prejudicar a performance de outros tenants.
  • Convergir a topologia de infraestrutura multitenant com a lógica de negócio dos tenants, conforme citado anteriormente, a classificação de criticidade pode ser definida no alicerce central e partir daí hospedar os tenants, seguindo esta lógica de organização.

Figura 1. Representação Multitenant.

Multitenant no Oracle Database 12c Depois de descrever em linhas gerais o conceito de multitenant, veremos como este modelo arquitetônico contido em cenários de cloud computing está empregado no Oracle database. A implantação prática do multitenant está presente no Oracle Database 12c como uma option exclusiva do Enterprise Edition até o momento. Conforme anteriormente visto, multitenant é uma arquitetura para cenários em cloud computing onde sua base fundamenta-se na ideia da consolidação de aplicações com o compartilhamento de recursos computacionais em diferentes níveis de abstração e isolamento. No cenário de cloud computing o termo aplicação é conhecido como tenants e somente pode ser consolidado devido a existência de um alicerce central que sustenta sobre si os tenants. Segundo definições do Oracle ACE, Eduardo Legatti, a option Multitenant permite que tenhamos um ou mais "sub-bancos de dados" dentro de um único "super banco de dados". Para melhor entendimento desta definição é fundamental cruzarmos esses termos com o conteúdo apresentado em parágrafos anteriores, os "sub-bancos de dados" são os tenants que estão hospedados sobre um alicerce central que Legatti definiu como "super banco de dados". O alicerce central ou "super banco de dados" é oficialmente denominado pela Oracle como "Multitenant Container Database" cujo o acrônimo é CDB, já os tenants ou "sub-bancos de dados" é oficialmente denominado como Pluggable Databases cujo o acrônimo é PDB (containers de bancos de dados plugáveis traduzindo para o português). De acordo com a Oracle os bancos de dados CDB e PDB são containers que representa uma coleção de schemas, objetos e outras estruturas relacionadas. O CDB também pode ser chamado de ROOT container (CDB$ROOT), cada container existente dentro de um CDB (container ROOT - CDB$ROOT), ou seja, um PDB possui um ID único bem como um nome. Com isso o Oracle Database Multitenant, resume-se em permitir a criação de um ou mais PDBs (tenants) dentro de um único CBD (alicerce central). A ideia principal por trás deste conceito consiste em permitir um uso mais eficiente dos recursos do sistema, além de oferecer um gerenciamento mais simplificado. É importante frisar que não haverá nenhuma mudança no processo de conexão com o banco de dados sob a perspectiva do usuário cliente ou aplicação.

Arquitetura Oracle Database 12c Multitenant Com o intuito de clarificar o conceito o multitenant em ambientes Oracle database, veremos em detalhes a arquitetura tendo como referência principal as documentações oficiais da Oracle. Segundo a Oracle, o ROOT (CDB$ROOT) e todos os PDB que estão sobre ele são considerados um "container", sendo assim, podemos criar uma convenção neste cenário, chamando o "root conteiner" (CDB) e de "conteiners secundários" os PDBs que estão hospedados nele. Este é simplificadamente o conceito base do Oracle database multitenant. De acordo com as documentações oficiais, todos os cenário de Oracle database multitenant possui os seguintes conteiners:

  • Um root conteiner

É um banco de dados central titulado pela como CDB$ROOT, muitas literaturas de cloud computing definem está camada como alicerce central. Ela contém os metadados, também conhecido como dicionário de dados e também os usuários comuns (common user).

  • Um seed container

É um conteiner modelo para criação de novos PDB, titulado pela Oracle como PDB$SEED, pode-se dizer que este conteiner é um template para criação de outros conteiner PDB, este é um exemplo de um tenant ou conteiner secundário.

  • Zero ou mais Pluggable Databases (PDB)

É um banco de dados que receberá os dados da aplicação. É importante frisar que este conteiner receberá os "dados de negócio", como exemplo um ERP. Da mesma forma que o seed container o PDB é um tenant ou conteiner secundário.

Figura 2. Representação de um cenário database multitenant.

Imagem retirada da documentação oficial da Oracle

Como descrito na documentação oficial, um cenário de Oracle database multitenant é contextualizado como CDB, conforme citação abaixo:

"... The multitenant architecture enables an Oracle database to function as a multitenant container database (CDB) that includes zero, one, or many customer-created pluggable databases (PDBs). ..." (http://docs.oracle.com/database/121/ADMIN/cdb_intro.htm#ADMIN13507)

Os cenários pre-12c são chamados de Non-CDB, conforme citação abaixo:

"... A PDB is a portable collection of schemas, schema objects, and nonschema objects that appears to an Oracle Net client as a non-CDB. All Oracle databases before Oracle Database 12c were non-CDBs." (http://docs.oracle.com/database/121/ADMIN/cdb_intro.htm#ADMIN13507)

Portanto, a partir da versão 12c release 1, onde há o nascimento da option multitenant, entende-se por CDB os cenários que a option multitenant está presente e Non-CDB os cenários que conhecemos antes do surgimento desta option, ou seja, aqueles que temos o costume de usar e que possuem a arquitetura que conhecemos nas versões 11g, 10g, 9i, 8i, etc.

Em um cenário CDB, o ROOT container contém as estruturas de tablespaces SYSTEM, SYSAUX, TEMP e UNDO além dos controlfiles, redo log files, archived redo log files, Flashback logs, Change Tracking File, trace files e instance parameter files (spfile e/ou pfile). Muitas dessas estruturas são compartilhadas entre os PDBs, conforme necessidade, caracterizando a ideia fundamental do multitenant de consolidação. Um PDB também possui algumas estruturas dedicadas, como a(s) tablespace(es) de aplicação além da SYSTEM e SYSAUX. Opcionalmente é possível criar e usar uma tablespace temporária de forma dedicada para um PDB, neste caso abdica-se do direito de uso compartilhado da estrutura de tablespace temporária, localizada no root container. É importante ressaltar que essa opção não tange a tablespace de UNDO, ou seja, a estrutura de UNDO é compulsoriamente compartilhada entre os PDBs.

Entre algumas vantagens que está arquitetura multitenant proporciona, é oportuno nesta parte enfatizar duas: - O root container disponibilizar certos recursos como tablespace UNDO, controlfiles, redo log files e etc, para seus PDBs suportados, resultando na eliminação de duplicidade estrutural. É uma considerável economia de utilização do hardware, principalmente pelo fato da eliminação de processos duplicados no sistema operacional (SO). Assim, os processos de background e a database instance (Oracle CDB Instance) são compartilhados entre os PDBs. Além disso, também se evita mapeamento/alocação de áreas de memória desnecessárias.

- A facilidade em operações de upgrade database. Os PDBs estão plugados no root container que por sua vez pertence a um binário de instalação 12c Enterprise Edition ($ORACLE_HOME). Assim, em um upgrade de versão/release dos binários do CDB, como por exemplo 12.1.0.1 para 12.1.0.2, todos os PDB pertencentes a ele também serão atualizados.

Desta forma, uma migração de um cenário Non-CDB para um CDB deve ser primeiramente planejado. O que inclui um estudo de viabilidade, pois em alguns casos poderão não ser vantajosos para a aplicação. Tudo vai depender de uma série de fatores que o DBA/instituição devem analisar. Simplificadamente, o intuito do multitenant é evitar o uso desnecessário do hardware, contudo existem aplicações que demandam um maior poder computacional e o compartilhamento de recursos talvez não seja saudável.

Outra vertente, do ponto de eliminação de duplicidade estrutural, é a diminuição de objetos. O root container armazena o schema de dicionário de dados, que a Oracle subdivide em "Dictionary Object Definition (Metadata)" e "Dictionary Object Data". O usuário SYS é owner do dicionário de dados, ou seja, o SYS é proprietário de todos os objetos que pertencem ao schema de dicionário de dados. Estes objetos são a base de muitos utilitários (exemplo rman), possuindo uma relevância no que se referente a metadados. Vale dizer que o root container não armazena os metadados do PDB, assim a tabela OBJ$ localizada no CDB que alimenta a view DBA_OBJECTS não contém os dados referentes aos objetos do PDB e a tabela OBJ$ localizada no PDB não contém os dados referente aos objetos do CDB, a integração desses dados é explicada em detalhes no próximo tópico. Com isso, não há a necessidade de manter os objetos de dicionário de dados em cada PDBs, o que gera economia de armazenamento em área permanente (disco) e volátil (memória).

SCHEMA

Uma schema é o conjunto de objetos (tabelas, views, índices, pacotes, etc.) que pertence a uma conta de usuário. Muitas vezes é usado como uma outra maneira de se referir a uma conta de usuário no banco de dados Oracle.

Arquitetura de dicionário de dados em um CDB

Dicionário de dados

O DICIONÁRIO DE DADOS É UM REPOSITÓRIO DE INFORMAÇÕES SOBRE O BANCO DE DADOS ORACLE, CONHECIDO COMO METADADOS. METADADOS SÃO DADOS SOBRE DADOS (APLICAÇÃO), OU DADOS QUE DEFINEM OUTROS DADOS.

Quando você cria um tabela, é no dicionário de dados que fica registrado o nome da tabela, suas colunas, quem pode consultá-la, alterá-la e algumas outras informações. Chamamos de metadados essas informações sobre tabelas, índices, colunas, quem pode acessá-los, e assim vai. Mas também há informações (metadados) sobre o banco de dados, que não dependem da aplicação, como por exemplo tablespaces, datafiles, controlfiles, etc. O dicionário de dados em um cenário multitenant possui um segregação entre PDB e CDB, o root container armazena somente o database metadata (Metadados de banco de dados), já o PDB armazena somente o user metadata (Metadados de usuário), conforme podemos ver na Figura 3. De modo diferente, um cenário Non-CDB não possui a tal segregação existente no cenário CDB, conforme é visto na Figura 4. Segundo a Oracle o user metadata localizado no PDB, contém ponteiros chamados de “metadata links” para o dicionário de dados localizado no root container, ou seja, os objetos de dicionário de dados (objetos de sistema), tais como "data dictionary table definitions" e pacotes PL/SQL (exemplo DBMS_ADVISOR) estão materializados apenas no root container. Observando da perspectiva do usuário é natural perceber uma transparência, dando a falsa sensação que tudo está em um mesmo lugar. Porém, internamente os dados são requisitados via metadata link. Imaginemos que seja necessário fazer um leitura completa da view dba_objects, neste caso temos um acesso completo na user metadata e um acesso completo via metadata link na database metadata. Esse mecanismo tem como objetivo a eliminação de duplicação de objetos, conforme abordados em parágrafo anterior, não sendo necessário cada PDB manter uma versão materializada do database metadata.

Figura 3. Segregação do dicionário de dados entre PDB e CDB. Imagem retirada da documentação oficial da Oracle

Figura 4. Dicionário de dados em um cenário Non-CDB. Imagem retirada da documentação oficial da Oracle

Em cenários Non-CDB, são classificados como "dictionary views" ou views de dicionário de dados aquelas com prefixo USER_, ALL_ e DBA_. Já no CBD, essas views foram mantidas com a adição de uma nova categoria com prefixo CDB_ e o mecanismo interno de restrição de visualização em função da perspectiva. Por exemplo, se estivermos em um PDB não teremos acesso a mesma quantidade de linhas caso estivéssemos em um root containers. Devido a mudança de arquitetura é natural a necessidade de algumas modificações na disposição da "dicationary views". Assim, nasce no CDB o "Container Data Objects" que são tabela ou views que contém dados relativos ao(s) PDB(s) e ao root container. O "Container Data Objects" possui um mecanismo interno para restringir os dados visíveis para os diferentes tipos de usuários. Veremos mais adiante em detalhes esses diferente tipos de usuários, abaixo descreveremos todas as categoria da "dictionary views" (views de dicionário de dados):

  • USER_: Para extrair informações referente aos objetos do usuário corrente.
  • ALL_: Para extrair informações referente aos objetos acessíveis ao usuário corrente (objetos que o usuário corrente possui permissão de acesso).
  • DBA_: Para extrair informações referente a todos os objetos do container (PDB ou ROOT).
  • CDB_: Para extrair informações referente ao CDB, ou seja, todos os objetos de todos os containers existentes no CDB.

Figura 5. Categorias de “Dictionary views” Imagem retirada da documentação oficial da Oracle

Tipos de usuários Em cenários Non-CDB um usuário é uma entidade única e imutável, ou seja, não existe classificações de tipos de usuários, como ocorre em cenário um CDB, o princípio de consolidação da arquitetura multitenant deve acompanhar o isolamento entre os container, assim é necessário haver usuários local do PDB e usuários comum entre os PDBs. Conforme a documentação da Oracle, existem dois tipos de usuários são eles: Common User (Usuários comum) e Local User (usuário local). O princípio básico em relação a esses tipos de usuários é que um common user está (e estará) presente em todos os container (PDB e ROOT), ou seja, comum em todos os containers. Em contrapartida, um Local User (usuário local) é restrito a um container PDB existente, ou seja, o usuário só está presente em um PDB específico. O mesmo nome de usuário pode estar presente em vários PDBs, porém não tem nenhuma relação entre si, respeitando assim o isolamento entre os containers. A figura 6 esboça a diferença entre Common User e Local User. Esse o princípio básico de "comum" e "local" também tange as roles, que possuem duas categorias "Common Role" (Role Comum) que estão presente em todos os container (PDB e ROOT) que existem atualmente e que irão existir no futuro e "Local Role" (Role Local) que existem somente em um container PDB, respeitando o mesmo isolamento lógicos existente nos usuários.

Figura 6. Princípio básico “Comum” e “Local” Imagem retirada da documentação oficial da Oracle

A Figura 7 nos mostra a relação entre CDB x PDB e Common User x Local User. No exemplo existem 11 PDBs um para cada aplicação, que estão hospedado (ou plugados) no CDB. O usuário administrador do CDB é um Common User, ele é capaz de estar em qualquer um dos 11 PDBs existentes e qualquer outro PDB que possivelmente poderá existir O Common User está materializado no CDB, não sendo necessário o fazer em todos os containers. Já o usuário administrador do PDB é um Local User, que é capaz de estar somente em seu container (PDB), uma vez que este está materializado apenas no PDB.

Figura 7. Representação do princípio básico “Comum” e “Local” Imagem retirada da documentação oficial da Oracle

Criando um cenário Oracle Database Multitenant (CDB)

Conforme foi abordado, é necessário existir um CDB para que exista um PDB. Não entraremos em maiores detalhes da criação do CDB, mas a figura 8 mostra o passo mais importante, que está sendo criado via DBCA. Na seta de cor vermelha (cima) damos um nome para o database e o database instance, na seta de cor azul (baixo) é marcado o box "Create As Container Database", que informa ao instalador que trata-se de um ambiente em multitenant (CDB).

Figura 8. Criando um CDB via DBCA.

Criando o root container (CDB$ROOT) temos o alicerce central. Após essa etapa, é possível plugarmos PDBs já existentes ou criamos novos PDBs. Vale relembrar que a criação do CDB, inclui a criação de um PDB template chamado de PDB$SEED, que servirá de molde para criação de novos PDBs no root container (CDB$ROOT).

Abaixo, demostraremos algumas informações após a criação do CDB:

  • Utilizando utilitário sqlplus, consultamos a view v$database e selecionamos os campos relevantes em arquitetura multitenant, são eles "NAME" que especifica o nome do banco de dados, "CDB" que especifica que este cenário trata-se de um database multitenant e "CON_DBID" que especifica o número de identificação do database container.

[CDB1.oracle@dbafurushima scripts]$ sqlplus / as sysdba

 

SQL*Plus: Release 12.1.0.2.0 Production on Mon Sep 8 22:56:35 2014
Copyright (c) 1982, 2014, Oracle.   All rights reserved.
 
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit  Production
With the Partitioning, Oracle Label Security, OLAP, Advanced Analytics
and Real Application Testing options

SQL> select name,cdb,con_dbid from v$database;

NAME      CDB   CON_DBID
--------- --- ----------
CDB1      YES  831192750
  • Consultado a V$CONTAINER podemos verificar a coluna “CON_ID”, que representa o ID do container e a coluna “NAME” que nos informa o nome do container.
  SQL> select con_id, name from v$containers;

				CON_ID NAME

				------ ------------------------------ 
				
				1 CDB$ROOT 2 PDB$SEED
  • Consultado a V$PDBS podemos verificar quais PDBs existem no CDB (root container), onde a coluna “NAME” representa o nome do PDB e a coluna “OPEN_MODE” representa o estado do PDB.
  SQL> select name, open_mode from v$pdbs;

				NAME                           OPEN_MODE 
				
				------------------------------ ---------- 
				
				PDB$SEED                       READ ONLY

É possível fazer toda criação do ambiente multitenant usando o utilitário DBCA (Database Configuration Assistant), que ganhou uma nova aparência no 12c. Tendo um visual semelhante ao runInstaller, mostrou-se vantajoso devido ao enriquecimento dos detalhes no que se refere as especificações das opção de operações disponíveis.

Depois de criado o CDB é necessário criar o PDB que pode ser feito manualmente ou via DBCA. É importante entendermos as representações de cada etapa e interpretá-las, compreendendo quais as necessidade em uma criação de um PDB. As figuras abaixo (Figura 9-1 até Figura 9-7), mostra a criação de um PDB, via DBCA, não entraremos em muitos detalhes. Exceção apenas para as figura 9-3 e 9-5, que são os passos mais importante para a compreensão da relação CDB x PDB.

Figura 9-1. Criando um PDB via DBCA.

Figura 9-2. Criando um PDB via DBCA.

  • Neste passo (Figura 9-3) é necessário selecionar o CDB a qual o PDB será plugado, como pode ser visto no enunciado da tela, o DBCA requisita que você selecione um Oracle Container DataBase (CDB) que hospedará o PDB após criado.

"Select a container database in which the pluggable database can be created. ..."

Figura 9-3. Criando um PDB via DBCA.

Figura 9-4. Criando um PDB via DBCA.

  • Este passo (Figura 9-5) engloba 3 diferentes variáveis, o nome do PDB que será plugado no CDB, o PDB Storage contempla o tipo de armazenamento, ou seja, onde os datafiles residirão sendo ASM e Filesystem como opções possíveis e por fim o PDB User que é um Local User administrador do novo PDB que está sendo criado.

Figura 9-5. Criando um PDB via DBCA.

Figura 9-6. Criando um PDB via DBCA.

Figura 9-7. Criando um PDB via DBCA.

  • As view V$PDBS e dba_pdbs trazem importantes informações associadas ao PDB, a query abaixo propõe um join entre as views, para extrair alguns campos referente ao status do PDB.
  SQL> select a.con_id,

					2         a.name, 
					3         b.status,
					4         a.open_mode,
					5         a.total_size
					6  FROM  v$pdbs a, 
					7         dba_pdbs b 
					8  WHERE a.con_id = b.pdb_id; 
					CON_ID NAME                           STATUS   OPEN_MODE  TOTAL_SIZE

					------ ------------------------------ ------- ---------- ---------- 
					
					2 PDB$SEED             NORMAL  READ ONLY   812646400 
					3 PDB1                 NORMAL  READ WRITE   859832320

A view V$PDBS prove informações sobre os PDBs associados as CDB, os PDBs possuem um "open mode", que significa seu status para uso, os possíveis estados são "MOUNTED", "READ WRITE" (pronto para um pleno uso de escrita e leitura), "READ ONLY" (somente leitura) e "MIGRATE" (estado para operações de upgrade).

Hierarquia de Diretórios A hierarquia dos diretórios referente ao armazenamento dos arquivos de banco de dados Oracle, seguem a lógica da arquitetura multitenant, assim o diretório que armazena os database files do CDB, armazena também como diretório filho os database files do PDB, seguindo a lógica que PDB está contido no CDB, veja abaixo a representação desta estrutura.

Figura 10. Hierarquia de Diretórios.

Representação prática da estrutura de hierarquia de diretórios em sistemas operacionais Linux.

 [root@dbafurushima oradata]# tree -t  /oracle/app/product/oradata/

   /oracle/app/product/oradata/
   └── CDB1
   ├── control01.ctl
   ├── redo03.log
   ├── sysaux01.dbf
   ├── system01.dbf
   ├── undotbs01.dbf
   ├── temp01.dbf
   ├── users01.dbf
   ├── redo02.log
   ├── redo01.log
   ├── PDB1
   │   ├── system01.dbf
   │   ├── sysaux01.dbf
   │   ├── temp01.dbf
   │   └── PDB1_users01.dbf
   └── pdbseed
   ├── sysaux01.dbf
   ├── system01.dbf
         └── temp01.dbf

Representação prática da estrutura de hierarquia de diretórios em sistemas operacionais Windows. E:\oracle\app\oradata> tree /F /A

  E:.

   \---CDB1
   |   CONTROL01.CTL
   |   CONTROL02.CTL
   |   REDO01.LOG
   |   REDO02.LOG
   |   REDO03.LOG
   |   SYSAUX01.DBF
   |   SYSTEM01.DBF
   |   TEMP01.DBF
   |   UNDOTBS01.DBF
   |   USERS01.DBF
   |
   +---PDB1
   |       PDB1_USERS01.DBF
   |       PDB1_APLICACAO01.DBF
   |       PDBSEED_TEMP01.DBF
   |       SYSAUX01.DBF
   |        SYSTEM01.DBF
   |
   \---pdbseed
   PDBSEED_TEMP01.DBF
   SYSAUX01.DBF
   SYSTEM01.DBF

Conclusão

O objetivo geral desse trabalho é dar ao leitor uma visão sobre a nova option do Oracle 12c chamada Multitenant, apresentando uma fundamentação teórica do tema em cenários de cloud computing e como este fundamento é implementado no banco de dados Oracle, além contextualizar tendências de mercado, abordando o crescimento de SaaS (Software como serviço - Software as a service) e quais suas relações com o Multitenant. Em muitas documentações oficiais e não oficiais, consideram este modelo como uma espécie de virtualização intrínseca de banco de dados, sendo um modelo alternativo a consolidação baseada no schema, onde o intuito é garantir a eficácia no compartilhamento de recursos, visando níveis de abstração e isolamento. Onde o intuito central deste cenário é obter economia de escala, é importante ressaltar que, o ato de economizar, significa evitar desperdício nos diversos vários níveis computacionais, ou seja, economizar recursos não significa perder poder computacional. O objetivo da economia em multitenant é alcançar um ponto de tangência entre um bom desempenho e o compartilhamento de recursos computacional, o equilíbrio é fundamental para o sucesso deste cenário.

Links úteis

  • Oracle Multitenant: Abordando a arquitetura e criação do Container Database (CDB) e Pluggable Databases no Oracle 12c http://eduardolegatti.blogspot.com.br/2014/02/oracle-multitenant-abordando.html
  • Overview of the Multitenant Architecture http://docs.oracle.com/database/121/CNCPT/cdblogic.htm#CNCPT89248
  • Introduction to the Multitenant Architecture http://docs.oracle.com/database/121/CNCPT/cdbovrvw.htm#CNCPT89234
  • Oracle MULTITENANT 12c – Criação de um Pluggable Database http://www.profissionaloracle.com.br/gpo/artigo/banco-de-dados/168-oracle-multitenant-12c-criacao-de-um-pluggable-database

    • Carlos H. Y. Furushima é um especialista em banco de dados relacional, trabalhando como consultor de TI, atuando principalmente como o Oracle Database Administrator (DBA Oracle). Tem uma vasta experiência e conhecimento em "Performance, diagnosticand tuning", "High Availability", "Backup & Recovery" e "Exadata". Ele também está entusiasmado com sistema operacional Linux/Unix, onde contribui com o desenvolvimento do código do kernel Linux em parceria com a comunidade "GNU Linux", com criação e revisão de novas funcionalidades, melhorias e correções de bugs. Recentemente, Furushima divide seu tempo com consultoria especializada em banco de dados Oracle e estudos sobre "Oracle Internals", com o objetivo de descobrir e entender os benefícios do bancos de dados Oracle em plataforma Linux/Unix.

    Este artigo foi revisto pela equipe de produtos Oracle e está em conformidade com as normas e práticas para o uso de produtos Oracle.