根本原因是oracle_sid未export：仅在.bash_profile中写oracle_sid=orcl而不加export，导致子进程sqlplus无法继承该变量，从而触发ora-12162错误；必须写成export oracle_sid=orcl并source生效。
ORACLE_SID没export导致sqlplus报ORA-12162
根本原因不是没配，而是配了但没导出——ORACLE_SID=orcl写在.bash_profile里，却漏掉export ORACLE_SID。这种写法只在当前shell进程里创建变量，子进程（比如sqlplus）完全看不见它。
常见错误现象：
-
sqlplus / as sysdba报ORA-12162: TNS: net service name is incorrectly specified -
echo $ORACLE_SID显示为空，哪怕你刚在配置文件里写了 -
env | grep ORACLE查不到ORACLE_SID
实操建议：
- 打开
~/.bash_profile，确认ORACLE_SID赋值后紧跟export ORACLE_SID，不能只写ORACLE_SID=orcl - 改完执行
source ~/.bash_profile立即生效，别依赖重新登录 - 验证：运行
echo $ORACLE_SID应输出预期值，再跑sqlplus / as sysdba看是否成功
多个Oracle实例共存时ORACLE_SID硬编码失效
单用户只跑一个实例时，把ORACLE_SID固定写死没问题；但一旦部署多个实例（比如orcl和testdb），硬编码就变成定时炸弹——切实例必须手动改配置、重载，极易出错。
实操建议：
- 删掉
.bash_profile里硬写的export ORACLE_SID=xxx - 改用Oracle官方推荐的
oraenv脚本动态切换：. oraenv（注意开头的点），然后按提示输入SID - 确保
/etc/oratab已正确登记所有实例，格式为sid_name:/path/to/oracle_home:Y/N，否则oraenv找不到目标 - 如果常用某几个SID，可写别名简化操作，例如
alias orcl='. oraenv && echo $ORACLE_SID'
su - oracle后环境变量丢失的真正原因
用su - oracle（带短横）会触发登录shell，读~/.bash_profile；但su oracle（不带短横）是非登录shell，只读~/.bashrc。很多人把export全塞进.bashrc，结果su -反而失效。
实操建议：
- 检查
/etc/passwd中oracle用户的shell字段，确认是/bin/bash而非/bin/sh -
.bash_profile里必须包含if [ -f ~/.bashrc ]; then . ~/.bashrc; fi这一行，保证.bashrc也被加载 - 所有Oracle相关
export语句统一放在.bash_profile，不要分散到.bashrc里 - 测试：新终端窗口执行
su - oracle -c 'echo $ORACLE_SID'，应有输出
Windows下注册表ORACLE_SID设置被忽略
Windows平台设了系统环境变量或注册表HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_xxx\ORACLE_SID，但sqlplus仍报错，大概率是Oracle服务启动时没读注册表，或者当前用户权限不够读取该路径。
实操建议：
- 优先使用用户级环境变量：右键“此电脑”→“属性”→“高级系统设置”→“环境变量”，在“用户变量”里新增
ORACLE_SID - 注册表路径中的
KEY_xxx必须与实际Oracle Home注册名严格一致，比如KEY_OraDB21Home1，错一个字符都不认 - 修改后必须重启命令行窗口，cmd或PowerShell都不会自动继承新环境变量
- 验证：在cmd里运行
set ORACLE_SID，确认输出值；再运行sqlplus / as sysdba
最麻烦的其实是多实例+跨平台+服务账户启动的组合场景，这时候ORACLE_SID不是靠一次配置就能一劳永逸的，得盯住三个地方：用户shell配置、注册表/系统变量、以及/etc/oratab或服务启动参数里的SID声明。漏掉任何一环，sqlplus都会给你脸色看。
