任何軟體，特別是企業級系統元件的升級工作，是一個非常複雜的過程。升級路徑、資料留存預案、回退步驟、原有業務功能衝擊程度，都是需要反覆測試論證的問題。所有的運維人員在遇到升級問題的時候，都要抱有謹慎的態度。

筆者最近接手一個升級過的系統，在測試過程中遇到了一些問題。經過查詢MOS和網路資源加以解決。記錄下來，留待需要的朋友。

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

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)。

其中，介紹了使用檢查指令碼進行修復的解決方案。

4、問題解決

在MOS文章中，介紹了故障的解決方法，就是從中下載SQL指令碼Fix1882.sql，到介面上進行執行。

解壓之後，上傳到Server段的$ORACLE_HOME/rdbms/admin目錄下。注意：Oracle強烈推薦在服務端執行指令碼。

[oracle@allfirst /]$ cd $ORACLE_HOME

[oracle@allfirst 10g]$ cd rdbms/admin/

[oracle@allfirst admin]$ ls -l | grep Fix

-rw-r--r-- 1 root root 11278 01-28 14:58 Fix1882.sql

更換執行許可權。

[root@allfirst admin]# chown oracle:dba Fix1882.sql

[root@allfirst admin]# ls -l | grep Fix

-rw-r--r-- 1 oracle dba 11278 1月 28 14:58 Fix1882.sql

在SQLPLUS中執行程式。

[oracle@allfirst ~]$ sqlplus /nolog

SQL*Plus: Release 10.2.0.4.0 - Production on 星期二 1月 28 15:00:36 2014

SQL> conn / as sysdba

已連線。

SQL> @?/rdbms/admin/Fix1882.sql

PL/SQL 過程已成功完成。

會話已更改。

drop view FIX1882V

*

第 1 行出現錯誤:

ORA-00942: 表或檢視不存在

檢視已建立。

drop table FIX1882_PROGRESS *

第 1 行出現錯誤:

ORA-00942: 表或檢視不存在

表已建立。

drop table ADJUST_TZ_TAB

*

第 1 行出現錯誤:

ORA-00942: 表或檢視不存在

表已建立。

PL/SQL 過程已成功完成。

過程已建立。

ORA-1882 in SYS.SCHEDULER$_JOB(LAST_ENABLED_TIME), checking rows

Found ORA-1882 on SYS.SCHEDULER$_JOB(LAST_ENABLED_TIME): AAABPpAABAAACuiAAA

Row successfully modified: SYS.SCHEDULER$_JOB(LAST_ENABLED_TIME)

AAABPpAABAAACuiAAA

（篇幅原因，有省略……）

檢視已刪除。

執行過程需要消耗幾分鐘，從輸出資訊看，Oracle指令碼在檢查每個包括Time Zone相關欄位，進行修改處理。輸出資訊裡面還包括了資料行的rowid資訊。

執行之後，檢查資料行。

SQL> select last_start_date from dba_scheduler_jobs;

LAST_START_DATE

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

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

27-1月 -14 10.00.02.601102 下午 +08:00

27-1月 -14 10.00.02.619984 下午 +08:00

18-3月 -12 03.00.00.095899 上午 PST8PDT

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

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

01-1月 -14 01.01.01.097621 上午 +08:00

27-1月 -14 10.00.02.633247 下午 +08:00

9 rows selected

故障解決！

5、結論

升級故障是我們日常運維經常遇到的問題。一套系統進行升級，問題、故障是不能避免的。對我們而言，詳細的規劃和前期研究，反覆的測試實驗，可以最大程度的減少我們的風險和壓力。

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

相關文章