Question: Why do I sometimes get performance warnings when applying filters in the cleansing editor?
Answer:DMU can identify rows with a given type of convertibility issues by either using the rowids collected in the migration repository or analyzing the column values dynamically on the client as they are fetched from the database. For the latter approach, when only a small percentage of rows in the table meet the filter criteria, DMU may have to fetch and analyze many rows before it finds enough rows to fill the cleansing editor. From the performance standpoint, it is recommended to scan the table to pre-collect the rowid information and enable the “User Scan Log to Filter Data� button on the cleansing toolbar before applying the filters.
Question: The migration status tab says "The current setting rules out CTAS conversion method for tables with Row Movement disabled". What does it mean?
Answer:For tables with relatively large percentage of convertible data, DMU can assign the "Copy data using CREATE TABLE AS SELECT" conversion method which provides significant performance advantage. The CTAS conversion method is not enabled by default since it may not preserve the rowids of rows in the table. If your applications do not store rowids, you can set the "Consider CTAS with Row Movement Disabled:" parameter to "Yes" in the database property tab so that DMU will assign the CTAS conversion method for optimal conversion performance.
Question: How do I monitor the table-level conversion progress in the conversion phase?
Answer:You can monitor the table-level conversion progress in the "View Table Conversion Progress" link on the Conversion Progress tab. It will display the completion percentage for each table based on the status from the V$SESSION_LONGOPS view along with the execution status of individual SQL statements.
Question: I got ORA-12721 during altering database character set to Unicode in the conversion phase. How can I diagnose the offending session?
Answer:The SQL statement ALTER DATABASE CHARACTER SET, which the DMU uses in the conversion phase, succeeds only if the session executing the statement is the only user session logged into the database. Therefore, before starting the conversion, the DMU warns you about any user sessions logged into the database that are not opened by the DMU itself. You may use the following SQL statement in SQL*Plus or SQL Developer to find out the details of the offending sessions: SELECT sid, serial#, username, status, osuser, machine, process, program FROM v$session WHERE username IS NOT NULL AND program <> 'Database Migration Assistant for Unicode';
At this point, you can still disconnect the offending sessions and resume the conversion.