The Database Migration Assistant for Unicode (DMU) Tool (文档 ID 1272374.1)

APPLIES TO:

Oracle Database - Enterprise Edition - Version 10.2.0.4 to 12.1.0.1 [Release 10.2 to 12.1]
Oracle Database - Standard Edition - Version 10.2.0.4 to 12.1.0.1 [Release 10.2 to 12.1]
Database Migration Assistant for Unicode - Version 1.2 and later
Oracle Database - Enterprise Edition - Version 12.1.0.2 to 12.1.0.2 [Release 12.1]
Information in this document applies to any platform.

PURPOSE

Provides Overview, Introduction , Features and Installation steps for DMU (Database Migration Assistant for Unicode)

SCOPE

To customers and engineers who are interested to know about characterset migration to Unicode.

DETAILS

1) What is the DMU (Database Migration Assistant for Unicode) tool?

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 is the Database Migration Assistant for Unicode . It converts the NLS_CHARACTERSET of an existing database to AL32UTF8 or UTF8.
It is NOT a tool to do an Oracle RDBMS version migration. 
To upgrade the Oracle RDBMS version you need to use the DBUA (Database Upgrade Assistant), note that the DBUA cannot change the NLS_CHARACTERSET during the version upgrade.
DMU can convert/migrate/change the NLS_CHARACTERSET to AL32UTF8/UTF8 for a database but NOT migrate this database to another version (for that there is the DBUA) or migrate the dataset to another AL32UTF8/UTF8 database (for that there is export/import).

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.

2) Where to find the tool and the documentation?

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:

• do a complete "testdrive" of the WHOLE change on a copy of the database you want to migrate and to take a backup before doing the conversion.
• read Note 788156.1 AL32UTF8 / UTF8 (Unicode) Database Character Set Implications first and to make sure your application and clients are checked and ready for the change on database level.
• Use Oracle Sqldeveloper , not sqlplus, toad, etc, to "test" or "check" data after conversion see note 1628060.1 How to diagnose losing characters , getting "funny" output when inserting or selecting other than A-Z,a-z data ( = non English data like Chinese, Russian, Hebrew , insert any language here to the list that is not English) CHAR, VARCHAR2, LONG or CLOB

3) Oracle RDBMS version requirements (this is server / database side) for the DMU tool:

3a) Oracle database 12cR1 (12.1.0.1) and higher

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.

SQL>conn / as sysdba
SQL>@?/rdbms/admin/prvtdumi.plb

3b) Oracle database 11.2.0.3 and 11.2.0.4

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.

SQL>conn / as sysdba
SQL>@?/rdbms/admin/prvtdumi.plb

3c) Oracle database 11.2.0.2 and lower ( including 11gR1 and 10g)

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 :

• the 11.2.0.2.7 version of the database patch 9825461 can be applied on 11.2.0.2.7 and later PSU's 
• the 11.2.0.2.0 version of the database patch 9825461 can be applied on 11.2.0.2.0 and the 11.2.0.2.1, 11.2.0.2.2 and 11.2.0.2.3 PSU ( Patch 12419331) -> note that using dmu with 11.2.0.2.4 , 11.2.0.2.5,  11.2.0.2.6 - and up - is not possible seen patch 9825461 will conflict with those PSU's
• for 11.2.0.1 the database need to be on the exact listed PSU level , which is 11.2.0.1.3 (Patch 9952216) to apply the database patch 9825461 for 11.2.0.1.3
• for 11.1.0.7 the database need to be on the exact listed PSU level , which is 11.1.0.7.5 (Patch 9952228) to apply the database patch 9825461 for 11.1.0.7.5
• the 10.2.0.5.0 version of the database patch 9825461 can be applied on 10.2.0.5.0 and the 10.2.0.5.1, 10.2.0.5.2, and 10.2.0.5.3 PSU ( Patch 11724962 ) -> note that using dmu with 10.2.0.5.4 ( Patch 12419392 ) - and up - is not possible seen patch 9825461 will conflict with those PSU's
• for 10.2.0.4 the database need to be on the exact listed PSU level , which is 10.2.0.4.4  ( Patch 9352164) to apply the database patch 9825461 for 10.2.0.4.4

