su oracle找不到lsnrctl或sqlplus是因为仅切换用户身份而不加载目标用户的shell初始化文件，PATH仍为原用户值，未包含$ORACLE_HOME/bin；应使用su - oracle以启动登录shell并读取.bash_profile等配置文件。
su oracle 为什么找不到 lsnrctl 或 sqlplus
因为 su oracle 不加载目标用户的 shell 初始化文件，PATH 仍沿用原用户（比如 root）的值，而 /u01/app/oracle/product/19c/dbhome_1/bin 这类 Oracle 工具路径根本不在里面。你执行 echo $PATH 就会发现输出里没有 $ORACLE_HOME/bin。
-
su oracle：只切换 UID/GID，保留当前环境变量、工作目录、shell 配置 -
su - oracle或su -l oracle：启动登录 shell，重置HOME、SHELL、USER、LOGNAME和PATH，再读取~oracle/.bash_profile（或.profile） - 如果
~oracle/.bash_profile本身没正确设置ORACLE_HOME和PATH，即使加了-也白搭
检查 .bash_profile 是否真生效
切到 oracle 用户后，先确认配置文件是否被读取、内容是否完整：
- 运行
ls -la ~oracle/.bash_profile，确保文件存在且非空 - 检查内容是否包含类似这三行（顺序不能错）：
export ORACLE_BASE=/u01/app/oracle export ORACLE_HOME=$ORACLE_BASE/product/19c/dbhome_1 export PATH=$ORACLE_HOME/bin:$PATH
- 特别注意：
$ORACLE_HOME/bin必须放在$PATH开头，否则可能调用到系统自带的老版本工具 - 如果用的是
.bashrc而不是.bash_profile，su -默认不读它——登录 shell 只认.bash_profile（或.profile）
crontab 或脚本里 su 切换失败的典型写法
在定时任务或自动化脚本中直接写 su oracle -c "lsnrctl status"，大概率报 command not found。这不是权限问题，是环境没加载。
- 错误写法：
su oracle -c "sqlplus / as sysdba"→ PATH 仍是 root 的 - 正确写法：
su - oracle -c "sqlplus / as sysdba"（注意中间的-） - 更稳妥的写法（绕过环境依赖）：
su - oracle -c "/u01/app/oracle/product/19c/dbhome_1/bin/sqlplus / as sysdba" - 如果脚本本身以 root 运行，也可提前
export ORACLE_HOME=...和export PATH=...，再调用命令
为什么 which sqlplus 有时返回空，但手动 cd 进 bin 目录却能运行
说明 PATH 没生效，但二进制文件本身没问题。常见于以下情况：
-
ORACLE_HOME路径拼写错误（比如少个dbhome_1），导致$ORACLE_HOME/bin是个不存在的路径 -
.bash_profile中漏了export，例如写了ORACLE_HOME=...却没export ORACLE_HOME - Oracle 安装时用了不同用户（如 grid），但
su - oracle后未设置对应实例名：export ORACLE_SID=orcl虽不影响命令查找，但后续连接会失败 - 文件系统挂载点权限限制（比如
/u01所在分区挂载时加了noexec），此时连绝对路径都执行不了
真正容易被忽略的是：.bash_profile 里变量定义顺序和 export 缺失——这两点比 su 加不加 - 更隐蔽，而且一旦出错，所有基于环境变量的 Oracle 命令都会静默失效。
