Oracle 10.2.0.4上ORA-01882故障解決一例

任何軟體，特別是企業級系統組件的升級工作，是一個非常複雜的過程。升級路徑、資料留存預案、回退步驟、原有業務功能衝擊程度，都是需要反覆測試論證的問題。所有的營運人員在遇到升級問題的時候，都要抱有謹慎的態度。
 
筆者最近接手一個升級過的系統，在測試過程中遇到了一些問題。經過尋找MOS和網路資源加以解決。記錄下來，留待需要的朋友。

推薦閱讀：

ORA-01172、ORA-01151錯誤處理

ORA-00600 [2662]錯誤解決

ORA-01078 和 LRM-00109 報錯解決方案

ORA-00471 處理方法筆記

ORA-00314,redolog 損壞，或丟失處理方法

ORA-00257 歸檔日誌過大導致無法儲存的解決辦法

 

 1、環境介紹

 

接手的是一個升級到10.2.0.4的Linux版。

 

SQL> select * from v$version;

BANNER

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

Oracle Database 10g Release 10.2.0.4.0 - 64bit Production

PL/SQL Release 10.2.0.4.0 - Production

CORE 10.2.0.4.0 Production

TNS for Linux: Version 10.2.0.4.0 - Production

NLSRTL Version 10.2.0.4.0 - Production

 

2、故障問題展示

 

在巡檢中，發現記錄Oracle內部作業調度的視圖dba_scheduler_jobs不能支援查詢。

 

SQL> select * from dba_scheduler_jobs;

 

select * from dba_scheduler_jobs

ORA-01882: 未找到時區

 

1882錯誤的官方解釋資訊如下：

 

[oracle@allfirst ~]$ oerr ora 1882

01882, 00000, "timezone region %s not found"

// *Cause: The specified region name was not found.

// *Action: Please contact Oracle Customer Support.

 

但是，並不是所有的欄位都不支援查詢動作。

 

SQL> select owner, job_name from dba_scheduler_jobs;

 

OWNER                          JOB_NAME

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

SYS                            SQLSCRIPT_4084880

SYS                            AUTO_SPACE_ADVISOR_JOB

SYS                            GATHER_STATS_JOB

SYS                            FGR$AUTOPURGE_JOB

SYS                            PURGE_LOG

EXFSYS                        RLM$SCHDNEGACTION

EXFSYS                        RLM$EVTCLEANUP

ORACLE_OCM                    MGMT_STATS_CONFIG_JOB

ORACLE_OCM                    MGMT_CONFIG_JOB

 

9 rows selected

 

從欄位性質看，值得懷疑與時區有關的欄位是Time Zone。

 

SQL> select column_name, data_type from dba_tab_columns where owner='SYS' and table_name=upper('dba_scheduler_jobs') and data_type like '%TIME ZONE%';
 
 

COLUMN_NAME                    DATA_TYPE

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

START_DATE                    TIMESTAMP(6) WITH TIME ZONE

END_DATE                      TIMESTAMP(6) WITH TIME ZONE

LAST_START_DATE                TIMESTAMP(6) WITH TIME ZONE

NEXT_RUN_DATE                  TIMESTAMP(6) WITH TIME ZONE

 

但是，也並不是所有的time zone類型欄位都不能顯示。而且這樣的問題不止出現在這個視圖中。

 

 

SQL> select start_date from dba_scheduler_jobs;

START_DATE

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

19-3月 -12 05.48.23.742796 下午 +08:00

28-1月 -14 02.42.49.000000 下午 +08:00

13-5月 -13 07.40.35.640706 下午 +08:00

13-5月 -13 07.32.40.314879 下午 +08:00

 

9 rows selected

 

SQL> select * from SYS.scheduler$_job ;

select * from SYS.scheduler$_job

 

ORA-01882: 未找到時區

3、問題分析

從直觀看，應該是資料庫部分資料表中與timezone有關的數值出現問題造成的。

時區TimeZone在Oracle中不僅僅是一個環境變數，而且是融入到資料取值儲存過程中的。Oracle欄位類型中，與時區有關的欄位類型只有兩個：timestamp with time zone和timestamp with local time zone。
 
Oracle的時區是通過時區檔案來進行控制的，不同版本的資料庫，選擇不同版本的時區檔案。

 

SQL> select * from v$timezone_file;

FILENAME        VERSION

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

timezlrg.dat          4

 

一個經常發生的故障，是升級資料庫過程中，沒有升級time zone檔案。這樣導致升級失敗現象。Time Zone檔案是歸屬在DST技術體系下。10.2.0.2使用的是DST版本為DSTv2、10.2.0.3使用DSTv3、10.2.0.4使用DSTv4。從我們剛才的測試來看，使用的DST版本是正確的。
 
時區問題的另一個特點是伺服器、用戶端特性差異。如果需要確定是否是伺服器問題，需要直接到伺服器上執行命令。

 

[oracle@allfirst /]$ sqlplus /nolog

SQL*Plus: Release 10.2.0.4.0 - Production on 星期二 1月 28 14:54:51 2014

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

 

SQL> conn / as sysdba

已串連。

SQL> select * from dba_scheduler_jobs;

ERROR:

ORA-01882: 未找到時區地區 %s

 

說明是資料庫伺服器端問題。如果是用戶端問題，則需要及時升級用戶端版本。

一種猜想是：當Oracle進行版本升級的時候，使用資料庫時區檔案的確是升級了，但是對應的內部資料還沒有進行更新。這樣就存在不相容的問題。

在MOS中，我們也檢查到了對應的討論文章：Time Zone IDs for 7 Time Zones Changed in Time Zone Files Version 3 and Higher, Possible ORA-1882 After Upgrade (文檔 ID 414590.1)。
 
其中，介紹了使用檢查指令碼進行修複的解決方案。

更多詳情見請繼續閱讀下一頁的精彩內容：

1 2 下一頁