Recentemente, um colega num dos grupos de discussão que frequento estava com dúvidas sobre porque existem colunas CON_ID e PDB_ID nas views do sistema, quando e como usar cada uma delas. O objetivo deste artigo é esclarecer os conceitos envolvidos e tentar indicar quando e como / para que as usar.
Quando temos um ambiente multi-tenant, nós temos um database CDB (que seria o ‘database de controle’, database “MASTER” se vc quiser fazer um paralelo com SQL SERVER, ie, um database em princípio dedicado a gerenciar os outros databases). E temos N PDBs (PDBs= Pluggable Databases, são os databases a conter os dados dos usuários finais, databases esses gerenciados/controlados pelo database CDB/MASTER, e que inclusive tem esse nome de PLUGGABLE porque podem ser desplugados de um CDB e plugados em outro)….
Então, a PRIMEIRA coisa que você TEM que saber é que pra poder obter detalhes sobre PDBs em princípio você ** TEM ** que estar conectado no banco CDB : é ELE que conhece, é ELE quem ‘controla’ os PDBs todos…. Veja só:
Estou conectado no database CDB:
SYSTEM@xe>select cdb, name from v$database; CDB NAME --- ---- YES XE 1 linha selecionada. SYSTEM@xe>
Consigo ver info sobre TODOS os PDBs controlados/gerenciados pelo CDB :
SYSTEM@xe>select PDB_ID, PDB_NAME FROM CDB_PDBS ORDER BY 1; PDB_ID PDB_NAME ---------- ----------- 2 PDB$SEED 3 XEPDB1 2 linhas selecionadas. SYSTEM@xe>
(Esse PDB$SEED é um PDB “interno”, usado como um ‘modelo’, um ‘template’ quando você vai criar um database PDB, desconsidere-o de momento)…
Muito bem. Já se estiver conectado num PDB, ** óbvio ** que ele não tem “permissão” pra enxergar os outros PDBs :
SYSTEM@xepdb1>select PDB_ID, PDB_NAME FROM CDB_PDBS; PDB_ID PDB_NAME ---------- -------- 3 XEPDB1 1 linha selecionada. SYSTEM@xepdb1>
Esse é o primeiro ponto que eu TENHO que indicar, se você for administrar um ambiente MULTI-TENANT tenha CERTEZA que teus scripts gerais que desejam consultar dados gerais estão rodando no banco CDB , okdoc ??
Muito bem, agora vamos falar de CONTAINERS. Pense no CONTAINER como uma área Lógica, aonde são mantidos dados sobre os databases – e o próprio database CDB , sendo um database, tem um Container a que se refere.E a cada vez que um PDB é criado, um Container relacionado com ele é criado também:
SYSTEM@xe>select con_id, name from v$containers order by 1; CON_ID NAME ---------- ----------- 1 CDB$ROOT 2 PDB$SEED 3 XEPDB1 3 linhas selecionadas. SYSTEM@xe>
Vamos checar os PDBs controlados por este banco CDB:
SYSTEM@xe>select PDB_ID, PDB_NAME, CON_ID FROM CDB_PDBS order by 1; PDB_ID PDB_NAME CON_ID ---------- ----------- ---------- 2 PDB$SEED 2 3 XEPDB1 3 2 linhas selecionadas. SYSTEM@xe>
Se eu criar um novo PDB, automagicamente um novo CONTAINER será registrado:
SYSTEM@xe>create pluggable database "BOOKSTORE"
2 admin user "BOOKSTOREADMIN"
3 identified by "BOOKSTOREADMIN"
4 file_name_convert = ('d:\app\oracle\product\XE\18.0.0\oradata\XE\pdbseed\', 'd:\app\oracle\product\XE\18.0.0\oradata\XE\bookstore\');
Banco de dados plugável criado.
SYSTEM@xe>select PDB_ID, PDB_NAME FROM CDB_PDBS;
SYSTEM@xe>select con_id, name from v$containers order by 1;
CON_ID NAME
---------- -----------
1 CDB$ROOT
2 PDB$SEED
3 XEPDB1
4 BOOKSTORE
4 linhas selecionadas.
E taí o novo PDB também registrado:
SYSTEM@xe>select PDB_ID, PDB_NAME, CON_ID FROM CDB_PDBS order by 1; PDB_ID PDB_NAME CON_ID ---------- ----------- ---------- 2 PDB$SEED 2 3 XEPDB1 3 4 BOOKSTORE 4 3 linhas selecionadas. SYSTEM@xe>
Vou aproveitar e já ABRIR o novo PDB também:
SYS@xe>alter pluggable database "BOOKSTORE" open read write; Banco de dados plugável alterado. SYS@xe>
Muito bem. Voltando à lista de PDBs e CONTAINERS acima, veja que o CONTAINER 1 (o CDB$ROOT) não aparece na view que lista os PDBs porque NÂO se relaciona a um PDB mas sim ao database CDB….
Agora SIM, chegamos no ponto do artigo que é o porquê de algumas views do sistema conterem CON_ID e outras conterem PDB_ID. CON_ID vai ser preenchido para objetos que TANTO podem estar em databases CDB quanto em PDB. Por exemplo, tablespaces.
SYSTEM@xe>desc CDB_TABLESPACES Nome Nulo? Tipo ----------------------------------- -------- ----------------- TABLESPACE_NAME NOT NULL VARCHAR2(30) BLOCK_SIZE NOT NULL NUMBER INITIAL_EXTENT NUMBER NEXT_EXTENT NUMBER MIN_EXTENTS NOT NULL NUMBER MAX_EXTENTS NUMBER MAX_SIZE NUMBER PCT_INCREASE NUMBER MIN_EXTLEN NUMBER STATUS VARCHAR2(9) CONTENTS VARCHAR2(21) LOGGING VARCHAR2(9) FORCE_LOGGING VARCHAR2(3) EXTENT_MANAGEMENT VARCHAR2(10) ALLOCATION_TYPE VARCHAR2(9) PLUGGED_IN VARCHAR2(3) SEGMENT_SPACE_MANAGEMENT VARCHAR2(6) DEF_TAB_COMPRESSION VARCHAR2(8) RETENTION VARCHAR2(11) BIGFILE VARCHAR2(3) PREDICATE_EVALUATION VARCHAR2(7) ENCRYPTED VARCHAR2(3) COMPRESS_FOR VARCHAR2(30) DEF_INMEMORY VARCHAR2(8) DEF_INMEMORY_PRIORITY VARCHAR2(8) DEF_INMEMORY_DISTRIBUTE VARCHAR2(15) DEF_INMEMORY_COMPRESSION VARCHAR2(17) DEF_INMEMORY_DUPLICATE VARCHAR2(13) SHARED VARCHAR2(13) DEF_INDEX_COMPRESSION VARCHAR2(8) INDEX_COMPRESS_FOR VARCHAR2(13) DEF_CELLMEMORY VARCHAR2(14) DEF_INMEMORY_SERVICE VARCHAR2(12) DEF_INMEMORY_SERVICE_NAME VARCHAR2(1000) LOST_WRITE_PROTECT VARCHAR2(7) CHUNK_TABLESPACE VARCHAR2(1) CON_ID NUMBER SYSTEM@xe>
Em views que se referem à PDBs, vou ter o PDB_ID:
SYSTEM@xe>desc cdb_pdbs
Nome Nulo? Tipo
----------------------------------------- -------- --------------
PDB_ID NOT NULL NUMBER
PDB_NAME NOT NULL VARCHAR2(128)
DBID NOT NULL NUMBER
CON_UID NOT NULL NUMBER
GUID RAW(16)
STATUS VARCHAR2(10)
CREATION_SCN NUMBER
VSN NUMBER
LOGGING VARCHAR2(9)
FORCE_LOGGING VARCHAR2(39)
FORCE_NOLOGGING VARCHAR2(3)
APPLICATION_ROOT VARCHAR2(3)
APPLICATION_PDB VARCHAR2(3)
APPLICATION_SEED VARCHAR2(3)
APPLICATION_ROOT_CON_ID NUMBER
IS_PROXY_PDB VARCHAR2(3)
CON_ID NOT NULL NUMBER
UPGRADE_PRIORITY NUMBER
APPLICATION_CLONE VARCHAR2(3)
FOREIGN_CDB_DBID NUMBER
UNPLUG_SCN NUMBER
FOREIGN_PDB_ID NUMBER
CREATION_TIME NOT NULL DATE
REFRESH_MODE VARCHAR2(6)
REFRESH_INTERVAL NUMBER
TEMPLATE VARCHAR2(3)
LAST_REFRESH_SCN NUMBER
TENANT_ID VARCHAR2(255)
SNAPSHOT_MODE VARCHAR2(6)
SNAPSHOT_INTERVAL NUMBER
SYSTEM@xe>
Já que não tenho PDB_ID, tenho que usar CON_ID para consultar as tablespaces na view:
SYSTEM@xe>select distinct CON_ID from CDB_TABLESPACES;
CON_ID
----------
1
3
4
3 linhas selecionadas.
SYSTEM@xe>
Novamente, o Container 1 se refere a um database que não É PDB, então esse CON_ID = 1 não estará contido nas views que se referem à PDBs, como por exemplo a CDB_PDBS. Assim sendo, tenho que fazer um OUTER JOIN se eu quiser mostrar as tablespaces TODAS existentes no ambiente e (quando for uma tablespace referente à PDB) mostrar o nome do PDB:
SYSTEM@xe>select A.CON_ID, B.PDB_NAME, A.TABLESPACE_NAME from CDB_TABLESPACES A, CDB_PDBS B 2 WHERE A.CON_ID = B.PDB_ID (+) 3 order by 1,3; CON_ID PDB_NAME TABLESPACE_NAME ---------- ----------- ------------------------------ 1 SYSAUX 1 SYSTEM 1 TEMP 1 UNDOTBS1 1 USERS 3 XEPDB1 SYSAUX 3 XEPDB1 SYSTEM 3 XEPDB1 TEMP 3 XEPDB1 UNDOTBS1 3 XEPDB1 USERS 4 BOOKSTORE SYSAUX 4 BOOKSTORE SYSTEM 4 BOOKSTORE TEMP 4 BOOKSTORE UNDOTBS1 14 linhas selecionadas. SYSTEM@xe>
Ou seja, a resposta final do artigo é: Nem todas as views do sistema ORACLE num banco CDB possuem PDB_ID porque nem todas se relacionam à PDBs, E caso haja a necessidade de joinear uma view com info de PDB contra uma sem (como foi o caso acima) pode se usar CON_ID…
Para finalizar, três observações:
1. Antes de mais nada, eu tenho que lembrar que a opção de MULTI-TENANT (ie, ter múltiplos databases ‘controlados’ por um database ‘mestre’ e com um só conjunto de processos principais atendendo a todos) foi introduzida na versão 12.1 do RDBMS Oracle, na forma mais simples,que foi a referenciada aqui no artigo. Na versão 12.2 em diante foi INTRODUZIDA a funcionalidade de Application Containers, que é um elemento lógico de controle ADICIONAL a mais para levar em conta.
Os interessados podem se aprofundar lendo este link e a série de artigos sobre Oracle Multi-tenant.
2. A numeração constante na coluna CON_ID ** não é ** aleatória/desprovida de significado. A documentação da Oracle já nos diz:
Each container data object contains a CON_ID column that identifies the container for each row returned.
E também:
Table 19-1 describes the meanings of the values in the CON_ID column.
Table 19-1 CON_ID Column in Container Data Objects
Value in CON_ID Column Description
0 The data pertains to the entire CDB
1 The data pertains to the CDB root
2 The data pertains to the PDB seed
3 – 4,098 The data pertains to a PDB, an application root, or an application PDB
Ou seja, CON_ID é o identificador DO CONTAINER ao qual o PDB está relacionado, os Containers 0, 1 e 2 são ‘reservados’, de uso interno, possuem significado diferenciado nas views do sistema…
3. Não está relacionado com o tema do Artigo, mas há o conceito de CURRENT CONTAINER – mudando o CONTAINER ao qual você está conectado, você passa a enxergar os dados como se estivesse conectado ao database relacionado com o novo CONTAINER:
SYSTEM@xe>alter session set CONTAINER=XEPDB1;
Sessão alterada.
Pronto. Passo a enxergar os dados como se tivesse conectado ao database XEPDB1, que se relaciona com o container XEPDB1:
SYSTEM@xe>select con_id, name from v$containers;
CON_ID NAME
---------- -----------
3 XEPDB1
1 linha selecionada.
SYSTEM@xe>select PDB_ID, PDB_NAME FROM CDB_PDBS ORDER BY 1;
PDB_ID PDB_NAME
---------- -----------
3 XEPDB1
1 linha selecionada.
SYSTEM@xe>
=> Obviamente, só pode fazer isso um usuário Autorizado/permissionado…
Abraços
