Flashback Database, Backup and Recovery in. Oracle Database 12c Release 2

Transcription

1 Flashback Database, Backup and Recovery in Oracle Database 12c Release 2

2 Select profile_details from oracle_community where name = Joerg Sobottka ; ORACLE DB SINCE 1991 IT Strategy OCP DBA (9i-12c) joerg.sobottka@robotron.ch Enterprise Manager Blog: Tuning High Availability Licensing Development SW Design

3 Topics Architecture Non-CDB New default architecture CDB with PDBs (Single-Tenant, Multi- Tenant) New Features for Flashback Database, Backup and Recovery (12.2 and a little bit 12.1) Detailed view into Flashback Database in a CDB-/PDB environment Do s and don ts Flashback PDB Detailed view into Backup and Recovery with RMAN in a CDB-/PDB environment Do s and don ts Backup and Recovery with RMAN Live demo

4 Architecture Non-CDB One database with typically one, sometimes more instances (RAC, Standby, ) and one system tablespace, one sysaux tablespace, typically one undo tablespace and one temp tablespace with one or more user schemas and therefore one or more user tablespaces with one or more files per tablespace, shared redo logs, flashback area, control files, archive redo logs, etc. managed as one database with one set of parameters and a central data dictionary But different applications normally don t share resources

5 Architecture Non-CDB

6 Architecture CDB/PDB - Singletenant Container-based database Available since 12.1, NEW: default architecture in 12.2 ONE Container (CDB$ROOT) with own data files (System, SysAux, Temp, Undo, possible but bad design: application tablespaces) Root container manages redo logs, flashback logs, memory, processes ONE pluggable database with System, SysAux, Temp Tablespaces as blueprint (PDB$SEED-Container) ONE pluggable user/application database with System, SysAux, Temp and Undo Tablespace (Application Container) Difference to 12.1: Every PDB now has its own UNDO (local undo)! Managed typically as ONE database Different dictionaries for CDB and PDB (metadata) Singletenant has 3 containers (CDB$ROOT, PDB$SEED, 1 Apps.PDB)

7 Architecture CDB/PDB - Multitenant Container-based database Available since 12.1 ONE Container (CDB$ROOT) with own data files (System, SysAux, Temp, Undo, possible but bad design: application tablespaces) Root container manages redo logs, flashback logs, memory, processes ONE pluggable database with System, SysAux, Temp Tablespaces as blueprint (PDB$SEED-Container) ONE OR MANY pluggable user/application databases with System, SysAux, Temp and Undo Tablespace (Application Containers) Difference to 12.1: Every PDB now has its own UNDO (local undo)! Managed typically as ONE OR MANY databases Different dictionaries for CDB and PDB (metadata) Multitenant has > 3 containers (CDB$ROOT, PDB$SEED, x Apps.PDB)

8 Architecture CDB/PDB Multitenant 12.1

9 Architecture CDB/PDB Multitenant 12.2

10 CDB/PDB States/File states Container based database Shutdown Close Nomount Mount Open Pluggable database Shutdown / alter pluggable database close Close Mount Open PDB state depends on CDB state (=> Controlfile owned by CDB) PDB MAY be opened together with CDB open or stays mounted If CDB is open, it s possible to put PDB in Mount or Open state Can t work with a PDB when CDB is closed or unmounted (nomount)

11 Flashback Database and RMAN outstanding New Features 12.1 Support for single-/multitenant databases: - Backup, restore and recover CDBs and PDBs as whole db - Point-in-time recovery of a CDB or PDB requires point-in-time recovery of the (shared) undo tablespace - Duplicate to standby databases as whole db - Flashback whole databases - Recover using backup sets from physical standby db Useful in a CDB environment: Point-in-time table recovery SYSBACKUP privilege for separation of duty (no view into data) Native sql interface enhancements Cross platform data transport using full and incremental backup sets

12 Flashback Database and RMAN outstanding New Features 12.2 Single PDB can be flashed back (rewind) to a point-in-time without influencing other PDBs or the CDB Syntax: Enhanced SET NEWNAME command for database and tablespace: set newname for database to '/oradata1/%b'; set newname for tablespace users to '/oradata2/%u'; Easier point-in-time recovery of a PDB due to local undo Point-in-time table recover to a new tablespace or new schema with REMAP_TABLESPACE and REMAP SCHEMA Point-in-time table recover checks for sufficient disk space Recover nonlogged data blocks from standby or primary database Recover UNTIL AVAILABLE REDO Restore and Recover: No need to offline files before restore/recover!

13 Flashback Database in 12.1 and 12.2 Prerequisites: - local undo must be enabled (default in 12.2, owner CDB and each PDB) - Fast recovery area must be configured (owner CDB) - Flashback logging enabled: alter database flashback on (owner CDB) - Archive logging enabled (owner CDB) - Connect as SYSDBA or SYSBACKUP - Doesn t work with Nologging, direct-path inserts, shrunken data files, Flashback a CDB with ALL included PDBs Connect to CDB Shutdown immediate Startup mount Flashback database to <timestamp/scn/restore Point/ >; Alter database open resetlogs; Useful for test environments, upgrades, automatic build systems,

