資料庫壞塊

⑴ 請問Oracle資料庫恢復怎麼弄啊，oracle資料庫中數據文件出現壞塊，求解

Oracle因為結構復雜在日常工作中經常會碰到因非正常退出、網路不穩定或病毒等原因造成的Oracle資料庫損壞。損壞了的資料庫會造成軟體運行不穩定，出現各種運行錯誤

⑵ 我們單位用的是oracle資料庫 現在發現資料庫老有壞塊 請問oracle里要怎麼檢測壞塊呢

雖然我們也可以通過dbv(dbfileverify)工具做到對單個數據文件的壞塊檢測，但是直接使用RMAN的」;」結合V$DATABASE_BLOCK_CORRUPTION視圖要方便地多。

Script:

1)$rmantarget/nocatalog

2)RMAN>run{
allocatechanneld1typedisk;
allocatechanneld2typedisk;
allocatechanneld3typedisk;
allocatechanneld4typedisk;
;
}

3)select*fromV$DATABASE_BLOCK_CORRUPTION;

如果自己搞不定可以找ASKMACLEAN專業ORACLE資料庫修復團隊成員幫您恢復!

⑶ 遇到大規模oracle壞塊該怎麼處理

最近一兩個月，一直有場景化運維、場景化大數據分析的聲音圍繞在耳畔，以Gdevops全球敏捷運維峰會杭州站上新炬網路執行副總裁程永新的「 一切沒有場景驅動的運維平台建設都是假大空！ 」最為振聾發聵。我們一直在談技術，談原理，談內核，總以為「懂了」這些的人，就勢必能廣闊天地大有所為。

技術固然重要，但偏離了業務/應用場景的技術，無法呈現業務價值的技術就非常不重要。

技術也應該是場景驅動的，對於運維技術人員來說，離開場景學習的所謂高深技術，只是浪費時間。所以新同事進入一個新團隊後，能使技術更好發揮作用的環境、流程的考核會占據了另外的三分之二。

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

這是我內部分享的一個簡單思維導圖，如果有遺漏，歡迎在後面評論補充。

面試的時候通常是這么問的：你了解Oracle壞塊么？壞塊為什麼會產生？描述一下你處理過的壞塊案例細節？如果你負責的好幾個資料庫都突然發生了壞塊，你會怎麼做？

通常，前面幾個問題的回答都不會太差。但是最後一個問題的回答，鮮有能出眾的。原因在於面太窄，思維太窄。如果這個時候你還要一個個庫的去看alert日誌，那麼顯然就走錯了方向。

現實情況就是，我們的資料庫可能是五六十套，或者上百套，你一套套庫的去看這些日誌里的報錯的塊，再根據塊找到對象，確定是表還是索引，再去用壞塊的修復手段去修復…….那麼，所有人都會被你害了。

我們經歷過，花了兩天的時間，都沒修復完一個庫中幾萬個壞塊的情況，在其他大牛還在哼哧哼哧做恢復的時候，我向領導提議啟用了新的方案，在大老闆沒有完全失去耐性的情況下恢復了業務。

真正正確的做法是，如果確定壞塊數量為數眾多，趕緊停業務，切災備，後面再補數據。 災備是干什麼吃的，養庫千日，用庫一時，就在這個時候了！

非常可惜的是，大多數來面試的DBA會非常糾結於用block recover，還是用dbms_repair，還是用BBED，還是……

那麼，什麼時候往上申報，要切災備？

且不談許多公司的災備形同虛設，關鍵時候不敢切的事情。就算這些災備都是實實在在可用的，恐怕也不是說切立即就能切的，切災備涉及到應用、網路、主機、存儲等多方面的調整。

那麼多久應該切呢？ 一般的企業從故障處理開始，預估2小時之內不能讓業務恢復正常運行的，應該申報切災備。當然，如果是金融行業，特別是證券基金行業，1分鍾之內故障還沒恢復，就要知會證監會，半個小時沒有恢復就會受到同行業通報，所以要切就應該在這個時間之內申報。

問題又回到了原點。你得先有規劃，作為企業的重要系統，你得先建設災備環境，而且是有效的災備，並且應該事先有一個災備切換預案。

作為DBA來說，動作敏捷的檢查資料庫的情況，並及時匯報非常重要。其實這里，又想說自動運維平台了。通過簡單的按鈕點點，就能快速知道告警日誌里的壞塊涉及什麼對象，是不是就好很多呢？

繼續往回看，面試的問題是什麼？是多個資料庫同時發現大量壞塊。

作為一個經驗豐富的運維管理人員，第一反應應該是，為什麼會同時發生呢？顯然是由於外因導致的。因此做好容災切換，業務恢復使用的第一時間，應該去看看這些資料庫共同的基礎是不是同樣的存儲、同樣的存儲管理軟體、卷管理軟體。

依我的經驗，大部分多個庫同時出現壞塊，都壞在存儲管理軟體身上。

有一次是Storage Foundation做卷復制的時候出現了軟體bug，IBM、Oracle、symentec等眾多廠家在「問題作戰室」里整整呆了一個月，各家公司二線、三線出具各種證據自己沒問題，最後最後才找到蛛絲馬跡，揪出來。

還有一次稍微容易些，存儲軟體狀態恢復後壞塊沒有恢復，一個個系統通過fsck命令來進行的修復。你說，這是什麼類型的壞塊呢？

作為有經驗的DBA，要解決問題，但不要急著去敲命令，站在更高點的位置來看待問題，可能會事半功倍。

