記一次慘敗的Oracle DBA面試經歷

記一次慘敗的 Oracle DBA 面試經歷

說明： 記錄下前段時間一次印象比較深的 Oracle DBA 面試經歷，為什麼 印象比較深呢，因為全程都是被按在地上摩擦的，暴露出很多技術盲點，之前對很多技術細節不求甚解，解決掉一個問題後，沒有去深究問題的根本原因，總想著以後有時間再去研究。

之前面試官已經看過簡歷了，沒有自我介紹環節，直接開始第一個問題：

1 說下你處理過比較有難度的一次故障

這個問題實際上是想看下我擅長的領域、對問題的理解、知識的深度等。

我說了一個4,5 年前處理的一個案例，確實是我印象最深的，一個 OLAP 型別的資料庫當機了，剛接手的資料庫無備份，週五晚上出現當機，歷時兩天時間，在週一早上我才將故障搞定。

故障大概是因為undo 段頭塊損壞導致資料庫當機，因為資料庫同時有 5 個以上的使用者在執行 impdp 操作，大量的資料載入， undo 一直處於繁忙狀態。 無備份情況下是可以通過 _corrupted_rollback_segments 跳過損壞段啟動資料庫的，但是資料庫無法 open, 也就無法檢視到具體的 rollback_segment 名稱，告警日誌和 trace 日誌裡也沒有輸出損壞的段名。問題似乎陷入了死迴圈，想 open 資料庫的前提是知道 rollback_segment ，但是想知道 rollback_segment 的前提又是 open 資料庫。實際上在不啟動資料庫的情況下也有很多方法可以知道 rollback_segment 名稱的，比如通過作業系統 strings 命令檢視 system 資料檔案裡的 rollback_segment 名稱，命令如下：

strings system01.dbf | grep _SYSSMU | cut -d $ -f 1 | sort -u > listSMU

rollback_segment 資訊是記錄在 system 表空間 undo$ 表裡的，我當時錯誤的認為 rollback_segment 資訊是記錄在 undo 表空間裡的，所以執行 strings undotbs01.dbf 什麼也沒查到，這也是基礎不牢的弊端，無奈只好考慮使用自己更不熟悉的 bbed 工具來檢視 rollback_segment ，最終也是通過 bbed 工具，在資料庫關閉的狀態下，讀取出了全部的 rollback_segment ，再將 rollback_segment 加入到 _corrupted_rollback_segments 解決了這個問題，具體問題可以看我的另一篇部落格：

http://blog.itpub.net/29785807/viewspace-2128326/

在我講述這個案例時突然意識到面試官會不會針對這個問題繼續問我bbed 的細節，比如資料塊格式，偏移量等等，時間過去很久了，具體細節已經都忘得差不多了。

面試官可能也是為了避免一開始問的太深我答不上來顯得尷尬，並沒有繼續問我更深的細節，而是問了下比較基礎的壞塊問題：

2 說下壞塊的種類

我只知道有物理壞塊和邏輯壞塊，物理壞塊一般是塊格式本身出現損壞，邏輯壞塊一般是oracle BUG 引起的。

3 物理壞塊和邏輯壞塊又可以細分哪幾類？比如物理壞塊的塊斷裂等？

不清楚物理壞塊和邏輯壞塊更細的分類了，之前也沒有關注過，即使面試官給了提示也沒回答上來。也是平時處理問題時沒有注意細節和及時總結的後果，存在很多技術上的盲點。

這是後來在網上查的關於壞塊的描述。

Physical and Logical Block Corruptions. All you wanted to know about it. (Doc ID 840978.1)

https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=80681922571215&id=840978.1&_afrWindowMode=0&_adf.ctrl-state=6q340rfff_80

Physical Block Corruptions

This kind of block corruptions are normally reported by Oracle with error ORA-1578 and the detailed corruption description is printed in the alert log. 

Corruption Examples are:

·  Bad header - the beginning of the block (cache header) is corrupt with invalid values

·  The block is Fractured/Incomplete - header and footer of the block do not match

·  The block checksum is invalid

·  The block is misplaced

·  Zeroed out blocks  Note 1545366.1

Physical Corrupted Blocks consisting of all Zeroes indicate a problem with OS, HW or Storage (Doc ID 1545366.1)

Logical Block Corruptions

Corruption Examples are:

