oracle修改会话时区后，重启数据库后时区又变成原来的了

首先确认会话时区是否正确，会话时区可能和数据库时区不一致

SQL> SELECT SESSIONTIMEZONE FROM DUAL;

SESSIONTIMEZONE

---------------------------------------------------------------------------

+08:00

会话时区是北京时区

SQL> SELECT DBTIMEZONE FROM DUAL;

DBTIME

------

+00:00

DB是世界时区

SQL> SELECT TZ_OFFSET(SESSIONTIMEZONE), TZ_OFFSET(DBTIMEZONE) FROM DUAL;

TZ_OFFS TZ_OFFS

------- -------

+08:00 +00:00

1检查数据库是否有这样的字段类型 TIMESTAMP WITH LOCAL TIME ZONE

SQL>select cowner || '' || ctable_name || '(' || ccolumn_name || ') -'

|| cdata_type || ' ' col

from dba_tab_cols c, dba_objects o

where cdata_type like '%WITH LOCAL TIME ZONE'

and cowner=oowner

and ctable_name = oobject_name

and oobject_type = 'TABLE'

order by col

/

SQL>select uname || '' || oname || '' || cname TSLTZcolumn

from sysobj$ o, syscol$ c, sysuser$ u

where ctype# = 231

and oobj# = cobj#

and uuser# = oowner#;

2检查当前数据库时区

SQL> select from database_properties where property_name='DBTIMEZONE';

行将被截断

PROPERTY_NAME PROPERTY_VALUE

------------------------------ -------------------------------------------------

DBTIMEZONE 00:00

3改变数据库时区

SQL> ALTER DATABASE SET TIME_ZONE = '+8:00';

数据库已更改。

SQL> shutdown immediate

数据库已经关闭。

已经卸载数据库。

ORACLE 例程已经关闭。

SQL> startup

ORACLE 例程已经启动。

Total System Global Area 272629760 bytes

Fixed Size 1248528 bytes

Variable Size 92275440 bytes

Database Buffers 171966464 bytes

Redo Buffers 7139328 bytes

数据库装载完毕。

数据库已经打开。

SQL> select dbtimezone from dual;

DBTIME

------

+08:00

4检查时间

SQL> select to_char(sysdate, 'yyyy-mm-dd hh24:mi:ss') from dual

SQL> SELECT SYSTIMESTAMP FROM dual;

SYSTIMESTAMP

---------------------------------------------------------------------------

23-7月 -09 115025750000 上午 +08:00

1、user_name,以及time是sqlserver中的关键字建议更名

2、最后的那个地方order by 要和IPADDRESS空出格

这样就能编译成功了。另外java可以连接好多数据库包括sqlserver，肯定支持datetime类型，试着从网上下载一些驱动包（jar），用的时候导入，并在程序中import相应的类包。

以下链接你可以参考一下：java中的日期和sql中的日期转换

最近在使用date命令时，发现表示东8区(中国时区)要使用 GMT-8 ，但在Java中却需要使用 GMT+8 ，如下：

而在Java中，如下：

这就让人有点迷糊了，经过一段时间搜索，发现在时区表达形式上还有不少知识点呢！

众所周知，为了方便各地区本地时间之间的转换，人们将全球划分为了24个时区，以格林尼治天文台(GMT)为零时区，往东西两个方向分别有12个时区，所以自然有了以GMT为前缀的时区表示法，如下：

GMT+8 表示东8区，中国就是使用这个时区，而 GMT-8 表示西8区，如果格林尼治天文台的本地时间是2022-03-19的0点，那么 GMT+8 地区的本地时间就是2022-03-19的8点，而 GMT-8 的本地时间就是往前8小时，即2022-03-18的16点。

注意，上面的各地区本地时间的表述虽然不同，但它们实际是同一个时刻(绝对时间)，要理解本地时间与绝对时间的区别。

GMT+8 正是Java中支持的时区表示法，那为啥Linux中却是 GMT-8 呢？实际上Linux中的 GMT-8 也可以写成 Etc/GMT-8 ，这才是它的标准名称，如下：

可以发现用 Etc/GMT-8 的话，Linux与Java的输出都是一样的了，是的， Etc/GMT-8 也是一种类似 GMT+8 的时区表示机制，只不过它的 +- 号是反的。

Ok，虽然上面的差异弄清楚了，但时区的表示形式还没有介绍完，接着往下看

