碼上快樂

相關內容    簡體    繁體

oracle表查詢速度極慢的處理過程記錄一下

本文轉載自   查看原文   2018-09-04 15:14   1242    Oracle

oracle表查詢速度極慢的處理過程記錄一下

https://blog.csdn.net/haitaofeiyang/article/details/50855401

版權聲明：本文為博主原創文章，未經博主允許不得轉載。 https://blog.csdn.net/haitaofeiyang/article/details/50855401
Oracle 單個表查詢速度極慢處理過程
 
現象：前兩天看到我們的oracle數據庫，一條查詢語句執行的特別慢，導致應用程序連接超時，客戶根本查不出來東西，非常着急。后來在plus中執行select count(1) from fee,也特別慢，這張表一共才50w的數據。
配置：        Oracle 11G RAC 、linux redhat操作系統
處理過程：
我最開始認為是不是查詢語句的問題，或者索引的問題。於是把性能差的語句截出來看了看。
SELECT * FROM (select * FROM v$sqlarea order BY disk_reads DESC )where ROWNUM<10;
前十條基本都是查詢有分頁的情況，數據庫在計算分頁的總條數。於是根據SQL建了幾個字段的索引，日期和BU_CD等字段。結果優化的不是很理想。
查了一下 上一篇網友提供的步驟，覺得思路特別對，於是就按照執行了一遍。然后查看了alert日志，看了看臨時表空間和系統表空間的狀況，結果兩個節點都很正常沒有問題；最后懷疑是表鎖的問題。
 
  1.  
    SELECT l.session_id sid, s.serial#, l.locked_mode, l.oracle_username, s.user#,
  2.  
    l.os_user_name,s.machine, s.terminal,a.sql_text, a.action
  3.  
    FROM v$sqlarea a,v$session s, v$locked_object l
  4.  
    WHERE l.session_id = s.sid
  5.  
    AND s.prev_sql_addr = a.address
  6.  
    ORDER BY sid, s.serial#;

也沒有鎖表的問題。奇怪，最后查了一下所有連接庫的session運行情況。
  1.  
    select distinct a.sid,b.SERIAL#,b.PROCESS,b.STATUS from v$session_wait a,v$session b
  2.  
    where a.SID=b.SID

最后查出來有一堆的session，基本分不清什么連接，於是粗暴的把session 全部kill掉：
  1.  
    alter system kill session '2,1';
  2.  
    alter system kill session '69,1';
  3.  
    alter system kill session '70,3';
  4.  
    alter system kill session '71,7';
  5.  
    alter system kill session '76,443';
  6.  
    alter system kill session '126,3';
  7.  
    alter system kill session '131,1';
  8.  
    alter system kill session '134,9';
  9.  
    alter system kill session '192,1';
  10.  
    alter system kill session '3,1';
  11.  
    alter system kill session '4,3';
  12.  
    alter system kill session '5,1';
  13.  
    alter system kill session '125,1';
  14.  
    alter system kill session '6,1';
  15.  
    alter system kill session '67,1';
  16.  
    alter system kill session '127,3';
  17.  
    alter system kill session '190,1';
  18.  
    alter system kill session '66,1';
  19.  
    alter system kill session '128,1';
  20.  
    alter system kill session '129,1';
  21.  
    alter system kill session '144,3023';
  22.  
    alter system kill session '187,1';
  23.  
    alter system kill session '194,2149';
  24.  
    alter system kill session '1,1';
  25.  
    alter system kill session '189,1';
  26.  
    alter system kill session '196,3';
  27.  
    alter system kill session '7,3';
  28.  
    alter system kill session '132,11';
  29.  
    alter system kill session '193,1';
  30.  
    alter system kill session '197,6729';
  31.  
    alter system kill session '9,3';
  32.  
    alter system kill session '10,3';
  33.  
    alter system kill session '65,1';
  34.  
    alter system kill session '64,1';
  35.  
    alter system kill session '75,1567';
  36.  
    alter system kill session '188,1';
  37.  
    alter system kill session '191,1';

