Oracle數(shù)據(jù)庫無響應(yīng)故障處理方式

Oracle數(shù)據(jù)庫無響應(yīng)故障處理方式

站在用戶的角度思考問題，與客戶深入溝通，找到陜州網(wǎng)站設(shè)計(jì)與陜州網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗(yàn)，讓設(shè)計(jì)與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個(gè)性化、用戶體驗(yàn)好的作品，建站類型包括：成都網(wǎng)站設(shè)計(jì)、網(wǎng)站制作、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣、域名注冊(cè)、虛擬主機(jī)、企業(yè)郵箱。業(yè)務(wù)覆蓋陜州地區(qū)。

Oracle數(shù)據(jù)庫無響應(yīng)故障，簡(jiǎn)單地講就是數(shù)據(jù)庫實(shí)例不能響應(yīng)客戶端發(fā)起的請(qǐng)求，客戶端提交一個(gè)SQL后，就一直處于等待數(shù)據(jù)庫實(shí)例返回結(jié)果的狀態(tài)。更嚴(yán)重的現(xiàn)象是客戶端根本不能連接到數(shù)據(jù)庫，發(fā)起一個(gè)連接請(qǐng)求后，一直處于等待狀態(tài)。Oracle數(shù)據(jù)庫無響應(yīng)故障怎么處理呢?下面跟我一起來學(xué)習(xí)Oracle數(shù)據(jù)庫無響應(yīng)故障的處理方法吧!

無響應(yīng)的故障現(xiàn)象一般有以下幾種：

1.Oracle的進(jìn)程在等待某個(gè)資源或事件

這種現(xiàn)象一般可以從V$SESSION_WAT、V$LATCH、V$LATCHHOLDER等動(dòng)態(tài)視圖中檢查進(jìn)程正在等待的資源或事件，而被等待的資源或事件，一直都不能被獲取，甚至是很長(zhǎng)時(shí)間都不可獲得。如果這個(gè)正在等待的進(jìn)程持有了其他的資源，則會(huì)引起其他的進(jìn)程等待，這樣就很可能引起實(shí)例中大范圍的會(huì)話發(fā)生等待。由于進(jìn)程在等待資源或事件時(shí)，通常都處于SLEEP狀態(tài)，消耗的CPU資源非常少(在等待latch時(shí)要稍微多消耗一些CPU資源)，所以從OS來看，CPU的消耗并不高，甚至是非常低。

這種因?yàn)榈却鸬膫€(gè)別進(jìn)程Hang，相對(duì)比較容易處理。

2. OracleProcess Spins

所謂Spin，就是指Oracle進(jìn)程中的代碼在執(zhí)行某個(gè)過程時(shí)，陷入了循環(huán)。在V$SESSION視圖中，往往可以看到Hang住的會(huì)話，一直處于“ACTIVE”狀態(tài)。對(duì)于這樣的會(huì)話，用“alter system kill session ‘sid,serial#’”命令也不能完全斷開會(huì)話，會(huì)話只能被標(biāo)記為“killed”，會(huì)話會(huì)繼續(xù)消耗大量的CPU。進(jìn)程Spins由于是在做循環(huán)，CPU的消耗非常大，從OS上明顯可以看到這樣的進(jìn)程，通常會(huì)消耗整個(gè)CPU的資源。

而對(duì)于這樣的Hang住的會(huì)話，處理起來相對(duì)比較復(fù)雜，并且為了從根本上解決問題，需要超過DBA日常維護(hù)所需要的技能。

從故障范圍來看，無響應(yīng)故障可以分為以下幾種情況：

1. 單個(gè)或部分會(huì)話(進(jìn)程)Hang住

這種情況屬于小范圍的故障，業(yè)務(wù)影響相對(duì)較小，一般來說只會(huì)影響業(yè)務(wù)系統(tǒng)的個(gè)別模塊。在一個(gè)多應(yīng)用系統(tǒng)的數(shù)據(jù)庫上面，如果Hang住的會(huì)話比較多，則影響的可能是其中的一個(gè)應(yīng)用系統(tǒng)。這里有一個(gè)例外，如果Hang住的進(jìn)程是系統(tǒng)后臺(tái)進(jìn)程，如pmon、smon等，則影響的范圍就非常大了，最終甚至?xí)绊懻麄€(gè)數(shù)據(jù)庫及所有應(yīng)用系統(tǒng)。還有值得注意的是，即使是少部分會(huì)話Hang住，也要及時(shí)處理，否則極有可能會(huì)擴(kuò)散到整個(gè)系統(tǒng)。

2. 單個(gè)數(shù)據(jù)庫實(shí)例Hang住

這種情況造成的影響非常大。在這個(gè)實(shí)例上的所有應(yīng)用系統(tǒng)均受到嚴(yán)重影響，并且在找到根源并最終解決問題之前，數(shù)據(jù)庫實(shí)例往往須要重啟。

