oba

Multitenant development and

migration guide

Copyright 2013, Oracle and/or its affiliates. All rights reserved

DB12c

TABLE OF CONTENTS
OVERVIEW .................................................................................................................................... 3
Challenges addressed by Oracle Multitenant ............................................................................................... 3
Managing Oracle Multitenant .................................................................................................................... 4
Oracle Multitenant Architecture ................................................................................................................... 4
Path to new Architecture .............................................................................................................................. 9
CDB global choices, PDB local choices ........................................................................................................ 12
Resource Manager in Oracle Multitenant .................................................................................................. 14
Summary .................................................................................................................................................. 15
Appendix .................................................................................................................................................. 16
Appendix A New Features for Oracle Database Developers .................................................................... 16
Appendix B Changes, Deprecated and Desupported Features for Oracle Database 12c......................... 19

Copyright 2013, Oracle and/or its affiliates. All rights reserved

DB12c

OVERVIEW
Oracle Multitenant Option is a new option for the Oracle Database 12c Enterprise Edition which helps
customers to reduce IT costs by simplifying consolidation, provisioning, upgrades and more.
It is supported by a new architecture that allows a multitenant container database (CDB) to hold zero, one
or many customer-created pluggable databases (PDBs). A PDB is a portable collection of schemas,
schema objects and non-schema objects that appears to an Oracle Net clients as a non-CDB. All Oracle
databases before Oracle Database 12c were non-CDBs.
This paper will explain the new Oracle Database Multitenant architecture, talks about the new features for
Oracle Database Developers as well as new features in SQL and PL/SQL. It also covers deprecated and
de-supported features in Oracle Database 12c..

Challenges addressed by Oracle Multitenant

In todays IT landscape it is fairly common to find hundreds if not thousands of databases scattered over
almost as many machines, whether they are production, test or development databases. This provides
challenges when it comes to consolidation and management of all those databases. Hours and hours are
spend by IT operational staff in making sure that the systems are kept up to date and used most efficiently.
Consolidating different environments into schemas takes away some of the pain points but has some
challenges on its own:

Name collision might prevent schema-based consolidation

Schema-based consolidation brings weaker security
Per application backend point-in-time recovery is prohibitively difficult
Resource management between application back ends may be difficult

Provisioning of databases
Patching and upgrading the Oracle Database software version

Copyright 2013, Oracle and/or its affiliates. All rights reserved

DB12c

MANAGING ORACLE MULTITENANT

Oracle Database 12c Release 1 supports both, the new multitenant architecture, called CDB architecture
and the traditional, or now referred to as non-CDB architecture.
A CDB is a container database. A container database holds one or many containers. A container is either a
PDB (Pluggable database) or the root container. The root container is a collection of schemas, schema
objects, and non-schema objects to which all PDBs belong.

Oracle Multitenant Architecture

Every CDB has the following containers
Exactly one root
Exactly one seed PDB
Zero or more user-created PDBs
From the point of view of the client connecting via Oracle Net, the PDB is the database.

Copyright 2013, Oracle and/or its affiliates. All rights reserved

DB12c

The PDB/non-CDB compatibility guarantee means that a PDB behaves the same as a non-CDB as seen
from a client connecting with Oracle Net. The installation scheme for an application back end that runs
against a non-CDB runs the same against a PDB and produces the same result.

Copyright 2013, Oracle and/or its affiliates. All rights reserved

DB12c

Data Dictionary Architecture in a CDB

Within a container database the data dictionary metadata is split between the root container and the PDBs.
In the graphic below you can see that the data dictionary in a PDB contains pointers to the data dictionary
in the root container. This architecture achieves two main goals within the CDB:
-

Reduction of duplication for example the source code for DBMS_PROFILER PL/SQL package is
stored only in CDB$ROOT and shared with the PDBs through internal links.

Ease of database upgrade the definition of a data dictionary table exists only in the root, so at
upgrade there is no need to separately modify it in every PDB

All container data objects have a CON_ID column. This table below shows the meaning of the values:
Container ID
0
1
2
All Other IDs

