Oracle® Database Migration Assistant for Unicode
Release Notes
Release 2.1.1
November 2016
This document contains important information for Oracle Database Migration
Assistant for Unicode Release 2.1.1 that is not included in the regular documentation.
The product name Oracle Database Migration Assistant for Unicode is often
abbreviated as DMU throughout this document, in other Oracle documentation, and
on Oracle websites.
This document may be updated after it is released. To check for updates to this
document and to view other Oracle documentation, refer to the Documentation
section on the Oracle Technology Network (OTN) website:
This document contains the following topics:
• Changes between Releases 2.1.1 and 2.1 (page 1)
• Changes between Releases 2.1 and 2.0 (page 2)
• Supported Configurations (page 3)
• Installation Instructions (page 3)
• Requirements for using DMU (page 3)
• Known Issues and Limitations (page 6)
• Important Security Considerations (page 8)
• Documentation Accessibility (page 9)
Changes between Releases 2.1.1 and 2.1
The DMU repository definition has been updated in the DMU 2.1.1 release. If you
have an existing repository installed with an older DMU release, you will need to
upgrade or re-install the repository using DMU 2.1.1 before you can perform any
migration tasks with the DMU 2.1.1 software.
New Features in Release 2.1.1
The following changes are for Release 2.1.1:
• DMU 2.1.1 supports Java SE Development Kit (JDK) versions 7 and 8. Install one of
the supported JDK versions for your platform before using the DMU software.
• A new option has been provided for the pattern-based cleansing feature to control
the scope of the pattern-based replacement operation. You can now choose to apply
pattern-based cleansing to the rows containing problem data only or to all the rows
of the target columns. By default, DMU applies the pattern-based cleansing to the
rows containing problem data only.
• DMU 2.1.1 supports Oracle Database versions and later as Extended Support
for the earlier database versions has ended.
Changes between Releases 2.1 and 2.0
The DMU repository schema has been updated in the DMU 2.1 release. If you have an
old repository installed with the DMU 2.0 release, then you will need to upgrade the
repository using DMU 2.1 before you can perform any migration tasks with the DMU
2.1 software.
New Features in Release 2.1
The following changes are for Release 2.1:
• DMU 2.1 offers a solution to achieve a near-zero downtime migration to Unicode
by leveraging the DMU migration functionality in conjunction with the Oracle
GoldenGate replication technology. Using DMU 2.1 and Oracle GoldenGate or later, you can set up a migration procedure that utilizes DMU to
accomplish scanning, cleansing, and conversion of the database, while relying on
Oracle GoldenGate to capture and replicate incremental data changes that take
place during the migration process.
DMU also generates the required Oracle GoldenGate configuration files to ensure
that all the incremental data is replicated correctly by taking into consideration any
scheduled data cleansing actions already defined to address convertibility issues.
• You can now export a DMU migration profile from one database instance and
import it into another database instance created as a clone of the original instance.
The DMU migration profile contains general information about the database, userspecified migration settings for scanning and conversion operations, and any
scheduled cleansing actions.
This feature can be particularly useful for reusing and fine-tuning migration
settings during the trial migrations where end-to-end migration procedure is
rehearsed in the test environment using a snapshot of the production database.
• In addition to the Scan Report, Problem Data Report feature has been introduced to
allow the detailed information about the data in the database objects containing
convertibility issues to be generated into a spreadsheet file. Problem Data Report
can be convenient for reviewing the data issues with users who may not have
access to the DMU interface and also for record-keeping purposes.
• DMU 2.1 can detect and upgrade any existing DMU 2.0 repository in the database
to the DMU 2.1 format and preserve the migration information so that the upgrade
process is mostly transparent to the user without having to re-install the repository
• The format and content of DMU log files have been enhanced to facilitate
diagnostics collection and trouble-shooting usage issues.
Supported Configurations
The latest support information for Oracle Database Migration Assistant for Unicode is
available in the Supported Configurations document on the OTN website:
Installation Instructions
The installation instructions for Oracle Database Migration Assistant for Unicode are
available in the Getting Started document on the OTN website:
Requirements for using DMU
This section describes the following requirements for using the DMU software:
• General Database Requirements (page 3)
• Database Convertibility Requirements (page 5)
• Database Space Requirements (page 5)
General Database Requirements
The database must meet certain requirements to be supported by the DMU. These
requirements are:
• The database character set must be ASCII-based, therefore, databases running on
the EBCDIC-based platforms IBM z/OS and Fujitsu BS2000 are not supported.
• The package SYS.DBMS_DUMA_INTERNAL must be installed in the database.
The script ?/rdbms/admin/prvtdumi.plb to create the package is available as
part of the database installation. You must create the package manually by running
the script from the Oracle home of the database. See the installation instructions for
• Oracle Database Vault must be disabled before starting the migration process,
because DMU is not certified to work with it, when it is enabled.
• The database must be opened in read/write mode.
• DMU supports the migration of Oracle pluggable databases (PDBs) in Oracle
Database 12c release. If you are using the new PDB feature to consolidate databases
with different database character sets, then note that every PDB must have a
database character set that is compatible with that of the container database (CDB)
which the PDB is being plugged into. Compatible means that the character set has
to be the same or the PDB's character set must be a binary subset of the CDB's
character set, and both have to be single-byte or both have to be multibyte.
Oracle's recommended best practices approach for such consolidation is to use the
Unicode character set AL32UTF8 for the new CDB and its PDBs. AL32UTF8
provides a uniform superset character set that can support character data in any
language, thus allowing maximum compatibility among databases with different
legacy character sets to be consolidated.
To consolidate databases with different character sets:
Create a CDB with the database character set AL32UTF8 and the national
character set AL16UTF16. If most of the databases to be consolidated use the
national character set of UTF8, then use UTF8 instead of AL16UTF16.
For each non-CDB to be consolidated:
Upgrade it to Oracle Database 12c in case it uses Oracle Database version
that is earlier to 12c.
Migrate its database character set to AL32UTF8 using DMU.
Migrate its national character set to the national character set of the CDB
(AL16UTF16 or UTF8). Contact Oracle Support to find out how to do this
Use the upgraded and migrated non-CDB to create a PDB.
See Also:
Oracle Database Administrator's Guide for information about creating a PDB using a
If you have already consolidated your databases using a non-Unicode character set
and need to migrate your existing PDBs to Unicode, then you can do so using
DMU as explained in the following steps:
Create or identify an AL32UTF8 CDB into which the migrated PDBs are to be
For each PDB to be migrated:
Use the DMU to scan the PDB and resolve any reported convertibility
issues while it is still plugged into the original non-Unicode CDB.
Unplug the PDB to be migrated and plug it into the target AL32UTF8 CDB
(this will put the PDB into restricted mode due to the character set
Use the DMU to convert the PDB to Unicode.
Restart the converted PDB in unrestricted mode.
This approach allows for an efficient and predictable consolidation process, which
reduces the downtime window requirement.
For performing scanning and cleansing operations on a PDB, you can connect to
PDB from the DMU as a database user having SYSDBA privilege in the local PDB.
For performing conversion operations on a PDB, you must connect to PDB using
the DMU as either the SYS user or a common user having SYSDBA privilege in
both the local PDB and the CDB.
Database Convertibility Requirements
Additional requirements pertain to databases that the DMU should convert. Without
meeting these requirements, the DMU can still be used for scanning and cleansing the
database. The requirements are:
• All database objects, including auxiliary objects created by standard PL/SQL
packages, such as DBMS_RULE, DBMS_DATA_MINING, or DBMS_WM, must be named
using only characters from the ASCII character set. In other words, the data
dictionary of the database cannot contain non-ASCII characters except in a few
selected tables.
See Also:
Section "Migrating Data Dictionary Contents" in Oracle Database Unicode Migration
Assistant Guide
• No OLAP analytical workspaces, other than predefined system workspaces and
certain predefined Oracle Applications workspaces, can exist in the database.
• No flashback data archives can exist in the database.
• No data to be converted can reside in a read-only or offline tablespace.
• Neither cluster key columns nor partitioning key columns can be defined with
character length semantics.
• No convertible data can be present in tables in the recycle bin.
• No convertible data can be present in a reference partitioning key column.
• No convertible data can be present in ANYDATA/ANYDATASET columns.
Database Space Requirements
The migration process requires free space in the database. The free space is required in
the following areas:
• Migration repository
Repository tables store DMU internal state information, scan results, scheduled
cleansing actions, conversion plan details, and collected rowids for convertible, or
problematic, or both rows in scanned tables. Oracle recommends that you create a
separate tablespace for the migration repository.
See Also:
Oracle Database Unicode Migration Assistant Guide for more information about creating
a separate tablespace for the migration repository.
• Data conversion
Data that is converted from a legacy character set to AL32UTF8 or UTF8, and
which does not consist of ASCII characters only, usually expands in size, because
the UTF-8 encoding of a character usually has more bytes than the legacy character
set encoding of the same character. Moreover, the conversion method "Copy data
using CREATE TABLE AS SELECT" converts data in a table while creating a copy of
the table with the SQL statement CREATE TABLE AS SELECT. After the copy is
created, the source table is dropped but for some time both tables exist
simultaneously. Therefore, additional space is required to accommodate copies of
tables converted using this conversion method.
To view an estimation of the amount of free space needed per tablespace to
accommodate the data expansion and the temporary space for CREATE TABLE AS
SELECT, right-click the database node in the Navigator pane of the DMU and select
Properties. On the opened Database Properties tab, select the Scanning subtab.
Click the Estimate Tablespace Extension button at the bottom of the page to
calculate the minimum and maximum space requirements for each tablespace. The
minimum tablespace extension is calculated by taking into account the postconversion data size expansion and the temporary space requirement of the largest
table converted using the "Copy data using CREATE TABLE AS SELECT" method.
The maximum tablespace extension is calculated by taking into account the postconversion data size expansion and the temporary space requirements of the first n
largest tables converted using the "Copy data using CREATE TABLE AS SELECT"
method where n is the number of conversion worker threads.
Use the reported extension information to estimate the order of magnitude of the
required free space but use the autoextend feature of database data files to ensure
that tablespaces can expand if required.
Known Issues and Limitations
This section describes known issues and limitations.
Creating DMU Diagnostic Packages on Oracle Database PDBs
The Create Diagnostic Package functionality does not work on PDBs in Oracle
Database when the PDB has an incompatible character set with the CDB
character set due to a known database bug (reference: Bug 17384878).
Non-ASCII Characters in PDB PL/SQL Definitions
If the PDB to be migrated contains non-ASCII characters in PL/SQL objects, triggers,
and view definitions, then the DMU conversion SQL generation operation fails with
ORA-6502 for Oracle Database (reference: Bug 16488610). The workaround is
to remove the non-ASCII characters from the definitions and re-scan the data
dictionary before generating the conversion SQL statements.
Editing ANYDATASET Columns with Collections
The cleansing editor cannot properly display ANYDATASET columns containing
varrays or nested tables (reference: Bug 11692435).
To cleanse data in such columns, you need to update the problematic values or use
larger built-in content types, depending on the reported issue. You can use the
ANYDATASET and ANYDATA OCI, or PL/SQL, or both APIs to access, decompose, edit,
and rebuild ANYDATASET values.
See Also:
• Oracle Database PL/SQL Packages and Types Reference for information on the
ANYDATASET and ANYDATA Oracle-supplied types and their methods that
• Oracle Call Interface Programmer's Guide for information on the OCIAnyDataSet
and OCIAnyData interfaces that comprise the ANYDATASET C API.
LOB Segment Attributes
Due to the Oracle Database bugs #5577093, #5983283, and #6677390, LOB segments in
tables converted by the conversion method "Copy data using CREATE TABLE AS
SELECT" may lose the storage attribute RETENTION and get the storage attribute
PCTVERSION. Run the following SQL statement to restore the expected attribute:
Scheduled Cleansing from CHAR to VARCHAR2
When a scheduled cleansing action is defined to migrate a CHAR column to VARCHAR2
data type, the scan results may incorrectly report over type limit issues, even if the
post-conversion length fits within the VARCHAR2 data type limit. If you can confirm
that the post-conversion data size fits within the VARCHAR2 data type limit in the
cleansing editor, then the workaround is to set the "Allow Conversion of Data with
Issues" column conversion property to "Yes" so that the conversion feasibility test on
this column can be bypassed. This issue is fixed in Oracle Database release
(reference: Bug 12868420).
Column-level Character Set Tagging in Multibyte Databases
Due to a restriction in the DMU server-side data scanning function, DMU does not
allow character set tagging for character length semantics columns when the database
character set is multibyte and Oracle Database version is or earlier. If such
tagging is necessary, consider temporarily switching the column to byte length
semantics for the duration of the migration (reference: Bug 13242969).
Editing Columns with Shift-sensitive Character Data
The cleansing editor currently does not support editing data in columns which are
tagged with shift-sensitive character sets. You can still view the data details for cells in
these columns using the data viewer (reference: Bug 14241789).
Replacement Characters Reported as Invalid for UTF8 Target Character Set
For Oracle Database 10.2, when source character set is multibyte and target character
set is UTF8, the '?' character is incorrectly reported as invalid in the scan results. For
Oracle Database 11g releases up to, if the data being scanned contains the '?'
character followed by any non-ASCII character, then it is incorrectly reported as
invalid when the source character set is multibyte and the target character set is UTF8.
If you can confirm that there is no other invalid data in the column, you can set "Allow
Conversion of Data with Issues" property on this column to "Yes" so that the
conversion feasibility test on this column can be bypassed (reference: Bug 14530511).
Scanning Shift-sensitive Data without Shift Characters
If a column tagged with a shift-sensitive character set contains data that does not
include any shift-in or shift-out characters, and the target migration character set is
UTF8, the DMU scan may hang due to a known bug. You can work around the issue
by adding shift characters into the input data (reference: Bug 14580879).
Flashback Data Archives for Tables with Convertible Data
Before the migration to Unicode, purge the flashback data archive for storing data
from tables with convertible data, because the binary representation of the historic
character data in these tables may become invalid under the Unicode database
character set.
PL/SQL Procedure Parameter Names Ending with Non-ASCII Characters
If a PL/SQL procedure has a parameter name ending with a non-ASCII character, the
DMU post-conversion phase may fail to replace the PL/SQL procedure after the
database character set is changed to Unicode. This is due to a known Oracle Database
bug (reference: Bug 20714938). The workaround is to drop the procedure before
changing the character set and restore it after changing it.
PL/SQL Modules Containing Character Length Semantics Attributes
After the migration to Unicode, run the SQL scripts utlirp.sql and utlrp.sql in
order to invalidate and recompile all PL/SQL modules in the database so that any
internal length limits for types containing character length semantics attributes are
adjusted properly based on the new Unicode database character set. Alternatively, you
can recompile only those standalone and PL/SQL types that have character length
semantics attributes. However, there is no easy method to identify all such types, as
types can be nested or embedded in PL/SQL.
Zone Maps Defined on Tables with Converted Character Data
It is recommended to rebuild the zone maps defined on the converted tables after the
migration as the binary representation of the character data stored in those tables may
have changed.
Important Security Considerations
Unless you install the DMU on a host system to which only you and appropriately
authorized people have access, you need to take precautions to protect the DMU
installation and the DMU configuration files. Otherwise, unauthorized access to the
files could compromise security of the databases to which you connect with the DMU.
After you have uncompressed the archive file with the DMU installation, ensure that
all uncompressed files and directories are writable only to you and other authorized
operating system users. The DMU does not come with an installer that could set the
file permissions automatically. Removing the write privilege from unauthorized users
is very important because such users with access to the DMU host could modify the
DMU files to make the DMU execute arbitrary SQL statements when the DMU is later
started with SYSDBA credentials. Such SQL statements could compromise database
If you select the Save Password check box when creating a database connection, the
password you specify is saved in an obfuscated form in a password file named
cwallet.sso in your user directory. Because obfuscation is a reversible operation, use
this feature only for passwords to test databases with no production data or only if the
DMU is installed on a very well protected host. Ensure that the password file is
readable only by you.
On UNIX systems, the file is in the directory $HOME/.dmu/. On Microsoft Windows,
the file is in the directory %APPDATA%\DMU\.
This release of the DMU requires that you connect to a database specifying a database
user with the SYSDBA privilege. This user will have full access to DMU repository
objects. Do not grant any privileges on any of the DMU tables or PL/SQL packages to
any database user, except in cases documented explicitly in the DMU documentation.
Documentation Accessibility
For information about Oracle's commitment to accessibility, visit the Oracle
Accessibility Program website at
Access to Oracle Support
Oracle customers that have purchased support have access to electronic support
through My Oracle Support. For information, visit
topic/lookup?ctx=acc&id=info or visit
ctx=acc&id=trs if you are hearing impaired.
Oracle® Database Migration Assistant for Unicode Release Notes, Release 2.1.1
Copyright © 2011, 2016, Oracle and/or its affiliates. All rights reserved.
This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws.
Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit,
perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for
interoperability, is prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.
If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is
U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation,
delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental
regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on
the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.
This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous
applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take
all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by
use of this software or hardware in dangerous applications.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of
SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered
trademark of The Open Group.
This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates
are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable
agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of thirdparty content, products, or services, except as set forth in an applicable agreement between you and Oracle.