Revisado por Marcelo Pivovar - Solution Architect
Em 2013, quando o Oracle Database 12c foi lançado, diversas novas características foram introduzidas. Dentre elas, podemos destacar a Arquitetura Multitenant.
Quando falamos de arquitetura Multitenant, estamos falando de Container Databases (CDBs), Pluggable Databases (PDBs) e o PDB$SEED (que é uma Pluggable Database especial).
Esta arquitetura pode ser ilustrada com a seguinte imagem:
Nesta imagem você pode notar algumas coisas importantes. A primeira é que a arquitetura Multitenant é composta da instância de banco de dados, um container chamado Root, uma Pluggable Database chamada Seed e várias Pluggable Databases. Porém, o mais importante são os arquivos do container Root. Pode-se ver claramente que tanto o container Root como todas as Pluggable Databases possuem suas próprias Tablespaces System e Sysaux.
Também podemos observar que os Control Files e Redo Logs pertencem ao container Root e que esses arquivos são “compartilhados" (Shared) com todas as Pluggable Databases. Em outras palavras todas as Pluggable Databases leem e escrevem nos Control Files e Redo Logs, mas esses arquivos pertencem ao Container Root, de modo que ao desconectar uma Pluggable Database ela só irá levar os seus próprios arquivos, como Datafiles das Tablespaces SYSTEM e SYSAUX e os Datafiles onde se encontram os dados do negócio.
É importante notar que a criação de uma Tablespace temporária em um Pluggable Database é opcional, se não existe na Pluggable Database, ela irá utilizar a do Container Root.
Os dados de Undo são muito importantes para um banco de dados Oracle. Esses dados são armazenados em extensões dentro de segmentos em uma tablespace dedicada a armazenar este tipo de dados.
Estes dados são frequentemente utilizados para reverter transações (Rollback), para recuperar uma transação que terminou abruptamente (Ex: kill – 9, ALTER SYSTEM KILL IMMEDIATE, etc.), para executar a recuperação de uma instância, para a recuperação a um ponto do tempo, para leituras consistentes, para resolver problemas lógicos e para operações de Flashback que foram introduzidos na versão 10g. Os dados Undo são tão importantes quanto os dados Redo e ambos se complementam. Enquanto o Undo desfaz, o Redo refaz.
Na versão 12cR1 a Tablespace de Undo era compartilhada por todas as Pluggable Databases e pertencia ao CDB$ROOT.
Uma das desvantagens desta configuração é que não era possível fazer Flashback Database no nível da Pluggable Databases. Quando era necessário voltar no tempo, o Flashback Database era aplicado no Container Database, o que impactava todas as Pluggable Databases.
Outra desvantagem era que para clonar uma Pluggable Database, era necessário colocar esse PDB no modo somente leitura, assegurando assim a consistência dos dados.
E finalmente, ter uma única Tablespace de Undo era um ponto de falha. Se algo afetasse a Tablespace de Undo, todas as Pluggable Databases eram afetadas.
No Oracle Database 12.2.0.1.0 existem dois tipos de configurações de Undo, o Shared Undo e o Local Undo.
O Shared Undo nada mais é do que a mesma configuração existente no 12cR1 na arquitetura Multitenant.
O Local Undo é a nova configuração onde basicamente cada Pluggable Database tem a sua própria Tablespace de Undo. Isto pode ser observado na figura abaixo:
O Local Undo permite a solução de alguns problemas que existiam no 12cR1. Se um Container Database utilizar Local Undo então será possível que uma Pluggable Database realize Flashback Pluggable Database. Também será possível realizar clonagens on-line (Hot Cloning) onde a Pluggable Database clonada pode ser remota ou estar em outro Container Database, seja ele local ou na nuvem.
NOTA: Os exemplos a seguir foram testados noOracle Database 12.2.0.1.0 Enterprise Edition Extreme Performance 64bit, na nuvem da Oracle.
Para criar um Container Database é necessário que o parâmetro enable_pluggable_database esteja com o valor True, conforme mostrado abaixo:
SQL> show parameters enable_pluggable_database
NAME TYPE VALUE
------------------------- -------- -------------
enable_pluggable_database boolean TRUE
O comando para criar um Container Database utilizando Local Undo é:
SQL> CREATE DATABASE NuvolaCG
USER SYS IDENTIFIED BY NuvolaCG
USER SYSTEM IDENTIFIED BY NuvolaCG
EXTENT MANAGEMENT LOCAL
DEFAULT TEMPORARY TABLESPACE temp
UNDO TABLESPACE undotbs1
ENABLE PLUGGABLE DATABASE
SEED
SYSTEM DATAFILES SIZE 125M AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED
SYSAUX DATAFILES SIZE 100M
LOCAL UNDO ON;
Database created.
Ao criar um banco de dados utilizando o DBCA, esta opção já está marcada por default:
Se um Container Database foi inicialmente criado com a configuração Shared Undo e precisa ser alterado para Local Undo os seguintes passos devem ser executados:
Baixar a instância do banco de dados:
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
Abrir o banco de dados em modo upgrade:
SQL> startup upgrade;
ORACLE instance started.
Total System Global Area 5452595200 bytes
Fixed Size 8804328 bytes
Variable Size 1090521112 bytes
Database Buffers 4345298944 bytes
Redo Buffers 7970816 bytes
Database mounted.
Database opened.
Certifique-se de que está conectado ao CDB$ROOT:
SQL> show con_name
CON_NAME
------------------
CDB$ROOT
Modificar o modo de Undo para Local Undo:
SQL> alter database local undo on;
Database altered.
Reiniciar o banco de dados:
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup;
ORACLE instance started.
Total System Global Area 5452595200 bytes
Fixed Size 8804328 bytes
Variable Size 1090521112 bytes
Database Buffers 4345298944 bytes
Redo Buffers 7970816 bytes
Database mounted.
Database opened.
Verificar a configuração que está em uso:
SQL> SELECT PROPERTY_NAME, PROPERTY_VALUE
FROM DATABASE_PROPERTIES
WHERE PROPERTY_NAME = 'LOCAL_UNDO_ENABLED'
PROPERTY_NAME PROPERTY_VALUE
-------------------- ---------------
LOCAL_UNDO_ENABLED TRUE
SQL> select pdb.name PDB_NAME, tbs.name TABLESPACE_NAME
from v$tablespace tbs, v$pdbs pdb
where tbs.con_id=pdb.con_id order by 1;
PDB_NAME TABLESPACE_NAME
-------------------- -----------------
NUVOLAPDB1 SYSAUX
NUVOLAPDB1 TEMP
NUVOLAPDB1 SYSTEM
NUVOLAPDB2 SYSAUX
NUVOLAPDB2 TEMP
NUVOLAPDB2 SYSTEM
PDB$SEED UNDO_1
PDB$SEED TEMP
PDB$SEED SYSAUX
PDB$SEED SYSTEM
10 rows selected.
As Tablespaces de Undo de cada uma das Pluggable Databases são criadas no momento em que cada PDB é aberta pela primeira vez após alterar as configurações para Local Undo:
SQL> alter pluggable database all open;
Pluggable database altered.
NOTA: Se você obter o seguinte erro ao tentar abrir as PDBs:
ORA-00060: deadlock detected while waiting for resource
Você deve abrir cada uma das PDBs em modo de Upgrade, fechar e reabrir em modo normal.
SQL> select pdb.name PDB_NAME, tbs.name TABLESPACE_NAME
from v$tablespace tbs, v$pdbs pdb
where tbs.con_id=pdb.con_id order by 1;
PDB_NAME TABLESPACE_NAME
---------- ----------------
NUVOLAPDB1 TEMP
NUVOLAPDB1 UNDO_1
NUVOLAPDB1 SYSAUX
NUVOLAPDB1 SYSTEM
NUVOLAPDB2 UNDO_1
NUVOLAPDB2 SYSTEM
NUVOLAPDB2 SYSAUX
NUVOLAPDB2 TEMP
PDB$SEED UNDO_1
PDB$SEED TEMP
PDB$SEED SYSAUX
PDB$SEED SYSTEM
12 rows selected.
Como podemos ver, após a primeira abertura de cada Pluggable Database, a Tablespace de Undo é criada em cada uma delas. É importante notar que o nome default para cada Tablespace de Undo é UNDO_1. Se for necessário utilizar um nome personalizado para a Tablespace de Undo, então a PDB$SEED deve ser modificada de acordo com o que será mostrado na próxima seção.
A Tablespace de Undo utilizada na PDB$SEED para criar novas Pluggable Databases pode ser personalizada seguindo estas instruções:
Forçar a abertura da PDB$SEED:
SQL> ALTER PLUGGABLE DATABASE PDB$SEED OPEN READ WRITE FORCE;
Pluggable database altered.
Ir para o container PDB$SEED:
SQL> ALTER SESSION SET CONTAINER=PDB$SEED;
Session altered.
Uma vez que a PDB$SEED é aberta, você pode modificar a Tablespace de Undo que foi criada automaticamente na PDB$SEED ou excluí-la e criar uma nova. Neste exemplo uma nova será criada com RETENTION GUARANTEE:
SQL> CREATE UNDO TABLESPACE seedundotbs RETENTION GUARANTEE;
Tablespace created.
Ir para o container PDB$SEED:
SQL> ALTER SESSION SET CONTAINER=CDB$ROOT;
Session altered.
Voltar o PDB$SEED ao estado original:
SQL> ALTER PLUGGABLE DATABASE PDB$SEED OPEN READ ONLY FORCE;
Pluggable database altered.
Baixar a instância do banco de dados:
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
Abrir o banco de dados em modo upgrade:
SQL> startup upgrade;
ORACLE instance started.
Total System Global Area 5452595200 bytes
Fixed Size 8804328 bytes
Variable Size 1090521112 bytes
Database Buffers 4345298944 bytes
Redo Buffers 7970816 bytes
Database mounted.
Database opened.
Certifique-se de que está conectado ao CDB$ROOT:
SQL> show con_name
CON_NAME
-------------------
CDB$ROOT
Modificar o modo de Undo para Shared Undo:
SQL> alter database local undo off;
Database altered.
Reiniciar o banco de dados:
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup;
ORACLE instance started.
Total System Global Area 5452595200 bytes
Fixed Size 8804328 bytes
Variable Size 1090521112 bytes
Database Buffers 4345298944 bytes
Redo Buffers 7970816 bytes
Database mounted.
Database opened.
Verificar a configuração que está em uso:
SQL> SELECT PROPERTY_NAME, PROPERTY_VALUE
FROM DATABASE_PROPERTIES
WHERE PROPERTY_NAME = 'LOCAL_UNDO_ENABLED';
PROPERTY_NAME PROPERTY_VALUE
------------------ ---------------
LOCAL_UNDO_ENABLED FALSE
Desde novembro 2016, quando a documentação do Oracle Database 12cR2 foi lançada, diversos novos recursos se tornaram conhecidos, incluindo a nova configuração de Undo. A configuração antiga agora se chama Shared Undo, enquanto a configuração introduzida no 12cR2 se chama Local Undo. Esta nova configuração oferece ainda mais independência para cada Pluggable Database e apoia outras novas características como Hot Cloning e Flashback Pluggable Database. Esta nova configuração é recomendada pela Oracle e é por isso que os Container Databases criados na Oracle Public Cloud utilizam Local Undo.
Este artigo descreveu as maneiras de mudar entre Shared Undo e Local Undo e revisamos a teoria dos mesmos. A Oracle definitivamente continua inovando constantemente e as empresas que utilizam o banco de dados número 1 do mundo continuam se beneficiando destas inovações.
Deiby Gomez é "Oracle ACE Director", "A Oracle Certified Master 11g" e "A Oracle 12c Certified Master". Ele tem sido um orador na Oracle Open World nos EUA e no Brasil; em Colaborar, Las Vegas e OTN Tour em vários países da América Latina. Vencedor do "SELECT Choice Award da revista Editor de 2016". Ele é um membro da "OraWorld-Team" foi "Beta Tester" da versão 12cR2. Deiby é Presidente o Grupo usuários Oracle de Guatemala (GOUG) e atualmente é Consultor bancos de dados Oracle em Nuvola Consulting Group (www.nuvolacg.com). Twitter @hdeiby.
Alex Zaballa, formado em Análise de Sistemas, é especialista em Banco de Dados Oracle com sólidos conhecimentos em Servidores de Aplicação e Sistemas Operacionais; trabalha com Oracle há 16 anos, é Oracle ACE Director, certificado OCM Database 12c/11G/Cloud e conta com mais de 200 outras certificações em produtos da Oracle. Alex também é membro do Groupo de Usuários Oracle do Brasil (GUOB), fundador do Grupo de Usuários Oracle de Angola (GUOA) e membro do time OraWorld.
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.