aman sharma rman_12c_new_features_sangam2013

What’s New in 12c RMAN?

Aman Sharma

Aman Sharma- Sangam 2013 2

Introduction to pre 12.1 Databases

Introduction to 12c Multitenant database

Using RMAN in multitenant environment

Using RMAN for Table-mode recovery

Enhanced support for SQL statements

Separation of duties using SYSBACKUP role

12c Enhancements for Multi-section Backups & Database Duplication

12c Enhancements for Cross platform Data transport

Q & A

Presentation Agenda

Aman Sharma

About 12+ years using Oracle Database

Oracle ACE

Frequent Contributor to OTN Database forum(Aman….)

Oracle Certified

Sun Certified

Twitter : @amansharma81 *

Oracle Blog : http://blog.aristadba.com *

Email: [email protected]


Who Am I?

http://twitter.com/amansharma81

http://blog.aristadba.com*/

My Books




Introduction to 12c Multitenant database architecture

Using RMAN in multitenant environment






Q & A

Presentation Agenda

SALES

Shared Pool

LGWR DBWR PMON

Buffer Cache

System

Metadata

User

Metadata User Data

Instance

Database

CTL

SYSTEM SYSAUX UNDO

TEMP FLBLOG BKUP

ARCH

ORL

SALES App

11g Database Architecture(simplified)


SALES

Shared Pool

LGWR DBWR PMON

Buffer Cache

System

Metadata

User Metadata User Data

HR

Shared Pool

LGWR DBWR PMON

Buffer Cache

System

Metadata

User Metadata User Data

CTL

UNDO TEMP

ORL

SYSTEM SYSAUX SALES

ARCH

CTL

UNDO TEMP

ORL

SYSTEM SYSAUX HR

ARCH

SALES App HR App

The More The Merrier?


• The databases are created for each client/account • Each database is a tenant at the server • Each database would need its own system

resources • Consolidation, if the number of db’s is large,

becomes a major challenge • Schemas are used to ensure privacy • Provisioning takes a huge time • Patching, not only becomes complex but also

takes a huge time


Not really!!


Which Is Better?



Introduction to 12c Multi-tenant database architecture

Using RMAN in multi-tenant environment






Q & A

Presentation Agenda

• First database release made for cloud and consilidation

• Using 12c Multitenant architecture, DBA’s can create private database clouds

• Enables database to be used as DbaaS

• Much efficient resource sharing among databases

• Reduced overhead for memory and storage

• Ensures privacy and enables role separation for database management

• Rapid provisioning and cloning

• Patching and upgrading becomes easier, less time consuming


12c Multi-tenant Database

• Fully RAC compatible

• Compatible with non-CDB databases

• Using Cloud Control 12c and SQL Developer, management of CDB’s and PDB’s become much easier

• Ease in performance troubleshooting

• Easy migration of PDB’s between different environments i.e. database releases

• Complete control over resource management using Resource Manager for both CDB and PDB

• Manage many databases as one!!


12c Multi-tenant Database (cont.)

CDB Instance

ROOT container

SALES

PDB

HR

PDB

FINANCE

PDB

CDB Database

SEED

Multi-tenant Database Architecture(simplified)

CON_ID=1 CON_ID=2

CON_ID=4 CON_ID=3

CON_ID=5

CON_ID=0


• A multitenant CDB database always contains – ROOT container – SEED container

• A CDB may also contain – PDB container

• Within one CDB, there can be maximum 252 PDB’s(for Enterprise Edition)

• Crossing the threshold throws ORA-65010

• Within one CDB,one PDB is allowed for free. More than 1 would require you to pay $

• For Standard Edition, only one Pluggable database is allowed

• An Instance is allocated for the whole CDB database

• V$CONTAINERS


Containers in Multitenant Database

SGA PDB1

LGWR DBWR PMON

SGA PDB2

Alert Log SPFILE

CDB Instance

CDB Instance

Maintained by SYS user

Allocated for the CDB only

Maintained by CDB SPfile/PFILE

enable_pluggable_database=TRUE

No PDB specific SPFILE/PFILE

Parameter(s) changed at PDB level don’t go up to their CDB database


CDB Database

CDB$ROOT

OBJ$ TAB$ USER$

PDB$SEED

CTL

ORL

SYSTEM SYSAUX UNDO

TEMP FLBLOG BKUP

ARCH

System Metadata

