* SHUTDOWN [ABORT | IMMEDIATE | NORMAL | TRANSACTIONAL [LOCAL]]
Shuts down a currently running Oracle Database instance, optionally closing and dismounting a
database. If the current database is a pluggable database, only the pluggable database is closed.
The consolidated instance continues to run.
Shutdown commands that wait for current calls to complete or users to disconnect such as SHUTDOWN NORMAL and SHUTDOWN TRANSACTIONAL have a time limit that the SHUTDOWN command will wait. If all events blocking the shutdown have not occurred within the time limit, the shutdown command cancels with the following message:
ORA-01013: user requested cancel of current operation
* If logged into a CDB, shutdown closes the CDB instance.
To shutdown a CDB or non CDB, you must be connected to the CDB or non CDB instance that
you want to close, and then enter
SHUTDOWN
Database closed.
Database dismounted.
Oracle instance shut down.
To shutdown a PDB, you must log into the PDB to issue the SHUTDOWN command.
SHUTDOWN
Pluggable Database closed.
Note:
* Prerequisites for PDB Shutdown
When the current container is a pluggable database (PDB), the SHUTDOWN command can only
be used if:
The current user has SYSDBA, SYSOPER, SYSBACKUP, or SYSDG system privilege.
The privilege is either commonly granted or locally granted in the PDB.
The current user exercises the privilege using AS SYSDBA, AS SYSOPER, AS SYSBACKUP, or
AS SYSDG at connect time.
To close a PDB, the PDB must be open.

Explanation
The log files are created only in $ADR_HOME/log
in alert log only alter system is catched.Sun Mar 30 23:30:04 2014ALTER SYSTEM SET enable_ddl_logging=TRUE SCOPE=BOTH;Sun Mar 30 23:32:41 2014ALTER SYSTEM SET enable_ddl_logging=TRUE SCOPE=BOTH;Sun Mar 30 23:39:35 2014ALTER SYSTEM SET enable_ddl_logging=FALSE SCOPE=BOTH;[oracle@ovs trace]$ only in diag/rdbms/.../../log/ two files are capturing this. The xml file is capturing full details and text file having only the commands.
[oracle@ovs log]$ pwd/oraclebase/diag/rdbms/ora12c1/ora12c1/log[oracle@ovs log]$ cat ddl/* create table testing2(a number) create table testing3( aa number)
[oracle@ovs log]$ cat ddl_ora12c1.logSun Mar 30 23:33:26 2014diag_adl:create table testing2(a number)diag_adl:create table testing3( aa number) References:

Note:
*BY SESSION
In earlier releases, BY SESSION caused the database to write a single record for all SQL
statements or operations of the same type executed on the same schema objects in the
same session. Beginning with this release(11g)of Oracle Database, both BY SESSION and
BY ACCESS cause Oracle Database to write one audit record for each audited statement
and operation.
*BY ACCESS
Specify BY ACCESS if you want Oracle Database to write one record for each audited
statement and operation.
Note:
If you specify either a SQL statement shortcut or a system privilege that audits a data
definition language (DDL) statement, then the database always audits by access. In all
other cases, the database honors the BY SESSION or BY ACCESS specification.
*For each audited operation, Oracle Database produces an audit record containing this
information:
/The user performing the operation
/The type of operation
/The object involved in the operation
/The date and time of the operation
Reference:Oracle Database SQL Language Reference 12c

Note:
Providing a UNIX Group Name
If you are installing a product on a UNIX system, the Installer will also prompt you to provide the
name of the group which should own the base directory.
You must choose a UNIX group name which will have permissions to update, install, and deinstall
Oracle software. Members of this group must have write permissions to the base directory chosen.
Only users who belong to this group are able to install or deinstall software on this machine.

* SET_TABLE_PREFS Procedure
This procedure is used to set the statistics preferences of the specified table in the specified schema.
* Example:
Using Pending Statistics
Assume many modifications have been made to the employees table since the last time statistics were gathered. To ensure that the cost-based optimizer is still picking the best plan, statistics should be gathered once again; however, the user is concerned that new statistics will cause the optimizer to choose bad plans when the current ones are acceptable. The user can do the following:
EXEC DBMS_STATS.SET_TABLE_PREFS('hr', 'employees', 'PUBLISH', 'false'); By setting the employees tables publish preference to FALSE, any statistics gather from now on will not be automatically published. The newly gathered statistics will be marked as pending.