最近的幾個技術問題總結和答疑（八)

今天的技術問答是劉晨兄的一個問題，提問來自於我新書中的一個實驗，劉晨兄非常認真，對我書中的很多細節都進行了測試。

看到這個錯誤，如果出現end-of-file這類的錯誤資訊，基本可以斷定資料庫例項是宕了。
找到劉晨兄提到的頁碼標示，原來和我書中的測試結果有一些差別。
我書中的結果類似這樣的形式：

錯誤程式碼也完全不同，這個問題該怎麼解釋呢，這個應該是一個很細節的問題。
首先網路上關於這個錯誤有很多種說法，很多我不認同。
我們先來複現一下問題，找了一套11.2.0.3的環境測試了一下。
先初始化資料

然後復現問題，錯誤和劉晨兄的描述是一致的。

這個時候我迅速去檢視最開始描述問題的部落格和書稿記錄。發現當時沒有詳細記錄當時的測試版本，印象中應該是10g的環境。
當然碰到這個問題，先來快速修復一下。

好了，問題能夠解決了，我們就來分析這個問題。網路上有一些說法，我帶著疑問進行了復現，發現應該不是描述的那樣。
網路上的觀點1：非歸檔模式的影響。但是經過我的測試，發現不存在所說的那種情況。

網路觀點2：存在多個資料檔案，我建立了表空間，包含多個資料檔案，也不存在這種問題。

後面還有一些說法，我就不一一列舉了，不能猜。
對於這個問題，TOM給出了一些解釋，是他很早的一個帖子中的回答。

commit;


還有一位朋友的復現：

我在他們的基礎上也做了一些復現，但是還是發現有一些奇怪之處，有些復現不了。問題的原因是什麼呢。
其中一個原因是在11.2.0.2後引入了一個隱含引數_datafile_write_errors_crash_instance，在我的新書第125~126頁也有提及。在之前版本中，歸檔模式下發生檔案寫入錯誤時，Oracle會自動將資料檔案離線；從11.2.0.2開始資料庫例項會crash而不是離線資料檔案。
我們來看看這個問題怎麼來試一試。

預設是TRUE,我們改為false
SQL> alter system set "_datafile_write_errors_crash_instance"=false;
System altered.

其實還有更多的因素影響，目前先分析到這裡，這也讓我對這個問題有了更新的認識，當然我在書中提到的那個場景是完全恢復，在備份的基礎上隨便玩都可以，只是表現形式會有差別。也是書中問題所要表達的本質。

dangran 這個問題我們來看看怎麼

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