最近新接手一套9i rac
因此開始要進行一堆翻修的動作。
當然第一個要做的就是備份。
9i之後的備份,已經不太去進行exp / imp的動作
原因是要花太多的時間,尤其是imp時還要注意許多schema與權限問題。
因此我一律採用Rman的備份。
不過今天要說的這套,因為有"前人"努力過,所以留下了一堆殘缺不全的內容。
在我備份完後,進行清除舊資料時,發現原先用磁帶備份的資料,會產生錯誤造成rman執行不完整。
delete force noprompt obsolete;
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of delete command at 06/26/2011 02:33:41
RMAN-06091: no channel allocated for maintenance (of an appropriate type)
怎麼刪都刪不掉,一直以為是因為之前備份是用tape,所以才備份失敗
所以改用:
configure device type 'sbt_tape' clear;
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' CLEAR;
想來清除與磁帶相關上的記錄
結果還是沒變。
一直到這個指令出現,才是正確解答(的一部份)
RMAN> delete noprompt obsolete device type disk;
RMAN retention policy will be applied to the command
RMAN retention policy is set to redundancy 1
released channel: ORA_DISK_1
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=588 devtype=DISK
Deleting the following obsolete backups and copies:
Type Key Completion Time Filename/Handle
-------------------- ------ ------------------ --------------------
Backup Set 15385 24-JUN-11
Backup Piece 15385 24-JUN-11 /oracle/dbs/c-1189594198-20110624-00
Datafile Copy 412 25-NOV-05 /dev/vx/rdsk/testdg/tools_50
Datafile Copy 413 25-NOV-05 /dev/vx/rdsk/testdg/index-his-30g
Datafile Copy 414 25-NOV-05 /dev/vx/rdsk/testdg/userdb_pacs_02_2048
Datafile Copy 415 25-NOV-05 /dev/vx/rdsk/testdg/userdb_his_10_10240
Datafile Copy 444 29-DEC-05 /dev/vx/rdsk/testdg/userdb_his_03_10240
Datafile Copy 445 29-DEC-05 /dev/vx/rdsk/testdg/userdb_his_04_10240
Datafile Copy 446 29-DEC-05 /dev/vx/rdsk/testdg/userdb_pacs_01_4096
Datafile Copy 447 29-DEC-05 /dev/vx/rdsk/testdg/userdb_his_05_10240
Datafile Copy 448 29-DEC-05 /dev/vx/rdsk/testdg/userdb_his_02_10240
Controlfile Copy 1267 02-MAY-08 /oracle/rscp/pacsctlbk.ctl
deleted backup piece
backup piece handle=/oracle/dbs/c-1189594198-20110624-00 recid=15385 stamp=754671617
deleted controlfile copy
controlfile copy filename=/oracle/rscp/pacsctlbk.ctl recid=1267 stamp=653691555
Deleted 2 objects
RMAN-06207: WARNING: 9 objects could not be deleted for DISK channel(s) due
RMAN-06208: to mismatched status. Use CROSSCHECK command to fix status
List of Mismatched objects
==========================
Object Type Filename/Handle
--------------- ---------------------------------------------------
Datafile Copy /dev/vx/rdsk/testdg/tools_50
Datafile Copy /dev/vx/rdsk/testdg/index-his-30g
Datafile Copy /dev/vx/rdsk/testdg/userdb_pacs_02_2048
Datafile Copy /dev/vx/rdsk/testdg/userdb_his_10_10240
Datafile Copy /dev/vx/rdsk/testdg/userdb_his_03_10240
Datafile Copy /dev/vx/rdsk/testdg/userdb_his_04_10240
Datafile Copy /dev/vx/rdsk/testdg/userdb_pacs_01_4096
Datafile Copy /dev/vx/rdsk/testdg/userdb_his_05_10240
Datafile Copy /dev/vx/rdsk/testdg/userdb_his_02_10240
哈,只刪了一個Control file,不過還好,至少沒有錯誤訊息了。
由於這個Device type disk 的提示,我後來就進行Crosscheck copy的找出已經失效檔案,再進行刪除記錄:
RMAN> delete noprompt obsolete device type disk;
RMAN retention policy will be applied to the command
RMAN retention policy is set to redundancy 1
released channel: ORA_DISK_1
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=588 devtype=DISK
Deleting the following obsolete backups and copies:
Type Key Completion Time Filename/Handle
-------------------- ------ ------------------ --------------------
Datafile Copy 412 25-NOV-05 /dev/vx/rdsk/testdg/tools_50
Datafile Copy 413 25-NOV-05 /dev/vx/rdsk/testdg/index-his-30g
Datafile Copy 414 25-NOV-05 /dev/vx/rdsk/testdg/userdb_pacs_02_2048
Datafile Copy 415 25-NOV-05 /dev/vx/rdsk/testdg/userdb_his_10_10240
Datafile Copy 444 29-DEC-05 /dev/vx/rdsk/testdg/userdb_his_03_10240
Datafile Copy 445 29-DEC-05 /dev/vx/rdsk/testdg/userdb_his_04_10240
Datafile Copy 446 29-DEC-05 /dev/vx/rdsk/testdg/userdb_pacs_01_4096
Datafile Copy 447 29-DEC-05 /dev/vx/rdsk/testdg/userdb_his_05_10240
Datafile Copy 448 29-DEC-05 /dev/vx/rdsk/testdg/userdb_his_02_10240
deleted datafile copy
datafile copy filename=/dev/vx/rdsk/testdg/tools_50 recid=412 stamp=575303261
deleted datafile copy
datafile copy filename=/dev/vx/rdsk/testdg/index-his-30g recid=413 stamp=575307628
deleted datafile copy
datafile copy filename=/dev/vx/rdsk/testdg/userdb_pacs_02_2048 recid=414 stamp=575313295
deleted datafile copy
datafile copy filename=/dev/vx/rdsk/testdg/userdb_his_10_10240 recid=415 stamp=575317535
deleted datafile copy
datafile copy filename=/dev/vx/rdsk/testdg/userdb_his_03_10240 recid=444 stamp=578337094
deleted datafile copy
datafile copy filename=/dev/vx/rdsk/testdg/userdb_his_04_10240 recid=445 stamp=578339270
deleted datafile copy
datafile copy filename=/dev/vx/rdsk/testdg/userdb_pacs_01_4096 recid=446 stamp=578340124
deleted datafile copy
datafile copy filename=/dev/vx/rdsk/testdg/userdb_his_05_10240 recid=447 stamp=578340816
deleted datafile copy
datafile copy filename=/dev/vx/rdsk/testdg/userdb_his_02_10240 recid=448 stamp=578342100
Deleted 9 objects
至此,問題終於解決了。
搜尋此網誌
星期六, 6月 25, 2011
星期四, 6月 09, 2011
資料庫調效經驗
今天的環境是:
Solaris 8 and Oracle 9.2.0.6 export / import to Linux 4 and Oracle 9.2.0.6
為一異質平台的轉換。
由於Oracle 9i 尚未支援Transportable Tablespace,因此只能依賴傳統的export / import。
問題反應:
1、某些資料查詢過於緩慢,較舊系統緩慢約3~4倍時間。
2、大量Procedure & Function 無法使用
分析過程:
1、利用Toad 的Monitor session的功能,在監控查詢時卡住的程序,並判斷是否有使到到Index
2、若有使用到Index的查詢時,系能仍緩慢,則開啟Trace來監控。
3、檢視procedure & Function 的Error messages
分析結果:
1、由於tables & indexes 沒有統計值,因此造成大量的Full Table Scan. 重新analyze 後,即完成。
2、有用到Index的查詢仍舊緩慢,經檢查後,發現使用到錯誤的indexes。 重新將table與index同時analyze後就恢復正常。
3、由於客戶有自行定義Function, 而這function又建立在其它的schema中,再加上原先有的public synonyms並未一併匯入進去(這點很怪),因此在重新建立 Synonyms後即完成任務。
另外的問題:
1、客戶某個table中,日期的存放格式為Month Varchar2(5), 以10005代表100年5月。在某支查詢中,會出現1722的錯誤 invalid number。
查看sql語法為to_number(month)>= :argument_1。因此去查詢table中的資料,發現有一筆的資料內容並非是數字,
因此造成字元轉換的錯誤。但…怪異的事,相同的語法在舊系統上仍可以查詢出來,真是怪哉呀。
最後把資料刪除後,程式即運作正常。
2、exp / imp 一般而言會有統計值,除非你在import 或 export 過程中,指定不匯出/ 匯入統計值,才會發生今天的問題。
3、Trace 檔沒用到,就解決了上述問題,下次再試試吧。
Solaris 8 and Oracle 9.2.0.6 export / import to Linux 4 and Oracle 9.2.0.6
為一異質平台的轉換。
由於Oracle 9i 尚未支援Transportable Tablespace,因此只能依賴傳統的export / import。
問題反應:
1、某些資料查詢過於緩慢,較舊系統緩慢約3~4倍時間。
2、大量Procedure & Function 無法使用
分析過程:
1、利用Toad 的Monitor session的功能,在監控查詢時卡住的程序,並判斷是否有使到到Index
2、若有使用到Index的查詢時,系能仍緩慢,則開啟Trace來監控。
3、檢視procedure & Function 的Error messages
分析結果:
1、由於tables & indexes 沒有統計值,因此造成大量的Full Table Scan. 重新analyze 後,即完成。
2、有用到Index的查詢仍舊緩慢,經檢查後,發現使用到錯誤的indexes。 重新將table與index同時analyze後就恢復正常。
3、由於客戶有自行定義Function, 而這function又建立在其它的schema中,再加上原先有的public synonyms並未一併匯入進去(這點很怪),因此在重新建立 Synonyms後即完成任務。
另外的問題:
1、客戶某個table中,日期的存放格式為Month Varchar2(5), 以10005代表100年5月。在某支查詢中,會出現1722的錯誤 invalid number。
查看sql語法為to_number(month)>= :argument_1。因此去查詢table中的資料,發現有一筆的資料內容並非是數字,
因此造成字元轉換的錯誤。但…怪異的事,相同的語法在舊系統上仍可以查詢出來,真是怪哉呀。
最後把資料刪除後,程式即運作正常。
2、exp / imp 一般而言會有統計值,除非你在import 或 export 過程中,指定不匯出/ 匯入統計值,才會發生今天的問題。
3、Trace 檔沒用到,就解決了上述問題,下次再試試吧。
星期日, 7月 18, 2010
訂閱:
文章 (Atom)