很不幸的前兩天，某個朋友公司核心資料庫「莫名奇妙」地遇到中止了。原因不方便說，但是據說等故障恢復完之後，朋友已經抽了好幾包煙了。

我們先來看看，是由於LGWR終止了資料庫（ 註：做了一些脫敏處理 ）。

但是，重啟資料庫卻發現資料庫啟動不了，發現眾多數據文件發生了壞塊，資料庫根本不能open：

同時伴隨著類似的內部錯誤：

怎麼破？通過當天的資料庫備份結合歸檔進行恢復，遠遠比去修復壞塊要快。

⑷ Oracle 資料庫中的出現壞塊問題，該如何處理

oracle資料庫的壞塊問題是個讓人比較頭痛的問題，主要分為邏輯壞塊和物理壞塊，邏輯壞塊就是數據文件里的邏輯關系出現的混亂，這一般是由於資料庫的BUG導致的。物理壞塊就是數據文件中的數據不存在任何意義，沒有任何邏輯和結構，造成物理壞塊多因為伺服器IO系統故障導致的。

⑸ oracle檢查資料庫是否有壞塊的命令

dbv是檢查物理上是否有壞塊的命令

#su - oracle
#dbv file=/oracleruanko/app/oracle/oracle/proct/10.2.0/ruanko/dbs/ruankotest blocksize=8192

DBVERIFY: Release 10.2.0.1.0 - Proction on Fri May 28 09:56:37 2010

Copyright (c) 1982, 2005, Oracle. All rights reserved.

DBVERIFY - Verification starting : FILE = /oracleruanko/app/oracle/oracle/proct/10.2.0/ruanko/dbs/ruankotest

⑹ ORACLE使用dbv工具檢驗數據文件是否有壞塊

dbv工具可以用來驗證數據文件的有效性，在資料庫恢復之前可以使用該命令對備份文件進行有效性檢查，
防止因備份文件本身的問題導致資料庫無法恢復。
當然，dbv命令也可以對在線的數據文件進行檢查。
注意，dbv工具只可以對數據文件進行檢查，無法使用它完成控制文件和日誌文件的檢查。
1.dbv命令語法
dbverify ::=
dbv [ USERID=username/password ]
FILE = filename
| { START = block_address | END = block_address }
| BLOCKSIZE = integer
| HIGH_SCN = integer
| LOGFILE = filename
| FEEDBACK = integer
| HELP = { Y | N }
| PARFILE = filename
End of description.
參考自Oracle官方文檔http://download.oracle.com/docs/cd/E11882_01/server.112/e10701/img_text/dbverify.htm
2.查看幫助文檔
從語法定義中我們看到「HELP = { Y | N }」選項，我們可以使用它查看dbv的幫助信息。
ticket@secDB /home/oracle$ dbv help=y
DBVERIFY: Release 11.2.0.1.0 - Proction on Wed Mar 31 19:47:36 2010
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Keyword Description (Default)
----------------------------------------------------
FILE File to Verify (NONE)
START Start Block (First Block of File)
END End Block (Last Block of File)
BLOCKSIZE Logical Block Size (8192)
LOGFILE Output Log (NONE)
FEEDBACK Display Progress (0)
PARFILE Parameter File (NONE)
USERID Username/Password (NONE)
SEGMENT_ID Segment ID (tsn.relfile.block) (NONE)
HIGH_SCN Highest Block SCN To Verify (NONE)
(scn_wrap.scn_base OR scn)
幫助信息中描述了dbv命令的使用方法，不贅述。
3.體驗dbv工具的效果
1）查看系統中的數據文件名稱
sys@ticket> col name for a60
sys@ticket> select name from v$datafile;
NAME
------------------------------------------------------------
/oracle/ora11gR2/oradata/ticket/system01.dbf
/oracle/ora11gR2/oradata/ticket/sysaux01.dbf
/oracle/ora11gR2/oradata/ticket/undotbs01.dbf
/oracle/ora11gR2/oradata/ticket/users01.dbf
2）使用dbv工具對users01.dbf進行檢查
（1）使用最簡單的參數
sys@ticket> !dbv file=/oracle/ora11gR2/oradata/ticket/users01.dbf
DBVERIFY: Release 11.2.0.1.0 - Proction on Wed Mar 31 19:50:59 2010
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
DBVERIFY - Verification starting : FILE = /oracle/ora11gR2/oradata/ticket/users01.dbf

DBVERIFY - Verification complete
Total Pages Examined : 35520
Total Pages Processed (Data) : 33029
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 20
Total Pages Failing (Index): 0
Total Pages Processed (Other): 402
Total Pages Processed (Seg) : 0
Total Pages Failing (Seg) : 0
Total Pages Empty : 2069
Total Pages Marked Corrupt : 0
Total Pages Influx : 0
Total Pages Encrypted : 0
Highest block SCN : 9291961 (0.9291961)
在實際使用中重點關注以下信息：
Total Pages Failing (Data) : 0
Total Pages Failing (Index): 0
Total Pages Failing (Seg) : 0
Total Pages Marked Corrupt : 0
如果以上信息返回結果不為0，需要重點關注！及時排查原因。
（2）如果指定logfile參數，檢查結果將只記錄在日誌文件中，屏幕上不顯示
sys@ticket> !dbv file=/oracle/ora11gR2/oradata/ticket/users01.dbf logfile=dbv_users01.log
DBVERIFY: Release 11.2.0.1.0 - Proction on Wed Mar 31 19:52:20 2010
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
此時可以使用SQL*Plus的edit命令查看生成的日誌文件內容。
sys@ticket> ed dbv_users01.log