presentation day2 oracle12c

1

ORACLE DATABASE 12C

New Features with CDB, PDB overview

(Reference – Oracle documentation)

Check detailed contents on http://dbaboss.com/

2

New Features • Restoring a table with rman.

• In preceding versions, it was not achievable to restore a table or partition using existing physical backups. In order to restore a particular object, you must have logical backup. With 12c R1, you can recover a particular table or partition to a point-in-time or SCN from RMAN backups in the event of a table drop or truncate.

• When a table or partition recovery is initiated via RMAN, the subsequent action is performed:

• Required backup sets are identified to recover the table/partition• An auxiliary database will be constructed to a point-in-time temporarily in the process

of recovering the table/partition• Required table/partitions will be then exported to a dumpfile using the data pumps• Optionally, you can import the table/partitions in the source database• Rename option while recovery An example of a table point-in-time recovery via RMAN (ensure you already have a full database backup from earlier): Check detailed contents on

http://dbaboss.com/

3

• RMAN> connect target "username/password as SYSBACKUP";RMAN> RECOVER TABLE username.tablename UNTIL TIME 'TIMESTAMP…'AUXILIARY DESTINATION '/u01/tablerecovery'DATAPUMP DESTINATION '/u01/dpump'DUMP FILE 'tablename.dmp'NOTABLEIMPORT -- this option avoids importing the table automatically.

REMAP TABLE 'username.tablename': 'username.new_table_name'; -- can rename table with this option. • Important notes: • Ensure satisfactory free space available under /u01 filesystem for auxiliary database and

also to keep the data pump file• A full database backup must be exists, or at least the SYSTEM related tablespaces• The following limitations/restrictions are applied on table/partition recovery in RMAN:• SYS user table/partition can’t be recovered• Tables/partitions stored under SYSAUX and SYSTEM tablespaces can’t be recovered• Recovery of a table is not possible when REMAP option used to recovery a table that

contains NOT NULL constraints


4

• How to execute SQL statement in RMAN • In 12c, you can now achieve any SQL and PL/SQL commands in RMAN

without the need of a SQL prefix: you can execute any SQL and PLS/SQL commands directly from RMAN. How you can execute SQL statements in RMAN:

• RMAN> SELECT username, machine FROM v$session;• RMAN> ALTER TABLESPACE users ADD DATAFILE SIZE 12991m;


5

• DDL logging • There was no path choice available to log the DDL action in the previous releases.

In 12cR1, you can now log the DDL action into xml and log files. This will be very useful to know when the drop or create command was executed and by who. The ENABLE_DDL_LOGGING initiation parameter must be aligned in order to turn on this feature. The parameter can be set at the database or session levels. When this parameter is enabled, all DDL commands are logged in an xml and a log file under the $ORACLE_BASE/diag/rdbms/DBNAME/log|ddl location. An xml file contains information, such as DDL command, IP address, timestamp etc. This helps to identify when a user or table dropped or when a DDL statement is triggered.

• • To enable DDL logging• SQL> ALTER SYSTEM|SESSION SET ENABLE_DDL_LOGGING=TRUE; • The following DDL statements are likely to be recorded in the xml/log file:• •CREATE|ALTER|DROP|TRUNCATE TABLE• •DROP USER• •CREATE|ALTER|DROP PACKAGE|FUNCTION|VIEW|SYNONYM|SEQUENCE


6

• Online rename and relocation of an active data file • Unlike in the previous releases, a data file migration or renaming in Oracle database 12c R1 no longer

requires a number of steps i.e. putting the tablespace in READ ONLY mode, followed by data file offline action. In 12c R1, a data file can be renamed or moved online simply using the ALTER DATABASE MOVE DATAFILE SQL statement. While the data file is being transported, the end user can perform queries, DML and DDL tasks. Moreover, data files can be migrated between storages e.g. from non-ASM to ASM and vice versa.

• • Change name a data file:• SQL> ALTER DATABASE MOVE DATAFILE '/u00/data03/users01.dbf' TO '/u00/data/users_01.dbf'; • Migrate a data file from non-ASM to ASM:• SQL> ALTER DATABASE MOVE DATAFILE '/u00/data03/users_01.dbf' TO '+DG_DATA'; • Migrate a data file from one ASM disk group to another:• SQL> ALTER DATABASE MOVE DATAFILE '+DG_DATA/DBNAME/DATAFILE/users_01.dbf ' TO '+DG_DATA_02'; • Overwrite the data file with the same name, if it exists at the new location:• SQL> ALTER DATABASE MOVE DATAFILE '/u00/data03/users_01.dbf' TO '/u00/data_new/users_01.dbf'

REUSE; • Copy the file to a new location whilst retaining the old copy in the old location:• SQL> ALTER DATABASE MOVE DATAFILE '/u00/data03/users_01.dbf' TO '/u00/data_new/users_01.dbf' KEEP; • You can monitor the progress while a data file being moved by querying the v$session_longops dynamic

view. Additionally, you can also refer the alert.log of the database where Oracle writes the details about action being taken place.


7

OS GROUP

Database Privilege

Short description

BACKUPDBA

SYSBACKUP This group allows operating system users to have a limited set of database backup and recovery related administrative privileges

DGDBA SYSDG This group allows a group of operating sytem users to have a limited set of privileges to administer and monitor Oracle Data Guard

