作者介绍
崔华 网名 dbsnake
Oracle ACE Director，ACOUG 核心专家
答：这个是没有影响的。
答：总共有两种，分别是timestamp with time zone和timestamp with local time zone，Oracle分别用13个byte和11个byte来存储他们。
这里面timestamp with time zone没什么好说的，因为里面的时区是用2个byte来固定的存储时区的偏移量，所以源库和目标库的时区即使不一样，对原始数据也没有影响。
答：timestamp with local time zone不会具体存储时区的偏移量，而是会根据dbtimezone和用户插入数据时指定的时区（通常就等于sessiontimezone）之间的差值来调整所存储的时间：
我们来看一个实例：
数据库1：
现在这个库的systimestamp中包含的时区和dbtimezone相同，所以当我插入systimestamp的时候，Oracle 不会对timestamp with local time zone做时间上的调整：
从结果里我们看到，17减1后是16，也就是下午4点，所以这里是没有发生时间的调整的，原因我上面已经说过了。
我们修改一下sessiontimezone后再插入一条记录，我把sessiontimezone修改为洛杉矶所在的时区：
注意，这个时候不能再插入systimestamp了，systimestamp跟sessiontimezone和dbtimezone没有关系，它只取决于database server端环境变量TZ的设置
从结果里我们可以看到，之前插入的那条记录显示结果变成了2月1日上午零点18分，这是正常的，因为timestamp with local time zone的显示结果会随着sessiontimezone的改变而改变，洛杉矶滞后于北京16个小时，所以我们在16点18分插入的那条记录的显示结果变成了上午零点18分。
现在我们来解释刚刚插入的第二条记录的显示结果：
插入的时候我们指定了是以洛杉矶当地时间16点38分19秒，而现在的sessiontimezone就是洛杉矶所在的时区，所以第二条记录的显示结果就是16点38分19秒。
现在第二条记录Oracle实际上的存储结果是120,112,2,2,9,39,20，这里因为dbtimezone是+08:00，插入的时候我们指定了是以洛杉矶当地时间（相当于sessiontimezone是-08:00），所以Oracle要对timestamp with local time zone实际存储结果加上sessiontimezone和dbtimezone的差值，也就是16个小时。16点38分19秒加上16是32点38分19秒，也就是第二天早上8点38分19秒，所以这里Oracle实际的存储结果变成了2,2,9,39,20。
我们导出上述表：
现在我们切换到目标数据库2，这个库里dbtimezone和数据库1的dbtimezone是不一样的，这里我用dbtimezone的差异来模拟时区的差异：
数据库2：
我们尝试导入刚才在数据库1里导出的表t2：
现在我们来看一下导入的结果：
现在我们再次回到数据库1并将sessiontimezone设成和数据库2一样：
数据库1：
可以看到两条记录的显示时间是一致的，所以对于timestamp with local time zone而言，数据迁移时不同的时区是没有关系的。
这里数据库1的dbtimezone是+08:00，数据库2的dbtimezone是+00:00，所以Oracle对原来的第一条记录的小时17减了8变成了9,第二条记录的小时9减了8变成1。
其本质原因是Oracle在做数据迁移时，对timestamp with local time zone类型的数据Oracle会根据源库和目标库不同的dbtimezone来对timestamp with local time zone类型的数据做转换。
分享
【线上分享 第47期】Hive 中利用正则表达式
恩墨大数据讲堂每周三八点与您相约。恩墨大讲堂邀请恩墨学院大数据产品总监孟硕老师，为你讲述Hive 中利用正则表达式 。主要为您阐述：
1、 正则表达式定义；2、 正则表达式函数；3、 正则解析器；4、使用正则解析器生成表；
参与方式：扫描下图的二维码。