Root Container

RSRCMGR

CON_ID=2

CON_ID=1

CON_ID=0


Root Container

• The very first tenant of the multitenant database

• CDB$ROOT(predefined)

• Contains data files, online redo logs, control files, Undo

• Contains system metadata

• Contains information about underlying PDB’s

• Contains common users

• Shouldn’t contain user data

• Resource Manager-for both CDB and underlying PDB’s

• Managed by a Container DBA(CDBA)

• Backup support by RMAN


PSDB$SEED

SYSTEM SYSAUX TEMP

Seed Container

Default Pluggable database

Created at the time of creation

of the multitenant database

Named as PDB$SEED

Acts as a template for creating

pluggable databases in the

future

Users/DBA’s can’t create and

modify objects in the seed

database

Can not be deleted

One CDB contains only one

SEED container

Backup support by RMAN


CON_ID=2

CDB Database

CDB$ROOT

OBJ$ TAB$ USER$

PDB$SEED

CTL

ORL

SYSTEM SYSAUX UNDO

TEMP FLBLOG

ARCH

System Metadata

OBJ$ TAB$ USER$

USER Metadata

SYSTEM

TEMP SYSAUX USERS SALES

SALES

PDB

Country

Customers

USER

Data

Metadata Link

SYSTEM SYSAUX TEMP

Pluggable Container/DB(PDB)

RSRCMGR

RSRCMGR


Pluggable Container

• User defined and created

• Explicitly named

• Stores user-data & user-metadata

• For applications, appear as a normal database

• Contains local users-specific to exactly one PDB

• PDB specific Resource Manager

• 252 Pluggable containers maximum are allowed in one CDB

• Managed by PDB DBA(PDBA)

• Linked with other PDB’s using inter-PDB DB link

• V$PDBS, DBA_PDBS


CDB Database

PSDB$SEED

SYSTEM SYSAUX TEMP

SGA PDB1

LGWR

SGA PDB2

CDB Instance

DBWR SMON

CTL

UNDO TEMP

ORL

SYSTEM SYSAUX

FLBL

ARCH

CDB$ROOT

System Metadata

OBJ$ TAB$ USER$

OBJ$

USER Metadata

SALES

PDB

Country

Customers

USER

Data

TEMP SYSTEM SYSAUX SALES

TAB$ USER$

OBJ$

USER Metadata

HR

PDB

DEPT

EMP

USER

Data

TEMP SYSTEM SYSAUX HR

TAB$ USER$

Metadata Link

Inter PDB DB Link

SALES App HR App

RSRCMGR

RSRCMGR

RSRCMGR



Are You Thinking?


Well, Don’t Forget!!








12c enhancements for multi-section backups & database duplication

12c enhancements for Cross platform Data transport

Q & A

Presentation Agenda


RMAN in Multitenant Environment

RMAN Non-CDB

PDB

CDB$ROOT

CDB


BACKUP command-12c!

RMAN>BACKUP DATABASE;

• Backup of whole database(CDB/non-CDB)

RMAN>BACKUP PLUGGABLE DATABASE HRPDB;

• Backup of pluggable database(s)

RMAN>BACKUP PLUGGABLE DATABASE ROOT;

• Backup of ROOT container database

RMAN> BACKUP TABLESPACE HRPDB:HR_TBS;

• Partial backup of pluggable database


RECOVER command -12c!

RMAN>RECOVER DATABASE;

• To recover whole database(CDB/non-CDB)

RMAN>RECOVER PLUGGABLE DATABASE HRPDB;

• To recover pluggable database(s)

RMAN>RECOVER PLUGGABLE DATABASE ROOT;

• To recover ROOT container database

RMAN>RECOVER TABLESPACE HRPDB:HR_TBS;

• TO recover partially pluggable database




RMAN in multitenant environment

RMAN for Table-mode recovery





Q & A

Presentation Agenda

• Using Tablespace Point-in-time

recovery(TSPITR)

• Using Database Point-in-time

recovery(DBPITR)

• Using Recycle Bin

• Using Flashback Table command

Sounds good, so why we need anything new?


Performing Recovery of Table-pre 12c

You know it already!

• Using DBPITR for a one or just a few tables is just like-replacing engine too along with the flat wheel of your car!

• For recovery of a single table, TSPITR is also not much different from DBPITR .

• Both DBPITR & TSPITR move the entire database or tablespace back in the time.

