請教：NBU備份oracle報(bào)227錯(cuò)誤

無牙

原帖由 花和尚 于 2009-3-2 10:21 發(fā)表
或者這樣，看out文件已經(jīng)備份完datafile了，那么我是否可以把腳本分成兩個(gè)，一個(gè)備份datafile，一個(gè)備份archivelog和controlfile呢？
做完完全備份就直接備份archivelog和controlfile。當(dāng)時(shí)實(shí)施的時(shí)候就有切換 ...

如果是這樣，應(yīng)該和這兩個(gè)有關(guān)：
1.CLIENT_READ_TIMEOUT調(diào)大到3600。
3.DBWR_IO_SLAVES的設(shè)置？

花和尚

現(xiàn)在連不到客戶那邊，只能等晚上了。

第三條可不敢改哦，要停數(shù)據(jù)庫的吧，還不知道改了會有什么影響�？蛻裟沁叺臄�(shù)據(jù)庫是不能停的。只能改第一條試試了。


謝謝了!

[ 本帖最后由 花和尚 于 2009-3-2 14:33 編輯 ]

無牙

原帖由 花和尚 于 2009-3-2 14:32 發(fā)表
現(xiàn)在連不到客戶那邊，只能等晚上了。

第三條可不敢改哦，要停數(shù)據(jù)庫的吧，還不知道改了會有什么影響�？蛻裟沁叺臄�(shù)據(jù)庫是不能停的。只能改第一條試試了。


謝謝了!

只要看看第三條用的設(shè)置就行了，不需要改。

DBWR_IO_SLAVES 缺省是0，如果是這樣就沒關(guān)系了。如果不是0，則需要添加BACKUP_TAPE_IO_SLAVES = true。
但這只是建議，加不加還需要和用戶的DBA商量。

sqmax

原帖由 無牙 于 2009-3-2 14:55 發(fā)表


只要看看第三條用的設(shè)置就行了，不需要改。

DBWR_IO_SLAVES 缺省是0，如果是這樣就沒關(guān)系了。如果不是0，則需要添加BACKUP_TAPE_IO_SLAVES = true。
但這只是建議，加不加還需要和用戶的DBA商量。

DBWR_IO_SLAVES最好別動(dòng),起用異步IO未必能解決問題,開與不開不會報(bào)LZ的這個(gè)錯(cuò)誤;你現(xiàn)在CATALOG庫的版本和生產(chǎn)庫哪個(gè)高,CATALOG一定要高于或等于生產(chǎn)庫,再你再次進(jìn)行備份以前,你在RMAN中使用CROSSCHECK archivelog all,然后再進(jìn)行單獨(dú)的歸檔日志備份看一下.

花和尚

原帖由 無牙 于 2009-3-2 14:55 發(fā)表


只要看看第三條用的設(shè)置就行了，不需要改。

DBWR_IO_SLAVES 缺省是0，如果是這樣就沒關(guān)系了。如果不是0，則需要添加BACKUP_TAPE_IO_SLAVES = true。
但這只是建議，加不加還需要和用戶的DBA商量。

學(xué)習(xí)了，我晚上看看。謝謝！

花和尚

原帖由 sqmax 于 2009-3-2 15:08 發(fā)表


DBWR_IO_SLAVES最好別動(dòng),起用異步IO未必能解決問題,開與不開不會報(bào)LZ的這個(gè)錯(cuò)誤;你現(xiàn)在CATALOG庫的版本和生產(chǎn)庫哪個(gè)高,CATALOG一定要高于或等于生產(chǎn)庫,再你再次進(jìn)行備份以前,你在RMAN中使用CROSSCHECK arch ...

我剛才也查了DBWR_IO_SLAVES這個(gè)參數(shù)的資料，好像是如你所說；目前還沒有catalog；crosscheck archivelog 做過了，目前備份archivelog正常。

看來只能試試無牙兄的第一條辦法了。謝謝你們！

lostgamer

無牙老師的回答 看了學(xué)習(xí)了！

