This document contains important information for Oracle Database Migration Assistant for Unicode, Release 23.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:

http://www.oracle.com/technetwork/database/database-technologies/globalization/dmu/overview/index.html

Changes between Releases 23.1 and 19.1

The DMU repository definition has been updated in the DMU 23.1 release.

If you have an existing repository installed with an older DMU release, then before you can perform migration tasks using the DMU 23.1 software, you must upgrade or reinstall the repository using DMU 23.1.

New Features in Release 23.1

The following changes are new for Release 23.1:

• DMU 23.1 supports Java SE Development Kit (JDK) version 11. Install the supported JDK version for your platform before using the DMU software.

• Index Check

  When scanning the database, you can instruct the DMU to perform an index check and generate an index check report. This report lists all indexes whose key sizes will exceed the maximum supported size as a result of converting the database. You can then fix the problematic indexes before proceeding with the database conversion.

  See “Database Scan Report: Index Check Report” in Oracle Database Migration Assistant for Unicode User’s Guide.

• Convert using Data Pump

  A new conversion method called “Convert using Data Pump” is available. When you use this method, tables are exported to a specified database directory using Oracle Data Pump, the database character set is changed, and the tables are imported back into the database using Oracle Data Pump. This method can speed up the conversion process for tables that contain large amounts of CLOB data.

  See “Table Properties: Converting” in Oracle Database Migration Assistant for Unicode User’s Guide.

• Support for blockchain tables and immutable tables

  You can use the DMU to migrate databases that contain blockchain and immutable tables.

  See “Migrating Blockchain and Immutable Tables” in Oracle Database Migration Assistant for Unicode User’s Guide.

Changes between Releases 19.1 and 2.2

The DMU repository definition has been updated in the DMU 19.1 release.

If you have an existing repository installed with an older DMU release, then before you can perform migration tasks using the DMU 19.1 software, you must upgrade or reinstall the repository using DMU 19.1.

New Features in Release 19.1

The following changes are new for Release 19.1:

• PL/SQL code scan

  You can use the DMU to scan PL/SQL application code in the database to identify Unicode migration-related issues and coding patterns that may need to be addressed.

  See “Scanning the PL/SQL Code” in Oracle Database Migration Assistant for Unicode User’s Guide.

• Character set detection

  During data analysis, you can use the character set detection feature in the cleansing editor to help determine the real character set for problem data.

  See “Setting the Assumed Character Set” in Oracle Database Migration Assistant for Unicode User’s Guide.

• SSH support for database connections

  The Create Database Connection dialog box now supports SSH connections. You can specify the SSH host name, port, user name, key file, and so on.

  See “Creating a Database Connection” in Oracle Database Migration Assistant for Unicode User’s Guide.

Changes between Releases 2.2 and 2.1.1

The DMU repository definition has been updated in the DMU 2.2 release.

If you have an existing repository installed with an older DMU release, then before you can perform any migration tasks with the DMU 2.2 software, you must upgrade or re-install the repository using DMU 2.2.

New Features in Release 2.2

The following changes are new for Release 2.2:

• DMU 2.2 supports Java SE Development Kit (JDK) version 8. Install the supported JDK version for your platform before using the DMU software.

  See “Overview of Java Runtime Requirements” in Oracle Database Migration Assistant for Unicode User’s Guide.

• A new command-line scanner (DMU-CLS) has been introduced in this release to perform database scans and generate reports, which is useful for regularly monitoring data convertibility issues and implementing health check for Unicode databases.

  See “Scanning the Database with the DMU Command-line Scanner (DMU-CLS)” in Oracle Database Migration Assistant for Unicode User’s Guide.

• Changes and updates to support the migration of Oracle Database 12c Release 2 (12.2) to Unicode.

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 11.2.0.4 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 12.1.2.1.0 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, user-specified 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 again.

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

You can find the document at the following URL:

http://www.oracle.com/technetwork/database/database-technologies/globalization/dmu/learnmore/index.html

Installation Instructions

The installation instructions for Oracle Database Migration Assistant for Unicode are available in the Getting Started document on the OTN website.

You can find the document at the following URL:

http://www.oracle.com/technetwork/database/database-technologies/globalization/dmu/learnmore/index.html

Requirements for Using DMU

There are general requirements for using the DMU software, and also requirements specifically relating to convertibility and space.

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