• For TSPITR, the tablespace must be self-contained.

• Table dropped with PURGE option can’t be recovered using Recycle Bin.

• Flashback Table command only works if there is no structural change done over the table.

• If there is no sufficient Undo data available, Flashback Table won’t work.


Limitations in table recovery using old techniques

• New feature in RMAN 12c

• Enables the recovery of table(s) and table-partition(s) using RMAN

• Uses database backups(Backup Sets) and archived redo logs

• Database remains online(read-write) while recovery proceeds

• Happens at an auxiliary location

• Uses an automatically created & maintained Auxiliary instance

• Other database objects remain untouched and accessible

• Requires that the database must be – Archive log mode – COMPATIBLE=12.0 – OPEN_MODE=READ WRITE


12c RMAN Table-mode Recovery

Recover Table(along with options)

Backup is located

Auxiliary instance creation at the

mentioned destination

Recovery gets performed using

the backups at the auxiliary location

Automatic creation of EXPDP Dump File

containing the recovered table

Automatic Import of the recovered

table in the database

Auxiliary instance, DUMP file are

removed

RMAN renames the recovered

table(optional)

Table Recovery is complete!


RMAN Table Recovery-Process Flow

• Recovery Point-in-Time options

– Until Time(requires NLS_LANG & NLS_DATE_FORMAT) – Until SCN – Until Sequence

• Optional Configurations

– AUXILIARY DESTINATION: • Path for the auxiliary instance creation

– DUMP FILE • Name of the dump file which would contain the recovered table

– DATAPUMP DESTINATION • OS path for the export dump file

– NOTABLEIMPORT • To not do the automatic import of the recovered table in the

target database

– REMAP TABLE/TABLESPACE • To rename the recovered table or to move to a new tablespace


RMAN Table Recovery-Options

RMAN> RECOVER TABLE AMAN.TESTTAB OF PLUGGABLE DATABASE APDB UNTIL TIME "to_date('2013-09-13:22:30:00','YYYY-MM-

DD:HH24:MI:SS')" AUXILIARY DESTINATION

'/tmp' DATAPUMP DESTINATION '/tmp' DUMP

FILE 'rtab_dump.dmp';

RMAN> RECOVER TABLE AMAN.TESTTAB OF PLUGGABLE DATABASE APDB UNTIL SCN 2235227 AUXILIARY DESTINATION

'/tmp/aux' DATAPUMP DESTINATION

'/tmp/dump/' DUMP FILE 'rtab_dump.dmp';


RMAN Table Recovery-Examples


RMAN Table Recovery-Limitations

• Tables and table partitions belonging to SYS schema can not be recovered

• Tables and table partitions belonging to the tablespaces SYSTEM and SYSAUX can not be recovered

• Tables and table partitions on standby databases can not be recovered

• Tables with named NOT NULL constraints can not be recovered with the REMAP option




RMAN in multitenant environment

RMAN for Table-mode recovery



12c Enhancements for Incremental Backups & Database Duplication


Q & A

Presentation Agenda


Support for SQL statements in RMAN

• RMAN of versions before 12.1 requires SQL

prefix

• From 12.1 onwards, no SQL prefix is required

• DESC[RIBE]command is supported natively

RMAN> SQL ‘alter system archive log current’;

RMAN> select INSTANCE_NAME,STATUS from V$INSTANCE;

RMAN> DESC HR.DEPARTMENTS








12c Enhancements for Multi-Section Backups & Database Duplication


Q & A

Presentation Agenda


SYSBACKUP Role in 12c

• New predefined role-exclusively for backup/recovery operations

• Enables to create separation of duties for different database administration related tasks – SYS user with the SYSDBA role, for complete control

– Non-default user with the DBA role, for day-to-day activities and normal usage

– Non-default user with the SYSBACKUP Role-for backup/recovery related tasks

• Privileges included in the SYSBACKUP role (partial list) – STARTUP/SHUTDOWN – Create Control File, SPFILE, PFILE – FLASHBACK DATABASE

• Does not include SELECT ANY TABLE privilege

• Created with the database installation

• Using SYSBACKUP role in the OS authentication logs you as (new) SYSBACKUP schema

• Best practice- create a new, non-default schema with the SYSBACKUP role assigned to it, for both CDB and PDB containers










Q & A

Presentation Agenda


Multi-section Backup Enhancements

