Presentation day2 oracle12c

ORACLE DATABASE 12C
New Features with CDB, PDB overview
(Reference – Oracle documentation)
Check detailed contents on
http://dbaboss.com/ 1

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):
http://dbaboss.com/
2

• 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
3

• 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;
4

• 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
5

• 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.
6

OS
GROUP
Database
Privilege
Short description
BACKUP
DBA
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
7

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
8

• 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.
9

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
10

• 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
11

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.
12

• 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 SQL
alter session set container = mine_cdb
or 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.
•
13

Presentation day2 oracle12c

Recommended

More Related Content

What's hot (20)

Similar to Presentation day2 oracle12c (20)

Recently uploaded (20)

Presentation day2 oracle12c