Oracle Database 12c, O que acontece em um CDB quando um PDB tem ser recuperado
Por Joel Pérez, Mahir M. Quluzade e Rodrigo Mufalani ,
Postado em Agosto 2014
Introducción Neste artigo nós queremos responder a questão: O que acontece durante a inicialização de um CDB se um dos PDB’s tiver com problemas de mídia (precisa de recover)? Visão geral da arquitetura Multitenant Oracle Multitenant é uma nova arquitetura do Oracle Database 12c Enterprise Edition que ajuda aos clientes a reduzir custos de TI simplificando a consolidação, provisionamento, upgrades e mais. Isso é suportado pela noa arquitetura que permite um container database (CDB) ter um ou muitos pluggable databases (PDBs). A quantidade de PDBs em um único CDB compartilha memória e background processes, deixando você operar muito mais PDBs em uma plataforma espefícica do que você pode com databases únicos na arquitetura antiga. Este é o mesmo benefício que uma consolidação baseada em schemas trás. Mas há barreiras significantes para adaptar consolidação baseada em schemas, e isso causa prpoblemas de operação. A nova arquitetura remove essas barreriras e problemas de operação.
A arquitetura Multitenant preenche completamente outras opções, incluindo Oracle Real Application Clusters (RAC) e Oracle Active Data Guard. Um database existente pode adaptado simplesmente, sem mudanças , como um pluggable database , e não há necessidade de qualquer outra mudança em outra camada de aplicação.
Um PDB pode ser desplugado de um CDB e plugado em outro. Alternativamente, você pode clonar um, no mesmo CDB, ou de um CDB para outro. Estas operações, juntas com criação de um pluggable database, são feitas com novos comandos SQL e levam alguns segundos. Consolidando um banco de dados existente como pluggable databases, simplifica a administração, que pode ser feita como um todo.
O tempo investido e os esforços para aplicar patches em um CDB resulta em aplicar patches em todos os pluggable databases. Para aplicar patch em um database específico, você simplesmente pode desplugar e plugar este em uma versão diferente do Oracle Database software, já com patch aplicado.
Oracle Database 12c Resource Manager é uma funcionalidade estendida que instantâneamente controla a competição por recursos entre os pluggable databases em um container database.
Muitos database em um servidor Antes do Oracle Database 12c , a Oracle recomendava: somente um database armazenado em um servidor. Depois do 12c nós podemos usar multiplos pluggable databases em um único container database em um único servidor. Agora questões emergem: O que acontece em um CDB quando um dos PDBs tem um problema de mídia? Como este problema de mídia afeta outros PDB’s ou o CDB? Neste artigo em nosso ambiente de testes prmcdb é um Container Database e tem dois Pluggable databases neste CDB: prmpdb01, prmpdb02
[oracle@oel62-ora12c /]$ export ORACLE_SID=prmcdb
[oracle@oel62-ora12c /]$ sqlplus / as sysdba
SQL*Plus: Release 12.1.0.1.0 Production on Wed Feb 12 12:53:16 2014
Copyright (c) 1982, 2013, Oracle. All rights reserved.
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
SQL> select con_id, cdb, name, open_mode from v$database;
CON_ID CDB NAME OPEN_MODE
------ --- --------- --------------------
0 YES PRMCDB READ WRITE
SQL> select con_id, name, open_mode from v$pdbs;
CON_ID NAME OPEN_MODE
------ ------------------ ----------
2 PDB$SEED READ ONLY
3 PRMPDB01 READ WRITE
4 PRMPDB02 READ WRITE
SQL> select file#, name from v$datafile;
FILE# NAME
----- --------------------------------------------------------
1 /u01/app/oracle/oradata/prmcdb/system01.dbf
3 /u01/app/oracle/oradata/prmcdb/sysaux01.dbf
4 /u01/app/oracle/oradata/prmcdb/undotbs01.dbf
5 /u01/app/oracle/oradata/prmcdb/pdbseed/system01.dbf
6 /u01/app/oracle/oradata/prmcdb/users01.dbf
7 /u01/app/oracle/oradata/prmcdb/pdbseed/sysaux01.dbf
8 /u01/app/oracle/oradata/prmcdb/prmpdb01/system01.dbf
9 /u01/app/oracle/oradata/prmcdb/prmpdb01/sysaux01.dbf
10 /u01/app/oracle/oradata/prmcdb/prmpdb01/prmpdb01_users01.dbf
11 /u01/app/oracle/oradata/prmcdb/prmpdb02/system01.dbf
12 /u01/app/oracle/oradata/prmcdb/prmpdb02/sysaux01.dbf
13 /u01/app/oracle/oradata/prmcdb/prmpdb02/prmpdb02_users01.dbf
SQL> select file#, status, error from v$datafile_header;
FILE# STATUS ERROR
----- --------- ---------------------------------------------
1 ONLINE
3 ONLINE
4 ONLINE
5 ONLINE
6 ONLINE
7 ONLINE
8 ONLINE
9 ONLINE
10 ONLINE
11 ONLINE
12 ONLINE
13 ONLINE
12 rows selected.
SQL> select action_time,action,version,bundle_series,comments from dba_registry_history;
ACTION_TIME ACTION VERSION BUNDLE_SERIES COMMENTS
-------------------------------- ------- --------- --------------- ---------------
24-MAY-13 01.20.05.485655000 PM APPLY 12.1.0.1 PSU Patchset 12.1.0.0.0
08-JUL-13 04.12.17.807394000 PM APPLY 12.1.0.1 PSU Patchset 12.1.0.0.0
Nota: Como você pode ver pela view dba_registery_history nosso database não teve nehum patch aplicado ainda.
Cenário: Nós iremos remover um datafule de um dos pluggable database com um comando do sistema operacional e iremos reiniciar o container database. Como você sabe, quando inicializamos um container database, os pluggable databases não são abertos automaticamente. Nós devemos usar o comando SQL alter pluggable database <pluggable database name> open; ou alter pluggable database all open; Antes de tudo fizemos um backup full do Container Database com o Recover Manager (RMAN):
[oracle@oel62-ora12c /]$ rman target /
Recovery Manager: Release 12.1.0.1.0 - Production on Wed Feb 12 12:52:32 2014
Copyright (c) 1982, 2013, Oracle and/or its affiliates. All rights reserved.
connected to target database: PRMCDB (DBID=2504197888)
RMAN> backup database plus archivelog delete all input;
Starting backup at 12-FEB-14
current log archived
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
...
Finished backup at 12-FEB-14
Starting Control File and SPFILE Autobackup at 12-FEB-14
piece handle=/u01/app/oracle/fra/PRMCDB/autobackup/2014_02_12/o1_mf_s_839336238_9hpfvkm7_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 12-FEB-14 Agora Irei remver um datafile do Pluggable Database prmpdb02.
SQL> select con_id, name, open_mode from v$pdbs;
CON_ID NAME OPEN_MODE
------ ------------ ----------
2 PDB$SEED READ ONLY
3 PRMPDB01 READ WRITE
4 PRMPDB02 READ WRITE
SQL> select file#, name from v$datafile;
FILE# NAME
----- -----------------------------------------------------
1 /u01/app/oracle/oradata/prmcdb/system01.dbf
3 /u01/app/oracle/oradata/prmcdb/sysaux01.dbf
4 /u01/app/oracle/oradata/prmcdb/undotbs01.dbf
5 /u01/app/oracle/oradata/prmcdb/pdbseed/system01.dbf
6 /u01/app/oracle/oradata/prmcdb/users01.dbf
7 /u01/app/oracle/oradata/prmcdb/pdbseed/sysaux01.dbf
8 /u01/app/oracle/oradata/prmcdb/prmpdb01/system01.dbf
9 /u01/app/oracle/oradata/prmcdb/prmpdb01/sysaux01.dbf
10 /u01/app/oracle/oradata/prmcdb/prmpdb01/prmpdb01_users01.dbf
11 /u01/app/oracle/oradata/prmcdb/prmpdb02/system01.dbf
12 /u01/app/oracle/oradata/prmcdb/prmpdb02/sysaux01.dbf
13 /u01/app/oracle/oradata/prmcdb/prmpdb02/prmpdb02_users01.dbf
SQL> ! rm –fr /u01/app/oracle/oradata/prmcdb/prmpdb02/prmpdb02_users01.dbf
SQL> shutdown immediate;
ORA-03113: end-of-file on communication channel
SQL> exit
Disconnected from Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options Como você vê, nós precisamos inicializar o Container Database:
[oracle@oel62-ora12c /]$ sqlplus "/ as sysdba"
SQL*Plus: Release 12.1.0.1.0 Production on Wed Feb 12 13:52:32 2014
Copyright (c) 1982, 2013, Oracle. All rights reserved.
Connected to an idle instance.
SQL> startup
ORACLE instance started.
Total System Global Area 801701888 bytes
Fixed Size 2293496 bytes
Variable Size 377487624 bytes
Database Buffers 419430400 bytes
Redo Buffers 2490368 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 13 - see DBWR trace file
ORA-01110: data file 13: '/u01/app/oracle/oradata/prmcdb/prmpdb02/prmpdb02_users01.dbf' O que ocorre? Container Database não está aberto Não, o database não está aberto, por causa do datafile 13 que não foi encontrado. Sim, nós podemos abrir o container database colocando este datafile offline, então podemos abrir o CDB and podemos abrir os outros PDBs. Por um outro lado, podemos restaurar e recuperar o datafile antes de abrir os outros databases. Eu restaurei o datafile removido e abri todos os PDBs novamente. Se você aplicar o Patch 17552800 (12.1.0.1.2 Database Patch Set Update released: January 14, 2014), não irá conhecer este problema, CDB irá abrir normalmente. Quando for abrir todos os PDBs, o CDB irá pular a abertura do PDB com problemas e irá abrir os demais.
Nós baixamos e aplicamos este patch .
SQL> select action_time,action,version,bundle_series,comments from dba_registry_history;
ACTION_TIME ACTION VERSION BUNDLE_SERIES COMMENTS
-------------------------------- ------- --------- ------------- ---------------
24-MAY-13 01.20.05.485655000 PM APPLY 12.1.0.1 PSU Patchset 12.1.0.0.0
08-JUL-13 04.12.17.807394000 PM APPLY 12.1.0.1 PSU Patchset 12.1.0.0.0
12-FEB-14 09.48.05.383369000 AM APPLY 12.1.0.1 PSU PSU 12.1.0.1.2
SQL> select * from dba_registry_sqlpatch;
PATCH_ID ACTION STATUS ACTION_TIME DESCRIPTION LOGFILE
17552800 APPLY SUCCESS 12-FEB-14 09.49.00.559171000 AM bundle:PSU
/u01/app/oracle/product/12.1.0/dbhome/sqlpatch/17552800/17552800_apply_PRMCDB_CDBROOT_2014Feb12_09_47_49.log Nós backupeamos nosso database e tentamos mais uma vez reproduzir o mesmo problema.
SQL> ! rm -fr /u01/app/oracle/oradata/prmcdb/prmpdb02/prmpdb02_users01.dbf
SQL> shut immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 801701888 bytes
Fixed Size 2293496 bytes
Variable Size 377487624 bytes
Database Buffers 419430400 bytes
Redo Buffers 2490368 bytes
Database mounted.
Database opened.
Agora o Container Database abriu sem qualquer erro. Agora irei abrir todos os Pluggable Databases.
SQL> alter pluggable database all open;
alter pluggable database all open
*
ERROR at line 1:
ORA-01157: cannot identify/lock data file - see DBWR trace file
SQL> select name, open_mode from v$pdbs;
NAME OPEN_MODE
------------- ----------
PDB$SEED READ ONLY
PRMPDB01 READ WRITE
PRMPDB02 MOUNTED
SQL> select file#, status, error from v$datafile_header;
FILE# STATUS ERROR
----- -------- ---------------------------------------
1 ONLINE
3 ONLINE
4 ONLINE
5 ONLINE
6 ONLINE
7 ONLINE
8 ONLINE
9 ONLINE
10 ONLINE
11 ONLINE
12 ONLINE
13 ONLINE FILE NOT FOUND Eu peguei o erro, mas outro pluggable database pode ser aberto e agora o alert log mostra:
SQL> alter pluggable database all open;
alter pluggable database all open
*
ERROR at line 1:
ORA-01157: cannot identify/lock data file - see DBWR trace file
SQL> select name, open_mode from v$pdbs;
NAME OPEN_MODE
------------- ----------
PDB$SEED READ ONLY
PRMPDB01 READ WRITE
PRMPDB02 MOUNTED
SQL> select file#, status, error from v$datafile_header;
FILE# STATUS ERROR
----- -------- ---------------------------------------
1 ONLINE
3 ONLINE
4 ONLINE
5 ONLINE
6 ONLINE
7 ONLINE
8 ONLINE
9 ONLINE
10 ONLINE
11 ONLINE
12 ONLINE
13 ONLINE FILE NOT FOUND
12 rows selected.
Eu peguei o erro, mas outro pluggable database pode ser aberto e agora o alert log mostra:
alter pluggable database all open
Wed Feb 12 15:11:15 2014
Errors in file /u01/app/oracle/diag/rdbms/prmcdb/prmcdb/trace/prmcdb_dbw0_11432.trc:
ORA-01157: cannot identify/lock data file 13 - see DBWR trace file
ORA-01110: data file 13: '/u01/app/oracle/oradata/prmcdb/prmpdb02/prmpdb02_users01.dbf'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
Wed Feb 12 15:11:15 2014
Pdb PRMPDB02 hit error 1157 during open read write and will be closed.
ALTER SYSTEM: Flushing buffer cache inst=0 container=4 local
Wed Feb 12 15:11:15 2014
Errors in file /u01/app/oracle/diag/rdbms/prmcdb/prmcdb/trace/prmcdb_p001_11482.trc:
ORA-01157: cannot identify/lock data file 13 - see DBWR trace file
ORA-01110: data file 13: '/u01/app/oracle/oradata/prmcdb/prmpdb02/prmpdb02_users01.dbf'
Wed Feb 12 15:11:18 2014
Due to limited space in shared pool (need 6094848 bytes, have 3981120 bytes),
limiting Resource Manager entities from 2048 to 32
Opening pdb PRMPDB01 (3) with no Resource Manager plan active
Pluggable database PRMPDB01 opened read write
ORA-1157 signalled during: alter pluggable database all open...
Wed Feb 12 15:11:41 2014
Shared IO Pool defaulting to 24MB Sim, outrso Pluggable Databases foram abertos normalmente. CDB pulou a abertura do prmdb02 (cujo um dos seus datafile não foi econtrado). Nós podemos restaurar o Pluggable Database com o RMAN:
[oracle@oel62-ora12c ~]$ export ORACLE_SID=prmcdb
[oracle@oel62-ora12c ~]$ rman target /
Recovery Manager: Release 12.1.0.1.0 - Production on Wed Feb 12 15:26:42 2014
Copyright (c) 1982, 2013, Oracle and/or its affiliates. All rights reserved.
connected to target database: PRMCDB (DBID=2504197888)
RMAN> restore pluggable database prmpdb02;
Starting restore at 12-FEB-14
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=44 device type=DISK
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00011 to /u01/app/oracle/oradata/prmcdb/prmpdb02/system01.dbf
channel ORA_DISK_1: restoring datafile 00012 to /u01/app/oracle/oradata/prmcdb/prmpdb02/sysaux01.dbf
channel ORA_DISK_1: restoring datafile 00013 to /u01/app/oracle/oradata/prmcdb/prmpdb02/prmpdb02_users01.dbf
channel ORA_DISK_1: reading from backup piece /u01/app/oracle/fra/PRMCDB/F231EDEC22372112E043AA38A8C01F0B/
backupset/2014_02_12/o1_mf_nnndf_TAG20140212T125307_9hpfs0td_.bkp
channel ORA_DISK_1: piece handle=/u01/app/oracle/fra/PRMCDB/F231EDEC22372112E043AA38A8C01F0B/
backupset/2014_02_12/o1_mf_nnndf_TAG20140212T125307_9hpfs0td_.bkp tag=TAG20140212T125307
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:25
Finished restore at 12-FEB-14
RMAN> recover pluggable database prmpdb02;
Starting recover at 12-FEB-14
using channel ORA_DISK_1
starting media recovery
media recovery complete, elapsed time: 00:00:09
Finished recover at 12-FEB-14
RMAN> alter pluggable database prmpdb02 open;
Statement processed
RMAN> select name, open_mode from v$pdbs;
NAME OPEN_MODE
------------------------------ ----------
PDB$SEED READ ONLY
PRMPDB01 READ WRITE
PRMPDB02 READ WRITE Conclusão Como podemos ver, depois de aplicado o PSU1, um problema de mídia em um PDB não afeta qualquer outro PDB. Isso quer dizer que quando usamos Pluggable Databases para diferentes aplicações, um problema em um PDB não vai afetar outras aplicações em outros PDBs.
Joel é um DBA expert com mais de 12 anos de experiência, especializado nas áreas de bases de dados com especial ênfase em soluções de alta disponibilidade (RAC, Dataguard, e outros). É um palestrante habitual em eventos de Oracle como: OTN LAD TOUR e outros. É o primeiro latino-americano a ser nomeado "OTN Expert " no ano de 2003 e é Oracle ACE Director. Durante estes anos, Joel trabalhou como consultor senior em um grande número de empresas e clientes em diversos países: Venezuela, Panama, Costa Rica, Dominican Rep., Haiti, Nicaragua, Guatemala, Colombia, Honduras, Ecuador, Mexico, India, Italy, France.
Mahir é um DBA Senior com mais de 10 anos de experiência no Oracle Database com foco especial em Alta disponibilidade e soluções de Recuperação contra desastres (RAC, Data Guard, RMAN,…). Atualmente trabalha para o Central Bank of the Republic of Azerbaijan. Ele é um Oracle Certified Professional DBA. Mahir é palestrante do Azerbaijan Oracle User Group (AZEROUG) e também é blogger.
Mufalani é um DBA Sr. com mais de 10 anos de experiência, começou com o Oracle 8i, mas teve a oportunidade de dar suporte a Oracle 7.3.4 em diante. É especialista em banco de dados Oracle com foco principal em Performance &Tuning e RAC. É palestrante em eventos de Oracle como: OTN LAD TOUR e outros. Atualmente trabalha como consultor diversas empresas no segmento de variados ramos como: Educação, Saúde, Tecnologia, Seguros e etc. Foi o terceiro Oracle ACE a ser nomeado no Brasil e é OCP DBA nas versões 10g e 11g. Siga Mufalani em seu blog ou no twitter @mufalani.