• 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 PDB feature in Oracle Database 12c Release 1 (12.1) 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 the PDB’s character set must be either same as that of the CDB’s character set or it must be a binary subset of the CDB’s character set, and both the character sets must be either single-byte or multibyte.

  If you are using the PDB feature in Oracle Database 12c Release 2 (12.2) or later, and if the container database (CDB) character set is AL32UTF8, then the PDBs’ character sets do not have to be compatible with that of the CDB.

  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:

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

  2. For each non-CDB to be consolidated:

     1. Upgrade it to Oracle Database 12c in case it uses Oracle Database version that is earlier to 12c.

     2. Migrate its database character set to AL32UTF8 using DMU.

     3. 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 migration.

     4. Use the upgraded and migrated non-CDB to create a PDB.

     See Also: Oracle Multitenant Administrator’s Guide to learn how to create a PDB from a non-CDB

  If you have already consolidated your databases using a non-Unicode character set, and if you need to migrate your existing PDBs to Unicode on Oracle Database 12c Release 1 (12.1), then you can use DMU as follows:

  1. Create or identify an AL32UTF8 CDB into which the migrated PDBs are to be plugged.

  2. For each PDB to be migrated:

     1. Use the DMU to scan the PDB and resolve any reported convertibility issues while it is still plugged into the original non-Unicode CDB.

     2. Unplug the PDB to be migrated, and then plug it into the target AL32UTF8 CDB. This operation puts the PDB into restricted mode due to character set incompatibility.

     3. Use the DMU to convert the PDB to Unicode.

     4. Restart the converted PDB in unrestricted mode.

  Starting in Oracle Database 12c Release 2 (12.2), you can follow a similar procedure. The difference is that, if necessary, you can use the DMU to scan and cleanse the PDB after plugging it into the AL32UTF8 CDB because the PDB is not automatically placed into restricted mode.

  This approach allows for an efficient and predictable consolidation process, which reduces the downtime window requirement.

  To perform scanning and cleansing operations on a PDB, you can connect as a user with the SYSDBA privilege in the local PDB. However, to convert a PDB to Unicode, you must connect as the SYS user.

Database Convertibility Requirements

Additional requirements apply to databases to be converted by the DMU. Without meeting these requirements, you can still use the DMU to scan and cleanse the database.

The requirements are as follows:

• 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: “Migrating Data Dictionary Contents” in Oracle Database Migration Assistant for Unicode User’s 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 for the DMU repository and for data conversion.

Free space is required in the following areas:

• DMU repository

  The DMU 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 DMU repository.

  See Also: Oracle Database Migration Assistant for Unicode User’s Guide for more information about creating a separate tablespace for the DMU 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. This is 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 post-conversion 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 post-conversion 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

DMU has a number of known issues and limitations.

Converting Auditing Tables on Oracle Databases

The following notes apply when converting auditing tables on Oracle databases:

• To convert an Oracle database to Unicode using the DMU, where the database version is between 12cR2 and 21c, you must open the database in UPGRADE mode before starting the conversion process to work around a known issue with converting auditing tables (reference: Bug 22230211). This workaround is no longer necessary when converting Oracle Database version 23ai or later.

• For better migration performance, it is advisable to archive the AUDSYS.AUD$UNIFIED table and purge its contents before starting the DMU migration process. If possible, disable audit policies that cause extensive auditing of SYS user activities for the duration of the migration to minimize performance overhead.

Creating DMU Diagnostic Packages on Oracle Database 12.1.0.1 PDBs

The Create Diagnostic Package functionality does not work on PDBs in Oracle Database 12.1.0.1.0 when the PDB has an incompatible character set with the CDB character set.