Rows pertain to
Whole CDB
CDB$ROOT
PDB$SEED
User-Created PDBs

In a CDB, for every DBA_ view, a corresponding CDB_ view exists.

Copyright 2013, Oracle and/or its affiliates. All rights reserved

DB12c

Commonality in a CDB
In a CDB, the basic principle of commonality is that a common phenomenon is the same in every existing
and future container.
In a CDB, common means common to all containers. In contrast, a local phenomenon is restricted to
exactly one existing container.
A corollary to the principle of commonality is that only a common user can alter the existence of common
phenomena. More precisely, only a common user connected to the root can create, destroy or modify CDBwide attributes of a common user or role.
Common and Local Users in a CDB

A common user is as database user that has the same identity in the root and in every existing and future
PDB. Every common user can connect to and perform operations within the root, and within any PDB in
which it has the appropriate privileges.
A local user is a database user that is not common and can operate only within a single PDB.

Copyright 2013, Oracle and/or its affiliates. All rights reserved

DB12c

The figure below shows sample users and schemas in two PDBs: hrpdb and salespdb.
SYS and c##dba are common users who have schemas in CDB$ROOT, hrpdb and salespdb.
Local users hr and rep exist in hrpdb.
Local users hr and rep also exist in salespdb.

Copyright 2013, Oracle and/or its affiliates. All rights reserved

DB12c

Path to new Architecture

The following graphic depicts the options for creating a PDB:

Creating a PDB by Copying it

Creation of a PDB from Seed
The Seed PDB acts as source for every future PDB to be created. It contains the minimal set of objects
required by a PDB to be operational. If you create a new PDB, it will copy those objects from the Seed
PDB. You can simply use the following SQL statement to create a new PDB from the Seed PDB using
Oracle Managed Files:

SQL> CREATE PLUGGABLE DATABASE hrpdb ADMIN USER dba1 IDENTIFIED BY <password>;

Creation of a PDB by Cloning a PDB

You can also create a new PDB by cloning it from another PDB. When you clone an existing PDB the
underlying data files will be copied so that the new PDB can exist on its own. Naturally, every user, object
and row within the PDB gets copied as well. The following SQL statement clones a PDB named salespdb
from the plugged-in PDB named hrpdb:

SQL> CREATE PLUGGABLE DATABASE salespdb from hrpdb;

Copyright 2013, Oracle and/or its affiliates. All rights reserved

DB12c

Creating a PDB by Plugging In

Plugging in and migrate a non-CDB into a PDB
There are 2 approaches:
i.
Direct adoption of a 12.1 non-CDB as a PDB
ii.
Adoption of the content of non-CDB, using for example Data Pump, into an empty PDB

Direct adoption of a 12.1 non-CDB as a PDB

A pre-12.1 non-CDB cannot be directly adopted as a PDB; it has to be upgraded in place first, using the
usual approach and then plug in. Once you have upgraded you database to 12.1, following steps are
required to migrate it into a PDB:
1) Ensure the non-CDB is in a transactional-consistent state and place it in read-only mode
2) On the non-CDB run the DBMS_PDB.DESCRIBE procedure to construct an XML metadata file that
describes the non-CDB

SQL> BEGIN
DBMS_PDB.DESCRIBE(pdb_descr_file => /tmp/noncdb_to_pdb.xml);
END;
/
The XML metadata file also referred to as the PDB manifest contains all necessary information
regarding the non-CDB database.
3) Shutdown the non-CDB
4) Create a new pluggable database from your non-CDB

SQL> CREATE PLUGGABLE DATABASE PDB_FROM_NONCDB

USING /tmp/noncdb_to_pdb.xml
COPY SOURCE_FILE_NAME_CONVERT = none STORAGE UNLIMITED

5) Run the noncdb_to_pdb.sql convert scrip in the $ORACLE_HOME/rdbms/admin/ folder of your

CDB ORACLE_HOME.
6) Open the newly created PDB in read/write mode

SQL> ALTER PLUGGABLE DATABASE PDB_FROM_NONCDB OPEN;

