前言：

時間一晃已經來到了6月，技術人生系列文章已經半年沒有更新了，在過去的半年時間里，我們技術人生系列文章的作者們一直奮戰在工作一線，同時不忘積累和總結，為我們的文章提供更深厚的底蘊；如今，技術人生系列將攜中亦課堂正式回歸，依舊嚴謹深刻，生動再現客戶現場處理問題的點點滴滴，希望在傳遞更多知識點的同時給大家帶來更多深度的思考。

在這里，首先感謝一直以來支持技術人生系列的小伙伴們，你們的支持與轉發是我們持續分享的動力。

一、 問題來了

某個周五的悠閑晚上，正在窗前思考人生的老k，接到了一個客戶的問題，客戶現場的DBA處理了有一些日子了，準備在周末的時間窗口重啟來解決該問題，不過客戶還是很謹慎的囑咐說，估計重啟后該問題可能就沒法重現了，我們需要在重啟前找到問題的觸發根因，避免再次出現此類問題。

那么具體問題是什么呢？客戶描述的信息如下：

從跟客戶的交流來看，似乎已經被這個問題折磨了很久，而現在已經對分析這個問題的原因不報太大的希望，只是報著試一試的心態來分析這個問題；

客戶只是報著試一試的心態給我們轉交了這個問題，但是我們作為服務商，就必須以全力以赴的態度來解決客戶的問題。

二、 摸清情況

要盡快解決問題，只能遠程分析，于是我聯系到客戶的接口DBA，通過遠程連接到客戶的服務器，了解了相關環境，分析問題；具體情況如下：

首先跟客戶DBA溝通，拿到了幾個存在該問題的SQL，直接執行這些語句，在試驗很多次后，確實遇到了好幾次錯，特別是執行時間較長的SQL；

選取其中較簡單的一個語句，其語句和執行計劃如下：

這個SQL語句中，出現問題的表是XXXstatelog，這個表比較小，只有60M；

而出現的ORA-1410錯誤是什么呢？

ORA-1410錯誤是因為有無效的ROWID，ORACLE并未提示出現該類情況的可能原因；

三、 交流與搜索

現在基本情況了解了，不過客戶DBA已經分析了有一些時間了，而且他們更了解整體的應用、硬件以及相關的變化情況，在接手現場問題的時候，我都習慣多與客戶DBA進行更多的溝通，一方面可以借鑒他們的已有經驗，避免重復發明輪子，另一方面，旁觀者清，也許也可以給他們指出一些紕漏之處，發現問題的關鍵；總之，充分利用已有的資源來快速分析問題，更何況網絡時斷時續的，相關操作還需要客戶幫忙執行和收集。

  看來并沒有更多信息，那先思考一下吧；再看看這個報錯：

兩個關鍵信息： ROWID和invalid ；

首先，什么時候會用到ROWID呢，通常來說，ROWID是一個偽列，并不存在于表的數據塊中，似乎只有索引的葉子塊中才會存儲ROWID用以定位數據位置；

另外，INVALID，似乎意味著存儲在索引中的rowid出現了異常，或者在讀到內存中后出現了混亂？

沒有更多信息的情況下，不如借鑒MOS上已有的經驗，看看導致ORA-1410的現象都有哪些情況，于是找到了一篇解釋該類錯誤的文章：

其中描述了ORA-1410的觸發情況：

從這里給出的一系列描述看，主要可能的原因包括: 數據塊損壞、索引塊損壞、內存損壞、DDL操作導致的異常以及各種bug；

從我們遇到的情況看，數據塊/索引塊的損壞似乎不存在，因為多次執行并不會總是出現錯誤；

在先不考慮bug的情況下，就只有DDL操作或者內存異常的情況了，那么是不是DDL操作導致的問題呢？

四、思考與推斷

目前看到的這篇MOS文檔講述的還算比較全面，于是我先發送給客戶DBA討論；

然而，客戶DBA表示，已經仔細閱讀過這篇文檔了，而且他們跟應用溝通過，出現問題的時段應該是不會有DDL操作，只會在晚上的固定一個時間段存在一些TRUNCATE操作；另外，他們也在自己的環境也測試過了，truncate并沒有導致ORA-1410的報錯，而且以過往的經驗來看，以前遇到過的truncate導致的查詢錯誤報的都是ORA-8103；所以，這里客戶認為可能還是內存的問題或者ORACLE的bug導致的；看來客戶DBA還是很有經驗的。

對于客戶的看法，我是有幾分認同的：

1. ORA-1410我似乎很少遇到過，以前遇到過都是索引異常的情況；

2. 另外truncate導致SQL執行報錯的情況通常報的是ORA-8103，對象不存在；

3. 如果真的是沒有意識到的truncate操作，那前端業務可能已經受到影響了；

這樣好像不應該是truncate導致的，但是現象上時好時壞又是怎么產生的呢？如果真的是內存中的異常，那它是怎么好的呢？它的觸發條件是什么呢？

趁著與客戶網絡斷斷續續的情況，我開始了獨自思考。

根據mos 文檔的描述問題出現的原因主要有幾類：

1. 數據庫中存在著頻繁的DDL 語句。

2. 某個索引或者數據塊出現了損壞，也就是壞塊導致的問題

3. 硬件層面，例如：內存出現了問題 

4. Oracle 的bug

再仔細回顧一下這個問題的現象逐一思考各種可能原因：

1. DDL語句導致的，但是用戶已經確認了DDL語句只會在特定的時間執行。

2. 某個數據塊或者索引塊損壞，這個可以通過下面的語句來進行判斷

SQL>analyze table <table_name> validate structure cascade;

在和用戶確認過之后，發現著命令并沒有返回壞塊相關的信息，基本可以排除壞塊的可能。

3. 內存層面的問題，如果是內存層面的問題，更大的可能性是當訪問某個表的某一些數據塊的時候會出現問題。而且硬件工程師也確認了，內存并沒有問題，所以，也基本上可以排除，內存出現問題的可能性。

4. Oracle 的 bug，在 mos上進行了一些搜索之后，也沒有找到類似的問題。

五、 測試與模擬

經過上面的思考后，我還是認為truncate操作導致異常的可能性更大，對于這樣的case如果能重現出來，相信會非常有說服力，嗯，這樣的重現應該是比較簡單的，不如直接重現；

于是，我開始在自己的測試環境，同樣是10g數據庫，Redhat linux環境中來重現，實現操作如下：

1. 創建表，生成更多數據，創建索引

2. 構造通過索引訪問數據的語句

因為rowid只有在索引中才會用到，我們這里使用hint的方式，讓SQL執行過程中先訪問索引，再通過索引返表，這是一個比較差的執行計劃這個SQL執行時間會比較長；

3. 在進行上述查詢的過程中，我們在另一個會話中執行trauncate操作

  4. 觀察第2步的查詢操作，確認是否出現報錯

先后執行了幾次上述模擬案例測試，并未能重現ORA-1410的錯誤或者其他錯誤，查詢正常完成。問題似乎陷入了僵局，難道truncate 語句真的不是問題的原因？ 我們反過來想一下，如果要推翻自己的分析，最直接的辦法就是拿到更多的證據來證明自己的分析是錯誤的。那就再來搜集更多的信息吧。

六、 意外發現與解決問題

在自己的環境沒能快速重現出問題來，看來還得到生產環境繼續挖掘其他線索，爭取在重啟前搜集足夠的信息；

在查看的過程中，意外發現，這個環境上竟然部署了OGG（oracle goldengate），而它是作為源端將整個SCHEMA的表同步到目標端的ORACLE實例，這似乎給定位問題帶來了轉機： 如果是內存層面的異常，理論上是不會傳導到ogg目標端的ORACLE實例上的；而如果是表本身或者索引本身的問題，那么在ogg目標端的ORACLE實例上也就應該能重現；

接下來，我們就在ogg目標數據庫上執行相關查詢，經過半個小時的測試發現，同樣的語句在ogg目標數據庫上也會報錯，不過與生產環境不同的是，報錯信息是ORA-8103；

ORA-8103就比較熟悉了，通常是因為對象被drop掉或者truncate掉導致的；同時，我們發現目標數據庫的版本是11g的數據庫，頓時我們覺得問題就簡單多了，在11g數據庫中，存在一個參數enable_ddl_logging來控制是否將DDL操作記錄到alert日志中，而這源端的10g數據庫時沒有這個功能的；

于是，我們在目標端數據庫實例中調整了該參數后，alert日志中很快就捕捉到了truncate的信息；

至此，似乎就真相大白了，正是應用在代碼里加了truncate的操作，比較頻繁的truncate操作導致相關表的查詢出現報錯中斷，接下來客戶DBA要做的就是和開發溝通其truncate操作的目的，并對此進行相應的調整；

將頻繁的truncate操作去掉，改成定期的truncate操作后，便沒有再在業務時間段出現ORA-1410或者ORA-8103的錯誤了，這樣事情就告一段落了。

七、 研究與重現

客戶的問題是解決了，但是新的疑惑又開始縈繞在我的腦中，只不過現在沒有客戶的壓力，沒有時間的緊迫性，可以靜下心來慢慢研究這個問題：

要回答第一個問題，我們還是先要了解一下truncate操作對表/索引到底做了什么：

理解了上面的幾點，我們再來重現錯誤，就很簡單了；下面我們來構建幾個重現場景：

首先構造兩張表，其中T06182表比較大，T06183表比較小，在object_id列上存在索引：

構造查詢用的語句：

（注：truncate的完成時間是11:13:59,在查詢過程中，查詢未受影響）

（注：truncate完成時間是11:22:06，flush buffer_cache的開始時間是11:22:15，同期查詢報錯）

（注：truncate完成時間是11:20:05，insert執行時間是11:20:16，同期查詢報錯，truncate后插入數據，extent被重用，導致訪問數據時報錯）

對于第二個問題，其實在充分理解了ORA-1410和ORA-8103的錯誤后，我們也就能知道他們的共同之處了，看起來只是在10g報ORA-1410，而11g報ORA-8103；

可以看到，同樣的case，在11g數據庫環境中出現的是ORA-8103錯誤；

而且MOS上還可以找到類似的一些文章來說明這個問題：

1. 對于原理的理解，在解決問題特別是想重現故障的時候，極為重要，否則很有可能出現重現達不到預期效果而導致錯誤結論的情況；

2. 對于實時處理問題，即使壓力再大，時間再趕，對于不了解的細節，對于未讀過的文章，還是需要靜下心來仔細閱讀，否則就有可能錯失那個讓你一蹴而就的知識點；

3. 試著去重現你遇見的問題，這會比解決問題讓你印象更加深刻。