物理standby可建立但不可改字符集，因数据文件是主库镜像，控制文件与PROPS$中NLS_CHARACTERSET必须一致；强行修改会导致无法OPEN、RECOVER失败及DG Broker拒绝接管。可以建立，但物理 standby 会持续报 WARNING，且一旦以
OPEN READ ONLY 方式打开并执行含中文或 NCHAR 字段的查询，大概率触发 ORA-12705、ORA-01401 或日志应用中断——这不是“能不能建”，而是“建了之后能不能稳住”。
为什么物理 standby 能建但不能改字符集
主库和备库的 nls_characterset 值记录在控制文件和数据字典（如 props$）中，物理 standby 的数据文件是主库镜像，强行在备库执行：alter database characterset internal_use zhs16gbk
会导致：
• 备库无法 open（报 ora-01565 + ora-27047）
• 后续 recover 失败（ora-01194：控制文件与数据文件不一致）
• dg broker 拒绝接管（dgmgrl 显示 warning: database character set differs from primary）
NLS_LANG 和 NLS_NCHAR_CONV_EXCP 是唯一可控点
真正能动手的地方不是数据库层，而是连接层和会话行为：
• 在备库主机的 $ORACLE_HOME/network/admin/sqlnet.ora 中添加：NLS_LANG=AMERICAN_AMERICA.ZHS16GBK（值必须与主库 NLS_DATABASE_PARAMETERS.NLS_CHARACTERSET 完全一致）
• 连接时显式设置环境变量，避免依赖系统 locale：export NLS_LANG=AMERICAN_AMERICA.ZHS16GBK; sqlplus / as sysdba
• 动态关闭严格转换检查（关键）：ALTER SYSTEM SET NLS_NCHAR_CONV_EXCP=FALSE SCOPE=BOTH;
该参数生效后，遇到 NCHAR/NCLOB 字段转换异常不再报错，而是静默替换为 ? 或空格——比同步中断更可控
哪些操作会立刻暴露字符集问题
以下场景只要发生一项，就可能立即报错：
• 备库以 OPEN READ ONLY 状态执行 SELECT，且结果集含中文列、NCHAR 类型字段或视图定义里有字符集敏感逻辑
• 启用 SQL Apply（逻辑 standby）并执行 DML，尤其涉及字符长度判断（如 LENGTHB、SUBSTRB）
• 查询 V$NLS_PARAMETERS 或调用 UTL_I18N.STRING_TO_RAW 等依赖字符集的内置函数
• 使用 JDBC/ODBC 连接时未显式指定 charset 参数，客户端默认用 UTF-8 解析 ZHS16GBK 数据
最易被忽略的验证点
很多人只查 NLS_CHARACTERSET，却漏掉：
• NLS_NCHAR_CHARACTERSET 是否一致（它独立于主字符集，影响 NCHAR 字段）
• 备库 sqlnet.ora 中是否同时配置了 NLS_LANG 和 SQLNET.ALLOWED_LOGON_VERSION_SERVER=8（旧版客户端兼容性开关，不配可能导致连接失败）
• V$DATABASE.NLS_CHARSET_ID 和 V$DATABASE.NLS_NCHAR_CHARSET_ID 两者的数值是否与主库完全相同（不只是名称匹配）