The cause is a known database bug. See 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 12.1.0.1.0 (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.

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:

• Bug 11692435

• Oracle Database PL/SQL Packages and Types Reference for information on the ANYDATASET and ANYDATA Oracle-supplied types and their methods that comprise the ANYDATASET PL/SQL API

• Oracle Call Interface Developer’s Guide for information on the OCIAnyDataSet and OCIAnyData interfaces that comprise the ANYDATASET C API

LOB Segment Attributes

Due to bugs 5577093, 5983283, and 6677390, LOB segments in tables converted by the method “Copy data using CREATE TABLE AS SELECT” may lose the storage attribute RETENTION and get the attribute PCTVERSION.

Run the following SQL statement to restore the expected attribute:

ALTER TABLE table_name MODIFY LOB (lob_name) (RETENTION)

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 11.2.0.3 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 11.2.0.3 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

In some cases, the ? character is incorrectly reported as invalid.

In the following situations, the ? character is incorrectly reported as invalid in the scan results:

• In Oracle Database 10.2, when the source character set is multibyte and target character set is UTF8

• In Oracle Database 11g releases up to 11.2.0.3, when the source character set is multibyte, the target character set is UTF8, and the ? character is followed by any non-ASCII character

If you can confirm that there is no other invalid data in the column, then 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 if the target migration character set is UTF8, then 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.

The reason is that 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, then 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.

These scripts 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 because types can be nested or embedded in PL/SQL.

Zone Maps Defined on Tables with Converted Character Data

Oracle recommends that you rebuild the zone maps defined on the converted tables after the migration.

The reason is that the binary representation of the character data stored in those tables may have changed.

Scheduled Cleansing to CLOB for Columns With Indexes and Constraints

When a scheduled cleansing action is defined to migrate a column to CLOB data type, any existing indexes and constraints defined on the column may be dropped immediately instead of during the conversion phase (reference: Bug 34211677).

Avoid defining scheduled cleansing actions to CLOB data type for columns with indexes and constraints, or recreate the indexes and constraints on the column after defining the scheduled cleansing action.

Important Security Considerations

Before you start the migration, be aware of the DMU security considerations listed in this section.

• Protect DMU software integrity

  In this release, the DMU requires that you connect to a database with the SYSDBA privilege. This highest privilege is needed to analyze and convert all data in the database. But this also means that once a connection is established, the program—if maliciously modified—could read and change all database content, create database users and grant privileges to them, and so on.

  To ensure that this power is not abused, the DMU software files must be modifiable only by users who are also authorized to connect as SYSDBA. This implies that all files in the DMU installation directory must be owned and writable only by an operating system user to which only the trusted administrators can connect. If writable by a malicious user, the DMU program code in JAR files, the repository maintenance SQL scripts, or configuration files could be abused to inject malicious SQL statements.

  Unless you install the DMU on a host to which only authorized users have access, you must protect the DMU installation and configuration files using the operating system privileges. After you have uncompressed the archive file with the DMU installation, ensure that all uncompressed files and directories are writable only by you and other authorized operating system users. The DMU does not have an installer that can automatically set file permissions.

• Protect connection details

  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.

  The cwallet.sso file is in the $HOME/.dmu/ directory on Linux and UNIX systems, and in the %APPDATA%\DMU directory on Microsoft Windows systems.

• Protect DMU repository objects

  To avoid unauthorized access to potentially sensitive metadata and functionality, do not grant any privileges for the DMU repository database objects to any database users. This guideline applies to any object with a name starting with DUM$ or DBMS_DUMA.

• Avoid information leakage

  To avoid unauthorized access to potentially sensitive information, ensure that the DMU configuration, log, and report files are readable and modifiable only by authorized operating system users. By default, these files are in the $HOME/.dmu/ directory on Linux and UNIX systems, and in the %APPDATA%\DMU directory on Microsoft Windows systems. However, DMU users can often select a file path for generated logs and reports.

• Protect operating system files

  The DMU lets its users specify file paths to access specific files. In a remote terminal setup where a DMU user does not have full shell access to the shared host, this functionality could be abused to read or overwrite sensitive files. The host’s operating system administrator should protect all sensitive operating system files from inadvertent or malicious overwriting. This precaution is not specific to the DMU.

• Do not use in kiosk mode or over a network

  Do not allow unprivileged users to run the DMU GUI or DMU-CLS client in kiosk mode or through a web interface, such as the Common Gateway Interface (CGI). DMU is not designed for use in these environments.

  DMU permits users to specify various input- and output-file paths and relies on the operating system permissions of the account running it to protect the host system. If you make a DMU client available in kiosk mode, through a web interface, or by any other form of remote access, you are responsible for implementing controls that:

  • Prevent unauthorized access to the operating system and database

  • Ensure that users can read and modify only the reports generated by DMU

  • Prevent users from reading or modifying any other files on the client host

Documentation Accessibility

For information about Oracle’s commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customer access to and use of Oracle support services will be pursuant to the terms and conditions specified in their Oracle order for the applicable services.

Title and Copyright Information

Oracle Database Migration Assistant for Unicode Release Notes, Release 23.1

F77395-07

Copyright ©2011,2026,

Oracle and/or its affiliates.