3. OPS或RAC中的多個(gè)實(shí)例或所有實(shí)例都Hang住

在這種情況下，即使是OPS或RAC，都已經(jīng)沒辦法提供高可用特性了。使用這個(gè)數(shù)據(jù)庫的所有應(yīng)用系統(tǒng)將不能繼續(xù)提供服務(wù)，這種情況往往須要重啟。

無響應(yīng)故障成因分析

Oracle數(shù)據(jù)庫無響應(yīng)，一般主要由以下幾種原因引起：

1. 數(shù)據(jù)庫主機(jī)負(fù)載過高，嚴(yán)重超過主機(jī)承受能力

比如應(yīng)用設(shè)計(jì)不當(dāng)，數(shù)據(jù)庫性能低下，活動(dòng)會(huì)話數(shù)的大量增加，導(dǎo)致數(shù)據(jù)庫主機(jī)的負(fù)載迅速增加，數(shù)據(jù)庫不能正常操作，并最終Hang住;主機(jī)物理內(nèi)存嚴(yán)重不足，引起大量的換頁，特別是在SGA中的內(nèi)存被大量換出到虛擬內(nèi)存時(shí)，數(shù)據(jù)庫實(shí)例往往就會(huì)Hang住。

2. 日常維護(hù)不當(dāng)、不正確的操作引起數(shù)據(jù)庫Hang住

比如歸檔日志的存儲(chǔ)空間滿，導(dǎo)致數(shù)據(jù)庫不能歸檔，引起數(shù)據(jù)庫Hang住;在一個(gè)大并發(fā)的繁忙的系

統(tǒng)上，對(duì)DML操作比較多的大表進(jìn)行move、增加外鍵約束等操作也可能使系統(tǒng)在短時(shí)間內(nèi)負(fù)載大幅升高，并引起數(shù)據(jù)庫系統(tǒng)Hang住;不正確的資源計(jì)劃(Resource Plan)配置，使進(jìn)程得不到足夠的CPU等。

3. Oracle數(shù)據(jù)庫的Bug

幾乎每個(gè)版本都存在著會(huì)導(dǎo)致數(shù)據(jù)庫系統(tǒng)Hang住的Bug，這些Bug會(huì)在一些特定的條件下觸發(fā)，特別是在RAC數(shù)據(jù)庫中，引起數(shù)據(jù)庫Hang住的Bug比較多。

4. 其他方面的一些原因

比如在RAC數(shù)據(jù)庫中，如果一個(gè)節(jié)點(diǎn)退出或加入到RAC的過程中，當(dāng)進(jìn)行Resource Reconfiguration時(shí)，會(huì)使系統(tǒng)凍結(jié)一段時(shí)間，也有可能使系統(tǒng)Hang住。

以上所描述的幾種常見的會(huì)導(dǎo)致Oracle數(shù)據(jù)庫實(shí)例Hang住的原因中，大部分的情況是可以避免的，只要維護(hù)得當(dāng)，一般不會(huì)出現(xiàn)這種故障。對(duì)于Oracle數(shù)據(jù)庫Bug所導(dǎo)致的數(shù)據(jù)庫無響應(yīng)故障，由于是在特定的情況下才會(huì)觸發(fā)，所以如果能夠盡量對(duì)數(shù)據(jù)庫打上最新版本的補(bǔ)丁，并且熟悉當(dāng)前版本中會(huì)導(dǎo)致系統(tǒng)Hang住的Bug以及觸發(fā)條件，就能夠最大限度地避免這種故障的發(fā)生，提高系統(tǒng)的可用性。

那么，在數(shù)據(jù)庫Hang住的情況下，如何去分析并發(fā)現(xiàn)導(dǎo)致問題的根源?一方面，由于系統(tǒng)Hang住會(huì)導(dǎo)致業(yè)務(wù)系統(tǒng)不可用，為了能夠盡快地恢復(fù)業(yè)務(wù)，須快速地判斷問題所在，然后Kill掉引起故障的會(huì)話和進(jìn)程，或者數(shù)據(jù)庫實(shí)例不得不重啟以迅速恢復(fù)業(yè)務(wù);但另一方面，如果只是重啟數(shù)據(jù)庫或Kill會(huì)話和進(jìn)程來解決問題，在很多情況下是治標(biāo)不治本的辦法，在以后故障隨時(shí)可能會(huì)出現(xiàn)。如何在二者之間進(jìn)行抉擇呢?對(duì)于數(shù)據(jù)庫Hang故障的處理，首先是盡可能地收集到系統(tǒng)Hang住時(shí)的狀態(tài)數(shù)據(jù)，然后盡快地恢復(fù)業(yè)務(wù)，恢復(fù)業(yè)務(wù)后分析收集到的數(shù)據(jù)，找到數(shù)據(jù)庫系統(tǒng)Hang住的真正原因，然后再進(jìn)行相應(yīng)的處理。下一節(jié)將詳細(xì)描述數(shù)據(jù)庫系統(tǒng)Hang住后的處理流程。

