RMAN備份出現ORA-01801: date format is too long for internal buffer錯誤
ORACLE 10.2.0.2平臺上的基於物理DATAGUARD的備份失敗,檢視當時的日誌記錄,發現如下錯誤:
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03015: error occurred in stored script rman_level1_sc
RMAN-03002: failure of allocate command at 05/06/2008 02:00:20
RMAN-03014: implicit resync of recovery catalog failed
RMAN-03009: failure of partial resync command on default channel at 05/06/2008 02:00:20
ORA-01801: date format is too long for internal buffer
其中的rman_level1_sc是透過CATALOG執行增量備份的儲存指令碼的名稱
從錯誤提示看,肯定是和日期格式相關的,而且肯定是執行RESYNC CATALOG的時候出現的問題,於是手工登陸進去,執行RESYNC CATALOG命令來同步CATALOG,出現同樣的錯誤,,看來問題就出現在這裡了。GOOGLE了半天,發現有人()透過設定NLS_LANG=AMERICAN_AMERICA.AR8MSWIN1256成功解決了這個故障,嘗試設定環境變數來改變日期的格式,失敗。
METALINK上有人提到這個問題,不過最後的結果是它的歸檔日誌中出現了04/31/2007這樣的格式,要知道4月是根本沒有31號的,所以在同步catalog的時候這個日期不能夠插入到CATALOG庫中,所以導致的錯誤,這種情況有可能在主庫日誌傳輸到DATAGUARD的時候導致日期出現錯誤。可是我這裡發生問題的卻是08年的5月6號,而且歸檔日誌的日期也全部正確,看來此路不通了。連結如下:
最後還是回到了日期格式上,有文章中提到了是因為控制檔案中的日期格式和實際同步CATALOG的時候的格式不一致導致的(那個文章也沒有細說,也找不到那個連結了,抱歉),而且METALINK上分析出來的錯誤的日期也是從CONTROLFILE中得到的。最後乾脆把CONTROLFILE DUMP出來看看吧。
方法如下: 以SYSDBA身份登入SQL*PLUS
SQL> oradebug setmypid
SQL> oradebug dump controlf 3
將把control file dump到USER_DUMP_DEST初始化引數指定的目錄下。
其中3為dump level。 level的解釋如下:
1 :only the file header
2 :just the file header, the database info record, and checkpoint progress records
3 :all record types, but just the earliest and latest records for circular reuse record types
4 :as above, but includes the 4 most recent records for circular reuse record types
5+ :as above, but the number of circular reuse records included doubles with each level
把CONTROLFILE大致看了一遍,也沒有什麼異常的日期,但是格式卻有點不大一樣,因為我們習慣的設定日期為YYYY-MM-DD HH24:MI:SS形式,而且RMAN備份的時候使用的是環境變數中直接透過NLS_DATE_FORMAT來設定的格式,但是RMAN中卻記錄的都是MM/DD/YY HH24:MI:SS格式的資料,難道問題就出現在這裡??
手工設定NLS_DATE_FORMAT格式為CONTROLFILE中的格式,然後手工執行RESYNC CATALOG,居然就OK了,看來還真的是這個日期的格式在作怪,可是為什麼以前一致都是設定的NLS_DATE_FORMAT=YYYY-MM-DD HH24:MI:SS就備份了半年多了都沒有問題呢?其他人也碰到過一致這樣設定沒問題,可是後來卻出現問題的,一樣,沒有答案,好在問題解決了。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/25016/viewspace-1003500/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 【RMAN】Oracle12c之後,rman備份Dataguard備端恢復可能出現邏輯錯誤Oracle
- rman備份archivelog出現ORA-19625Hive
- SqlServer NBU備份出現錯誤程式碼2SQLServer
- 刪除大量檔案Argument list too long錯誤解決
- idea在使用git clone 時出現Filename too long的報錯資訊IdeaGit
- 【RMAN】在備庫執行rman備份時報錯RMAN-06820 ORA-17629
- Python錯誤:PyCharm 安裝出錯 Internal error,please。。。PythonPyCharmError
- 【RMAN】RMAN備份至ASMASM
- IntelliJ IDEA 執行專案的時候提示 Command line is too long 錯誤IntelliJIdea
- RMAN備份中發現壞塊
- data too long for column
- RMAN備份概述
- 【RMAN】RMAN的備份保留策略
- RMAN刪除歸檔日誌出現RMAN-0813錯誤的處理
- RMAN備份恢復典型案例——RMAN備份&系統變慢
- RMAN備份進度
- rman 備份指令碼指令碼
- RMAN的備份原理
- 針對python錯誤 format()PythonORM
- SQL Server 備份 出現作業系統錯誤 5(拒絕訪問。)SQLServer作業系統
- RMAN備份恢復技巧
- 【rman備份策略】實驗
- Oracle RMAN備份實戰Oracle
- Oracle OCP(60):RMAN 備份Oracle
- rman 增量備份恢復
- Spring Boot Intellij 執行應用的時候 Command line is too long. Shorten command line for 錯誤Spring BootIntelliJ
- Excel為批註設定圖片背景 出現Bad Request - Request Too longExcel
- HTTP 錯誤 500.19- Internal Server Error 錯誤解決方法HTTPServerError
- git拉取程式碼報錯filename too long unable to create fileGit
- 【RMAN】同時建立多個備份(建立多重備份)
- Error running ‘Application’Command line is too longErrorAPP
- RMAN 備份相關的概念
- [20190522]rman備份問題.txt
- RMAN備份異機恢復
- RMAN備份詳解(轉載)
- 使用RMAN備份資料庫資料庫
- 執行遷移檔案報錯 1071 Specified key was too long.
- MAN備份FORMAT格式中%的含義ORM