-
1.如果我的数据库版本未在支持的配置中列出，我能否使用 DMU？
-
为了使用 DMU，必须安装一个数据库补丁以添加 DMU 所需的服务器端迁移功能。该补丁目前仅适用于受支持的配置。如果您的数据库版本不在列表中，请考虑升级到受支持的版本之一。
-
2.运行 DMU 客户端需要哪个 JDK 版本？
-
JDK 6 或 7。
-
3.我能否远程运行 DMU 客户端迁移数据库？
-
虽然可以从另一台计算机远程运行 DMU，但强烈建议您在待迁移数据库服务器所在主机本地运行它，这样可以提升性能、降低网络开销。另外还建议您在迁移期间用专用服务器模式运行数据库。
-
4.数据库服务器使用 DMU 迁移数据库有何硬件要求？
-
迁移到 Unicode 是资源密集型操作，尤其是对于迁移大型数据库。建议在配置充足的硬件上执行迁移，以尽可能提高迁移吞吐量。确切的硬件要求因数据库大小和目标停机时间窗口而异，但迁移 100GB 及以上的数据库时，最好至少要有 8 个 CPU 内核和 16GB 内存。
-
5.运行 DMU 客户端有何硬件要求？
-
Oracle 建议您在待迁移数据库服务器所在的主机上运行 DMU 客户端，以尽量减少网络开销。如果您必须在其他主机上运行 DMU 客户端，则最低硬件要求包括：CPU 速度 — 2GHz，内存 — 4GB RAM。避免在同一环境中运行显著消耗系统资源的其他作业。
-
6.我在启动 DMU 时设错了 JDK 位置。如何才能更改 JDK 位置？
-
对于基于 Unix 的平台，DMU 将
java
可执行文件路径保存在
~/.dmu_jdk
中。如果删除了此文件，该工具会再次要求输入完整路径。如果在
PATH
中找到
java
可执行文件或定义了
JAVA_HOME
，则不会提示用户输入。在 Microsoft Windows 上，可以在 DMU 安装文件夹下的文件
dmu\dmu\bin\dmu32.conf
（32 位 JDK 的 DMU）或文件
dmu\dmu\bin\dmu64.conf
（64 位 JDK 的 DMU）中编辑 JDK 位置。查找关键字
SetJavaHome
。
-
7.关于清理无效数据，有什么建议的策略？
-
产生无效数据往往是因为存储数据的编码格式与使用直通式配置（绕过客户端/服务器字符集转换）的数据库字符集不同。为了正确迁移此类数据，必须识别用于这些数据的实际编码。DMU 字符集标记特性让您能够通过以不同字符集重新呈现的方式分析包含无效数据的列。确认实际字符集并标记到列之后，这将用于所有后续数据扫描和转换操作。如果您认为数据库中的所有数据用另一种字符集存储，您可以在数据库属性选项卡的“Assumed Database Character Set”域中设置（如将 WE8MSWIN1252 数据存储在 WE8ISO8859P1 数据库中）。
无效数据还有可能是因为应用错误或将二进制数据存储到字符列中而导致的。有关更多清理方案，请参见用户指南的第 6 章。
-
8.关于清除数据膨胀问题，有什么建议的策略？
-
从非 ASCII 数据迁移为 Unicode 数据时，产生的数据所需存储空间会增加，因为 Unicode 是多字节编码。数据膨胀问题可能表现为超过列限制问题或超过数据类型限制问题。
对于“超过列限制”问题，您有以下选择：
-
延长列
-
将列的长度语义从字节更改为字符。
-
手动缩短存储的值
-
允许 DMU 在转换期间截断值
-
编辑值以替换转换中膨胀的字符
-
迁移到更大的数据类型
对于“超过数据类型限制”问题，可以选择以下办法：
-
迁移到更大的数据类型
-
手动缩短存储的值
-
允许 DMU 在转换期间截断值
-
编辑值以替换转换中膨胀的字符
涉及更改列定义的清理操作可能不适合在生产环境中执行，因为它们通常需要相应更新应用代码逻辑。DMU 针对此类情况提供了计划的清理操作，这样就可以将更改保存在 DMU 信息库中，稍后在转换阶段作为停机时间窗口的一部分执行。要定义计划的清理操作，请从目标列上的清理编辑器上下文菜单中选择“Schedule Column Modification…”。
-
9.数据字典的 DMU 转换标准是什么？
-
一般而言，如果数据字典表中有可转换数据，DMU 不支持在此版本中转换数据字典，以下情况除外：
-
CLOB 列 — 仅在单字节数据库中才是必需的
-
二进制 XML 令牌管理器表，名称类似 XDB.X$QN% 和 XDB.X$NM%
-
PL/SQL 源代码：
CREATE PROCEDURE
、
CREATE FUNCTION
、
CREATE PACKAGE
、
CREATE PACKAGE BODY
、
CREATE TYPE BODY
、
CREATE TRIGGER
和
CREATE LIBRARY
文本；类型规范 (
CREATE TYPE
) 不转换
-
视图定义：
CREATE VIEW
文本
-
列：
-
SYS.SCHEDULER$_JOB.NLS_ENV
— Database Scheduler 作业 (
DBMS_SCHEDULER
) 的 NLS 环境
-
SYS.SCHEDULER$_PROGRAM.NLS_ENV
— Database Scheduler 作业程序 (
DBMS_SCHEDULER
) 的 NLS 环境
-
SYS.JOB$.NLS_ENV
— 原有作业 (
DBMS_JOB
) 的 NLS 环境
-
CTXSYS.DR$INDEX_VALUE.IXV_VALUE
— Oracle Text 策略的属性值
-
SYS
、
SYSTEM
和
CTXSYS
模式中 50 多个不同的列，包含各种数据库对象的用户注释
PL/SQL 源代码和视图源文本保存在多个表中。处理源代码和视图定义时，DMU 检查以下列：
-
SYS.VIEW$.TEXT
— 视图定义文本
-
SYS.SOURCE$.SOURCE
— PL/SQL 和 Java 源代码
-
SYS.ARGUMENT$.PROCEDURE$
— PL/SQL 参数定义：过程名称
-
SYS.ARGUMENT$.ARGUMENT
— PL/SQL 参数定义：参数名称
-
SYS.ARGUMENT.DEFAULT$
— PL/SQL 参数定义：默认值
-
SYS.PROCEDUREINFO$.PROCEDURENAME
— 软件包中声明的过程和函数名称
-
SYS.IDL_CHAR$.PIECE
— PL/SQL 的内部表示
-
SYS.PLSCOPE_IDENTIFIER$.SYMREP
— PL/SQL 的内部表示；此表是新的 Oracle Database 11g 表
DMU 不会将上列表和列中的可转换字符数据报告为转换问题。数据字典其余表和列中的任何可转换数据会在扫描报告和 Migration Status 选项卡上标记为转换问题。在删除标记数据之前，不能启动数据库转换步骤。不允许对数据字典表执行清理操作。
-
10.如何处理 AWR 表（WRI$_%、WRH$_%、WRR$_%）中的可转换数据？
-
SYS 模式包含多个名称以
WRI$
、
WRH$%
和
WRR$_
开头的表，它们组成自动负载信息库 (AWR)。除历史对象统计信息之外，该信息库还存储重要系统统计信息的快照，如各种固定视图（如
V$SYSSTAT
和
V$SQLAREA
）中可见的快照。
如果在对象名称或 SQL 语句（如在字符文字或注释中）中使用了非 ASCII 字符，这些字符可能会被捕获到 AWR 表中。DMU 扫描将此类字符报告为可转换数据字典内容，这可能妨碍数据库转换。为了彻底去除此数据，请使用
SYSDBA
权限登录到 SQL*Plus 并运行以下命令重新创建自动负载信息库：
SQL> @?/rdbms/admin/catnoawr.sql
SQL> @?/rdbms/admin/catawr.sql
SQL> execute dbms_swrf_internal.register_local_dbid;
由于在 Oracle Database 10.2.0.4 版及早期版本中没有
catawr.sql
脚本，Oracle 建议您先安装 Oracle Database 补丁集 10.2.0.5，再清除 AWR 内容。
-
11.为什么我在修改 Oracle E-Business Suite 模式下的列时收到警告？
-
不支持修改 Oracle E-Business Suite 模式的结构，因为这可能导致 Oracle 应用工作异常。只有在受影响的表是您创建的自定义表或者 Oracle Support 建议您这样做的时候，才应修改这些列。
-
12.我刚在清理编辑器中删除了 CLOB 数据单元格中导致无效二进制表示的字符。为什么这些字符仍然突出显示为异常？
-
这是意料之中的，因为重新扫描客户端的较大数据类型可能代价高昂。清理编辑器筛选和突出显示 CLOB、LONG 和 XMLType 列基于对表的最新扫描结果，而在您重新扫描表/列之前，这些结果不会变化。
-
13.DMU 如何报告同时展示无效二进制表示和大小膨胀问题的数据单元格？
-
DMU 仅将每个数据单元格归入一个扫描结果类别。有无效二进制表示问题的值即使其长度在转换后也超过列或数据类型限制，也只能归为此类。一般而言，用户在尝试转换之前应先解决无效数据问题并重新扫描数据。由于 DMU 还可以让您忽略无效数据问题并强制转换列，您应该知道，含有无效二进制表示的强制转换值可能会被额外截断。您可以比较列的 Maximum Post-conversion Length 属性值与列和数据类型长度限制，看看是否会发生截断。
-
14.为何我在清理编辑器中应用筛选器时有时会收到性能警告？
-
通过使用迁移信息库中收集的 rowid，或从数据库读取行时在客户端动态分析列值，DMU 可以识别具有指定类型的转换问题的行。对于后一种方法，当表中只有少量行符合筛选条件时，DMU 可能必须得读取和分析许多行，才能找到足够的行来填充清理编辑器。从性能的角度来看，建议先扫描表以预先收集 rowid 信息，启用清理工具栏上的“User Scan Log to Filter Data”按钮，然后再应用筛选器。
-
15.迁移状态选项卡显示“The current setting rules out CTAS conversion method for tables with Row Movement disabled”（当前设置禁止对禁用 Row Movement 的表执行 CTAS 转换方法）。这是什么意思？
-
对于可转换数据所占比例较大的表，DMU 可以分配“使用 CREATE TABLE AS SELECT 复制数据”的转换方法，可显著提高性能。默认情况下不启用 CTAS 转换方法，因为它不能保存表中行的 rowid。如果应用不存储 rowid，您可以在数据库属性选项卡中将“Consider CTAS with Row Movement Disabled:”参数设置为“Yes”，这样 DMU 就会分配 CTAS 转换方法以实现最佳转换性能。
-
16.如何监视转换阶段的表级转换进度？
-
您可以通过 Conversion Progress 选项卡中的“View Table Conversion Progress”链接监视的表级转换进度。它将根据
V$SESSION_LONGOPS
视图的状态以及各 SQL 语句的执行状态显示每个表的完成百分比。
-
17.我在转换阶段将数据库字符集修改成 Unicode 时收到 ORA-12721。如何才能诊断有问题的会话？
-
DMU 在转换阶段使用的 SQL 语句 ALTER DATABASE CHARACTER SET 仅当执行该语句的会话是登录数据库的唯一用户会话时才会成功。因此，在开始转换之前，DMU 会警告您关于任何登录到该数据库但并非由 DMU 本身打开的用户会话。您可以在 SQL*Plus 或 SQL Developer 中使用以下 SQL 语句找到有问题的会话的详细信息：
SELECT sid, serial#, username, status,
osuser, machine, process, program
FROM v$session
WHERE username IS NOT NULL
AND program <> 'Database Migration Assistant for Unicode';
此时，您仍然可以断开冲突的会话，恢复转换。
-
18.DMU 扫描在某些表上失败，返回消息“ORA-29913: error in executing ODCIEXTTABLEOPEN callout”。如何解决这个问题？
-
该错误表明 DMU 无法读取外部表。如果外部表的数据文件不在预期的位置或者文件格式错误，就可能发生这种情况。外部表通常仅用于在特定时间点从外部源加载数据，数据文件不可用的情况很常见。您可以确保数据文件存在并重新尝试扫描，也可以忽略这些错误，因为它们不会阻止任何后续迁移操作。
-
19.DMU 为何在验证模式中报告 Unicode 替换字符无效？
-
Database Properties 选项卡的 Scanning 子选项卡上“Report U+FFFD as an invalid character”属性的值确定 DMU 如何解释 Unicode 默认替换字符 U+FFFD（AL32UTF8 和 UTF8 中的字节序列 0xEF 0xBF 0xBD）。如果属性值为“Yes”，该字符将被视为无效数据。这是默认行为，因为数据中存在该字符通常表明该数据是某个未正确标记其真实字符集的输入的字符集转换的结果。如果您使用字符 U+FFFD 进行某些内部处理，并且不希望 DMU 将其报告为无效，请将该属性值更改为“No”。
-
20.我已经修复了一些数据问题。DMU 状态图标怎么还是显示受影响的对象未准备好转换？
-
DMU 根据最新扫描的结果确定数据的就绪状态。请确保在应用清理操作后重新扫描受影响的数据库对象，查看更改的效果，并验证已经成功解决数据问题。
如果您在 DMU 之外清理了一个表，例如在 SQL Developer 或 SQL*Plus 中延长了某个列，这些更改未反映到 DMU 中，则单击 Migration 菜单中的“Refresh DMU Repository...”刷新 DMU 信息库。
-
21.DMU 有回滚特性吗？
-
DMU 本身不提供任何转换回滚特性，但它附带了内置转换错误处理，如果转换过程因某个错误条件而中断，它可能会解决问题并恢复转换。如果您真需要将数据库回滚到转换之前的状态，可以从备份还原或使用闪回数据库特性。
注：
闪回数据库特性未经过针对
ALTER DATABASE CHARACTER SET
(ADBCS) 语句的测试。虽然该特性的设计应该不会与 ADBCS 冲突，但如果 ADBCS 已经在转换过程中执行，也就是说，查询
SELECT value FROM nls_database_parameters WHERE parameter='NLS_CHARACTERSET'
显示目标字符集，建议您还是选择从备份还原。如果您没有备份可用，不得不在 ADBCS 之后尝试闪回数据库，请确保在执行闪回命令之后立即重新启动实例。在开始转换过程之前，请参见
Oracle 数据库备份和恢复用户指南
中有关
FLASHBACK DATABASE
及其要求的更多信息。
-
22.我数据库上有些 DMU 操作似乎挂起或用时特别长。这是为什么？
-
如果您注意到 DMU 操作（尤其是通常很快的那种，如刷新信息库或在扫描之前计算分割阈值）用时特别长或者似乎挂起，则验证数据库初始化参数
optimizer_features_enable
并未设置为旧的数据库版本。例如，已知此参数的值为
9.2.0
会导致 DMU 中的某些内部查询使用欠佳的执行计划。
-
23.DMU 启动时总是选用旧版的 JDK。如何指定正确的 JDK 位置？
-
在类似 Unix 的操作系统上启动时，DMU 会依次在以下位置查找 JDK：
-
文件
dmu/dmu/bin/dmu.conf
中
SetJavaHome
指令指定的位置
-
$APP_JAVA_HOME
-
$OIDE_JAVA_HOME
-
dmu/jdk
-
dmu/../jdk
-
$JAVA_HOME
-
/usr/java/jdk1.6.*
（最高版本）
-
先前由用户指定并存储在文件
$HOME/.dmu_jdk
中的位置
-
用户请求的位置。
在 Microsoft Windows 操作系统上启动时，DMU 会依次在以下位置查找 JDK：
-
文件
dmu\dmu\bin\dmu32.conf
（如果是通过
dmu32.exe
或
dmuW32.exe
启动的）或文件
dmu\dmu\bin\dmu64.conf
（如果是通过
dmu64.exe
或
dmuW64.exe
启动的）中
SetJavaHome
指令指定的位置
-
dmu\..\jdk
-
用户请求的位置；相应地，该位置存储在
dmu32.conf
或
dmu64.conf
中的
SetJavaHome
下。
在以上每个位置中，DMU 会验证是否存在文件
bin/java
和
jre/bin/java
（在 Windows 上为
java.exe
）
如果以上任何位置包含错误的 JDK 版本，DMU 就有可能读取该版本而导致错误。要解决这个问题，请修改文件
dmu/dmu/bin/dmu[32|64].conf
，在
SetJavaHome
指令中添加正确的 JDK 安装路径。
-
24.使用 DMU 转换数据库时所需停机时间是否与数据库的大小成正比？
-
通常不能单凭数据库大小来推断迁移停机时间窗口。其他重要因素包括数据是否完成转换准备、需要转换的数据百分比（非 CLOB 列中的非字符数据类型和 7 位 ASCII 数据无需转换）以及 CLOB 列的大小（通常转换 CLOB 要比转换 CHAR/VARCHAR2 更耗资源）等。
为了更精确地估算转换时间，最好的办法是克隆待迁移数据库，然后通过端到端的流程在受控测试环境中运行该克隆数据库。这可以在数据转换之前很好地了解有哪些类型的数据转换问题以及预计的转换时间窗口。
-
25.DMU 报告 Oracle Database 12.1.0.2 PDB 中的 SYS.BOOTSTRAP$ 表中存在无效表示数据。如何处理此数据？
-
19533216 号错误中报告了这一问题。在 Oracle Database 12.1.0.2 中，PDB 在数据字典列 SYS.BOOTSTRAP$.SQL_TEXT 中可能包含一行或多行二进制数据。DMU 2.0 将此数据报告为有无效表示，这会妨碍 PDB 的字符集转换。从 Oracle 数据库的角度来看，存在该数据并不被视为错误。
要解决此问题，请将 DMU 升级到最新版本。DMU 2.1 或更高版本包含针对此问题的修复。