無響應(yīng)故障處理流程

對(duì)于Oracle無響應(yīng)故障的處理，我們可以按下圖所示的流程進(jìn)行。

值得注意的是，上圖并不是一個(gè)完整的Oracle數(shù)據(jù)庫故障處理流程圖，只是處理Oralce數(shù)據(jù)庫無響應(yīng)這一類特定的故障的流程，只列出了針對(duì)這一特定類型故障處理時(shí)的關(guān)鍵處理點(diǎn)。不過既然是故障，所以這類故障的處理流程與其他故障的處理流程，有著非常相似的地方。

下面是整個(gè)流程的詳細(xì)說明：

1. 在出現(xiàn)數(shù)據(jù)庫無響應(yīng)故障后，首先確認(rèn)系統(tǒng)的影響范圍，如上節(jié)所描述的'，是部分業(yè)務(wù)系統(tǒng)或模塊還是所有的業(yè)務(wù)系統(tǒng)都受影響，是不是整個(gè)實(shí)例或多個(gè)實(shí)例都無響應(yīng)。同時(shí)應(yīng)詢問系統(tǒng)維護(hù)和開發(fā)人員，受影響的系統(tǒng)在出現(xiàn)故障前是否有過變動(dòng)，包括主機(jī)硬件、操作系統(tǒng)、網(wǎng)絡(luò)、數(shù)據(jù)庫以及應(yīng)用等。有時(shí)一個(gè)細(xì)小的變動(dòng)就可能導(dǎo)致出現(xiàn)數(shù)據(jù)庫Hang住這樣嚴(yán)重的故障。曾經(jīng)遇到一個(gè)庫，應(yīng)用只是修改了一個(gè)SELECT語句就導(dǎo)致了數(shù)據(jù)庫Hang住。

2. 為了避免由于網(wǎng)絡(luò)、數(shù)據(jù)庫監(jiān)聽或客戶端因素影響分析，建議都登錄到主機(jī)上進(jìn)行操作。

3. 如果主機(jī)不能登錄(為了避免干擾流程主線，這里不討論如網(wǎng)絡(luò)問題這樣也會(huì)導(dǎo)致不能連接的故障)，嘗試關(guān)閉出現(xiàn)問題的業(yè)務(wù)系統(tǒng)，甚至是所有的業(yè)務(wù)系統(tǒng)。如果關(guān)閉了所有的業(yè)務(wù)系統(tǒng)之后，仍然不能連接，則只有考慮重新啟動(dòng)數(shù)據(jù)庫主機(jī)。在數(shù)據(jù)庫主機(jī)重新啟動(dòng)后，使用操作系統(tǒng)工具或OSW等長(zhǎng)期監(jiān)控操作系統(tǒng)的資源使用，同時(shí)監(jiān)控Oracle數(shù)據(jù)庫的性能和等待等。

4. 登錄上主機(jī)后，先用top、topas等命令簡(jiǎn)單觀察一下系統(tǒng)?？纯聪到y(tǒng)的CPU使用、物理內(nèi)存和虛擬內(nèi)存的使用、IO使用等情況。

5. 使用SQLPLUS連接數(shù)據(jù)庫，如果不能連接，則只能從操作系統(tǒng)上觀察系統(tǒng)中是否有異常的現(xiàn)象，比如占用CPU過高的進(jìn)程。使用gdb、dbx等debugger工具對(duì)數(shù)據(jù)庫進(jìn)行system state dump;使用strace、truss等工具檢查異常進(jìn)程的系統(tǒng)調(diào)用;使用pstack、procstack等工具察看異常進(jìn)程的call stack等。

6. 使用SQLPLUS連接上數(shù)據(jù)庫后，進(jìn)行hanganalyze、system state dump等操作;或檢查等待事件、異常會(huì)話等正在執(zhí)行的SQL等待。

7. 找到故障產(chǎn)生的原因，如果暫時(shí)找不到原因，盡量收集數(shù)據(jù)。

8.確良如果應(yīng)用急須恢復(fù)，可通過Kill會(huì)話、重啟數(shù)據(jù)庫實(shí)例等方式，先恢復(fù)應(yīng)用。

9. 根據(jù)最終診斷結(jié)果，對(duì)數(shù)據(jù)庫升級(jí)打補(bǔ)丁，或者修改應(yīng)用等方式從根本上解決問題。

怎樣避免數(shù)據(jù)庫出現(xiàn)無響應(yīng)故障