執行上面語句后去查詢表依然還是長時間不能出來結果，
且在v$session里查這些session都標記為killed了，然后就想到了到操作系統級別將這些session進程占用的資源徹底的給釋放掉，如下：
在linux下執行：
ps -aux|grep ora;
 
  1.  
    oracle 23485 0.0 0.2 3440784 22132 ? Ss 18:50 0:00 ora_pmon_cdzfrac1
  2.  
    oracle 23487 0.1 0.2 3440424 17600 ? Ss 18:50 0:00 ora_psp0_cdzfrac1
  3.  
    oracle 23489 1.6 0.2 3438356 17188 ? Ss 18:50 0:00 ora_vktm_cdzfrac1
  4.  
    oracle 23493 0.0 0.2 3440040 19592 ? Ss 18:50 0:00 ora_gen0_cdzfrac1
  5.  
    oracle 23495 0.1 0.3 3444520 25228 ? Ss 18:50 0:00 ora_diag_cdzfrac1
  6.  
    oracle 23497 0.1 0.3 3441960 28800 ? Ss 18:50 0:00 ora_dbrm_cdzfrac1
  7.  
    oracle 23499 0.0 0.2 3438356 18056 ? Ss 18:50 0:00 ora_ping_cdzfrac1
  8.  
    oracle 23501 0.0 0.2 3438356 17236 ? Ss 18:50 0:00 ora_acms_cdzfrac1
  9.  
    oracle 23503 0.2 0.3 3446568 31328 ? Ss 18:50 0:00 ora_dia0_cdzfrac1
  10.  
    oracle 23506 0.3 0.5 3452964 48656 ? Ss 18:50 0:00 ora_lmon_cdzfrac1
  11.  
    oracle 23508 1.9 0.4 3454660 39888 ? Ss 18:50 0:00 ora_lmd0_cdzfrac1
  12.  
    oracle 23510 1.0 1.2 3453268 100168 ? Ss 18:50 0:00 ora_lms0_cdzfrac1
  13.  
    oracle 23514 1.0 1.2 3453268 100380 ? Ss 18:50 0:00 ora_lms1_cdzfrac1
  14.  
    oracle 23518 0.0 0.2 3438356 18120 ? Ss 18:50 0:00 ora_rms0_cdzfrac1
  15.  
    oracle 23520 0.0 0.2 3438952 19564 ? Ss 18:50 0:00 ora_lmhb_cdzfrac1
  16.  
    oracle 23522 1.8 2.6 3438356 216396 ? Ss 18:50 0:00 ora_mman_cdzfrac1
  17.  
    oracle 23524 0.0 0.3 3449252 28544 ? Ss 18:50 0:00 ora_dbw0_cdzfrac1
  18.  
    oracle 23526 0.1 0.4 3464124 40288 ? Ss 18:50 0:00 ora_lgwr_cdzfrac1
  19.  
    oracle 23528 0.0 0.3 3442620 26648 ? Ss 18:50 0:00 ora_ckpt_cdzfrac1
  20.  
    oracle 23530 0.3 0.5 3441976 43860 ? Ss 18:50 0:00 ora_smon_cdzfrac1
  21.  
    oracle 23532 0.0 0.2 3438356 17476 ? Ss 18:50 0:00 ora_reco_cdzfrac1
  22.  
    oracle 23534 0.0 0.2 3441020 20968 ? Ss 18:50 0:00 ora_rbal_cdzfrac1
  23.  
    oracle 23536 0.0 0.2 3440236 23272 ? Ss 18:50 0:00 ora_asmb_cdzfrac1
  24.  
    oracle 23538 2.1 1.0 3446932 86268 ? Ss 18:50 0:00 ora_mmon_cdzfrac1
  25.  
    oracle 23542 0.0 0.2 3439588 23952 ? Ss 18:50 0:00 ora_mmnl_cdzfrac1
  26.  
    oracle 23544 0.0 0.2 3444612 17456 ? Ss 18:50 0:00 ora_d000_cdzfrac1
  27.  
    oracle 23546 0.0 0.3 3446068 25048 ? Ss 18:50 0:00 ora_mark_cdzfrac1
  28.  
    oracle 23548 0.0 0.1 3439552 16184 ? Ss 18:50 0:00 ora_s000_cdzfrac1
  29.  
    oracle 23550 0.1 0.2 3440236 21196 ? Ss 18:50 0:00 ora_ocf0_cdzfrac1
  30.  
    oracle 23554 2.2 0.4 3439464 35864 ? Ss 18:50 0:00 ora_lck0_cdzfrac1
  31.  
    oracle 23556 0.0 0.2 3444372 22148 ? Ss 18:50 0:00 ora_rsmn_cdzfrac1
  32.  
    oracle 23575 0.1 0.2 3439836 19432 ? Ss 18:50 0:00 ora_o000_cdzfrac1
  33.  
    oracle 23595 0.0 0.2 3438356 17464 ? Ss 18:50 0:00 ora_gtx0_cdzfrac1
  34.  
    oracle 23597 0.1 0.3 3438888 24540 ? Ss 18:50 0:00 ora_rcbg_cdzfrac1
  35.  
    oracle 23601 0.0 0.2 3438356 18248 ? Ss 18:50 0:00 ora_qmnc_cdzfrac1
  36.  
    oracle 23603 0.5 0.4 3445076 33124 ? Ss 18:50 0:00 ora_q000_cdzfrac1
  37.  
    oracle 23605 1.3 0.5 3445200 45316 ? Ss 18:50 0:00 ora_q001_cdzfrac1
  38.  
    oracle 23648 0.6 0.3 3439888 29068 ? Ss 18:50 0:00 ora_pz99_cdzfrac1
  39.  
    oracle 23662 4.2 0.5 3447084 46432 ? Ss 18:50 0:00 ora_cjq0_cdzfrac1
  40.  
    root 23663 0.0 0.0 110240 1176 pts/1 R+ 18:51 0:00 ps -aux

基本也分不清這都是什么，因為我們是RAC兩台服務器，害怕把所有oracle的進程關閉后，數據庫也癱了。
於是查了查，找spid對應的進程ID。
  1.  
    select distinct a.sid,b.SERIAL#,b.PROCESS,b.STATUS from v$session_wait a,v$session b
  2.  
    where a.SID=b.SID

找出來之后，全部kill掉。
kill -9 23662;
再去查詢表，結果很快就出來了.頓時覺得 這個世界又美好了一點。
后來看了一下，他們寫的程序，有一個后台線程，多次在執行掃數據的操作，一條報文的數據在2000條左右，一次更新2000條數據做的都是update操作，鎖表的情況很嚴重，導致session超時。好了，問題找着了，已經讓他們去重新寫這個程序了。
 
記錄一下此次檢查的工作，接下來好好想想，大批量的插入更新的整體架構設計，能不能用上並發等手段去解決他們的頻繁掃描插入更新表數據的情況。


免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。



猜您在找 數據庫查詢速度極慢【個人工作問題解決過程記錄】 一次delete速度異常慢的處理過程 【linux】記錄一次系統被攻擊的處理過程 記錄一下折騰webp 的過程 記錄一下從懵懂到理解RESTful的過程 Oracle數據庫查詢優化方案（處理上百萬級記錄如何提高處理查詢速度） Oracle數據庫查詢優化方案（處理上百萬級記錄如何提高處理查詢速度） mysql的連接處理過程 記錄一下我在ubuntu下安裝 minikube的過程 HDMI SCDC處理過程
 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM