<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    談笑有鴻儒,往來無白丁

    在恰當(dāng)?shù)臅r間、地點(diǎn)以恰當(dāng)?shù)姆绞奖磉_(dá)給恰當(dāng)?shù)娜?..  閱讀的時候請注意分類,佛曰我日里面是談笑文章,其他是各個分類的文章,積極的熱情投入到寫博的隊伍中來,支持blogjava做大做強(qiáng)!向dudu站長致敬>> > 我的微博敬請收聽
    機(jī)房環(huán)境:
    OS:windows 2008
    數(shù)據(jù)庫版本:oracle 11g

    事件起因:

    昨天公司運(yùn)維說機(jī)房的HP服務(wù)器磁盤壞了,我當(dāng)時冷汗一下子就出來了,因為這是測試庫,沒有備份,沒有歸檔,但是里面可是有1.5T的數(shù)據(jù)啊,解決ORA-00600: <wbr>internal <wbr>error <wbr>code, <wbr>arguments: <wbr>[kcratr_nab_less_than_odr]錯誤下午他們修了一下午,系統(tǒng)可以進(jìn)去了,但是數(shù)據(jù)庫在啟動到OPEN的時候報錯SYSTEM01數(shù)據(jù)文件缺失一千多個數(shù)據(jù)塊,由于沒有備份和歸檔,所以這個數(shù)據(jù)庫是掛掉了。解決ORA-00600: <wbr>internal <wbr>error <wbr>code, <wbr>arguments: <wbr>[kcratr_nab_less_than_odr]錯誤(DBA們一定要做好備份,否則最后全是自己的事情),幸好我們還有一個一周前的冷備庫,所以我直接物理遷移,把數(shù)據(jù)庫恢復(fù)到一周以前了,恢復(fù)的過程非常簡單,因為數(shù)據(jù)庫必須的那些文件路徑都已存在(如參數(shù)文件內(nèi)的DUMP文件等),我只是把參數(shù)文件,密碼文件,控制文件,數(shù)據(jù)文件恢復(fù)到指定的目錄,然后直接STARTUP,在nomount和mount階段都是比較順利的,而到open階段的時候,則報錯了讓我鬧心的ORA-600ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr]的錯誤,因為大家都知道,ORA-600是數(shù)據(jù)庫自己內(nèi)部的BUG,我也是第一次遇到,問了很多人大家都不會,所以只能自己去摸索解決,值得慶幸的是在摸索了一個小時后,我終于把數(shù)據(jù)庫OPEN了,以下就是我恢復(fù)的步驟,如果感覺對您有所幫助,那么請支持我一下。解決ORA-00600: <wbr>internal <wbr>error <wbr>code, <wbr>arguments: <wbr>[kcratr_nab_less_than_odr]錯誤
    //報錯:ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [1], [1770], [779181], [779205], [], [], [], [], [], [], []
    //因為ORA-600的錯誤沒有具體提示,所以很多人無從下手,別著急,我們可以先去告警日志去看看,以下是我的告警日志信息:
    ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [1], [1770], [779181], [779205], [], [], [], [], [], [], [ 

    Incident details in: d:/app/administrator/diag/rdbms/ccxe/ccxe/incident/incdir_2570/ccxe_ora_2164_i2570.trc
    Aborting crash recovery due to error 600
    Errors in file d:/app/administrator/diag/rdbms/ccxe/ccxe/trace/ccxe_ora_2164.trc:
    ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [1], [1770], [779181], [779205], [], [], [], [], [], [], []
    Errors in file d:/app/administrator/diag/rdbms/ccxe/ccxe/trace/ccxe_ora_2164.trc:
    ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [1], [1770], [779181], [779205], [], [], [], [], [], [], []
    ORA-600 signalled during: alter database open...
    Tue May 10 10:13:10 2011
    Trace dumping is performing id=[cdmp_20110510101310]
    Tue May 10 10:13:11 2011
    Sweep [inc][2570]: completed
    Sweep [inc2][2570]: completed
    Tue May 10 10:29:52 2011
    Shutting down instance (immediate)
    Shutting down instance: further logons disabled

    //我們通過告警日志文件好像也沒查到什么有用的信息,別著急,我們還可以再查找對應(yīng)的TRC文件,我的對應(yīng)TRC文件則是ccxe_ora_2788_i2164.trc,以下是我的TRC信息

    WARNING! Crash recovery of thread 1 seq 1770 is

    ending at redo block 779181 but should not have ended before

    redo block 779205

    //看,有警告了,意思是我在恢復(fù)的時候,丟失了redo日志,當(dāng)時我很納悶,怎么會丟失redo呢?最后我把這個問題定位在傳輸redo的時候可能造成數(shù)據(jù)塊的丟失,因為我以前發(fā)生過這類事情,所以我重新拷貝redo日志,再次將數(shù)據(jù)庫啟動。

    Incident 3771 created, dump file: d:/app/administrator/diag/rdbms/ccxe/ccxe/incident/incdir_3771/ccxe_ora_2164_i3771.trc

    ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [1], [1770], [779181], [779205], [], [], [], [], [], [], []

    ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [1], [1770], [779181], [779205], [], [], [], [], [], [], []

    ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [1], [1770], [779181], [779205], [], [], [], [], [], [], []

    *** 2011-05-10 10:47:11.138

    Stopping background process MMNL

    *** 2011-05-10 10:47:12.139

    Stopping background process MMON

    *** 2011-05-10 10:47:13.259

    ksukia: Starting kill, flags = 1

    ksukia: killed 0 out of 0 processes.

    *** 2011-05-10 10:47:14.652

    *** 2011-05-10 10:47:14.652 4132 krsh.c

    ARCH: Archival disabled due to shutdown: 1089

    *** 2011-05-10 10:47:15.653

    *** 2011-05-10 10:47:15.653 4132 krsh.c

    ARCH: Archival disabled due to shutdown: 1089

    //重新拷貝redo日志到指定目錄,再次啟動數(shù)據(jù)庫。

    Total System Global Area 6413680640 bytes

    Fixed Size                  2187728 bytes

    Variable Size             754978352 bytes

    Database Buffers         5637144576 bytes

    Redo Buffers               19369984 bytes

    Database mounted.

    ORA-00338: log 4 of thread 1 is more recent than control file

    ORA-00312: online log 4 thread 1:

    'D:/APP/ADMINISTRATOR/ORADATA/CCXE/REDO04.LOG'

    //報錯果然不一樣了,這次報錯的意思是我的日志比我的控制文件新,要我恢復(fù)控制文件。
    SQL>  recover database using backup controlfile until cancel; 指定日志文件恢復(fù)

    Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

    D:/app/Administrator/oradata/CCXE/redo04.log

    ORA-00279: change 128488612 generated at 05/10/2011 11:13:52 needed for thread

    ORA-00289: suggestion :

    D:/APP/ADMINISTRATOR/FLASH_RECOVERY_AREA/CCXE/ARCHIVELOG/2011_05_10/O1_MF_1_1771_%U_.ARC

    ORA-00280: change 128488612 for thread 1 is in sequence #1771

    ORA-00278: log file 'D:/app/Administrator/oradata/CCXE/redo04.log' no longer

    needed for this recovery

    Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

    D:/app/Administrator/oradata/CCXE/redo05.log

    Log applied.

    Media recovery complete.

    SQL> alter database open; -必須以RESETLOGS方式打開數(shù)據(jù)庫

    alter database open

    ERROR at line 1:

    ORA-01589: must use RESETLOGS or NORESETLOGS option for database open

    SQL> alter database open RESETLOGS ;

    Database altered.


    OK,現(xiàn)在數(shù)據(jù)庫起來了,通過這次出錯我總結(jié)了幾點(diǎn),希望對大家有幫助

    1:數(shù)據(jù)庫不管是不是測試,都盡量備份,否則出問題哭都來不及。

    2:數(shù)據(jù)庫盡量歸檔,這樣就可以恢復(fù)數(shù)據(jù)庫在任何時刻。

    3:出錯時不要慌,要仔細(xì)查看報錯信息,分析報錯,根據(jù)自己所掌握的知識一步一步解決,當(dāng)你把問題解決

    時,你會發(fā)現(xiàn)排錯的過程真的是一個非常提升自己的過程。

    4:平常一定要有幾個在這方面很強(qiáng)的朋友,因為有的時候并不是自己查資料就能查到的,更多的是需要朋友的

    經(jīng)驗與幫助。

    注:以上就是這次錯誤的全部過程,過段時間我會把近期所遇到的錯誤都整理一下,都分享給大家,通過近期的工作我感覺數(shù)據(jù)庫真的是一個非常龐大的系統(tǒng),每次遇到新錯的時候我都會很郁悶的解決,因為我發(fā)現(xiàn)我的懂的還是太少了,學(xué)習(xí)畢竟是一個由點(diǎn)到線,由線到網(wǎng)的過程,一個問題由模糊到清晰,由清晰再模糊,反復(fù)來幾遍最終都會很明白的。我們要有清晰的理論知識,出錯的時候才會找到出題所在,作為一個DBA冷靜,清晰的頭腦也很重要,通過DBA的這個行業(yè),也是非常鍛煉自己的性格,希望大家都可以在DBA的這條職場之路,越走越遠(yuǎn),祝大家好運(yùn)。

    posted on 2015-03-20 15:08 壞男孩 閱讀(1372) 評論(0)  編輯  收藏 所屬分類: ORACLE篇章
    主站蜘蛛池模板: 亚洲第一精品电影网| 特色特黄a毛片高清免费观看| 杨幂最新免费特级毛片| 免费无码又爽又刺激一高潮| a毛片基地免费全部视频| 国产国拍精品亚洲AV片| 亚洲欧美自偷自拍另类视| 日本一道本不卡免费| 波多野结衣在线免费视频| 国产中文在线亚洲精品官网| 亚洲av无码久久忘忧草| a毛片在线免费观看| 国产又粗又猛又爽又黄的免费视频 | 美女视频黄频a免费观看| 亚洲高清视频免费| 久久精品国产亚洲综合色| 亚洲精品久久无码| 国产精品久久免费| 国产成人亚洲综合网站不卡| 免费人成在线观看69式小视频| 国产麻豆视频免费观看| 久久夜色精品国产噜噜亚洲a| 国产黄色免费观看| 全免费一级午夜毛片| 亚洲乱码卡三乱码新区| 91精品全国免费观看含羞草| 亚洲香蕉网久久综合影视| 一级毛片免费播放试看60分钟| 久久精品国产大片免费观看| 亚洲美女大bbbbbbbbb| 无码国产精品一区二区免费16 | 久久99国产综合精品免费| 亚洲黄色在线观看网站| 夭天干天天做天天免费看| 亚洲看片无码在线视频 | 特级毛片A级毛片100免费播放| 亚洲视频免费在线看| 国产精品亚洲lv粉色| 国产在线19禁免费观看国产| 97无码人妻福利免费公开在线视频| 免费永久在线观看黄网站|