a亚洲精品_精品国产91乱码一区二区三区_亚洲精品在线免费观看视频_欧美日韩亚洲国产综合_久久久久久久久久久成人_在线区

首頁 > 數據庫 > Oracle > 正文

[Oracle]一次數據庫性能問題的tuning

2024-08-29 13:50:20
字體:
來源:轉載
供稿:網友
基本情況:

    系統是一個基于web的業務系統,以online查詢為主,數據更新以批量為主,晚上執行。應該說系統還不算負載太大。5-1之后上班的時候客戶反映很慢,察看DB的cpu慢慢長到100%狀態。服務基本處于不可用狀態。i/o wait也挺高的。
    經檢查,前些天的批量竟然有達到20多小時才完成,導致次日批量都跑不起來。
   
    打開statspack收集信息
   
    從系統中發現本應該夜間執行的批量作業還在運行。停掉后,rollback做了4個小時!(因為一個transaction中只有一個復雜的、數據量巨大的insert語句)
   
    然后做statspack分析,
   
    系統中存在問題:等待事件較嚴重,緩存命中率較低,
   
    語句分析:

    1、一些大量執行update/delete語句竟然沒有建立索引,其實可以建立pk,根據pk處理。

    where中使用常量(引起parse)
   
    2、存在大量這樣的語句:

    SELECT fieldx FROM Tablesname where trim(ServiceNUM) = 'DDDDDD'
    - 在ServiceNUM字段上是唯一索引,因為trim就不能使用index(敗筆) --改!
    - 使用常量查詢,造成每次查詢都要parse,沒有必要的占用的CPU -- 改!
   
   
    3、在批量的存儲過程中,

    所有語句基本都是全表掃描! --- 和開發人員溝通,需要修改邏輯。改進之后效果還是蠻大的。
   
    另外發現一個問題:

    客戶需要的是n百萬用戶數據中的活動用戶萬數據,他們卻全部把n百萬數據從其他系統中收集到自己的系統中,在批量的時候又使用full table scan,性能自然不會好。系統從剛開始設計的時候就存在隱患。這個問題就需要從長計議了。
   
    修改后,CPU高峰時間基本穩定在30-40%之間。
    批量基本在2個小時內完成。
   
    其實是一個很簡單的系統,但是做到這種樣子,尤其是從設計到編碼都存在問題。呵呵,說真的,不是在優化語句的,而是從頭開始看設計。


上一篇:Oracle如何精確計算row的大小

下一篇:[Oracle]大數據類型的操作之CLOB

發表評論 共有條評論
用戶名: 密碼:
驗證碼: 匿名發表
學習交流
熱門圖片

新聞熱點

疑難解答

圖片精選

網友關注

主站蜘蛛池模板: 免费看的黄网站 | 国精产品一区一区三区免费完 | 欧美视频xxx | 一级黄色片网址 | 欧美日韩一级视频 | 国产精品美女久久久久久久久久久 | 伊人爱爱网 | 美足av| 91在线一区二区三区 | 国产一区二区视频精品 | 成人天堂噜噜噜 | 亚洲三级电影 | 成年人网站在线免费观看 | 久久久久久久一区 | 中文字幕亚洲在线 | 国内精品视频在线观看 | 亚洲欧美综合 | 日韩在线一区二区 | av最新网址 | 成人二区 | 成人午夜免费视频 | 永久91嫩草亚洲精品人人 | 日韩在线免费 | 高清av一区 | 色婷婷综合久久久久中文 | 成人欧美 | 日韩视频免费 | 欧美日一区二区 | 久久亚洲国产精品 | 亚洲欧美在线观看 | 久久久久久久一区 | 一区二区三区日韩 | 伊人小视频 | 久久精品免费观看 | www.久久| 在线观看中文 | 亚洲精品成人 | 亚洲欧美电影 | 国产精选视频 | 国产主播一区 | 久久久久久一区 |