KMDBA SYSKM This allows operating sytem users to have a limited set of privileges for encryption key management such as Oracle Wallet Manager management, since, by default, Oracle 12c encapsulates features such as database vault


8

Overview of CDB• From a physical viewpoint, a CDB has essentially the same structure as a non-CDB,

except that each PDB has its own set of tablespaces (including its own SYSTEM and SYSAUX tablespaces) and data files.

• One control file • A CDB has one online redo log and one set of archived redo log files. • One or more sets of temp files • By default, the CDB has a single default temporary tablespace named TEMP that every

PDB uses. You may choose to create a different default temporary tablespace. Only a temporary tablespace that you create while connected to the root can serve as a default temporary tablespace for the CDB. For an distinct PDB, you may override the CDB-wide temporary tablespace by creating a local temporary named TEMP, and then setting it as the default.

• One set of undo data files Check detailed contents on http://dbaboss.com/

9

• In a single-instance CDB, only one active undo tablespace exists. For an Oracle RAC CDB, one active undo tablespace exists for each instance. Only a common user who has the suitable privileges and whose current container is the root can create an undo tablespace. All undo tablespaces are visible in the data dictionaries and related views of all containers.

• A set of system data files for every container.

• The primary physical difference between CDBs and non-CDBs is the system data files. A non-CDB has only one set of system data files. In contrast, the root and each PDB in a CDB has its own SYSTEM and SYSAUX tablespaces and its own complete set of dictionary tables relating the objects in itself.

• In a typical use case, each PDB has its own set of non-system data files. These

data files comprise the data for user-defined schemas and objects in the PDB. • The storage of the data dictionary within the PDB permits it to be portable. You

can easily plug and unplug a PDB into a CDB.


10

Overview of PDB• Individually PDB has its own private data dictionary for customer-created database

objects; CDB on the other hand as a whole has the data dictionary for the Oracle-supplied system each data dictionary defines its own namespace. In other words, there is global Data dictionary (CDB level) and local one (PDB level).

• There is a new split data dictionary architecture that allows a PDB to be quickly unplugged from one CDB and plugged into a different CDB

• Each PDB sees a read-only definition of the Oracle-supplied system• There are global database initialization parameters on CDB level and local ones.

PDB parameters belong only to you particular PDB and will be persistent even after you unplug you PDB.

• Database users can be global (CDB) or local (PDB only). SYS and SYSTEM users exist in both DBs right at the beginning. If you create a new user in CDB you will see it in PDB also. In case of creation of a user on PDB level it will stay local.

• Temporary tablespaces can be global or local


11

• Redo logs and Undo tablspace are only global (on CDB level)

• Data Guard acts on the CDB as a whole; RMAN scheduled backups are done for the CDB as a whole; you can back up a selected PDB whenever you want to; you can do point-in-time

• An application connects, with no code changes, to a PDB; the system administrator connects to the CDB; the service named in the connect string specifies the destination PDB

• A PDB allows a clear declarative definition of an application; one PDB

knows nothing of the other PDBs within the same CDB; each PDB is a hermetically sealed container. That ensures new level of DB independence and robust security


12

Question and Answer• Now can we Point-In-Time recovery be conducted at Pluggable Database (PDB) level? • Yes, it will be possible. • Now can we have database services be created inside a Pluggable Database (PDB)?• Of course you can have many services within a PDB. Each will denote the PDB within which it is defined as

the initial current container. Use the usual methods to create, maintain, and drop additional services in a PDB. A PDB’s default service must not be dropped. Of course, service names should be unique across all the databases that are registered with a particular listener.

• Now can we have local TEMPORARY tablespace at Pluggable Database (PDB) level?• In spite, during the PDB formation only SYSTEM and SYSAUX tablespaces created, you can create local

temporary tablespace later for each PDB. UNDO tablespace can NOT be local and stays on the CDB level. • Why is conventional database mode will be still available in 12c database and later versions?• Yes, on Oracle 12c you will have two choices of creating a usual old-fashioned Oracle database (non-CDB)

or creating a Container Database (CDB) that will hold all your Pluggable Databases (PDB) that you will create or plug later. However, based on my information non-CDB mode will be available only in 12c release 1 for compatibility reasons and will be discontinued in 12cR2.


13

• Why or not Oracle 12c database have only one container?Yes and No! In fact, Oracle considers a CDB as well as all PDBs as containers. Every container has own name. For example a single Container Database (CDB) has a container name CDB$Root. Each Pluggable database has a container name alike to the PDB name. On CDB level by default your current container is CDB$Root but you can switch between PDBs’ containers also. On CDB level you can modified current container with following SQLalter session set container = mine_cdbor verify current container with below SQL:select Sys_Context('Userenv', 'Con_Name') "current container" from dual;

• Why cloning a PDB from one in a dissimilar CDB supported? So far it is not seen it in 12c Beta 2, but Oracle intends to provision it in the final version. You’ll identify the source CDB by creating a database link to it from the CDB in which you will produce the clone.

• Why online PDB cloning supported?• Not in 12c Beta2, but Oracle intentions to eliminate this constraint in the final version by

using the same approach that allows online RMAN backup: by re-constructing any blocks that change during the time it takes to copy the source PDB’s datafiles.

•


presentation day2 oracle12c

Data & Analytics