作為Oracle數(shù)據(jù)庫DBA，除了處理故障之外，更重要的是如何預(yù)防故障的發(fā)生。根據(jù)前面對(duì)數(shù)據(jù)庫無響應(yīng)故障的成因分析，在日常的維護(hù)工作中，須做到以下幾點(diǎn)：

1. 進(jìn)行正確的維護(hù)操作

很多的數(shù)據(jù)庫無響應(yīng)故障都是由于不正確的維護(hù)操作引起的。應(yīng)避免在業(yè)務(wù)高峰期做大的維護(hù)操作，比如像move、加主外鍵約束等會(huì)長(zhǎng)時(shí)間鎖表的操作。如果的確需要，盡量使用正確的操作方法。比如用ONLINE方式重建索引;建主鍵、唯一鍵約束時(shí)先建索引，然后在建約束時(shí)指定新建的索引，等等。也就是保證系統(tǒng)的并發(fā)性、可伸縮性，避免系統(tǒng)串行操作的出現(xiàn)。

2. 優(yōu)化應(yīng)用設(shè)計(jì)，優(yōu)化數(shù)據(jù)庫性能

為避免性能問題導(dǎo)致在業(yè)務(wù)高峰期數(shù)據(jù)庫不能及時(shí)有效處理來自業(yè)務(wù)的請(qǐng)求，甚至于完全Hang住。對(duì)于數(shù)據(jù)庫中存在串行訪問的部分進(jìn)行優(yōu)化，比如latch、enqueue，還包括不合理的sequence設(shè)計(jì)等。特別是在RAC數(shù)據(jù)庫中，嚴(yán)重串行訪問等待往往更容易引起嚴(yán)重的性能問題。優(yōu)化應(yīng)用設(shè)計(jì)，使數(shù)據(jù)庫具有更好的可伸縮性和并行處理能力，能夠有效地避免性能問題引起的數(shù)據(jù)庫Hang住。

3. 利用監(jiān)控系統(tǒng)隨時(shí)監(jiān)控系統(tǒng)負(fù)載

遇到系統(tǒng)負(fù)載過高，內(nèi)存不足，OS中虛擬內(nèi)存換頁很頻繁等情況時(shí)，及時(shí)采取措施;監(jiān)控Oracle數(shù)據(jù)庫的核心進(jìn)程，如pmon、smon等，看是否有異常，如過高的CPU消耗。出現(xiàn)異常應(yīng)立即處理;監(jiān)控歸檔空間和日志切換;監(jiān)控?cái)?shù)據(jù)庫中的等待事件，比如是否有大量的enqueue、log file switch (archiving needed)、resmgr:become active等待事件等。

4. 為數(shù)據(jù)庫打上補(bǔ)丁

很多的無響應(yīng)故障是由于Oracle的Bug引起的，數(shù)據(jù)庫DBA應(yīng)關(guān)注當(dāng)前版本中有哪些Bug會(huì)導(dǎo)致數(shù)據(jù)庫Hang住，盡量為數(shù)據(jù)庫打上解決這些Bug的補(bǔ)丁。

;

oracle出現(xiàn)壞塊怎么解決

oracle數(shù)據(jù)庫的壞塊問題是個(gè)讓人比較頭痛的問題，主要分為邏輯壞塊和物理壞塊，邏輯壞塊就是數(shù)據(jù)文件里的邏輯關(guān)系出現(xiàn)的混亂，這一般是由于數(shù)據(jù)庫的BUG導(dǎo)致的。物理壞塊就是數(shù)據(jù)文件中的數(shù)據(jù)不存在任何意義，沒有任何邏輯和結(jié)構(gòu)，造成物理壞塊多因?yàn)榉?wù)器IO系統(tǒng)故障導(dǎo)致的。

Oracle數(shù)據(jù)庫打不開 該怎么辦？我們公司的oracle數(shù)據(jù)庫壞了 打不開了，該如何處理？

如果自己搞不定可以找詩檀軟件專業(yè)ORACLE數(shù)據(jù)庫修復(fù)團(tuán)隊(duì)成員幫您恢復(fù)!

詩檀軟件專業(yè)數(shù)據(jù)庫修復(fù)團(tuán)隊(duì)

Oracle的損壞/壞塊 主要分以下幾種：

ORA-1578

ORA-8103

ORA-1410

ORA-1499

ORA-1578

ORA-81##

ORA-14##

ORA-26040

ORA-600 Errors

Block Corruption

Index Corruption

Row Corruption

UNDO Corruption

Control File

Consistent Read

Dictionary

File/RDBA/BL

Error Description Corruption related to:

ORA-1578 ORA-1578一般為Oracle檢測(cè)到存在物理壞塊問題，包括其檢測(cè)數(shù)據(jù)塊中的checksum不正確，或者tail_chk信息不正確等。 ORA-1578 is reported when a block is thought to be corrupt on read.

Block

數(shù)據(jù)塊

OERR: ORA-1578 “ORACLE data block corrupted (file # %s, block # %s)” Master Note

OERR: ORA-1578 “ORACLE data block corrupted (file # %s, block # %s)”

Fractured Block explanation

Handling Oracle Block Corruptions in Oracle7/8/8i/9i/10g/11g

Diagnosing and Resolving 1578 reported on a Local Index of a Partitioned table

ORA-1410

ORA-1410錯(cuò)誤常見于從INDEX或其他途徑獲得的ROWID,到數(shù)據(jù)表中查詢發(fā)現(xiàn)沒有對(duì)應(yīng)的記錄。

該錯(cuò)誤可能因?yàn)閿?shù)據(jù)表與其索引存在不一致，也可能是分區(qū)的數(shù)據(jù)表本身存在問題。

This error is raised when an operation refers to a ROWID in a table for which there is no such row.

The reference to a ROWID may be implicit from a WHERE CURRENT OF clause or directly from a WHERE ROWID=… clause.

ORA 1410 indicates the ROWID is for a BLOCK that is not part of this table.

Row

數(shù)據(jù)行

Understanding The ORA-1410

Summary Of Bugs Containing ORA 1410

OERR: ORA 1410 “invalid ROWID”

ORA-8103

該ORA-8103可能由多個(gè)BUG引起，例如LOB在10.2.0.4之前可能會(huì)由于BUG覆蓋了另一張表的segment header，導(dǎo)致出現(xiàn)ORA-8103錯(cuò)誤。

診斷該問題可以從數(shù)據(jù)表的segment header和data_object_id入手。

The object has been deleted by another user since the operation began.

If the error is reproducible, following may be the reasons:-

a.) The header block has an invalid block type.

b.) The data_object_id (seg/obj) stored in the block is different than the data_object_id stored in the segment header. See dba_objects.data_object_id and compare it to the decimal value stored in the block (field seg/obj).

Block

數(shù)據(jù)塊

ORA-8103 Troubleshooting, Diagnostic and Solution

OERR: ORA-8103 “object no longer exists” / Troubleshooting, Diagnostic and Solution

ORA-8102 ORA-8102常見于索引鍵值與表上存的值不一致。 An ORA-08102 indicates that there is a mismatch between the key(s) stored in the index and the values stored in the table. What typically happens is the index is built and at some future time, some type of corruption occurs, either in the table or index, to cause the mismatch.

Index

索引

OERR ORA-8102 “index key not found, obj# %s, file %s, block %s (%s)

ORA-1499 對(duì)表和索引做交叉驗(yàn)證時(shí)發(fā)現(xiàn)問題 An error occurred when validating an index or a table using the ANALYZE command.

One or more entries does not point to the appropriate cross-reference.

Index

索引

ORA-1499. Table/Index row count mismatch

OERR: ORA-1499 table/Index Cross Reference Failure – see trace file

ORA-1498 Generally this is a result of an ANALYZE … VALIDATE … command.

This error generally manifests itself when there is inconsistency in the data/Index block. Some of the block check errors that may be found:-

a.) Row locked by a non-existent transaction

b.) The amount of space used is not equal to block size

c.) Transaction header lock count mismatch.

While support are processing the tracefile it may be worth the re-running the ANALYZE after restarting the database to help show if the corruption is consistent or if it ‘moves’.

Send the tracefile to support for analysis.

If the ANALYZE was against an index you should check the whole object. Eg: Find the tablename and execute:

ANALYZE TABLE xxx VALIDATE STRUCTURE CASCADE; Block

OERR: ORA 1498 “block check failure – see trace file”

ORA-26040 由于采用過nologging/unrecoverable選項(xiàng)的redo生成機(jī)制，且做過對(duì)應(yīng)的recover，導(dǎo)致數(shù)據(jù)塊中被填滿了0XFF，導(dǎo)致報(bào)錯(cuò)ORA-26040。 Trying to access data in block that was loaded without redo generation using the NOLOGGING/UNRECOVERABLE option.

This Error raises always together with ORA-1578

Block

數(shù)據(jù)塊

OERR ORA-26040 Data block was loaded using the NOLOGGING option

ORA-1578 / ORA-26040 Corrupt blocks by NOLOGGING – Error explanation and solution

ORA-1578 ORA-26040 in a LOB segment – Script to solve the errors

ORA-1578 ORA-26040 in 11g for DIRECT PATH with NOARCHIVELOG even if LOGGING is enabled

ORA-1578 ORA-26040 On Awr Table

Errors ORA-01578, ORA-26040 On Standby Database