For windows platforms :
the needed serverside fixes ( patch 9825461 ) are included in these windows patch bundles sets

• 11.2.0.2 Patch 6 or higher
• 11.2.0.1 Patch 12 or higher
• 11.1.0.7 Patch 39 or higher
• 10.2.0.5 Patch 10 or higher
• 10.2.0.4 Patch 46 or higher

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.

SQL>conn / as sysdba
SQL>@?/rdbms/admin/prvtdumi.plb

4) DMU client ( User Interface) requirements:

4a) the server has Oracle 12c installed or an 12c client can be used

* 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):

• download the DMU 2.1.1 zip file from its OTN download page or from My Oracle Support (MOS) as Patch 23538563 . note that this patch is a simple zip file it's not an opatch patch.
• unzip the zip file in a temp directory , there will be a "dmu" directory.
• delete the 12.1.0.2 ORACLE_HOME/dmu directory
• copy the dmu directoy from the unzipped file to the 12.1.0.2 ORACLE_HOME (so there is again a ORACLE_HOME/dmu directory)
• start the DMU tool ( $ORACLE_HOME/dmu/dmu.sh or on Windows platforms use the "Database Migration Assistant for Unicode" start menu shortcut )
• when the DMU tool asks the java location  
  * on windows use the dialog box to browse to the 12.1.0.2 %ORACLE_HOME%/jdk/bin directory and select the "java" executable.
  * on Unix provide on the "specify the full pathname of a J2SE installation" prompt the 12.1.0.2 $ORACLE_HOME/jdk path 
     ** it's best to use the full path , not the $ORACLE_HOME variable 
     ** note that it's $ORACLE_HOME/jdk and not $ORACLE_HOME/jdk/bin or $ORACLE_HOME/jdk/bin/java

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

• do need the dmu serverside  patch 9825461 applied if the database version is lower than 11.2.0.3 (see point 3c).
• prvtdumi.plb need to be runned (from the database home not client) (see point 3c and 3b).

* 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):

• dowload the DMU 2.0 zip file from its OTN download page or from My Oracle Support (MOS) as Patch 23538563 (note that Patch 18392374 is a simple zip file, it is not an "opatch patch")
• unzip the zip file in a temp directory , there will be a "dmu" directory.
• delete the 12.1.0.1 ORACLE_HOME/dmu directory
• copy the dmu directoy from the unzipped file to the 12.1.0.1 ORACLE_HOME (so there is again a ORACLE_HOME/dmu directory)
• start the DMU tool ( $ORACLE_HOME/dmu/dmu.sh or on Windows platforms use the "Database Migration Assistant for Unicode" start menu shortcut )
• when the DMU tool asks the java location  
  * on windows use the dialog box to browse to the 12.1.0.1 %ORACLE_HOME%/jdk/bin directory and select the "java" executable.
  * on Unix provide on the "specify the full pathname of a J2SE installation" prompt the 12.1.0.1 $ORACLE_HOME/jdk path 
     ** it's best to use the full path , not the $ORACLE_HOME variable 
     ** note that it's $ORACLE_HOME/jdk and not $ORACLE_HOME/jdk/bin or $ORACLE_HOME/jdk/bin/java

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

• do need the dmu serverside  patch 9825461 applied if the database version is lower than 11.2.0.3 (see point 3c).
• prvtdumi.plb need to be runned (from the database home not client) (see point 3c and 3b).

4b) all clients/servers are Oracle 11gR2 (11.2.0.x) and lower

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 :

• the DMU client needs the Oracle Java SE Development Kit 7 or Oracle Java SE Development Kit 6 installed, DMU is not supported using OpenJDK 6 or 7
• the DMU client needs an 32bit Java install on an 64bit windows system when starting DMU using the dmuW32.exe executable (!) 
• there is no relation between using the "32 bit" or "64bit" DMU client executable on windows and the server, in other words, you can perfectly start dmuW32.exe and connect to an 64 bit database (or inverse). 
  Using dmuW64.exe has an advantage if the database contains lots of objects seen with dmuW64.exe the DMU client can adress more memory on the client side.