Adoption of the content of a non-CDB only

Adoption of the content of a non-CDB is done using Data Pumps full database export and import
functionality.

Copyright 2013, Oracle and/or its affiliates. All rights reserved

10

DB12c

If the Oracle Database release of the non-CDB is 11g Release 2 (11.2.0.3) or later then you can use full
transportable export/import to move the data. When transporting a non-CDB from an Oracle Database 11g
Release 2 to Oracle Database 12c, the VERSION Data Pump export parameter must be set to 12.0.0.0.0
or higher.
You can also use Oracle GoldenGate replication and replicate the data from the non-CDB to a PDB. Once
the PDB has caught up with the non-CDB, you can switch over to the PDB and decommission the nonCDB.

Plugging in an Unplugged PDB

In its unplugged state, a PDB is a self-contained set of data files and an XML metadata file. This technique
uses the XML metadata file that describes the PDB and the files associated with it. The XML metadata file,
also referred to as PDB manifest file, is then used to associate the PDB within a CDB.
The following graphic illustrates plugging in an unplugged PDB:

The following SQL statement plugs in a PDB named financepdb based on the metadata stored in the given
PDB manifest file. It specifies NOCOPY because the files of the unplugged PDB do not need to be copied:
CREATE PLUGGABLE DATABASE salespdb USING /tmp/financepdb.xml NOCOPY
All operations to manage PDBs are SQL statements; therefore, these can be done from a client machine
and need only authorization as suitably privileged Oracle Database users.

Copyright 2013, Oracle and/or its affiliates. All rights reserved

11

DB12c

CDB global choices, PDB local choices

This section sets out the choices that can be made only for the CDB as a whole, and gives examples of the
remaining one, those that can be made differently for each PDB

How to connect
Only CDB has a SID. PDBs do not have a concept of SID.
The direction is to use service connections either as defined in SERVICE_NAME in the tnsnames.ora file or
by using EZCONNECT. In order to migrate client connections to use services, the Oracle Net Services has
introduced a listener.ora parameter for SID to SERVICE_NAME translations. This would permit legacy
connections which still use SID descriptors to continue working. You will need to define
USE_SID_AS_SERVICE_LISTENER=ON in the appropriate listener.ora file and restart the listener to
enable this feature.

Spfiles, control files, password files

These files are common for the CDB as a whole.
This implies that PDB cannot literally have its own spfile. PDB parameters are persisted in the data
dictionary of the CDB, rather than the pfile or spfile.
You will see below that some parameter values can be set persistently with alter system within the scope of
a PDB.
If a parameter is set independently for a PDB, at unplug, the value is persisted in the manifest file. During
plug in, this value will be taken from the manifest file and used as defined there.

Character set
The character set is to be determined only for the CDB as a whole. The recommendation is that Unicode
(AL32UTF8) be used as the CDBs character set.
Some PDB character sets (binary subsets with the same single/multibyte characteristics requiring no data
conversion) will be automatically updated to the CDB character set at first open. However, most PDB
character sets different from the CDB character set will prevent the PDB from being opened in nonrestricted mode. See Support Note: Changing Or Choosing the Database Character Set (
NLS_CHARACTERSET (Doc ID 225912.1) or Oracle Globalization Support documentation ) for further
information.

Time zones
Database time zone can be different per PDB, however, there can only be one system time zone.
Session time zone is a session based setting and therefore does not affecta Multitenant environment.

NLS (National Language Support) settings

Database settings for currency (NLS_CURRENCY, NLS_ISO_CURRENCY, NLS_DUAL_CURRENCY),
used in evaluation of CHECK constraints and virtual column expressions can be different per PDB.
Initialization setting for currencies used to initialize new sessions but may be overwritten on a session by
session basis can be set per PDB. Session settings for currencies are session based settings and therefore
do not affect a Multitenant environment.
There are no changes in Locale specific settings, For example NLS_DATE_FORMAT is still managed as a
session level parameter. Each session started on behalf of a client application may run in the same or a
different locale as other sessions.

Copyright 2013, Oracle and/or its affiliates. All rights reserved

