NLS_DATE_FORMAT重启失效是因为它是会话级参数，仅对当前连接生效；持久化需在shell配置文件（如~/.bashrc）中export该变量并重新加载，或Windows系统环境变量中设置，并注意GUI工具、容器等特殊环境的继承差异。
修改 NLS_DATE_FORMAT 后为什么重启会失效？
因为 oracle 的 nls_date_format 是会话级参数，直接在 sql*plus 或客户端里用 alter session set nls_date_format = 'yyyy-mm-dd hh24:mi:ss' 只影响当前连接。哪怕你改了数据库初始化参数 nls_date_format（不推荐），它也只对新会话生效，且受客户端 nls 环境变量覆盖。
Linux/macOS 下让 NLS_DATE_FORMAT 环境变量真正持久化
必须让 shell 在每次启动时都加载该变量，且确保 Oracle 客户端（如 sqlplus、sqlcl）能读到它——关键不是“设了没”，而是“被哪个进程继承了”。
- 写入 shell 配置文件：
~/.bashrc（bash 用户）或~/.zshrc（zsh 用户），加一行：export NLS_DATE_FORMAT='YYYY-MM-DD HH24:MI:SS' - 别只改
/etc/profile或/etc/bash.bashrc：普通用户登录不一定 source 全局文件，尤其图形界面终端常只读用户级配置 - 改完后执行
source ~/.bashrc（或对应文件），再新开终端验证：echo $NLS_DATE_FORMAT - 注意单引号必须保留：日期格式里的
HH24、MI是 Oracle 特定占位符，不能被 shell 解析，所以不能用双引号（除非里面没特殊字符）
Windows 上设置 NLS_DATE_FORMAT 持久生效的要点
Windows 不像 Linux 那样有统一的 shell 初始化链，Oracle 客户端是否读取环境变量，取决于启动方式。
- 系统级设置：控制面板 → 系统 → 高级系统设置 → 环境变量 → 新建系统变量：
NLS_DATE_FORMAT值为YYYY-MM-DD HH24:MI:SS - 但 cmd.exe 启动前就已继承环境变量，所以改完必须**关闭所有 cmd/PowerShell 窗口重新打开**，否则旧进程看不到新值
- 如果用 PL/SQL Developer、SQL Developer 等 GUI 工具，它们未必从父进程继承环境变量——有些需在工具内单独配置 NLS 参数，或通过启动脚本 wrapper 设置
- PowerShell 用户注意：
$env:NLS_DATE_FORMAT='YYYY-MM-DD HH24:MI:SS'只对当前会话有效；要持久化仍得走系统环境变量设置
NLS_DATE_FORMAT 和数据库参数 NLS_TERRITORY 的冲突风险
即使环境变量设对了，Oracle 仍可能无视它——当客户端显式设置了 NLS_TERRITORY（比如 AMERICA），它会强制绑定一套默认日期格式（如 DD-MON-RR），覆盖 NLS_DATE_FORMAT。
- 检查当前会话实际生效的值：
SELECT * FROM NLS_SESSION_PARAMETERS WHERE PARAMETER IN ('NLS_DATE_FORMAT', 'NLS_TERRITORY'); - 避免隐式覆盖：不在连接字符串里传
?NLS_TERRITORY=AMERICA这类参数；也不在sqlnet.ora中配NLS_TERRITORY - 最稳妥做法：环境变量设好后，在应用连接池或脚本开头统一执行
ALTER SESSION SET NLS_DATE_FORMAT = '...';，双重保险
Oracle 的 NLS 行为高度依赖“谁启动了谁”和“哪一层先说话”，环境变量只是其中一环。最容易被忽略的是：GUI 工具、IDE 内嵌终端、Docker 容器、systemd 服务，它们的环境继承路径全都不一样——别假设改了 ~/.bashrc 就万事大吉。
