Provides Overview, Introduction , Features and Installation steps for DMU (Database Migration Assistant for Unicode)
To customers and engineers who are interested to know about characterset migration to Unicode.
DMU is a GUI based tool that is more intuitive than csscan/csalter and automate a lot of the conversion process when changing the NLS_CHARACTERSET to UTF8 or AL32UTF8 of an Oracle RDBMS database.
DMU can also be used to validate data in existing AL32UTF8/UTF8 database and , if needed, correct data in an UTF8/AL32UTF8 db that is not stored in AL32UTF8/UTF8 encoding due to incorrect client config.
From DMU 1.2 onwards DMU can also be used (with limitations) to correct a database NLS_CHARACTERSET.
The current version of DMU is DMU 2.1 and was relased in May 2015.
Information and downloads can be found on http://www.oracle.com/technetwork/database/database-technologies/globalization/dmu/overview/index.html and in this note.
There is also a webcast that gives a quick overview of using DMU to go to AL32UTF8/UTF8, it is available for replay (length is about 35 minutes, you can skip to page 12 when it starts).
To acces this webcast, open note 1456176.1 Oracle Database Advisor Webcast Schedule and Archive recordings , click on the "Archived 2012" tab and select "Introduction to DMU (Database Migration Assistant for Unicode)" .
This webcast is an excellent way to have a basic overview on how to use DMU. The webcast uses a previous DMU 1.1 version so there will be some differences compared to the current DMU version.
A simple example of using DMU 1.2 (so there will be some differences compared to use the current DMU version.) with screenshots is found in note 1546507.1 How to Migrate a WE8ISO8859P1 DB to AL32UTF8 using DMU 1.2 - an example
Other resources are the DMU 2.1 docset and the DMU FAQ.
Please DO check before using the DMU tool note 2018250.1 Tips For and Known Issues With The Database Migration Assistant for Unicode (DMU) Tool version 2.1
It's strongly recommended to:
No need to install any patch on the server / database home.
To use DMU it is however needed to install the SYS.DBMS_DUMA_INTERNAL package , which need to be created by running (using sqlplus from the database home) ?/rdbms/admin/prvtdumi.plb when connected with a sysdba connection.
No need to install any patch on the server / database home.
To use DMU it is however needed to install the SYS.DBMS_DUMA_INTERNAL package , which need to be created by running (using sqlplus from the database home) ?/rdbms/admin/prvtdumi.plb when connected with a sysdba connection.
DMU requires a serverside patch 9825461for databases who are on a version lower than 11.2.0.3.
This means DMU can be used to change a database on a version / platform combination for which patch 9825461 is available.
Using Csscan and Csalter or Csscan and Export/import is the only way to go to AL32UTF8 for versions / platforms who are not supported by DMU.
Using Csscan and Csalter to go to AL32UTF8 is documented in Note 260192.1 Changing the NLS_CHARACTERSET to AL32UTF8 / UTF8 (Unicode) in 8i, 9i , 10g and 11g.
For Unix platforms :
For windows platforms :
the needed serverside fixes ( patch 9825461 ) are included in these windows patch bundles sets
For availability of these Windows patch bundles please see Note 161549.1 Oracle Database Server and Networking Patches for Microsoft Platforms.
For Opatch questions please see Note 242993.1 OPATCH FAQ
The DMU "serverside" patch requirement allow to install the SYS.DBMS_DUMA_INTERNAL package , which need to be created by running (using sqlplus from the database home) ?/rdbms/admin/prvtdumi.plb when connected with a sysdba connection.
* 12.1.0.2
The DMU 2.0 client (User Interface) is included in Oracle RDBMS 12.1.0.2
We strongly suggest to update the included DMU 2.0 version to the current 2.1.1 DMU version.
When using the 12.1.0.2 installation start for Unix platforms $ORACLE_HOME/dmu/dmu.sh and for Windows platforms use the "Database Migration Assistant for Unicode" start menu shortcut.
The DMU 2.0 client (User Interface) is installed for 12.1.0.2 client installations when choosing the "administrator" type of installation. the 12.1.0.2 client can be downloaded here , choose the "see all" link for 12.1.0.2.
To update an 12.1.0.2 (client) installation from the included DMU 2.0 to DMU 2.1.1: start DMU 2.0 , choose the "help" menu and choose "check for updates" , follow the wizard.
To update an 12.1.0.2 (client) installation from the included DMU 2.0 to DMU 2.1.1 manually (due firewall restrictions or policy's about downloading):
Note that it is perfectly possible to use the DMU client (User Interface) using an 12.1.0.2 (client) installation to convert a database that has a lower Oracle RDBMS version.
The database however
* 12.1.0.1
The DMU 1.2 client (User Interface) is included in Oracle RDBMS 12.1.0.1
We strongly suggest to update the included DMU 1.2 version to the current 2.1.1 DMU version.
When using the 12.1.0.1 (client) installation start for Unix platforms $ORACLE_HOME/dmu/dmu.sh and for Windows platforms use the "Database Migration Assistant for Unicode" start menu shortcut .
The DMU 1.2 client (User Interface) is installed for 12.1.0.1 client installations when choosing the "administrator" type of installation
When using 12.1.0.1 (client) installation there is no need to have an external Oracle Java SE Development Kit installed, the 12.1.0.1 home already contains this.
To update an 12.1.0.1 (client) installation from the included DMU 1.2 to DMU 2.1.1: start DMU 1.2 , choose the "help" menu and choose "check for updates" , follow the wizard.
To update an 12.1.0.1 (client) installation from the included DMU 1.2 to DMU 2.1.1 manually (due firewall restrictions or policy's about downloading):
Note that it is perfectly possible to use the DMU client (User Interface) using an 12.1.0.1 (client) installation to convert a database that has a lower Oracle RDBMS version.
The database however
The DMU 2.1 client (User Interface) is available from its OTN download page or from My Oracle Support (MOS) as Patch 18392374 as an zip file ( note that Patch 18392374 is a simple zip file, it is not an "opatch patch").
Both download packages are identical but the OTN download is made available under the OTN Developer License, which allows you to evaluate the tool, while the MOS download is a Program Update under the database support contract and permits you to migrate production databases covered by a valid support contract on any level that entitles to Program Updates.
There is only one DMU client download for all Unix and windows platforms and supported Oracle RDBMS database versions.
The DMU client does not need any Oracle RDBMS client installed, it connects trough thin JDBC and is self contained.
The DMU client (User Interface) is a Java based client and can, but does not need to, run on the server.
Download the DMU 2.1 client zip file , unzip it and then start \dmu\dmuW32.exe (32bit windows or 64bit windows with an 32bit Java 6/7 install), \dmu\dmuW64.exe ( 64bit windows with an 64bit Java 6/7 install) or /dmu/dmu.sh (Unix platforms).
The DMU client will normally ask the Java location, more information is in the DMU FAQ
Note that :
Tip: for 64 bit Windows clients the JDK in Oracle SQLdeveloper 4 can be used without any need to install or update the current Java version.
Download the "Windows 64-bit - zip file includes the JDK 7" zip file from here , unzip and point when starting the dmuW64.exe executable (!) to <directory that has sqldeveloper.exe>\jdk\bin\java.exe
If you are using Oracle EBS then there is a good chance you have on the Application tier already Java 6 installed, see note 455492.1 Using Latest Java 6.0 Update With Oracle E-Business Suite Release 12 and note 401561.1 Using J2SE Version 6 with Oracle E-Business Suite 11i
Note: There is NO requirement to update the java installed on EBS tier to java 6 in order to use DMU. The 2 notes are simply provided to help you locate a Java 6 installation to start and use with the DMU client.
Oracle DMU 2.1.1 is a free Oracle Database tool. It is distributed via OTN and via My Oracle Support (MOS) as Patch 23538563.
Both download packages are identical but the OTN download is made available under the OTN Developer License, which allows you to evaluate the tool, while the MOS download is a Program Update under the database support contract and permits you to migrate production databases covered by a valid support contract on any level that entitles to Program Updates.
DMU is fully supported for customers with database support contracts on any level that entitles to assistance with service requests.
DMU is also fully supported for migrating an Oracle Applications Installation to Unicode , see Note 124721.1 Migrating an Applications Installation to a New Character Set
If there are questions about:
Open the scan report
choose the "with some issues" filter and click "expand all"
export the scan report
The best way to know this is to take a clone of the production and do a trial migration in a controlled test environment using the same hardware and software as the server where the actual conversion will take place.
The actual migration time may depend on many factors such as the data volume, hardware spec, data types involved, amount of data exceptions, percentage of data that requires conversion, just to name a few.
The DMU tool has been used to successfully migrate large terabyte-scale databases but Oracle support simply cannot give a timeframe on how long it will take.
If your system has a Logical Standby database this Logical standby needs to be re-created from the "main" database after the characterset conversion, there is no supported way to alter the standby together with the main database.
Seen the Logical standby database needs to have the same NLS_CHARACTERSET as the source database it's also not possible to for example change a Logical standby database and then, after changing the NLS_CHARACTERSET of the logical apply database, restart the apply of the redo of the main database to this database.
For Physical Standbys lower than 11.1.0.7 the Physical Standby also needs to be re-created.
From 11.1.0.7 onwards this is not needed any more for Physical Standbys, please see Note 1124165.1 Changing Primary Database Character Set without Recreating Data Guard Physical Standbys.
The DMU tool can validate the contents of an existing AL32UTF8 or UTF8 database. Such a database might have been converted in the past to or initially created with an UTF8 or AL32UTF8 NLS_CHARACTERSET.
There is an webcast documenting this "validation" option in DMU (using DMU 1.2 so some differences may be seen compared with the current DMU version) , open note 1456176.1 Oracle Database Advisor Webcast Schedule and Archive recordings , click on the "Archived 2013" tab and select "Introduction to Character Set correction with the DMU tool" .
Please DO note that this "validation" mode is NOT a migration mode , it's use is to confirm/check the dataset of an CURRENT UTF8 or AL32UTF8 database, not to CONVERT any database NLS_CHARACTERSET.
This is mainly usefull to find data that gives "ORA-29275: partial multibyte character" or "ORA-600 [kole_t2u], [34]" errors
Ssee Note 788156.1 AL32UTF8 / UTF8 (Unicode) Database Character Set Implications / B.4) The meaning of SP2-0784, ORA-29275 and ORA-600 [kole_t2u], [34] errors / losing characters when using convert.
If the problem is happening before the connection can be made or the repository is installed then please provide the DMU client log files, they are found by default under %APPDATA%\DMU\log (normally "C:\Users\<windows user name>\AppData\Roaming\DMU\log" ) on Windows and ~/.dmu ( $HOME/.dmu/) for Unix/linux (simply exit DMU and zip the contents of that directory).
The DMU diag package needs a database directory to temporary make an expdp, if there is none listed in the wizard dropdown box this means there is no valid location on the server, you can created a directory using
If you can create the dmu-diag.jar ( see the steps in the DMU docset here) then the next steps do NOT need to be followed.
please , if dmu-diag.jar is created simply upload the dmu-diag.jar to the sr and do not start with zipping and combining dmu-diag.jar , dmp files and log files in zip files inside zip files
If the diagnostic package still fails to be created then please provide
* the DMU client log files , they are found by default under %APPDATA%\DMU\log (normally "C:\Users\<windows user name>\AppData\Roaming\DMU\log" ) on Windows and ~/.dmu ( $HOME/.dmu/ NOT $ORACLE_HOME/dmu) for Unix/linux (simply exit DMU and zip the contents of that directory).
* an export of the system schema , take export as below and zip the resulting dmp file:
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.
DMU 2.0 note: note 1637455.1 Known Issues With The Database Migration Assistant for Unicode (DMU) Tool version 2.0
Yes, that's possible, this may mainly be usefull during testing to test out different options/settings.
Note 1947587.1 Flashback DB and DMU to Convert Characterset to Unicode (AL32UTF8) and Revert Back (Tested only on 11.2.0.3 and 11.2.0.4)
This is documented in the DMU 2.1 Release Notes http://docs.oracle.com/cd/E64126_01/doc.21/e56348/toc.htm#BAJJIJAD
Note that the DMU tool cannot convert a non-Unicode CDB to AL32UTF8 as this is not needed. You will receive the following error upon connecting to CDB using the DMU : Encountered an error while checking database's compatibility: Migration of container databases (CDB) is not supported.
To go from a non-Unicode CDB with (also non-Unicode) PDB's the steps are:
* Create a new Unicode (AL32UTF8) CDB
* Use the DMU to scan the non-Unicode PDB's 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 Unicode AL32UTF8 CDB (this will put the PDB into restricted mode due to the character set incompatibility).
* Use the DMU tool to convert the non-Unicode PDB to Unicode once plugged in the target Unicode AL32UTF8 CDB (= finish the conversion).
note 1968706.1 12c Multitenant Container Databases (CDB) and Pluggable Databases (PDB) Character set restrictions ORA-65116/65119: incompatible database/national character set ( Character set mismatch: PDB character set CDB character set )
a) Launch the DMU utility > Click "Tools" at the top > Preferences > Log
The path to the DMU Log directory is listed in the "Log Directory" box.
Once this path is known, you can navigate to that path in the OS and view the logs.
b) Launch the DMU utility > click "Help" at the top > About > Export > Save to File
This will provide version and configuration information that may be helpful with troubleshooting DMU issues.
In some scenarios it may not be possible to collect the DMU "Diagnostic Package". In those cases the log files can be acquired from the DMU log directory instead.
SRDC - DMU: Checklist of Evidence to Supply (Doc ID 1900615.1)
No. there is no command line interface for DMU or silent mode for DMU. For details and/or workarounds please refer Note 2224769.1.