• Multi-section backups, in the previous release

– For Backup Set format only

– For full backups only

• Since 12c onwards, Multi-section backups are supported for

– Backup Set & Image Copy formats

– Full & Incremental Backups

• Applies only to the data files

• Benefits remain the same-faster backups/restores


RMAN DUPLICATE command Enhancements

• 11.1 introduced ACTIVE DATABASE DUPLICATION – Uses Image Copies

– Known as Push method

• 11.2 enhanced the same – Connection to the target database made optional

• 12c further enhances the DUPLICATE command – Support for Backup Sets

– Termed as Pull method

• Support for – Compressed backup sets

– Encryption

– Multi-section backups

– NOOPEN option










Q & A

Presentation Agenda


Cross-Platform Transport Enhancements

• 8i introduced the feature of Transport Tablespace – Databases, source and destination , must match in the block size

– OS must be the same across the source and target databases

• 9i enhanced the same feature with Multiple Block Size support – OS still must be the same across the source and target database

• 10.1 introduced Cross Platform Tablespace Feature – Uses Image Copies

– Convert DATAFILE/TABLESPACE

• 10.2 enhanced the same feature with the option of Cross Platform Database – Convert DATABASE

• 12c further enhances the Cross Platform Transport – Support for Backup Sets

• Support for – Compressed backup sets

– Multi-section backups

– Allows inconsistent tablespace backups

• Completely supported for Multitenant environment

Backup sets created for cross platform transport are NOT cataloged in the control file


12c Cross Platform Transport-Going Deeper

• Prerequisites – COMPATIBLE = 12.0 – Source Database= Read Only (for Cross Platform Database

transport)

– Source Database= Read Write(for Cross Platform Tablespace transport)

• New Options – To perform Cross Platform database backup using Backup Sets

• BACKUP To Platform(conversion would be done on the source host)

• BACKUP For Transform(conversion would be done on the target host)

– To restore the cross platform database backup over the destination host • RESTORE FOREIGN

– To perform the Cross Platform tablespace backup • BACKUP To Platform….DATAPUMP

• BACKUP For Platform….DATAPUMP

– To perform the inconsistent tablespace backup • ALLOW INCONSISTENT


Cross Platform Tablespace Inconsistent Backups

• Cross Platform Tablespace transport in prior versions – Source Tablespace= Read Only

– Source Database= Read Write

– Can be used right away to plug-in the tablespace at the destination database

– Tablespace being in read-only mode may cause application a downtime

• Cross Platform Tablespace transport using Inconsistent backup – Uses new option ALLOW INCONSISTENT – The source tablespace remains ONLINE (READ ONLY) get host)

– The resultant backup is inconsistent as DML’s keep on hitting the data file

– The foreign data file, resulted during this backup, can not be used directly into the destination database

– Inconsistent data file is made consistent using the cross platform incremental backups

– A base level 0 backup and subsequent level 1 backups are created and applied over the destination database

– These backups are taken when the tablepsace is online

– A final level 1 backup is taken with the tablespace as read only

– RESTORE FOREIGN TABLESPACE/DATAFILE – RECOVER FOREIGN DATAFILE COPY


12c Cross Platform Transport-Example

RMAN>BACKUP To Platform ‘Linux x86 64-bit’ Format ‘/tmp/bkup_trans.bck’ DATABASE;

• To perform the conversion on the source host RMAN>BACKUP For Transport Format

‘/tmp/bkup_trans.bck’ DATABASE;

• To perform the conversion on the target host RMAN>RESTORE Foreign Database to NEW from BACKUP

SET ‘/tmp/bkup_trans.bck’;

• To restore the backup in the target host

RMAN>BACKUP For Transport ‘/tmp/bkup_tbstrans.bck’

DATAPUMP ‘/tmp/tbs.dmp’ TABLESPACE USERS;

• To perform the conversion for tablespace on the source host


Final words!

Usually when it’s about RMAN, response is

or

But remember, RMAN is oracle database’s “the tool” for performing backups and recovery tasks Have been around from a loong time(since 8.0.3) FREE!! Getting improved and more feature-rich with almost every release Worth giving a try and implemented so give RMAN a chance!


Thank You!

aman sharma rman_12c_new_features_sangam2013

Technology

c rman

c enhancements

database release

booksaman sharma sangam

c multitenant architecture

huge time aman sharma

otn database forumaman

private database clouds