·  row locked by non-existent transaction - ORA-600 [4512], etc

·  the amount of space used is not equal to block size

·  avsp bad

·  etc.

https://blogs.oracle.com/database4cn/oraclecorruption-

概述

-------------

資料庫壞塊(corruption) 的型別可以按照壞塊所屬物件的不同，分為使用者資料壞塊，資料字典壞塊， Undo 壞塊，控制檔案壞塊， Redo 壞塊， Lob 壞塊， index 壞塊等等；也可以按照壞塊產生的原因，分為物理壞塊 (physical corruption) 和邏輯壞塊 (logical corruption ) 。

本文主要討論使用者資料發生物理壞塊(physical corruption) 分析和解決方法。

物理壞塊

-------------

常見的物理壞塊（Physical Block Corruptions ）有塊頭和塊尾資訊不一致 (Fractured/Incomplete) ， checksum 值無效，資料塊資訊全部為 0 等情況，並且可能伴隨錯誤 ORA-1578 和 ORA-1110 。

為了及時發現物理壞塊和準確定位壞塊產生的原因，oracle 建議設定初始化引數 DB_BLOCK_CHECKSUM=TYPICAL （預設值）。一般情況下，物理壞塊是由於底層 OS/disk 系統錯誤 / 損壞，導致資料塊被修改，資料塊標誌為壞塊 (corruption)

資料塊的Checksum 值無效是一種常見的物理壞塊，當資料庫初始化引數 DB_BLOCK_CHECKSUM=TYPICAL （預設值）時， DBWR 程式將資料塊寫入 disk 時會計算資料塊的 Checksum ，並且將 Checksum 值記錄在資料塊的位置 offset 16 和 17 ；當從 disk 讀取該資料塊時， oracle 重新計算資料塊的 Checksum ，並且與記錄在資料塊中的 Checksum 做異或運算（ Xor ），如果異或結果為非 0 ，說明資料塊被修改過，資料塊為壞塊 (corruption) 。

https://www.cnblogs.com/yhq1314/p/11190045.html

oracle bug 可能導致邏輯壞塊的產生 . 特別是 parallel dml. 例如 :
Bug 5621677 Logical corruption with PARALLEL update
Bug 6994194 Logical corruption from UPDATE DML
Bug 15980234 ORA-1400 / logical corruption from direct path INSERT ALL(fail with   ORA-1400, in direct path / PDML) 。

看下docs.oracle.com 裡對 corrupt block 的說明：

https://docs.oracle.com/en/database/oracle/oracle-database/20/bradv/glossary.html#GUID-44B5A820-D859-47F5-99CC-56A95AF4BB3E

corrupt block

An Oracle block that is not in a recognized Oracle format, or whose contents are not internally consistent. Typically, corruptions are caused by faulty hardware or operating system problems. Oracle identifies corrupt blocks as either logically corrupt (an Oracle internal error) or media corrupt (the block format is not correct).

You can repair a media corrupt block with block media recovery, or dropping the database object that contains the corrupt block so that its blocks are reused for another object. If media corruption is due to faulty hardware, then neither solution works until the hardware fault is corrected.

4 出現壞塊後，如何判斷是否是儲存硬體問題呢？客戶說他們儲存硬體沒問題，你能通過比如日誌還是什麼工具說明到底是不是儲存硬體的問題？

這個也是我之前一直困擾的問題，之前處理過物理壞塊的問題，也想過是不是因為儲存硬體出現問題導致的壞塊，因為客戶曾不同時間多次出現過壞塊問題，也讓客戶去檢查儲存問題了，但是後來沒有繼續深入研究過。

面試時回答的是先基於 rman 進行 block 級別的恢復，恢復壞塊的影響，檢視系統日誌如 messages 等 ，然後觀察，如果後續又常出現物理壞塊問題，可能和硬體有關，物理壞塊通常是由於底層OS/disk 系統錯誤 / 損壞，導致資料塊被修改，但是當時也不能肯定到底是通過哪個日誌或者哪種工具能 100% 確定到底是不是硬體問題導致的物理壞塊。

連續兩個問題答的都不好，氣氛難免有點尷尬，面試官不在繼續問壞塊相關的問題了，換個問題，緩解下氣氛。

5 rac 網路心跳出現故障，一個節點伺服器自動重啟後又恢復正常了，如何判斷是否是網路卡有問題，檢視哪些日誌。

