不能直接用dbstart脚本开机启动，因为dbstart是无状态shell脚本，不守进程、不汇报状态、不处理依赖，systemd无法监控其真实运行状况，易导致服务显示active(exited)但数据库实际未启动或已崩溃。
为什么不能直接用 dbstart 脚本开机启动
因为 dbstart 是 Oracle 提供的 shell 封装脚本，它本身不守进程、不汇报状态、不处理依赖、也不受 systemd 生命周期控制。直接在 /etc/rc.local 里调用它，systemd 会认为服务“已启动”，而实际 Oracle 进程可能几秒后就因环境变量缺失或权限问题崩溃，且 systemctl status oracle-19c 显示 active (exited)，毫无意义。
Type=forking 必须配对使用 ExecStart 和 ExecStop
Oracle 启动后会 fork 出多个后台进程（监听器、PMON、SMON 等），主进程退出。systemd 需要明确知道哪个 PID 是“主进程”来跟踪服务状态，所以必须用 Type=forking，并确保：
-
ExecStart调用的是dbstart（不是sqlplus或lsnrctl start单独调用） -
ExecStop必须对应使用dbshut，不能只停监听器 - 必须设置
User=oracle和Group=oinstall，否则dbstart读不到/etc/oratab里的Y标记 -
Environment中的ORACLE_HOME、ORACLE_SID、PATH缺一不可，尤其PATH要包含$ORACLE_HOME/bin
/etc/oratab 的 Y 标记才是开关
systemd 服务文件里写再多配置，如果 /etc/oratab 对应实例行第三字段不是 Y，dbstart 就会跳过该实例。常见错误包括：
- 改了
/etc/oratab但没 reload：改完必须systemctl daemon-reload - 字段用空格分隔而非冒号：正确是
orcl:/u01/app/oracle/product/19c/dbhome_1:Y，不是orcl /u01/... Y - 路径大小写或拼写错误：比如
dbhome_1写成DBHOME_1，dbstart找不到目录就静默失败 - 多实例共存时，某一行写错导致整个
dbstart跳过所有实例
监听器和数据库服务要不要拆开？
可以拆，但没必要。Oracle 官方 dbstart 已内置先启监听器、再启实例的逻辑。强行拆成两个 service（如 oracle-lsnrctl.service + oracle-db.service）反而容易引发竞态：
- 监听器启动慢于数据库实例，导致实例注册失败、
tnsping不通 - 没加
After=oracle-lsnrctl.service和Wants=oracle-lsnrctl.service，systemd 并发启动，顺序不可控 - 停机时若只 stop 数据库 service，监听器还在跑，残留端口占用
- 运维复杂度上升，
systemctl restart oracle-19c变成两条命令
真正关键的是确保 dbstart 脚本本身能正常工作——先手动以 oracle 用户执行一遍 /u01/app/oracle/product/19c/dbhome_1/bin/dbstart /u01/app/oracle/product/19c/dbhome_1，确认输出里没有 “failed” 或 “not found”，再封装进 systemd。
