必须同步处理角色、对象级授权、系统权限、PUBLIC对象和密码策略五类要素，否则目标端用户无法登录或执行失败；需用dba_role_privs、dba_sys_privs、dba_tab_privs三查补全权限，注意ADMIN_OPTION、DEFAULT_ROLE及GRANTABLE字段；PUBLIC同义词和非属主DBLINK需单独导出；密码哈希与账户状态（如LOCKED、EXPIRED）须显式重建；还需检查角色依赖的系统包权限及细粒度审计策略。
直接结论：不能只导出权限语句就完事，必须结合角色、对象级授权、系统权限、PUBLIC对象和密码策略四类要素同步处理，否则目标端用户会无法登录或执行失败。
查全权限：dba_role_privs + dba_sys_privs + dba_tab_privs 缺一不可
只查 dba_role_privs 会漏掉直接授予用户的系统权限（如 CREATE SESSION）和对象权限（如对某张表的 SELECT）。生产环境中常见“用户能连上但查不了表”，就是只迁移了角色没迁系统权限。
- 用以下三组查询覆盖全部权限来源：
SELECT GRANTEE, GRANTED_ROLE, ADMIN_OPTION, DEFAULT_ROLE FROM dba_role_privs WHERE grantee = 'DATALOOK1';<br>SELECT GRANTEE, PRIVILEGE, ADMIN_OPTION FROM dba_sys_privs WHERE grantee = 'DATALOOK1';<br>SELECT GRANTEE, OWNER, TABLE_NAME, PRIVILEGE, GRANTABLE FROM dba_tab_privs WHERE grantee = 'DATALOOK1';
- 注意
ADMIN_OPTION和DEFAULT_ROLE字段：前者决定是否能再转授，后者影响用户登录后默认启用的角色，漏掉会导致权限不生效。 - 如果用户有
WITH GRANT OPTION授出的权限，GRANTABLE列为YES，迁移时需显式加上WITH GRANT OPTION，否则下游权限链断裂。
别忽略 PUBLIC 同义词和 DBLINK：它们不是用户私有对象
dba_synonyms 中 OWNER = 'PUBLIC' 的同义词，以及 dba_db_links 中非当前用户创建的数据库链接，不会随用户导出自动迁移。目标端若缺失，应用执行 SELECT * FROM emp（依赖 PUBLIC.emp 同义词）会报 ORA-00942: table or view does not exist。
- 导出命令要单独加：
SELECT 'CREATE SYNONYM ' || SYNONYM_NAME || ' FOR ' || TABLE_OWNER || '.' || TABLE_NAME || ';' FROM dba_synonyms WHERE OWNER = 'PUBLIC' AND TABLE_OWNER != 'SYS';<br>SELECT 'CREATE DATABASE LINK ' || DB_LINK || ' CONNECT TO ' || USERNAME || ' IDENTIFIED BY VALUES ''' || PASSWORD || ''' USING ''' || HOST || ''';' FROM dba_db_links WHERE OWNER != 'DATALOOK1';
- 注意：DBLINK 的
PASSWORD字段在dba_db_links中是加密值，无法还原明文；实际迁移中应重建 DBLINK 并用新密码，或改用 Oracle Wallet 管理凭证。
密码与账户状态必须显式重建，不能依赖 expdp 导出
expdp 默认不导出密码哈希值（除非用 ENCRYPTION_PASSWORD 加密导出且目标端版本兼容），更不会导出 ACCOUNT_STATUS（如 LOCKED、EXPIRED & LOCKED）。直接在目标端 CREATE USER 后不设密码或状态，用户将无法登录。
- 导出前先查原始状态：
SELECT USERNAME, ACCOUNT_STATUS, EXPIRY_DATE, PROFILE FROM dba_users WHERE USERNAME = 'DATALOOK1';
- 建用户时必须带完整参数：
CREATE USER DATALOOK1 IDENTIFIED BY VALUES 'F890A675B6C3D2E1...' ACCOUNT LOCKED;<br>ALTER USER DATALOOK1 PASSWORD EXPIRE;
-
IDENTIFIED BY VALUES后的哈希值可从源端sys.user$表查（需SELECT ANY TABLE权限），但仅限同版本 Oracle 间复用；跨版本或迁到金仓等国产库时，必须重置密码并重新授权。
容易被忽略的点：角色依赖的系统包权限和细粒度审计策略
有些权限看似是角色赋予的，实则依赖底层系统包调用。例如用户用 DBMS_OUTPUT.PUT_LINE，除了 EXECUTE 权限，还可能需要 SELECT 权限访问 V$SESSION 等动态性能视图——而这些视图权限往往由 SELECT_CATALOG_ROLE 间接授予，但该角色本身不包含 SELECT 语句权限，必须检查其实际授予内容。
- 查角色具体包含哪些权限：
SELECT * FROM role_tab_privs WHERE role = 'SELECT_CATALOG_ROLE';<br>SELECT * FROM role_sys_privs WHERE role = 'SELECT_CATALOG_ROLE';
- 审计策略（
audit policy）不会随用户导出，若源端启用了 FGA 或标准审计，目标端需单独执行CREATE AUDIT POLICY并AUDIT POLICY，否则安全合规检查会失败。