• when the DMU tool asks the java location  
  * on windows use the dialog box to browse to the <JDK6 or JDK7 directory>bin directory and select the "java" executable.
  * on Unix provide on the "specify the full pathname of a J2SE installation" prompt the <JDK6 or JDK7 directory> path 
     note that it's <JDK6 or JDK7 directory> and not <JDK6 or JDK7 directory>/bin or <JDK6 or JDK7 directory>/bin/java
• On Unix: when dmu.sh does not asks the java location but dmu fails with an error to start then an older JDK5 or lower is being picked up , please see the DMU FAQ
• This warning can be ignored when using JDK 7 , the DMU *IS* supported with JDK 7
  

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.

5) Is DMU supported / how to get help?

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.

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  and the DMU FAQ
Please DO use Oracle Sqldeveloper , not sqlplus, toad, etc, to "test" or "check" data after conversion see note 1628060.1 How to diagnose losing characters , getting "funny" output when inserting or selecting other than A-Z,a-z data ( = non English data like Chinese, Russian, Hebrew , insert any language here to the list that is not English) CHAR, VARCHAR2, LONG or CLOB

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:

• the usage of the DMU tool itself who are not answered in the DMU 2.1 documentation or the DMU FAQ then please use the DMU discussion forum or log a SR using the product "Database Migration Assistant for Unicode" .
• the DMU tool itself (the DMU tool hangs or errors out) please check first note 2018250.1 Tips For and Known Issues With The Database Migration Assistant for Unicode (DMU) Tool version 2.1 and if needed provide the DMU Diagnostic Package and log a SR using the product "Database Migration Assistant for Unicode" . If there are problems to create the diag package please see point 10) in this note.
• what action to take on Oracle RDBMS objects (SYS, SYSTEM etc) who are not documented in note 2018250.1 Tips For and Known Issues With The Database Migration Assistant for Unicode (DMU) Tool version 2.1 then please log a SR using the product "Database Migration Assistant for Unicode" and provide an html export of the scan result using the "with some issues" filter (See point 6) in this note).
• what action to take on Oracle Applications data or Oracle Applications objects then please see Note 124721.1 and log an Oracle Applications SR and provide an html export of the scan result using the "with some issues" filter (See point 6) in this note).
• what action to take on the User data or objects for a non-Oracle Application then please contact the application vendor.

6) How to take an html export of the scan result using the "with some issues" filter:

Open the scan report

choose the "with some issues" filter and click "expand all"

export the scan report

7) How long will a conversion using DMU take?

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.

8) What about Physical / Logical Standby databases?

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.

9) What is the "Install in Validation mode" option when installing the DMU repository when connecting to an UTF8 or AL32UTF8 NLS_CHARACTERSET database with the DMU tool?

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.

10) It's not possible to create the DMU diag package:

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

conn / as sysdba
CREATE OR REPLACE DIRECTORY DMU_TEMP_DIR AS '<writable directory by oracle OS user used to start the database on the server>';
exit

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:

conn / as sysdba
CREATE OR REPLACE DIRECTORY DMU_TEMP_DIR AS '<writable directory by oracle OS user used to start the database on the server>';
exit
expdp PARFILE=dmuexpdp.ctl
-- connect with / as sysdba

contents of dmuexpdp.ctl PARFILE:
INCLUDE=TABLE:"LIKE 'DUM$%'"
DIRECTORY=dmu_temp_dir
DUMPFILE=expdmu.dmp
LOGFILE=expdmu.log
SCHEMAS=system

11) Im currently using DMU 2.0,  can I update to DMU 2.1 without starting over?

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

12) Can I use Flashback DB while testing/migrating with DMU to go back?

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)

13) How to convert non-Unicode PDB's to Unicode PDB's?

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 ) 

14) How to obtain DMU logs

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)

15) Is there a command line interface for DMU.

No. there is no command line interface for DMU or silent mode for DMU. For details and/or workarounds please refer Note 2224769.1.