12

DB12c

CDB wide initialization parameters and PDB initialization parameters

Some initialization parameters are modifiable from within a PDB. The v$system_parameter and
v$parameter views contain a new column called ISPDB_MODIFIABLE which specifies whether a
parameter is modifiable per PDB or not.
Here is the list of parameters that are set globally in the CDB only:
audit_file_dest
audit_trail
background_core_dump
background_dump_dest
core_dump_dest
cpu_count
db_block_size
db_name
db_recovery_file_dest
db_recovery_file_dest_size
db_unique_name
instance_name
local_listener
log_archive_dest
log_archive_duplex_dest

memory_max_target
memory_target
parallel_degree_policy
pga_aggregate_limit
pga_aggregate_target
processes
result_cache_max_size
sga_max_size
sga_target
shared_pool_reserved_size
shared_pool_size
undo_management
undo_retention
undo_tablespace
user_dump_dest

To retrieve the subset of parameters which are modifiable at PDB level you can use this query:

SQL> select * from v$parameter

where ispdb_modifiable = 'TRUE'
order by name

Parameters that can have different values per PDB are distinguish by the value of CON_ID:

SQL> select name,value,con_id

from v$parameter where name='open_cursors'

If you attempt to modify a parameter within a PDB which is CDB modifiable only, you will get the bellow
error message:
ORA-65040 operation not allowed from within a pluggable database

Copyright 2013, Oracle and/or its affiliates. All rights reserved

13

DB12c

Resource Manager in Oracle Multitenant

The Database Resource Manager is enhanced to support the multitenant architecture. It allows you to
create a CDB-level plan to govern the resource competition between the PDBs within in the CDB.
The Resource Manager lets you manage following resources on per CDB-level:
The number of concurrent sessions
CPU
Amount of parallel server processes
The following are not controlled:
Use of SGA memory and ability to allocate PGA
Network I/O
Resource Manager does not allow you to manage memory distribution between PDBs directly. Instead the
database relies on the sophisticated LRU algorithms within the database that have been enhanced over
decades. Resource Management of CPU has a knock on effect in some instances of memory management
if you cant get CPU cycles you cant get data placed in the cache.

Copyright 2013, Oracle and/or its affiliates. All rights reserved

14

DB12c

SUMMARY
Oracle Multitenant represents the next generation of consolidation for application backends.
It delivers the manage-as-one benefits that adopters of schema-based consolidation had hoped to win.
Adopting it is a pure deployment choice: neither the application backend, nor the client code, needs to be
changed.

Copyright 2013, Oracle and/or its affiliates. All rights reserved

15

DB12c

APPENDIX
Appendix A New Features for Oracle Database Developers
Application Continuity
Application Continuity attempts to mask outages from end users and applications by recovering requests
following recoverable outages, unplanned and planned. Application Continuity performs this recovery
beneath the application so that the outage appears to the application as a delayed execution

Transaction Guard
Transaction Guard provides a generic tool for applications to use for at-most-once execution in case of
planned and unplanned outages. Applications use the logical transaction ID to determine the outcome of
the of the last transaction open in a database session following an outage. Without Transaction Guard,
applications that attempt to replay operations following outages can cause logical corruption by committing
duplicate transactions.

Temporal Validity Support

Temporal Validity support in Oracle Database enables you to associate a valid time dimension with a table
and to have data be visible depending on its time-based validity, as determined by the start and end dates
or time stamps of the period for which a given record is considered valid.

SQL Translation Framework

SQL Translation Framework converts non Oracle SQL within the Oracle Database at runtime. This will
enable Oracle to support other SQL dialects and it simplifies the migration of application code.

Can Grant Roles to PL/SQL Packages and Standalone Subprograms

In release 12.1, you can grant roles to individual PL/SQL packages and standalone subprograms. Instead
of a definer rights unit, you can create an invokers rights unit and then grant it roles.

