• <fieldset id="8imwq"><menu id="8imwq"></menu></fieldset>
  • <bdo id="8imwq"><input id="8imwq"></input></bdo>
    最新文章專題視頻專題問答1問答10問答100問答1000問答2000關鍵字專題1關鍵字專題50關鍵字專題500關鍵字專題1500TAG最新視頻文章推薦1 推薦3 推薦5 推薦7 推薦9 推薦11 推薦13 推薦15 推薦17 推薦19 推薦21 推薦23 推薦25 推薦27 推薦29 推薦31 推薦33 推薦35 推薦37視頻文章20視頻文章30視頻文章40視頻文章50視頻文章60 視頻文章70視頻文章80視頻文章90視頻文章100視頻文章120視頻文章140 視頻2關鍵字專題關鍵字專題tag2tag3文章專題文章專題2文章索引1文章索引2文章索引3文章索引4文章索引5123456789101112131415文章專題3
    問答文章1 問答文章501 問答文章1001 問答文章1501 問答文章2001 問答文章2501 問答文章3001 問答文章3501 問答文章4001 問答文章4501 問答文章5001 問答文章5501 問答文章6001 問答文章6501 問答文章7001 問答文章7501 問答文章8001 問答文章8501 問答文章9001 問答文章9501
    當前位置: 首頁 - 科技 - 知識百科 - 正文

    記DG備庫CPU消耗達到瓶頸的修復

    來源:懂視網 責編:小采 時間:2020-11-09 16:08:19
    文檔

    記DG備庫CPU消耗達到瓶頸的修復

    記DG備庫CPU消耗達到瓶頸的修復:DG standby 不定時CPU消耗達到瓶頸,重啟數據庫后問題解除嗎,由于備庫未對外提供任何服務,理論上不應該出現該問題 問題描述:DG standby 不定時CPU消耗達到瓶頸,重啟數據庫后問題解除嗎,由于備庫未對外提供任何服務,理論上不應該出現該問題 解決步驟
    推薦度:
    導讀記DG備庫CPU消耗達到瓶頸的修復:DG standby 不定時CPU消耗達到瓶頸,重啟數據庫后問題解除嗎,由于備庫未對外提供任何服務,理論上不應該出現該問題 問題描述:DG standby 不定時CPU消耗達到瓶頸,重啟數據庫后問題解除嗎,由于備庫未對外提供任何服務,理論上不應該出現該問題 解決步驟

    DG standby 不定時CPU消耗達到瓶頸,重啟數據庫后問題解除嗎,由于備庫未對外提供任何服務,理論上不應該出現該問題

    問題描述:
    DG standby 不定時CPU消耗達到瓶頸,重啟數據庫后問題解除嗎,由于備庫未對外提供任何服務,理論上不應該出現該問題

    解決步驟:

    在CPU消耗達到瓶頸時查看等待事件

    SELECT Sid, Event, P1text, P1, P2text, P2, P3text, P3
    FROM V$session_Wait
    WHERE Event NOT LIKE '%SQL%'
    AND Event NOT LIKE '%rdbms%'
    AND Event NOT LIKE '%mon%'
    ORDER BY Event;

    記DG備庫CPU消耗達到瓶頸的修復

    根據top觀察出消耗cpu100%的進程,查詢得到的sid果然是1346

    select a.sid, b.spid, a.serial#

    from v$session a, v$process b

    where a.paddr = b.addr

    and b.spid = '19034'

    記DG備庫CPU消耗達到瓶頸的修復

    記DG備庫CPU消耗達到瓶頸的修復

    問題已經定位,是新的會話連接到數據庫后library cache: mutex X事件致使數據庫hang住

    library cache: mutex X是11g時用來替換之前的library cache latch,主要作用是在hash bucket中定位handle時使用。

    期初懷疑是數據庫內存自動管理,數據庫pga,sga在備庫執行recover時來回收縮頻率過多導致,修改成了手動管理

    后期觀察發現問題仍然存在~

    dump出該回話的trace信息

    exec dbms_system.set_ev(1346,43,10046,12,'');

    執行一個SQL

    exec dbms_system.set_ev(1346,43,0,0,'');

    查詢當前session的trace文件SQL

    select d.value || 'http://www.linuxidc.com/' || lower(rtrim(i.instance, chr(0))) || '_ora_' ||

    p.spid || '.trc' trace_file_name

    from (select p.spid

    from sys.v$mystat m, sys.v$session s, sys.v$process p

    where m.statistic# = 1

    and s.sid = m.sid

    and p.addr = s.paddr) p,

    (select t.instance

    from sys.v$thread t, sys.v$parameter v

    where v.name = 'thread'

    and (v.value = 0 or t.thread# = to_number(v.value))) i,

    (select value from sys.v$parameter where name = 'user_dump_dest') d

    /

    觀察trace

    記DG備庫CPU消耗達到瓶頸的修復

    該等待一直有,會話一直hang住,查詢數據庫發現在等待library cache lock,數據庫沒有任何業務,,dg的歸檔應用也正常

    查看官方,發現有關11glibrary cache: mutex 的bug還真不少,主要涉及的應該是如下兩個:

    9530750 High waits for ‘library cache: mutex X’ for cursor Build lock

    10145558 Selects on library cache V$/X$ views cause “library cache: mutex X” waits

    解決方法:
    為數據庫打上相應的補丁包,p14727315_112020_Linux-x86-64.zip是11.2.0.2版本最后一個補丁包psu9
    打補丁過程記錄如下:
    下載opatch和補丁包
    p6880880_112000_Linux-x86-64.zip
    p14727315_112020_Linux-x86-64.zip

    解壓下載后的兩個zip包
    [Oracle@54-Oracle-Fog-Backup ~]$ cp OPatch/ $ORACLE_HOME/ -r
    [oracle@54-Oracle-Fog-Backup ~]$ cd $ORACLE_HOME
    [oracle@54-Oracle-Fog-Backup dbhome_1]$ cd OPatch/
    [oracle@54-Oracle-Fog-Backup OPatch]$ ls
    crs emdpatch.pl jlib opatch opatchdiag opatch.ini opatchprereqs README.txt
    docs fmw ocm opatch.bat opatchdiag.bat opatch.pl oplan

    [oracle@54-Oracle-Fog-Backup OPatch]$ ./opatch lsinventory
    Oracle Interim Patch Installer version 11.2.0.3.0
    Copyright (c) 2012, Oracle Corporation. All rights reserved.
    Oracle Home : /opt/app/oracle/product/11.2.0/dbhome_1
    Central Inventory : /opt/app/oraInventory
    from : /opt/app/oracle/product/11.2.0/dbhome_1/oraInst.loc
    OPatch version : 11.2.0.3.0
    OUI version : 11.2.0.2.0
    Log file location : /opt/app/oracle/product/11.2.0/dbhome_1/cfgtoollogs/opatch/opatch2015-09-17_14-02-19PM_1.log
    Lsinventory Output file location : /opt/app/oracle/product/11.2.0/dbhome_1/cfgtoollogs/opatch/lsinv/lsinventory2015-09-17_14-02-19PM.txt

    --------------------------------------------------------------------------------
    Installed Top-level Products (1):
    Oracle Database 11g 11.2.0.2.0
    There are 1 products installed in this Oracle Home.
    There are no Interim patches installed in this Oracle Home
    --------------------------------------------------------------------------------
    OPatch succeeded.

    [oracle@54-Oracle-Fog-Backup OPatch]$ ./opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /home/oracle/14727315/
    Oracle Interim Patch Installer version 11.2.0.3.0
    Copyright (c) 2012, Oracle Corporation. All rights reserved.

    PREREQ session

    聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com

    文檔

    記DG備庫CPU消耗達到瓶頸的修復

    記DG備庫CPU消耗達到瓶頸的修復:DG standby 不定時CPU消耗達到瓶頸,重啟數據庫后問題解除嗎,由于備庫未對外提供任何服務,理論上不應該出現該問題 問題描述:DG standby 不定時CPU消耗達到瓶頸,重啟數據庫后問題解除嗎,由于備庫未對外提供任何服務,理論上不應該出現該問題 解決步驟
    推薦度:
    • 熱門焦點

    最新推薦

    猜你喜歡

    熱門推薦

    專題
    Top
    主站蜘蛛池模板: 无码精品久久久久久人妻中字| 亚洲性日韩精品国产一区二区| 亚洲无码日韩精品第一页| 国产成人精品久久二区二区| 亚洲欧美日韩另类精品一区二区三区| 2021国产成人精品久久| 国产精品无码久久久久久| 亚洲精品少妇30p| 久热精品视频第一页| 粉嫩精品美女国产在线观看| 国产精品麻豆高清在线观看| 精品无码国产污污污免费网站| 亚洲欧美日韩国产精品| 欧美成人精品一区二三区在线观看| 99热精品毛片全部国产无缓冲| 国内精品91最新在线观看| 久久精品国产亚洲AV电影| 亚洲精品卡2卡3卡4卡5卡区| 日韩人妻无码精品无码中文字幕| 惠民福利中文字幕人妻无码乱精品 | 精品国产福利盛宴在线观看| 色播精品免费小视频| 国产精品久久永久免费| 91精品国产91久久综合| 国产精品内射后入合集| 精品黑人一区二区三区| 欧美午夜精品久久久久免费视| 亚洲精品乱码久久久久久久久久久久| 四虎国产精品永免费| 精品多毛少妇人妻AV免费久久 | 亚洲AV无码久久精品蜜桃| 四虎精品免费永久免费视频| 精品伦精品一区二区三区视频 | 2021精品国产综合久久| 2022国产精品福利在线观看| 国产乱子伦精品无码码专区| 久久精品99久久香蕉国产色戒| 精品一区二区三区无码免费视频| 乱码精品一区二区三区| 国产AV午夜精品一区二区入口| jizz国产精品网站|