必须同步更新 PATH 和 LD_LIBRARY_PATH，因为 PATH 决定 sqlplus 执行路径，LD_LIBRARY_PATH 控制 libclntsh.so 等共享库加载顺序，二者不匹配会导致启动失败或 OCI 初始化错误。
只改 ORACLE_HOME 不动 PATH 和 LD_LIBRARY_PATH，切换就等于没切——sqlplus 仍会调用旧版本二进制或库，报 libclntsh.so: cannot open shared object file 或直接启动失败。
为什么 PATH 和 LD_LIBRARY_PATH 必须同步更新？
Oracle 客户端工具（如 sqlplus、rman）的执行路径由 PATH 决定，而运行时依赖的共享库（如 libclntsh.so）加载顺序由 LD_LIBRARY_PATH 控制。两者不匹配会导致：
-
PATH指向新$ORACLE_HOME/bin，但LD_LIBRARY_PATH里老路径靠前 → 找到新sqlplus，却链接旧库 → OCI 初始化失败 -
LD_LIBRARY_PATH包含新$ORACLE_HOME/lib，但PATH还在用旧bin→ 启动的是旧版sqlplus，可能不兼容新库或参数 - 混用 Instant Client 和完整版 Oracle Home 时，若 Instant Client 的
lib路径排在前面，sqlplus可能加载错版本的libclntsh.so，引发段错误
用 shell 函数封装切换逻辑，别靠反复 source 配置文件
把一堆 export ORACLE_HOME=... 堆在 .bash_profile 里，每次手动改再 source，极易漏改、手抖、忘记重载；更麻烦的是，不同实例常需不同 TNS_ADMIN、NLS_LANG，硬编码成全局变量反而碍事。
实操建议：
- 在
.bashrc或独立脚本中定义函数，函数名体现版本或用途，例如：ora19c、ora12c_dev - 函数内严格设置三者：
ORACLE_HOME、PATH（$ORACLE_HOME/bin必须排最前）、LD_LIBRARY_PATH（$ORACLE_HOME/lib同样前置） - 按需补充
TNS_ADMIN（指向对应network/admin）、NLS_LANG（避免字符集乱码） - 不要在函数里
unset ORACLE_SID——除非你明确知道当前上下文需要清空；否则可能干扰已运行的后台进程
示例函数：
ora19c() {
export ORACLE_HOME=/u01/app/oracle/product/19c/dbhome_1
export PATH=$ORACLE_HOME/bin:$PATH
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH
export TNS_ADMIN=$ORACLE_HOME/network/admin
export NLS_LANG=AMERICAN_AMERICA.AL32UTF8
}
ORACLE_SID 不参与路径/库加载，但决定 sqlplus / as sysdba 连谁
ORACLE_SID 不影响 sqlplus 本身能否启动，但它控制本地操作系统认证连接的默认目标实例。设错会导致：
-
sqlplus / as sysdba连上错误实例，尤其当多个实例监听同一主机、不同端口时 - 因目标实例未启动、权限不足或参数差异，直接报
ORA-01031: insufficient privileges
注意：
- 远程连接（
sqlplus user@tns_alias）完全不依赖ORACLE_SID - 仅当使用本地连接（
/ as sysdba）时才需确保ORACLE_SID与目标实例实际 SID 严格一致（大小写敏感，不能拼错） - 多实例管理场景下，建议函数内统一设置
ORACLE_SID，值必须和tnsnames.ora或v$database.name查出的 SID 完全一致
真正容易被忽略的是三者对齐验证：每次切换后，务必手动检查 echo $ORACLE_HOME、echo $PATH | grep -o "$ORACLE_HOME/bin"、echo $LD_LIBRARY_PATH | grep -o "$ORACLE_HOME/lib" 是否都生效且顺序正确——少一个环节，故障就藏在下次 sqlplus 启动的一瞬间。
