不会，Oracle 的 TIME_ZONE 是静态参数，ALTER SYSTEM SET 会报错；必须重启数据库或用 ALTER DATABASE SET TIME_ZONE（需 MOUNT 状态）修改，默认仅影响新会话及 TIMESTAMP WITH LOCAL TIME ZONE 列的显示值。
ALTER SYSTEM SET TIME_ZONE 会立即生效吗？
不会。oracle 的 time_zone 系统参数是静态参数（static），必须重启数据库才能生效。直接执行 alter system set time_zone = 'asia/shanghai' scope=both 会报错 ora-02095: specified initialization parameter cannot be modified。
常见误操作是以为加了 SCOPE=BOTH 就能热修改，其实 Oracle 对该参数根本不支持动态修改。
-
TIME_ZONE是初始化参数（init.ora或 SPFILE 中的time_zone），只在实例启动时读取一次 - 运行中可通过
ALTER DATABASE SET TIME_ZONE修改，但仅影响后续新建的数据库连接的会话时区（不改变已连接会话） - 真正全局生效的唯一方式：停库 → 修改 SPFILE 或 PFILE → 启库
ALTER DATABASE SET TIME_ZONE 的真实作用范围
这条语句不是改系统时间，而是设定数据库级默认时区，用于 TIMESTAMP WITH LOCAL TIME ZONE 类型列的隐式转换基准。它只影响新建立的会话，且要求数据库处于 MOUNT 状态（不能 OPEN）。
典型错误流程：数据库已 OPEN，直接执行 ALTER DATABASE SET TIME_ZONE = 'Asia/Shanghai' → 报错 ORA-30079: cannot alter database timezone when database is open。
- 必须先
SHUTDOWN IMMEDIATE，再STARTUP MOUNT - 执行
ALTER DATABASE SET TIME_ZONE = 'Asia/Shanghai' - 再
ALTER DATABASE OPEN - 已有连接中的
SYSTIMESTAMP、CURRENT_TIMESTAMP不变；新连接中CURRENT_TIMESTAMP才按新时区返回
修改后 TIMESTAMP WITH LOCAL TIME ZONE 列的行为变化
这是最容易被忽略的实际影响点。如果表里有 TIMESTAMP WITH LOCAL TIME ZONE 字段，修改数据库时区后，**历史数据的显示值会变，但存储值不变**。
例如原时区为 America/New_York，某条记录存入 TIMESTAMP WITH LOCAL TIME ZONE 值为 '2024-01-01 12:00:00'，底层以 UTC 存储；切换到 Asia/Shanghai 后，同一行 SELECT 出来会显示为 '2024-01-01 01:00:00'（+13 小时偏移）——因为 Oracle 自动做了本地时区转换。
- 这种“显示漂移”不是 bug，是该数据类型的定义行为
- 若业务依赖字段显示值做逻辑判断（比如定时任务查“今天”的数据），可能出错
- 建议提前检查表结构：
SELECT table_name, column_name FROM dba_tab_columns WHERE data_type = 'TIMESTAMP WITH LOCAL TIME ZONE'
更安全的替代方案：用会话级或应用层控制时区
除非必须统一所有会话的默认时区（如跨时区部署的集中式数据库），否则不建议动数据库级 TIME_ZONE。多数场景下，用以下方式更可控：
- 连接时指定时区：
ALTER SESSION SET TIME_ZONE = 'Asia/Shanghai'（对当前会话生效） - Java 应用通过 JDBC URL 加参数：
?serverTimezone=Asia/Shanghai&useTimezone=true - SQL 中显式转换：
FROM_TZ(CAST(SYSDATE AS TIMESTAMP), 'UTC') AT TIME ZONE 'Asia/Shanghai' - 避免使用
TIMESTAMP WITH LOCAL TIME ZONE，统一用TIMESTAMP WITH TIME ZONE或DATE+ 显式注释时区
真正麻烦的从来不是改参数这一步，而是改完之后那些没写时区假设的 SQL 和老代码突然开始返回“不对”的时间值。