Workflow Tables ORA-01578 ORACLE data block corrupted ORA-26040 Data block was loaded using the NOLOGGING option

ORA-1578, ORA-26040 Data block was loaded using the NOLOGGING option

ORA-600[12700]

從索引獲得的ROWID，對(duì)應(yīng)到數(shù)據(jù)表時(shí)發(fā)現(xiàn)不存在數(shù)據(jù)行錯(cuò)誤。

一把是一致性度consistent read問題

Oracle is trying to access a row using its ROWID, which has been obtained from an index.

A mismatch was found between the index rowid and the data block it is pointing to. The rowid points to a non-existent row in the data block. The corruption can be in data and/or index blocks.

ORA-600 [12700] can also be reported due to a consistent read (CR) problem.

Consistent Read

一致性讀

Resolving an ORA-600 [12700] error in Oracle 8 and above.

ORA-600 [12700] “Index entry Points to Missing ROWID”

ORA-600[3020] 主要問題是redo和數(shù)據(jù)塊中的信息不一致 This is called a ‘STUCK RECOVERY’.

There is an inconsistency between the information stored in the redo and the information stored in a database block being recovered. Redo

ORA-600 [3020] “Stuck Recovery”

Information Required for Root Cause Analysis of ORA-600 [3020] (stuck recovery)

ORA-600[4194] 主要是redo記錄與回滾rollback/undo的記錄不一致 A mismatch has been detected between Redo records and rollback (Undo) records.

We are validating the Undo record number relating to the change being applied against the maximum undo record number recorded in the undo block.

This error is reported when the validation fails. Undo

ORA-600 [4194] “Undo Record Number Mismatch While Adding Undo Record”

Basic Steps to be Followed While Solving ORA-00600 [4194]/[4193] Errors Without Using Unsupported parameter

ORA-600[4193] 主要是redo記錄與回滾rollback/undo的記錄不一致 A mismatch has been detected between Redo records and Rollback (Undo) records.

We are validating the Undo block sequence number in the undo block against the Redo block sequence number relating to the change being applied.

This error is reported when this validation fails. Undo

ORA-600 [4193] “seq# mismatch while adding undo record”

Basic Steps to be Followed While Solving ORA-00600 [4194]/[4193] Errors Without Using Unsupported parameter

Ora-600 [4193] When Opening Or Shutting Down A Database

ORA-600 [4193] When Trying To Open The Database

ORA-600[4137] transaction id不匹配，問題可能存在與回滾段中或者對(duì)象本身存在訛誤 While backing out an undo record (i.e. at the time of rollback) we found a transaction id mis-match indicating either a corruption in the rollback segment or corruption in an object which the rollback segment is trying to apply undo records on.

This would indicate a corrupted rollback segment. Undo/Redo

ORA-600 [4137] “XID in Undo and Redo Does Not Match”

ORA-600[6101] Not enough free space was found when inserting a row into an index leaf block during the application of undo. Index

ORA-600 [6101] “insert into leaf block (undo)”

ORA-600[2103] Oracle is attempting to read or update a generic entry in the control file.

If the entry number is invalid, ORA-600 [2130] is logged. Control File

ORA-600 [2130] “Attempt to access non-existant controlfile entry”

ORA-600[4512] Oracle is checking the status of transaction locks within a block.

If the lock number is greater than the number of lock entries, ORA-600 [4512] is reported followed by a stack trace, process state and block dump.

This error possibly indicates a block corruption. Block

ORA-600 [4512] “Lock count mismatch”

ORA-600[2662] 主要是發(fā)現(xiàn)一個(gè)數(shù)據(jù)塊的SCN甚至超過了當(dāng)前SCN，常規(guī)解決途徑有調(diào)整SCN等，但11.2以后Oracle公司使較多調(diào)整SCN的方法失效了 A data block SCN is ahead of the current SCN.

The ORA-600 [2662] occurs when an SCN is compared to the dependent SCN stored in a UGA variable.

If the SCN is less than the dependent SCN then we signal the ORA-600 [2662] internal error. Block

ORA-600 [2662] “Block SCN is ahead of Current SCN”

ORA 600 [2662] DURING STARTUP

ORA-600[4097] 訪問一個(gè)回滾段頭以便確認(rèn)事務(wù)是否已提交時(shí)，發(fā)現(xiàn)XID有問題 We are accessing a rollback segment header to see if a transaction has been committed.

However, the xid given is in the future of the transaction table.

This could be due to a rollback segment corruption issue OR you might be hitting the following known problem. Undo

oracle asm reblance時(shí)，壞塊怎么處理

ASM 實(shí)例的創(chuàng)建和刪除也可以用DBCA 這個(gè)命令來操作。

在dbca 的第一個(gè)界面選擇配置自動(dòng)存儲(chǔ)管理就可以了。