SET_NULL_COLUMN_VALUES_TO_EXPR Procedure
Before release 12.1, when using edition-based redefinition (EBR), transforming the application data from its
pre-upgraded representation (in the old edition) to its post-upgrade representation (in the new edition)
required an UPDATE operation on every row a very expensive and time-consuming operation.
As of Release 12.1, you can sometimes invoke the procedure
DBMS_EDITIONS_UTILITIES.SET_NULL_COLUMN_VALUES_TO_EXPR to use a metadata operation to
transform the application data.

Implicit Statement Results

In Release 12.1, a PL/SQL stored subprogram can return query results to its client implicitly, using the
PL/SQL package DBMS_SQL instead of OUT REF CURSOR parameter. This technique makes it easy to
migrate applications that rely on the implicit return of query results from stored subprograms from thirdparty databases to Oracle databases.

Copyright 2013, Oracle and/or its affiliates. All rights reserved

16

DB12c

Client Auto-Tuning
Client Auto-Tuning is a feature that transparently optimizes the configuration parameters of OCI client
session features of middle-tier applications to gain higher application performance without the need to
reprogram you OCI application

In-Memory Column Store

This is an optional area of the SGA that stores copies of table and/or partition data in a columnar format
that is optimized for rapid scans (requires licensing of the In-Memory Option)

Force full database caching mode

This enables you to cache the entire database in memory, which may provide substantial performance
improvements when performing full table scans or accessing LOBs

Real time ADDM

This helps you analyze and resolve problems in unresponsive or hung databases without having to restart
the database

Adaptive SQL Plan Management (SPM)

SPM Evolve Advisor is a SQL advisor that evolves plans that have recently been added to the SQL plan
baseline. The advisor simplifies plan evolution by eliminating the requirement to do it manually

Adaptive query optimization

Adaptive query optimization is a set of capabilities that enable the optimizer to make run-time adjustments
to execution plans and discover additional information that can lead to better statistics

New types of histograms

This release introduces top frequency and hybrid histograms

Monitoring database operations

Real-Time Database Operations Monitoring enables you to monitor long running database tasks such as
batch jobs, scheduler jobs, ETL.

Concurrent statistics gathering

You can concurrently gather optimizer statistics on multiple tables, table partitions, or table subpartitions

SQL Test Case Builder enhancements

SQL Test Case Builder can capture and replay actions and events that enable you to diagnose incidents
that depend on certain dynamic and volatile factors

Partitioning Improvements
o

Online move of a partition (without DBMS_REDEFINITION)

Multiple partition operations in a single DDL

Interval + Reference partitioning

Asynchronous Global Index Maintenance for DROP and TRUNCATE partition

Copyright 2013, Oracle and/or its affiliates. All rights reserved

17

DB12c

Temporary UNDO
UNDO for temporary tables can now be managed in TEMP.
As we reduce the amount of UNDO in the UNDO tablespace we reduce the size of redo generated.
This allows for DML on temporary tables in Active Data Guard
SQL> ALTER SYSTEM/SESSION SET TEMP_UNDO_ENABLED=true/false

Row Pattern Matching

New pattern matching clause in SQL called match_recognize. This enables users to logically partition and
order the data used in match_recognize clause. It enables you to define patterns using regular expression
syntax over pattern variables

Improved Defaults
Default to a sequence, default when null inserted

Increased Size Limit for varchar2, nvarchar2 and RAW Data Types
Varchar2, NVarchar2 and raw datatypes may be up to 32k in size, like in PL/SQL
Max_string_size init.ora set to EXTENDED (default is not this)

Fetch first rows row limiting clause

New syntax available
SQL> Select owner, object_name, object_id
From all_objects
Order by owner, object_name
FETCH FIRST 5 ROWS ONLY;

Invisible columns
Invisible columns in Oracle Database 12c provide the ability to add a column to any table such that the
newly added column will not be visible in a SELECT * query and will not be considered for insertion in an
INSERT statement that does not explicitly list that column.

Copyright 2013, Oracle and/or its affiliates. All rights reserved

18

DB12c

Appendix B Changes, Deprecated and Desupported

Features for Oracle Database 12c
Oracle Update Batching is deprecated
Oracle Update Batching is deprecated in Oracle Database 12c. Use Standard Update Batching instead

