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

突然發現最近忙裡偷閒也回答了一些微信好友的問題。有的在公眾號提問，有的私信給我。簡單整理了一下。
問題1：
之前使用expdp和impdp匯出匯入資料庫statistics時遇到一個bug，無法impdp匯入，後來只能不匯入statistics，待匯入資料後自己收集物件統計資訊，但問題是收集的統計資訊和原來有些差異，特別是直方圖資訊有差異，導致sql執行計劃有變化，不知到楊總有沒有遇到過？又該怎麼處理呢？

答：
報錯是因為跨版本了吧，有的時候有這種情況，我們生產是不用直方圖的。容易有偏差。
儘管他沒有提供截圖，但是我想起之前有朋友提過一個類似的問題，解決方法也是類似的。
錯誤原因應該是10g的資料匯入11g同時匯入統計資訊，看錯誤應該是 impdp的時候的統計資訊的影響。加EXCLUDE=STATISTICS試試。參考mos文件 ID 878626.1有更詳細的解釋。

第二個問題源自我幫助一個網友解決的一個問題，可以參考 遠端協助解決重建索引的危機問題 http://blog.itpub.net/23718752/viewspace-2088227/
問題2：
跟我之前的系統現象一樣一樣的，都是大表重建索引，導致執行計劃走全表，io和cpu秒升，系統無響應。生產系統的操作一定要謹慎啊！一個小的疏忽可能造成幾個小時系統無響應！ 我還有個問題，為什麼文中說在讀比較多的時候online建立索引效率提升不大呢？

答：
online這樣的操作本身是ddl，看起來高可用，也是在後臺維護資料和資料字典資訊，對查詢本身沒有什麼提升和影響，而且online有個比較麻煩的地方就是，一旦後臺維護，你就不能隨便終止了。在10g裡面可能得重啟庫，11g裡面有個包可以臨時解決。
我所說的讀比較多，online建立索引主要是基於當時的環境，當時的會話都是查詢語句在執行，online操作還是有一定的風險，因為當時系統的負載極高，擔心會有當機的風險。

引用一個微信朋友的留言：非常典型的一個案例，有時經常會有這種生產系統重建索引或是新增一個有預設值但沒有NOT NULL約束的操作，不清楚原理，就不清楚這種操作帶來的風險，兩者相輔相成。

問題3：
請問如何判斷建索引的時間呢
答：如果執行時間很長，一種比較上手的方法就是寫個指令碼，執行幾秒鐘在這個過程中抓取v$session中的sql_id，然後在cursor裡面檢視對應的執行計劃
建立索引的語句不難，但是如果評估不出一個基本的時間點，這個過程就會很沒底。

問題4：、
如果匯出public的db link,密碼忘了
答：
一種快捷的辦法就是，直接全庫匯出結果 full=y,rows=n,用strings命令可以看到dump裡的內容，搜尋DATABASE LINK就看到所有的了，話說db link裡面的加密串真是夠長的。

問題5：
拋開我的低端儲存，就io效能問題，楊老師給點可行的思路，我先來一個，最佳化物理讀sql，
答：
最佳化物理讀是一方面，比如IO方面做一個基本的平衡，資料分割槽，分割槽表資料做IO分離。啟用大頁，減少碎片級的IO造成swap過多爭用。
如果深入sql層面，還是執行效率優良的sql語句。

問題6：
你好，有個問題哈，小白點，我這有幾套庫的主機要升級，可能對庫的影響是什麼？或者還需要同時升級哪些元件？我現在只覺得一起升級asmlib就成，這樣理解對麼？另外如果安裝了新的asmlib舊的也就不能回滾了，對吧？一般情況下，是不是很少對db的主機進行patch操作？

答：
作業系統升級，有些資料庫引數也有影響，比如filesystem_option, 說實話asmlib我生產還沒用過，是和核心版本繫結的，可以借這個機會弄成udev方式，這種升級可以考慮switchover，替換ip,然後原來的主就成備了，如果庫不大，直接初始化，搭建

群友反應這樣做工程太大了，他們的要求是從安全形度出發，才要patch的，並不是db角度，一般db都在內網，所以被攻擊的可能很小。我是否可從這個角度順服他們不升級？一般情況下，是不是db 主機也很少做patch的動作？
答：
很少有主動線上上打patch的，風險不可控