ASM 實(shí)例需要CSS 進(jìn)程， 如果是非RAC 環(huán)境， 在啟動(dòng)ASM 實(shí)例之前會(huì)提示用腳本 $ORACLE_HOME/bin/localconfig add 啟動(dòng)CSS。

一道面試題：遇到大規(guī)模Oracle壞塊該怎么處理

遇到大規(guī)模oracle壞塊，進(jìn)行評(píng)估恢復(fù)壞塊的時(shí)間。如果時(shí)間過長(zhǎng)。直接切換到備庫或者做恢復(fù)。盡量使停產(chǎn)的時(shí)間短些。

參考：

http://

bbs.csdn.net/topics/391956183

遇到大規(guī)模oracle壞塊該怎么處理

最近一兩個(gè)月，一直有場(chǎng)景化運(yùn)維、場(chǎng)景化大數(shù)據(jù)分析的聲音圍繞在耳畔，以Gdevops全球敏捷運(yùn)維峰會(huì)杭州站上新炬網(wǎng)絡(luò)執(zhí)行副總裁程永新的“ 一切沒有場(chǎng)景驅(qū)動(dòng)的運(yùn)維平臺(tái)建設(shè)都是假大空！ ”最為振聾發(fā)聵。我們一直在談技術(shù)，談原理，談內(nèi)核，總以為“懂了”這些的人，就勢(shì)必能廣闊天地大有所為。

技術(shù)固然重要，但偏離了業(yè)務(wù)/應(yīng)用場(chǎng)景的技術(shù)，無法呈現(xiàn)業(yè)務(wù)價(jià)值的技術(shù)就非常不重要。

技術(shù)也應(yīng)該是場(chǎng)景驅(qū)動(dòng)的，對(duì)于運(yùn)維技術(shù)人員來說，離開場(chǎng)景學(xué)習(xí)的所謂高深技術(shù)，只是浪費(fèi)時(shí)間。所以新同事進(jìn)入一個(gè)新團(tuán)隊(duì)后，能使技術(shù)更好發(fā)揮作用的環(huán)境、流程的考核會(huì)占據(jù)了另外的三分之二。

今天來談?wù)凮racle壞塊問題。 壞塊問題，相信做過兩三年Oracle維護(hù)、支持的DBA都會(huì)遇到過，即使從來沒遇到過的，看過Oracle 官方文檔的甚至是會(huì)度娘或者谷哥的，應(yīng)該也知道基本的處理手段。

這是我內(nèi)部分享的一個(gè)簡(jiǎn)單思維導(dǎo)圖，如果有遺漏，歡迎在后面評(píng)論補(bǔ)充。

面試的時(shí)候通常是這么問的：你了解Oracle壞塊么？壞塊為什么會(huì)產(chǎn)生？描述一下你處理過的壞塊案例細(xì)節(jié)？如果你負(fù)責(zé)的好幾個(gè)數(shù)據(jù)庫都突然發(fā)生了壞塊，你會(huì)怎么做？

通常，前面幾個(gè)問題的回答都不會(huì)太差。但是最后一個(gè)問題的回答，鮮有能出眾的。原因在于面太窄，思維太窄。如果這個(gè)時(shí)候你還要一個(gè)個(gè)庫的去看alert日志，那么顯然就走錯(cuò)了方向。

現(xiàn)實(shí)情況就是，我們的數(shù)據(jù)庫可能是五六十套，或者上百套，你一套套庫的去看這些日志里的報(bào)錯(cuò)的塊，再根據(jù)塊找到對(duì)象，確定是表還是索引，再去用壞塊的修復(fù)手段去修復(fù)…….那么，所有人都會(huì)被你害了。

我們經(jīng)歷過，花了兩天的時(shí)間，都沒修復(fù)完一個(gè)庫中幾萬個(gè)壞塊的情況，在其他大牛還在哼哧哼哧做恢復(fù)的時(shí)候，我向領(lǐng)導(dǎo)提議啟用了新的方案，在大老板沒有完全失去耐性的情況下恢復(fù)了業(yè)務(wù)。

真正正確的做法是，如果確定壞塊數(shù)量為數(shù)眾多，趕緊停業(yè)務(wù)，切災(zāi)備，后面再補(bǔ)數(shù)據(jù)。 災(zāi)備是干什么吃的，養(yǎng)庫千日，用庫一時(shí)，就在這個(gè)時(shí)候了！

非?？上У氖?，大多數(shù)來面試的DBA會(huì)非常糾結(jié)于用block recover，還是用dbms_repair，還是用BBED，還是……

那么，什么時(shí)候往上申報(bào)，要切災(zāi)備？