14 Flashback Database in 12.2 Flashback a PDB without influencing CDB Connect to the CDB Alter session set container=pdb1r2; Create restore point PDB1R2_RP1 guarantee flashback database; Make a fault at PDB1R2: Truncate table mytab; Connect to the CDB Alter pluggable database PDB1R2 close; #PDB must be in mount state Flashback pluggable database PDB1R2 to restore point PDB1R2_RP1; # or to scn/before timestamp/ Alter pluggable database PDB1R2 open resetlogs; #can not make an open reset logs (because the owner of redo logs is the CDB), but does something=>alert.log Later on: drop restore point PDB1R1_RP1;

15 Do s and Dont s Flashback PDB Check connections TWICE! Connect could be to CDB or any PDB! Avoid to flashback single PDBs to timestamp or SCN (not guaranteed) Better: use predefined guaranteed restore points with DIFFERENT NAMES for different targets (each PDB/CDB) Namespace for restore points is each PDB/CDB Attention: If a PDB restore point is not found, it is interpreted as a CDB restore point! Helpful: - Do all at CDB$ROOT using FOR PLUGGABLE DATABASE syntax, e.g. create restore point MyRP FOR PLUGGABLE DATABASE PDB1R2; Use ALTER SESSION SET CONTAINER clause to switch to PDB, if needed. - RMAN: LIST RESTORE POINT ALL; don t show PDB information - SELECT * FROM V$RESTORE_POINT; does show PDB information

16 Backup with RMAN in a CDB/PDB environment Backup and Restore of CDB with PDBs, only CDB or PDBs without CDB is possible Backing up a PDB is nearly the same as with Non-CDB databases If a backup of a PDB is done for later use, don t forget to backup controlfile and archive logs from CDB$ROOT Syntax/Execution is depending on the connection to a container Not all RMAN syntax is working everywhere or works different: - CDB$ROOT> backup database plus archivelog; #CDB, PDBs, arch. logs - CDB$ROOT> backup database root; #CDB$ROOT only - CDB$ROOT> backup pluggable database pdb1r2; #PDB - CDB$ROOT> backup pluggable database pdb1r2 plus archivelog; #PDB/logs - PDB1R2> backup database plus archivelog; # no backup of archivelog, no error is thrown - PDB1R2> backup datafile 27; #does not make an autobackup controlfile! - CDB$ROOT> backup datafile 27; #does make an autobackup controlfile!

17 Restore and Recover with RMAN in a CDB/PDB environment (1) Remember all time: Owner of control files, spfile, flashback logs, online and archive redo logs is only CDB$ROOT Some tablespaces do exist very often (System, Sysaux, Temp, Undo), but in different containers (CDB$ROOT, PDB$SEED, user PDBs) Same syntax, different output example: REPORT SCHEMA - reports connected to a PDB only Data-/Tempfiles owned by the PDB - reports connected to a CDB all Data-/Tempfiles for the CDB$ROOT and all PDBs (including PDB$SEED) Same syntax, not understandable error: ALTER DATABASE DATAFILE 25 OFFLINE; - works in the right PDB container - CDB$ROOT: ORA-01516: nonexistent file "25" in the current container => Set container for a session is in RMAN not allowed The solution is

18 Restore and Recover with RMAN in a CDB/PDB environment (2) PDB: rman target=sys/oracle@pdb1r2 rman> run { alter database datafile 25 offline; restore datafile 25; recover datafile 25; alter database datafile 25 online; } CDB: rman target=sys/oracle@orcl12c rman> run { alter pluggable database pdb1r2 close; restore datafile 25; recover datafile 25; alter pluggable database pdb1r2 open; }

19 Restore and Recover with RMAN in a CDB/PDB environment (4) CDB: rman target=sys/oracle@orcl12c rman> run { sql 'PDB1R2' 'alter database datafile 25 offline'; restore datafile 25; recover datafile 25; sql 'PDB1R2' 'alter database datafile 25 online'; } RMAN does not allow to reconnect RMAN does not allow to set datafiles owned by a PDB offline from CDB with integrated SQL syntax RMAN can run SQL(!) statements using the old SQL keyword in a specified container environment

20 Restore and Recover with RMAN in a CDB/PDB environment (5) Where will this work? CDB? PDB1R2? PDB2R2?... PDB145R2? rman> run { alter tablespace users offline; restore tablespace users; recover tablespace users; alter tablespace users online; } CDB should not have a users tablespace (but it is possible) Connected to every PDB where a datafile/users tablespace exists Ensure: Which PDB is affected by an error and connect to this! Restore and recover a PDB-tablespace with tablespace syntax connected to the CDB is not implemented => restore/recover the whole PDB

21 Restore and Recover with RMAN in a CDB/PDB environment (6) Data Recovery Advisor Diagnosis of failures Generates scripts to repair failures Easy to use for detected failures: List failure; advise failure; repair failure; Per default does not show all failures at all time (only already detected and only with high or critical priorities) Works connected to CDB only Does work in a Non-CDB or single-tenant environment very well Is not aware of any SLAs we do have on consolidated db with high number of PDBs Can restore and recover to original location (no relocation of data files) Target DRA: Have EVERYTHING online with as LESS I/O as possible