當時記得是有個叢集同步服務的，是 css ，錯記成了 ctss 了，概念和原理沒記清，當時也是答的一塌糊塗。

實際上是叢集層通過CSSD 程式來維護節點和節點之間關係的，在叢集層做心跳，需要檢查叢集件的告警日誌  alert<HOSTNAME>.log($GRID_HOME/log/$hostname)

和檢查 ocssd.log($GRID_HOME/log/<hostname>/cssd) ，對應的後臺程式為 cssd.bin 。

但是這些日誌只能檢視到misstime,nodexxx left cluster 等資訊，並沒有網路卡故障資訊。

還可以通過 ethtool 、  mii-too 等工具檢視網路卡狀態，檢視 messages 裡關於網路卡的資訊，   如果有監控平臺，可以看對應網路卡的歷史監控資訊，流量、連通性等。

6 說下 rac 有哪些程式分別什麼用途。

Rac 後臺程式有 LMON,LCK,LMD,LMS,DIAG 等，服務有 crs,css,ctss,evmd,ons 等。當時想起了幾個程式 ,LMON,LMS,LMD, 但是卻想不起來具體哪個程式做什麼用的了，最後基本上什麼也沒答上來。

7 ASM 磁碟組或磁碟故障，在替換和修復之前需要提前準備什麼。

之前處理過 OCR 磁碟組誤被格式化的問題，也沒提前準備什麼，直接用本地的 ocr 和 votedisk 的自動備份恢復了丟失的資料到新的磁碟組裡。也不清楚是要提前備份現有檔案比如磁碟頭、物理全備等，還是其他什麼意思，平時遇到的並不多，經驗和理論都有欠缺，也沒說出需要準備和注意的。

8 log file sync 等待事件相關的 oracle bug 遇到過哪些？

說了下 log file sync 大概原理和可能的原因，但是具體哪些 oracle bug 一個也沒記住。之前也整理過 log file sync 相關知識點，但是具體 bug 讓我跳過了沒有關注， MOS 上查了下， BUG 很多，只有真正處理過才會有印象吧。

http://support.oracle.com

WAITEVENT: "log file sync" Reference Note(Doc ID 34592.1)

The log file sync wait may be broken down into the following components:
1. Wakeup LGWR if idle 
2. LGWR gathers the redo to be written and issue the I/O
3. Time for the log write I/O to complete
4. LGWR I/O post processing
5. LGWR posting the foreground/user session that the write has completed
6. Foreground/user session wakeup

......

前面的問題回答的實在太水了，氣氛極度尷尬，面試官又嘗試出個送分題，緩和下氣氛。

9 假如昨天下午 15 點到 15 點 01 資料庫負載很大，今天如何去定位這 1 分鐘內的問題：

分析昨天某個時間段1 分鐘內的資料庫效能？我常用 AWR 去分析過去某個時間段的資料庫效能問題，但是 AWR 預設 1 小時收集一次快照，跨度太大了，很顯然不適合分析過去 1 分鐘的效能問題，除了 AWR 以外還有 ASH 和 ADDM ，平時用的也不多，好像也不能分析，難道是用一些我不知道的動態效能檢視分析的嗎？我知道的檢視有 v$session ， v$session_wait,v$session_wait_history ，但是這些最多隻能保留最近 10 次的等待，昨天的會話資訊肯定都沒有了。實際上我已經想的差不多了，順著 v$session_wait 和 v$session_wait_history 檢視再往下想應該就能想到 v$active_session_history ，然後想到 ASH 報告。 ASH 採用的策略是：儲存處於等待狀態的活動 session 的資訊，每秒從 v$session_wait 中取樣一次，並將取樣資訊儲存在記憶體中。 由於平時處理效能問題時很少使用ASH 和 ADDM ，導致我直接把 ASH 跳過了，本來一道送分題的，硬生生讓我答成送命題。

總結： 也做過幾年 DBA 了，有自己的一些野路子，但是在平時工作和學習的過程中，卻忽略了一些最基礎的概念和原理，導致存在很多盲點，知識體系存在斷層，今後還要加強這塊的學習。

珍惜當下，當你挑燈夜讀學會了各種技能，掌握了各種本領，你會發現，還 tm 不如打幾把排位了！！！

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/29785807/viewspace-2691375/，如需轉載，請註明出處，否則將追究法律責任。