且不談許多公司的災(zāi)備形同虛設(shè)，關(guān)鍵時(shí)候不敢切的事情。就算這些災(zāi)備都是實(shí)實(shí)在在可用的，恐怕也不是說切立即就能切的，切災(zāi)備涉及到應(yīng)用、網(wǎng)絡(luò)、主機(jī)、存儲(chǔ)等多方面的調(diào)整。

那么多久應(yīng)該切呢？ 一般的企業(yè)從故障處理開始，預(yù)估2小時(shí)之內(nèi)不能讓業(yè)務(wù)恢復(fù)正常運(yùn)行的，應(yīng)該申報(bào)切災(zāi)備。當(dāng)然，如果是金融行業(yè)，特別是證券基金行業(yè)，1分鐘之內(nèi)故障還沒恢復(fù)，就要知會(huì)證監(jiān)會(huì)，半個(gè)小時(shí)沒有恢復(fù)就會(huì)受到同行業(yè)通報(bào)，所以要切就應(yīng)該在這個(gè)時(shí)間之內(nèi)申報(bào)。

問題又回到了原點(diǎn)。你得先有規(guī)劃，作為企業(yè)的重要系統(tǒng)，你得先建設(shè)災(zāi)備環(huán)境，而且是有效的災(zāi)備，并且應(yīng)該事先有一個(gè)災(zāi)備切換預(yù)案。

作為DBA來說，動(dòng)作敏捷的檢查數(shù)據(jù)庫的情況，并及時(shí)匯報(bào)非常重要。其實(shí)這里，又想說自動(dòng)運(yùn)維平臺(tái)了。通過簡(jiǎn)單的按鈕點(diǎn)點(diǎn)，就能快速知道告警日志里的壞塊涉及什么對(duì)象，是不是就好很多呢？

繼續(xù)往回看，面試的問題是什么？是多個(gè)數(shù)據(jù)庫同時(shí)發(fā)現(xiàn)大量壞塊。

作為一個(gè)經(jīng)驗(yàn)豐富的運(yùn)維管理人員，第一反應(yīng)應(yīng)該是，為什么會(huì)同時(shí)發(fā)生呢？顯然是由于外因?qū)е碌摹Ｒ虼俗龊萌轂?zāi)切換，業(yè)務(wù)恢復(fù)使用的第一時(shí)間，應(yīng)該去看看這些數(shù)據(jù)庫共同的基礎(chǔ)是不是同樣的存儲(chǔ)、同樣的存儲(chǔ)管理軟件、卷管理軟件。

依我的經(jīng)驗(yàn)，大部分多個(gè)庫同時(shí)出現(xiàn)壞塊，都?jí)脑诖鎯?chǔ)管理軟件身上。

有一次是Storage Foundation做卷復(fù)制的時(shí)候出現(xiàn)了軟件bug，IBM、Oracle、symentec等眾多廠家在“問題作戰(zhàn)室”里整整呆了一個(gè)月，各家公司二線、三線出具各種證據(jù)自己沒問題，最后最后才找到蛛絲馬跡，揪出來。

還有一次稍微容易些，存儲(chǔ)軟件狀態(tài)恢復(fù)后壞塊沒有恢復(fù)，一個(gè)個(gè)系統(tǒng)通過fsck命令來進(jìn)行的修復(fù)。你說，這是什么類型的壞塊呢？

作為有經(jīng)驗(yàn)的DBA，要解決問題，但不要急著去敲命令，站在更高點(diǎn)的位置來看待問題，可能會(huì)事半功倍。

很不幸的前兩天，某個(gè)朋友公司核心數(shù)據(jù)庫“莫名奇妙”地遇到中止了。原因不方便說，但是據(jù)說等故障恢復(fù)完之后，朋友已經(jīng)抽了好幾包煙了。

我們先來看看，是由于LGWR終止了數(shù)據(jù)庫（ 注：做了一些脫敏處理 ）。

但是，重啟數(shù)據(jù)庫卻發(fā)現(xiàn)數(shù)據(jù)庫啟動(dòng)不了，發(fā)現(xiàn)眾多數(shù)據(jù)文件發(fā)生了壞塊，數(shù)據(jù)庫根本不能open：

同時(shí)伴隨著類似的內(nèi)部錯(cuò)誤：

怎么破？通過當(dāng)天的數(shù)據(jù)庫備份結(jié)合歸檔進(jìn)行恢復(fù)，遠(yuǎn)遠(yuǎn)比去修復(fù)壞塊要快。

分享文章：oracle壞塊怎么處理,oracle數(shù)據(jù)庫壞塊處理
當(dāng)前URL：http://jinyejixie.com/article46/hsideg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供軟件開發(fā)、電子商務(wù)、做網(wǎng)站、全網(wǎng)營(yíng)銷推廣、網(wǎng)站收錄、網(wǎng)頁設(shè)計(jì)公司

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)