資訊專欄INFORMATION COLUMN
接到應(yīng)用反饋某張業(yè)務(wù)表無法進(jìn)行查詢，報ORA-01578有壞塊出現(xiàn)。
1)、該表為普通表，可以通過analyze命令快速分析是表有問題還是索引有問題，可以確定表有壞塊。
2)、視圖查詢，顯示有3個壞塊（可能不準(zhǔn)確），通過文件號和塊號查詢出壞塊都指向了這張表。目前看只有這張表有問題。CORRUPTION_CHANGE#列0表示物理壞塊，非0表示邏輯壞塊。該庫沒有未接入備份,blockrecover用不了，也就是說正常手段無法修復(fù)。但可以通過expdp工具或者dbms_repair包等其它手段來搶救該表上正常塊上的數(shù)據(jù)。
3)、這套庫有adg，在adg上可正常查詢，比較幸運的是這張當(dāng)前無數(shù)據(jù)，無數(shù)據(jù)丟失風(fēng)險。
因為不需要做數(shù)據(jù)恢復(fù)，DB側(cè)最終給的建議是換表，便于后續(xù)寫入讀取數(shù)據(jù)。
另外因為有壞塊出現(xiàn)，后面通過dbv對全庫數(shù)據(jù)文件進(jìn)行檢測，命令大致如下如下：
set feedback off head off echo off linesize 200 pagesize 1000 spool /tmp/dbvchk.sh select dbv file= || name || blocksize=|| block_size || USERID=sys/x’x’x’x logfile= ||substr(name, instr(name, /, -1, 1) +1) ||. || file# || .log from v$datafile; |
對輸出結(jié)果進(jìn)行過濾，部分?jǐn)?shù)據(jù)文件上出現(xiàn)了大量壞塊
對于這種大量的壞塊，初步懷疑可能是存儲有問題，但主機側(cè)反饋底層存儲都正常，問題到這里就比較無解了，但好在有套adg環(huán)境，容災(zāi)庫上未發(fā)現(xiàn)有壞塊,后期考慮切到容災(zāi)庫。另外業(yè)務(wù)側(cè)除了反饋這張表有問題外，其它表再也沒反饋。只能說運氣較好，可能壞塊不是出在熱表上。
當(dāng)出現(xiàn)壞塊時，DBV可以快速的且不影響業(yè)務(wù)的情況下統(tǒng)計出全庫有多少壞塊。如果只有個別幾個塊，我們可以嘗試修復(fù)或者搶救出非壞塊上的數(shù)據(jù)。但如果是大量的出現(xiàn)壞塊，且影響業(yè)務(wù)，這可能就是災(zāi)難的故障。最后要說的是，對于DBA來說，備份重于一切。
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://m.hztianpu.com/yun/130056.html
摘要：初步分析提升可從兩方面入手，一個是增加并發(fā)數(shù)，其二是減少平均響應(yīng)時間。大部分的時間花在系統(tǒng)與數(shù)據(jù)庫的交互上，到這，便有了一個優(yōu)化的主題思路最大限度的降低平均響應(yīng)時間。不要輕易否定一項公認(rèn)的技術(shù)真理，要拿數(shù)據(jù)說話。 本文最早發(fā)表于個人博客：PylixmWiki 應(yīng)項目的需求，我們使用tornado開發(fā)了一個api系統(tǒng)，系統(tǒng)開發(fā)完后，在8核16G的虛機上經(jīng)過壓測qps只有200+。與我們當(dāng)...
摘要：直接顯示了一個疑似內(nèi)存泄漏的問題。然后分析文件給出的信息，發(fā)現(xiàn)一個叫的類。文件里面說的內(nèi)存泄漏的大概的意思就是說，這個類里面的存放的東西太多了，爆掉了。修改了代碼將調(diào)用的地方改成了單例。修改完線上跑了一段日子，后來也沒有出現(xiàn)過這樣的問題。 問題描述: ????早上去公司上班,突然就郵件一直報警,接口報異常,然后去查服務(wù)器的運行情況,發(fā)現(xiàn)java的cpu爆了.接著就開始排查問題 問題解決...
閱讀 1459·2023-01-11 13:20
閱讀 1812·2023-01-11 13:20
閱讀 1263·2023-01-11 13:20
閱讀 2005·2023-01-11 13:20
閱讀 4226·2023-01-11 13:20
閱讀 2879·2023-01-11 13:20
閱讀 1487·2023-01-11 13:20
閱讀 3807·2023-01-11 13:20
