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