除了 GMT+8 表示方式外，我们还经常会看到 UTC+8 这样的表示方式，这是UTC时区表示法。

即生GMT何生UTC？这是由于GMT是以格林尼治天文台为时间基准，但地球不是完美球体且自转速度在变慢，所以地球自转速度并不均匀，这导致以格林尼治天文台为时间基准是不准的。

为了更准确度量时间，科学家们发明了UTC时间，以铯原子跃迁次数来度量时间，比GMT时间更准确，为了保证GMT的准确性，每隔几年GMT时间会做一次调整，以与UTC时间对齐。

因此，既然有了更准确的UTC，那么就有了以UTC为前缀的时区表示法，如中国时区可使用 UTC+8 。

各时区偏移量表示法一览表，如下：

除了用偏移量来表示时区，为了方便，人们还按区域/城市的方式来定义时区，如 Asia/Shanghai ， Asia/Hong_Kong 都表示东8区，具体有哪些城市命名的时区，可以在时区数据库中查看。

另外，为了简化区域时区表示法，又定义了一套时区缩写，如CST是中国时区 China Standard Time 的缩写，可以在时区缩写中查看各种缩写定义。

注意，一般都不建议使用时区缩写，因为时区缩写的命名经常会重复，比如CST是 Central Standard Time (北美中部标准时间UTC -6)、 China Standard Time (中国标准时间UTC +8)、 Cuba Standard Time (古巴标准时间UTC -5)。

由于不同软件对CST的解释可能不同，导致会出现时间相差13或14个小时的情况，这在Java搭配MySQL时经常出现，我还专门写了一篇文章mysql的timestamp会存在时区问题？，对于一定要使用时区缩写的场景，可以使用香港时区缩写 HKT ，它不重复且和上海处于同一个时区。

在Java中和时区相关的类有TimeZone、ZoneId，其中TimeZone是老的时区类，而ZoneId是新的时区类，它有ZoneOffset和ZoneRegion两个子类，分别代表偏移量表示法和区域表示法。

那它们都支持上述的哪些时区写法呢？写个Demo验证一下，如下：

输出如下：

虽然偏移量表示法与区域表示法都可以表示时区，但由于夏令时的存在，它们并不完全等同。

夏令时（Daylight Saving Time: DST），也叫 夏时制，是指为了节约能源，在天亮的早的夏季，人为将时间调快一小时，以充分利用光照资源，节约照明用电。

而中国在 1986 年至 1991 年也实行过夏令时，在1986~1991的每年从四月中旬第一个星期日的凌晨2时整（北京时间），将时钟拨快一小时，即将表针由2时拨至3时，夏令时开始；到九月中旬第一个星期日的凌晨2时整（北京夏令时），再将时钟拨回一小时，即将表针由2时拨至1时，夏令时结束。从1986年到1991年的六个年度，除1986年因是实行夏时制的第一年，从5月4日开始到9月14日结束外，其它年份均按规定的时段施行。

故会有下面看起来有点奇怪的现象：

为什么 Asia/Shanghai 输出为3点，而 GMT+8 输出为2点呢？原因是 1986-05-04 02:00:00 这个时间点中国正开始实行夏令时，时钟拨快了1小时。

而 GMT+8 为什么输出为2点呢？因为中国、马来西亚、菲律宾、新加坡的时区都是 GMT+8 ，只有中国在实行夏令时，而在 GMT+8 中没法感知到区域信息，那java只能以没有实行夏令时的方法来计算本地时间了。

正是由于夏令时的存在，导致程序可能出现诡异的现象甚至bug，如下：

输出如下：

为啥会这样呢？原因是本地时间虽然看起来没变，但 Asia/Shanghai 这个代表的时区却发生了变化。

我们可以将上面 printZonedDateTime 中时间格式由 yyyy-MM-dd HH:mm:ss VV 修改为 yyyy-MM-dd HH:mm:ss VV xxx 再执行，发现输出如下：

如上，夏令时导致 Asia/Shanghai 这个时区不一定是东8区了，也可能是东9区，故Java中，想将ZoneRegion转换为ZoneOffset，需要传递一个instant时刻参数，如下：

夏令时真是一种自欺欺人的做法，还好中国从1991年后就没再实行了！

