我们有一个客户最近在AWS上迁移到Oracle 19 c。自从迁移以来，在我们的应用程序中使用DBMS_JOB.SUBMIT创建的任何Oracle作业都计划在DB服务器时间之前7小时运行。
例如，下面的测试代码是在7：00在客户端机器上运行的。AWS服务器上的时间是14：00，但实际作业创建为在21：00运行
DECLARE
I NUMBER;
BEGIN
DBMS_JOB.SUBMIT(I, 'DECLARE I NUMBER; BEGIN SELECT COUNT(1) INTO I FROM DUAL; END;');
COMMIT;
END;这听起来和时区有关吗有什么想法吗
更新：
我们的客户位于美国（我在英国），当我在他们的数据库上运行上面的代码时，我的操作系统时区设置为“（UTC+00：00）伦敦”，作业立即被调度。如果我将操作系统时区更新为“（UTC-08：00）太平洋时间”，以模仿他们的操作系统，运行上面的代码将作业调度为在7小时内运行。
1条答案
按热度按时间5ktev3wc1#
这个问题是由我刚刚确定的一个bug引起的。我已经在Oracle上创建了一个服务请求，所以他们可以在他们的dbms_ijob代码中修复这个问题。看起来这个bug是在19c中引入的，其中dbms_job代码被重构为dbms_scheduler的外观。在最新的Oracle DB RU（即19.19）中仍然存在该错误。dbms_ijob包执行了从日期到时间戳的错误转换，它将当前数据库主机的系统时间（sysdate）解释为当前会话时区中的时间（而它是数据库主机操作系统时区中的时间）。这导致所见的偏移。此偏移可以是正的，也可以是负的，这会导致作业开始得太早或太晚。现在唯一的解决方法是切换到dbms_scheduler或偏移dbms_job.submit next_date参数以补偿错误的时间戳。