sqmax

原帖由 花和尚 于 2009-3-2 15:41 發(fā)表



我剛才也查了DBWR_IO_SLAVES這個(gè)參數(shù)的資料，好像是如你所說；目前還沒有catalog；crosscheck archivelog 做過了，目前備份archivelog正常。

看來只能試試無牙兄的第一條辦法了。謝謝你們！

我詳細(xì)看了一下你的備份腳本,發(fā)現(xiàn)這么幾句
   sql 'alter system archive log current';
#RELEASE CHANNEL ch00;
#RELEASE CHANNEL ch01;
# backup all archive logs
#ALLOCATE CHANNEL ch02 TYPE 'SBT_TAPE';
#ALLOCATE CHANNEL ch03 TYPE 'SBT_TAPE';

為什么把釋放通道和指派通道都注釋掉,讓每完成一個(gè)小的備份任務(wù)后自動(dòng)釋放通道,再下個(gè)任務(wù)開始前,再指派通道,按我說的方法把你的腳本修改一下

花和尚

原帖由 sqmax 于 2009-3-2 15:59 發(fā)表


我詳細(xì)看了一下你的備份腳本,發(fā)現(xiàn)這么幾句
   sql 'alter system archive log current';
#RELEASE CHANNEL ch00;
#RELEASE CHANNEL ch01;
# backup all archive logs
#ALLOCATE CHANNEL ch02 TYPE 'SB ...

之前是沒有注釋掉的，但備份失敗，就出在這次釋放完通道，再分配通道的時(shí)候報(bào)錯(cuò)；后來我把腳本分成兩個(gè)腳本，第一個(gè)腳本是保留backup database那部分，備份archivelog部分全部注釋掉，第二個(gè)腳本恰好相反，這樣設(shè)置過后備份OK；后來想想，既然是第二次分配通道的時(shí)候出錯(cuò)，那么我索性就不釋放，一直用這兩個(gè)通道備份下去不就行了？于是就出現(xiàn)了頂樓這個(gè)腳本。呵呵！一直用到上個(gè)月16號都正常的。17號他們調(diào)整過數(shù)據(jù)庫，后來就一直報(bào)錯(cuò)。227的錯(cuò)誤。

sqmax

原帖由 花和尚 于 2009-3-2 16:03 發(fā)表



之前是沒有注釋掉的，但備份失敗，就出在這次釋放完通道，再分配通道的時(shí)候報(bào)錯(cuò)；后來我把腳本分成兩個(gè)腳本，第一個(gè)腳本是保留backup database那部分，備份archivelog部分全部注釋掉，第二個(gè)腳本恰好相反 ...

有空的話把中間的部分,改成這樣試下
RUN {
ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE';
ALLOCATE CHANNEL ch01 TYPE 'SBT_TAPE';
send 'NB_ORA_CLIENT=p650_pre';
BACKUP
    $BACKUP_TYPE
    SKIP INACCESSIBLE
    TAG hot_db_bk_level0
    FILESPERSET 5
    ## recommended format
    FORMAT 'bk_%s_%p_%t'
    DATABASE;
    sql 'alter system archive log current';
RELEASE CHANNEL ch00;
RELEASE CHANNEL ch01;
RUN {
ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE';
ALLOCATE CHANNEL ch01 TYPE 'SBT_TAPE';
BACKUP
   filesperset 20
   FORMAT 'al_%s_%p_%t'
   ARCHIVELOG ALL DELETE INPUT;
RELEASE CHANNEL ch00;
RELEASE CHANNEL ch01;
RUN {
ALLOCATE CHANNEL ch00 TYPE disk;
BACKUP
#recommended format
   FORMAT 'cntrl_%s_%p_%t'
  CURRENT CONTROLFILE;
#copy
#    CURRENT CONTROLFILE to '/oracle/controlfile.ctl';
RELEASE CHANNEL ch00;
}

呵呵,我想看看這樣的話是否可以正常執(zhí)行