SQLserver数据库的时区采用的是SQLServer服务器 *** 作系统的时区，修改时区需要修改 *** 作系统时区。

SQLServer2008（sql2008）由微软公司推出的大型的关系型数据库系统软件，专门用于大批量的数据存储和管理，适合服务器数据管理。

第一，根据自建数据库的数据量、MySQL版本以及访问量等信息申请对应的云数据库实例，申请云数据库实例完成后，联系云数据库的腾讯云技术人员调整云数据库和云服务器之间的网络配置。

第二，迁移数据库：

1、使用mysqldump导出自建数据库的数据，注意记录binlog的文件和位置（如需帮助请咨询云数据库技术人员），然后使用mysql命令导入至对应的云数据库实例中。推荐使用云数据库多线程导入导出工具。

2、在自建数据库上给云数据库的同步用户授权，授权语句范例如下：

GRANT REPLICATION SLAVE,FILE ON TO 'replication'@'%' IDENTIFIED BY 'test123';

3、在导入数据后根据备份的binlog位置和binlog文件使用change master命令配置从自建数据库到云数据库的主从同步。范例如下：

CHANGE MASTER TO MASTER_HOST='101110',MASTER_USER='replication',MASTER_PASSWORD='test123',MASTER_LOG_FILE='mysql-bin000012', MASTER_LOG_POS=106;

第三，迁移后数据校验：数据同步完成之后，可以使用数据抽样、对比表数量、库数量或者使用专业的对比工具确认数据是否完整。

第四，业务切换数据库：校验数据完整后，请选择适当时间来做业务的平滑切换，将业务连接的数据库切换至云数据库，切换后请务必检查自建数据库是否还有请求进来，避免出现还有请求连接到自建数据库的情况。

第五，断开自建数据库和云数据库主从同步：

1、切换后业务正常后，业务侧在云数据库上执行如下命令断开自建数据库到云数据库的主从同步。

2、断开主从同步后通知云数据库的技术人员恢复之前调整的网络。

在达梦数据库中，Timestamp类型的数据是不带时区信息的，即不考虑时区的影响。在存储Timestamp类型的数据时，达梦数据库会将其转换为UTC时间（协调世界时），因此不会受到本地时区的影响。 需要注意的是，虽然Timestamp类型不带时区信息，但在数据库服务器和客户端之间传输数据时，可能会受到时区设置的影响。例如，在使用JDBC驱动程序连接达梦数据库时，可以使用setTimestamp()方法设置Timestamp类型的数据，该方法接受一个javasqlTimestamp对象作为参数。如果该Timestamp对象带有时区信息，则JDBC驱动程序会将其转换为UTC时间，并存储到达梦数据库中，因此最终的存储结果可能会受到时区设置的影响。 因此，在使用达梦数据库存储Timestamp类型数据时，应该注意时区的设置问题，避免数据存储结果的不一致。建议使用标准的UTC时间格式存储Timestamp数据，并在需要时进行时区转换。

MySQL JDBC 8025版本中的时区处理与之前的版本有所差异。具体来说，这些差异主要涉及以下方面：

1 时区转换：MySQL JDBC 8025版本默认使用UTC时区进行时间戳的转换。如果需要在应用程序中使用本地时区或其他时区，需要通过设置连接参数或使用JDBC API进行相应的设置。

2 日期时间类型的处理：MySQL JDBC 8025版本中，日期时间类型的值会被转换为Java8中的日期时间类型（例如javatimeLocalDateTime、javatimeZonedDateTime等）。这些类型与之前版本中的javasqlDate和javasqlTimestamp有所不同，需要注意使用方式和转换规则。

3 时区信息的获取：MySQL JDBC 8025版本中，可以通过使用JDBC API获取MySQL服务器的时区信息，以便在应用程序中进行时区转换和处理。

需要注意的是，这些差异可能会对已有的应用程序产生影响，需要对应用程序进行相应的修改和适配。同时，在使用MySQL JDBC 8025版本时，需要仔细阅读官方文档，了解其提供的新特性和变化，以便更好地使用和管理MySQL数据库。

以上就是关于oracle修改会话时区后，重启数据库后时区又变成原来的了全部的内容，包括:oracle修改会话时区后，重启数据库后时区又变成原来的了、java使xml的时间格式上有时区时差之类的转换怎么查入数据库sqlServer2008、时区的坑，不想再踩了等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！