Implicit Connection Caching is desupported in Oracle Database 12c

Use Universal Connection Pool instead

Deprecation of CONNECTION_PROPERTY_STREAM_CHUMK_SIZE
JDBC property CONNECTION_PROPERTY_STREAM_CHUMK_SIZE is deprecated in this release

Stored outlines are deprecated

Stored outlines are deprecated in Oracle Database 12c. Use plan baselines instead

Changes for Oracle Call Interface

OCI deployment parameters in sqlnet.ora are deprecated. These include the following parameters:
OCI_RESULT_CACHE_MAX_SIZE, OCI_RESULT_CACHE_RSET_SIZE,
OCI_RESULT_CACHE_MAX_RSET_ROWS

Changed Default for resource_limit Parameter

The Oracle RESOURCE_LIMIT parameter determines whether resource limits are enforced in database
profiles. In this release, 12c, the RESOURCE_LIMIT parameter is set to TRUE by default.

Deprecation of catupgrd.sql Script and Introduction of New catctl.pl Utility

Oracle Database 12c introduces the new Parallel Upgrade Utility, catctl.pl. This replaces the catupgrd.sql
script that was used in earlier releases. Although you can still use the catupgrd.sql script, it is deprecated
starting with Oracle Database 12c and will be removed in future releases.

Deprecation of Oracle Restart

Oracle Restart is currently restricted to manage single instance Oracle databases and Oracle ASM
instances only, and is subject to desupport in future releases.

Copyright 2013, Oracle and/or its affiliates. All rights reserved

19

DB12c

Deprecated and Desupported Parameters

To obtain a current list of deprecated parameters run the following query in SQL*Plus:

SQL> Select name from v$parameter

Where isdeprecated=TRUE
Order by name;

Examples are:

Background_dump_dest
Commit_write
Log_archive_start

Plsql_v2_compatibility
Remote_os_authent
Sec_case_sensitive_logon

Sql_trace
Standby_archive_dest
User_dump_dest

Parameters removed and desupported in Oracle Database 12c

LOG_ARCHIVE_LOCAL_FIRST

Deprecated Views
The following views are deprecated in Oracle Database 12c
ALL_SCHEDULER_CREDENTIALS
DBA_NETWORK_SCL_PRIVILEGES
DBA_NETWORK_ACLS
V$OBJECT_USAGE. Use USER_OBJECT_USAGE instead

Deprecation of Oracle Streams

Oracle Streams is deprecated in Oracle Database 12c and may be desupported and unavailable in a later
Oracle Database release. Use Oracle GoldenGate to replace all replication features of Oracle Streams

Deprecation of Advanced Replication

Oracle Database Advanced Replication is deprecated in Oracle Database 12c. Use Oracle GoldenGate to
replace all features of Advanced Replication, including multimaster replication, updatable materialized
views, hierarchical materialized views, and deployment templates.

Deprecation of Single-Character SRVCTL CLI Options

The Server Control Utility (SRVCTL) command line interface (CLI) supports long GNU-style options in
addition to short CLI options used in earlier releases. Starting with Oracle Database 12c, single-character
options are deprecated and may be desupported in a later release.

Copyright 2013, Oracle and/or its affiliates. All rights reserved

20

DB12c

Desupport of Oracle Enterprise Manager Database Control

Starting with Oracle Database 12c, Oracle Enterprise Manager Database Control is desupported and is no
longer available. Oracle introduces Oracle Enterprise Manager Database Express (Oracle EM Express) as
a replacement. Oracle EM Express is installed when you upgrade to Oracle Database 12c.

Desupported Features on Microsoft Windows Platforms

