References:

Explanation/Reference:

Explanation/Reference:
Explanation:
* Overview, example:
- Log into ncdb12c as sys
- Get the database in a consistent state by shutting it down cleanly.
- Open the database in read only mode
- Run DBMS_PDB.DESCRIBE to create an XML file describing the database.
- Shut down ncdb12c
- Connect to target CDB (CDB2)
- Check whether non-cdb (NCDB12c) can be plugged into CDB(CDB2)
- Plug-in Non-CDB (NCDB12c) as PDB(NCDB12c) into target CDB(CDB2).
- Access the PDB and run the noncdb_to_pdb.sql script.
- Open the new PDB in read/write mode.
* You can easily plug an Oracle Database 12c non-CDB into a CDB. Just create a PDB manifest file for the
non-CDB, and then use the manifest file to create a cloned PDB in the CDB.
* Note that to plug in a non-CDB database into a CDB, the non-CDB database needs to be of version 12c
as well. So existing 11g databases will need to be upgraded to 12c before they can be part of a 12c CDB.

D: The database internally uses standard file system interfaces to create and delete files as needed for the following database structures:
Tablespaces
Redo log files
Control files
Archived logs
Block change tracking files
Flashback logs
RMAN backups
Note:
* Using Oracle-managed files simplifies the administration of an Oracle Database. Oracle- managed files eliminate the need for you, the DBA, to directly manage the operating system files that make up an Oracle Database. With Oracle-managed files, you specify file system directories in which the database automatically creates, names, and manages files at the database object level. For example, you need only specify that you want to create a tablespace; you do not need to specify the name and path of the tablespace's datafile with the DATAFILE clause.
http://www.oracle-base.com/articles/9i/oracle-managed-files.php
http://docs.oracle.com/cd/B10500_01/server.920/a96521/omf.htm
References:

With adaptive SQL plan management, DBAs no longer have to manually run the verification or evolve process for non-
accepted plans. When automatic SQL tuning is in COMPREHENSIVE mode, it runs a verification or evolve process for
all SQL statements that have non-accepted plans during the nightly maintenance window. If the non-accepted plan
performs better than the existing accepted plan (or plans) in the SQL plan baseline, then the plan is automatically
accepted and becomes usable by the optimizer. After the verification is complete, a persistent report is generated
detailing how the non-accepted plan performs compared to the accepted plan performance. Because the evolve
process is now an AUTOTASK, DBAs can also schedule their own evolve job at end time.
Note:
* The optimizer is able to adapt plans on the fly by predetermining multiple subplans for portions of the plan.
* Adaptive plans, introduced in Oracle Database 12c, enable the optimizer to defer the final plan decision for a
statement until execution time. The optimizer instruments its chosen plan (the default plan) with statistics collectors
so that it can detect at runtime, if its cardinality estimates differ greatly from the actual number of rows seen by the
operations in the plan. If there is a significant difference, then the plan or a portion of it will be automatically adapted
to avoid suboptimal performance on the first execution of a SQL statement.
References: