這一週 在搞oracle 性能優化。
哥記得 哥剛剛接手這個 項目時候， 發現有SQL 居然跑出了400 多分鐘的時間，200，100 ， 70 多分鐘，很多的， 南京分區的一個 什麼流程 跑了 7， 8 個小時。
於是哥 開始着手優化。 其實我做優化 心裏 自然是要一把尺子的， 首先看 系統 數據量， dba_segements 這個表， 大致是什麼表最大等等.... 。 再看服務器的硬件配置。 內存多少，IO 性能如何， 存儲空間多大， 這個其實都不需要 徹底瞭解， 瞭解大概 就差不多了， 比如 哥用併發搞定的一個案例， 該案例是刪除數據的SQL， 刪除用了 24分鐘， 最簡單的刪除， SQL 語句上面 已經無法優化了， undo 表空間 也是足夠的。 我當時 想跟 我們的項目經理 說了， 這個刪除 的速度 其實還可以接受， 誰知項目經理 說這個需要優化的， 那我提出了一個 觀點， 用硬件資源來換取一定的時間， 之前是因爲 哥看過服務器 能接受的 最大 併發數了， 開4個進程 穩穩的， 於是哥開了 4個 併發 ， 至於到底用到了幾個， 哥 沒有關注， 最後 這個 我們幾個在生產庫中測試了， 6分鐘 左右刪除。 於是項目經理 接受了這個優化方案。 哥但是想想 之前 400多分鐘的 SQL都接受了，24分鐘 需要優化？？？？
還有一個 感覺 哥要做抽自己 嘴巴的， 亂說話導致的。 哥 當時 在優化也沒有在意， 項目經理說插入 不該怎麼慢的啊， 我說怎麼了啊， 他說 插入速度 太慢了， 我看了一眼，發現 哥優化了的一個案例， 我說這個優化過了， 這個大概插入 150M 數據， 這個庫 每秒 插入 50M 左右的數據， 至少 插入40M是穩穩的， 於是項目經理說 那 這個 你把他優化了吧..... 我 這個才意識到問題的嚴重性， 41分鐘啊.... 優化 到 秒 ， 什麼概念？？？ 其實我們項目 我也知道 至少 這個時候 不會 很苛刻， 只要優化到 10來分鐘 差不多了。 於是哥的挑戰來了， 經過排查 ， 發現大量索引 碎片， 大量的索引 在插入後 排序 花費時間， 於是 哥想到了， 思路。 什麼都不要做 ， 就是搞一下索引 速度應該能到 十幾分鍾級別， 第2天 暫停生產庫 ， 搞索引， 第三天傍晚 看效果 ， 結果 真的在 秒級， 大概 30多秒吧， （ 其中 不排除哥做了其他方面的優化， 降低了oracle的負載了 ）。 這兩個案例是在 知道了服務器 性能方面的參數 做出的性能 調整。
監控業務核心業務表， 這個可以監控到， 我們只需要在 oracle 負載 並不是很強時候， 哥的意思是 ，核心表 和非核心 表分離，最典型的是 核心讀寫 文件的分離。 能保證非核心業務 能在 核心業務 進行之前結束， 或者是 在 其 結束後 搞。 不過這個哥 還沒有來得及實現。估計會很快搞這個的。
監測回滾段過於龐大， 在做這個優化時，超大量的數據更改， 幾乎是全表更改， 關聯更改。 一個方案是 拆分更改邏輯， 所謂更改 無非是先 找到數據， 然後改數據，其過程中必然 導致使用 undo 表空間， 那其很大，必然導致性能問題， 哥改的這些 SQL 都是 幾十分鐘的， 於是哥 先用hash join 查詢數據， 然後每次 提交10000 條數據，
更改再更改 下一個10000條， 結果 3秒左右， 幾十分鐘到 3秒的，性能的提升。 還是很顯著的...
數據表減肥， 這個性能 肯定提升， 當時哥問了一下， 說這個表太大了， 要刪除數據的， 這個肯定不行，刪除數據 在生產庫？？？ 項目經理說的好， 這個叫 歷史數據轉儲。 200萬數據， 轉儲150 萬數據， 性能能不提升？？
業務表，查詢條件統計， 我們起碼要知道 那些索引建的是有意義的， 之前哥看到好多索引 建的都 不知道是幹嘛的， 有些列上面的等值過濾 用了10000多次， 有的只用了7 8次， 有的這個列上面的值 全是1， 有的列上面的值 很不均衡，但這些列上面有索引。 組合索引的引導列 上面的選擇性 是100%。分區表上面 明顯可以搞分區索引的。
那第二步 在 v$sql ， 和sql 的歷史表，以及v$sql 和歷史表中 查詢 用到的 索引， 在排除一下得到沒有用到的索引。
第三步 在開索引監控， 看看 業務週期看看開索引監控 中到底有沒有用到這個， 第四 步 在吧沒有用到的索引刪除。
哥現在走到 第三步。 估計第四步很快就會走的。 哥在刪除 索引後對 insert 性能提升 效果 大大的。
比如也有個優化 是基於系統的理解上面 出現的， 我們業務發生時間是 白天，但是系統收集統計信息是在白天。 如果是大量的 insert ， update 呢？？ 統計信息大大的不準確，導致錯誤的執行計劃， 哥遇到的一個， oracle 以爲 這個表只有一條數據（其實有5萬多條 走了 NL， 結果哥改成hash ， 發現 性能 提升了 100多陪 。 這個有在前面的說過。
最近也優化了點SQL， 典型的是 開始 規範化了， 寫了 基本分頁的框架， 這個已經共享出來了。。。
具體的 SQL 優化， 看SQL， 看完SQL 看SQL執行計劃。 具體問題 具體對待 。知道並行提升效率， 不要動不動 就搞一個並行。hints 會用， 但不要濫用。
今天由於是週五， 明天不上班，看不到 陸續的優化結果了， 也看到項目經理腿抖的， 眼睛是不是的小的咪一下， 就問了一下 這周性能如何？？？ 他說
性能不錯， 以前 南京地區的流程跑了 7， 8 個小時， 現在一個多小時 出來了。 估計是 1小時不過20分吧，要過了 估計他會說 一個半小時。
我看了 至少現在沒有 說 有超過100分鐘的了， 有個76分鐘的， 60多分鐘的沒有 50多分鐘的 2， 3 個。 30多分鐘 大概 也有 2， 3 個吧， 哥的現在的任務是 搞35分鐘以上的。 哥看的 好像超不過 7個，
對此 哥特意花了 大概1個小時 記錄哥的心得， 以後看看的.......