22 Do s and Dont s RMAN in a CDB/PDB environment (1) More chances to do it wrong and to lose data or time if you don t know exactly, where you are and what you do than in a non-cdb environment For backups of single PDBs don t forget to backup the archivelogs separately, if you are connected to a PDB New RMAN session needed as PDB connection does not backup archivelogs Autobackup of controlfiles and spfile are done only after backup from CDB$ROOT level, not, if you are connected to a PDB Don t use delete input while backing up archivelogs, especially when using flashback database or with a high number of PDBs (as it is more likely than before that they may be used keep them e.g. at least 2 or 3 days on disk) With a rising number of PDBs, backups are getting huge in size. Think about incremental backup strategies or backup on PDB level

23 Do s and Dont s RMAN in a CDB/PDB environment (2) Use an external RMAN catalog! - It s cost free (no additional license needed, as long as the database is under support: - Don t loose backup metadata while creating, moving, dropping pluggable databases - Allows to report schema as of timestamp - Helps storing scripts for backup and recovery Do not drop a PDB from a container unless a new backup was taken from the new CDB where the database has been plugged in (CDB$ROOT, PDB and archive logs) and use backup controlfile to trace before and after structural changes Reduce the risk of losing data by doing all, that can be done, from the CDB$ROOT container Create predefined scripts and use them whenever possible

24 Do s and Dont s RMAN in a CDB/PDB environment (3) Ugly: Startup of a CDB may work (Opens the database without any error message) but one or more PDB can remain in mount status Consult (monitor) the ALERT.LOG often all known errors with data files, control files, etc. are reported in there (even if the CDB opens normally) Make yourself comfortable with all the new CDB and PDB views - OPEN_MODE from v$containers or v$pdbs shows mount/open status - STATUS from dba_pdbs is for Normal/Plugin/Convertion/upgrade states Trust the Data Recovery Advisor LESS than in a Non-CDB or Single PDB environment it tries its best, but it doesn t know your SLAs and it may does not know all errors BUT: use the Data Recovery Advisor with REPAIR FAILURE PREVIEW to see in combination with the ALERT.LOG, what really happened, to challenge your restore and recover strategy and to learn something about the syntax but be aware, that errors marked low are not shown by default and there may be some errors not found yet

25 Do s and Dont s RMAN in a CDB/PDB environment (4) restore tablespace system can be run on the CDB$ROOT, PDB$SEED and all user PDB containers. Use data file names/data file numbers instead of tablespaces or at least check your connections TWICE If you need to restore/recover the CDB oracle recommends to restore and recover ALL included PDBs because of possible metadata inconsistencies Train yourself regularly, e.g. create an environment, make and write down CONCEPTS and REVIEW them often: More necessary than before, to write down backup AND restore and recover concepts separately for every (pluggable) database or at least for groups of (pluggable) database with same SLA levels: WHAT? WHEN? HOW OFTEN? WHERE FROM? WHERE TO? KEEP HOW LONG? HOW TO RESTORE? HOW TO RECOVER? WHICH SLA? WHICH USERS? Use environment to exercise test scenarios again and again for backup and recovery from time to time (also with different database versions)

26 Do s and Dont s RMAN in a CDB/PDB environment (5) For dataguard environments: - Do backups from standby and restore and recover the primary to move the backup workload from your primary to your standby system - Be aware, that with 12.2 the standby system does NOT need to have all PDBs included running in your production (as it was with 12.1) - Nevertheless, ALL archive logs are shipped (and used for recovery) to the standby database system (so you can backup them there) With active data guard (EE extra cost option), e.g. block restore and recovery between primary and standby database are done without the need of interaction with a database administrator

27 Syntax Examples Live Demos

28 Your feelings: Still confused, but on a higher level? Start with your concepts!

29 weitere Informationsmöglichkeiten Über den Wolken Grenzenlose Freiheit mit purem Metall? Florian Barth, Katharina Büchse :00 Uhr, Raum Prag Schwerpunkt: Infrastruktur ODA X6M & DBVisit, braucht es mehr? Sven Illert :00 Uhr, Raum Prag Schwerpunkt: Infrastruktur Workshop: Get in Touch with Oracle Bare Metal Cloud Services (BMCS) Katharina Büchse, Florian Barth, Dr. Ingo Laue (Oracle) :00-16:00 Uhr :00-12:00 und 14:00-16:00 Uhr :00-12:00 und 14:00-16:00 Uhr Raum: Foyer Oslo-Istanbul Schwerpunkt: Community-Aktivitäten Flashback Database, Backup und Recovery in Oracle DB 12.2 Jörg Sobottka :00 Uhr, Raum Shanghai Schwerpunkt: Datenbank Oracle Database Appliance What's New? Marco Friebe :00 Uhr, Raum Budapest Schwerpunkt: Infrastruktur AWR und ASH für die Standard Edition Marco Mischke :00 Uhr, Raum Shanghai Schwerpunkt: Datenbank INFORMATIONEN am Robotron-Stand 226 auf Ebene 2 und auf

30 Thank you for your attention!