Question: When starting, the DMU consistently picks up an older version of the JDK. How to specify the location of the correct JDK?
Answer:When starting on a Unix-like operating system, the DMU looks for a JDK in the following locations in turn: • the location specified in the SetJavaHome directive in the filedmu/dmu/bin/dmu.conf • $APP_JAVA_HOME • $OIDE_JAVA_HOME • dmu/jdk • dmu/../jdk • $JAVA_HOME • /usr/java/jdk1.6.* (with highest version) • the location specified previously by the user and stored in the file $HOME/.dmu_jdk • the location requested from the user. When starting on a Microsoft Windows operating system, the DMU looks for a JDK in the following locations in turn: • the location specified in the SetJavaHome directive in the filedmu\dmu\bin\dmu32.conf if started through dmu32.exe or dmuW32.exe or in the file dmu\dmu\bin\dmu64.conf if started through dmu64.exe or dmuW64.exe • dmu\..\jdk • the location requested from the user; the location is stored under SetJavaHome indmu32.conf or dmu64.conf correspondingly. In each of the locations, the DMU verifies the presence of the files bin/java andjre/bin/java (java.exe on Windows). If any of the locations above contains an incorrect version of the JDK, this version may be picked up by the DMU resulting in an error. To solve the issue, modify the filedmu/dmu/bin/dmu[32|64].conf and add the path of the correct JDK installation in theSetJavaHome directive.
Question: Is the downtime needed to convert a database with the DMU directly proportional to the size of the database?
Answer:It is generally not possible to extrapolate the migration downtime window based on the database size alone. Other important factors include the readiness of the data for conversion, the percentage of the data that needs to be converted (non-character data types and 7-bit ASCII data in non-CLOB columns need no conversion), and the size of CLOB columns (CLOBs are typically more expensive to convert than CHAR/VARCHAR2), etc. To get a more precise estimate of the conversion time, the best approach is to take a clone of the database to be migrated and run the clone through the end-to-end process in a controlled test environment. This will give a good idea of what types of data convertibility issues need to be dealt with prior to the data conversion and the conversion time window one can expect.
Question: The DMU reports invalid representation data in the table SYS.BOOTSTRAP$ in an Oracle Database 12.1.0.2 PDB. How to handle this data?
Answer:This problem is reported in bug #19533216. In Oracle Database 12.1.0.2, a PDB may contain one or more rows with binary data in the data dictionary column SYS.BOOTSTRAP$.SQL_TEXT. The DMU reports this data as having invalid representation, which prevents character set conversion of the PDB. The presence of this data is not considered a bug from the Oracle Database perspective. To solve the problem, download patch #19533216 from the My Oracle Support site and follow the instructions in the readme.txt file available with the patch. After the patch is installed and the DMU repository is (re-)installed, the DMU will ignore the problematic data in the table SYS.BOOTSTRAP$.
• About Startup Dependencies: Oracle Restart ensures that Oracle components are started in the proper order, in accordance with component dependencies. For example, if database files are stored in Oracle ASM disk groups, then before starting the database instance, Oracle Restart ensures that the Oracle ASM instance is started and the required disk groups are mounted. Likewise, if a component must be shut down, Oracle Restart ensures that dependent components are cleanly shut down first. Oracle Restart also manages the weak dependency between database instances and the Oracle Net listener (the listener): When a database instance is started, Oracle Restart attempts to start the listener. If the listener startup fails, then the database is still started. If the listener later fails, Oracle Restart does not shut down and restart any database instances.
• About Starting and Stopping Components with Oracle Restart : Oracle Restart automatically restarts various Oracle components when required, and automatically stops Oracle components in an orderly fashion when you manually shut down your system. There may be times, however, when you want to manually start or stop individual Oracle components. Oracle Restart includes the Server Control (SRVCTL) utility that you use to manually start and stop Oracle Restart–managed components. When Oracle Restart is in use, Oracle strongly recommends that you use SRVCTL to manually start and stop components. After you stop a component with SRVCTL, Oracle Restart does not automatically restart that component if a failure occurs. If you then start the component with SRVCTL, that component is again available for automatic restart.
• Oracle utilities such as SQL*Plus, the Listener Control utility (LSNRCTL), and ASMCMD are integrated with Oracle Restart. If you shut down the database with SQL*Plus, Oracle Restart does not interpret this as a database failure and does not attempt to restart the database. Similarly, if you shut down the Oracle ASM instance with SQL*Plus or ASMCMD, Oracle Restart does not attempt to restart it. An important difference between starting a component with SRVCTL and starting it with SQL*Plus (or another utility) is the following: o When you start a component with SRVCTL, any components on which this component depends are automatically started first, and in the proper order. o When you start a component with SQL*Plus (or another utility), other components in the dependency chain are not automatically started; you must ensure that any components on which this component depends are started.