Oracle Database 12c does not contain Oracle COM Automation. This was deprecated in Oracle Database
11g, which is the last database release that contains the database component Oracle COM Automation.
Oracle recommends that you migrate your Oracle COM applications to current technology such as the
.NET Framework.
Oracle Database 12c does not contain Oracle Objects for OLE. This was deprecated in Oracle Database
11g. You can migrate your code to the OLE DB data access standard and ActiveX Data Objects (ADO), or
you can migrate your applications to .NET (or Java or another application architecture) and use another
driver.
Oracle Database 12c does not contain Oracle Counters for Windows Performance Monitor. This was
deprecated in Oracle Database 11g. The counters were not installed by default in earlier releases, and the
counters only work on Windows. For monitoring, Oracle recommends that you use Oracle Enterprise
Manager Cloud Control.

Desupport of Oracle Cluster File System (OCFS) on Windows

Starting with Oracle Database 12c, Oracle Cluster File System (OCFS) is desupported on Windows.
Support and distribution of OCFS on Linux (OCFS and OCFS2) remains unaffected by this desupport
notice. Databases currently using OCFS on Windows to host either the Oracle cluster files (Oracle Cluster
Registry and voting files) or database files or both need to have these files migrated off OCFS before
upgrading to Oracle Database 12c.

Changes to Security Auditing Features

The auditing functionality has been redesigned in Oracle Database 12c. When you create a new database
with Oracle Database 12c, the full set of auditing enhancement features are automatically available. If you
upgrade from an earlier release, then you are given the option of using some of the new audit features and
the audit functionality from the release from which you upgraded. Oracle strongly recommends that you
migrate to the full set of the latest audit features.

Deprecated DBMS_NETWORK_ACL_ADMIN PL/SQL package Procedures

Following procedures are deprecated
CREATE_ACL
ADD_PRIVILEGE
DELETE_PRIVILEGE
ASSIGN_ACL
UNASSIGN_ACL
DROP_ACL

Deprecation of SQLNET.ALLOWED_LOGON_VERSION Parameter

The SQLNET.ALLOWED_LOGON_VERSION parameter is deprecated and should not be used anymore.

Copyright 2013, Oracle and/or its affiliates. All rights reserved

21

DB12c

AUDIT_ADMIN and AUDIT_VIEWER Roles Note

In Oracle Database 12c two roles may exist in your database that affect upgrading: AUDIT_ADMIN and
AUDIT_VIEWER

Changes to Oracle Database Vault

Starting with Oracle Database 12c, the Database Vault Configuration Assistant (DVCA) and Database
Vault Administrator (DVA) are being deprecated. Both are replaced by Oracle Enterprise Manager Cloud
Control for Oracle Database Vault configuration and administration.

Desupport of CSSCAN and CSALTER

With the introduction of Oracle Database Migration Assistant for Unicode (DMU), Oracle is proceeding with
the desupport of the legacy database tools, CSSCAN and CSALTER. DMU provides a complete end-toend Unicode migration solution for database administrators. Starting with Oracle Database 12c, DMU is
included with Oracle Database, and the CSSCAN and CSALTER tools are no longer included nor
supported.

Oracle Net Services Changes

In Oracle Database 12c release, Oracle Net Services has deprecated or no longer supports some features,
parameters and commands

Desupport of Oracle Net Connection Pooling

In Oracle Database 12c, Oracle Net connection pooling is no longer supported. Oracle Net connection
pooling was deprecated in Oracle Database 11g. This includes the DISPATCHERS attributes TICKS,
SESSIONS, and CONNECTIONS.

Desupport of Oracle Names

Oracle Names has not been supported as a naming method since Oracle Database 11g. You must migrate
to directory naming.

Desupport of Oracle Net Listener Password

In Oracle Database 12c, the Oracle Net Listener password feature is no longer supported. This does not
cause a loss of security because authentication is enforced through local operating system authentication.

Desupport of Oracle Names Control Utility for Oracle Net Services

The Oracle Names Control Utility is desupported and has not been available starting with Oracle Database
10g. This includes all the related control utility commands. Oracle Database clients cannot use a Names
Server to resolve connect strings. Migrate your applications to Oracle Internet Directory with LDAP
directory naming.

References:
Oracle Database SQL Reference 12c Release 1
Oracle Database PL/SQL Language Reference 12c Release 1

Copyright 2013, Oracle and/or its affiliates. All rights reserved

22