成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

Oracle Redo的并行機制運行中要用到的代碼

數據庫 Oracle
以下的文章主要介紹的是Oracle Redo的并行機制的實際操作,以及其相關實際應用代碼的介紹,以下就是文章的具體內容的分析。

我們今天主要介紹的是Redo log 恢復與高級特性的重要相關數據,我們大家都知道一個Oracle redo條目包含了相應操作導致的數據庫變化的所有的信息,所有redo條目最終都要被寫入redo文件中去。

Redo log buffer是為了避免Redo文件IO導致性能瓶頸而在sga中分配出的一塊內存。

一個redo條目首先在用戶內存(PGA)中產生,然后由oracle服務進程拷貝到log buffer中,當滿足一定條件時,再由LGWR進程寫入Oracle redo文件。

由于log buffer是一塊“共享”內存,為了避免沖突,它是受到redo allocation latch保護的,每個服務進程需要先獲取到該latch才能分配redo buffer。因此在高并發且數據修改頻繁的oltp系統中,我們通??梢杂^察到redo allocation latch的等待。Redo寫入redo buffer的整個過程如下:

在PGA中生產Redo Enrey -> 服務進程獲取Redo Copy latch(存在多個---CPU_COUNT*2) -> 服務進程獲取redo allocation latch(僅1個) -> 分配log buffer -> 釋放redo allocation latch -> 將Redo Entry寫入Log Buffer -> 釋放Redo Copy latch;

 

  1. shared strand 

為了減少redo allocation latch等待,在oracle 9.2中,引入了log buffer的并行機制。其基本原理就是,將log buffer劃分為多個小的buffer,這些小的buffer被成為strand(為了和之后出現的private strand區別,它們被稱之為shared strand)。

每一個strand受到一個單獨redo allocation latch的保護。多個shared strand的出現,使原來序列化的redo buffer分配變成了并行的過程,從而減少了Oracle redo allocation latch等待。

shared strand的初始數據量是由參數log_parallelism控制的;在10g中,該參數成為隱含參數,并新增參數_log_parallelism_max控制shared strand的***數量;_log_parallelism_dynamic則控制是否允許shared strand數量在_log_parallelism和_log_parallelism_max之間動態變化。

  1. HELLODBA.COM>select nam.ksppinm, val.KSPPSTVL, nam.ksppdesc   
  2. 2 from sys.x$ksppi nam,   
  3. 3 sys.x$ksppsv val   
  4. 4 where nam.indx = val.indx   
  5. 5 --AND nam.ksppinm LIKE '_%'   
  6. 6 AND upper(nam.ksppinm) LIKE '%LOG_PARALLE%';   
  7.  
  8. KSPPINM KSPPSTVL KSPPDESC   
  9. -------------------------- ---------- ------------------------------------------   
  10. _log_parallelism 1 Number of log buffer strands   
  11. _log_parallelism_max 2 Maximum number of log buffer strands   
  12. _log_parallelism_dynamic TRUE Enable dynamic strands  

每一個shared strand的大小 = log_buffer/(shared strand數量)。strand信息可以由表x$kcrfstrand查到(包含shared strand和后面介紹的private strand,10g以后存在)?!?/p>

  1. HELLODBA.COM>select indx,strand_size_kcrfa from x$kcrfstrand where last_buf_kcrfa != '00';   
  2. INDX STRAND_SIZE_KCRFA   
  3. ---------- -----------------   
  4. 0 3514368   
  5. 1 3514368   
  6. HELLODBA.COM>show parameter log_buffer   
  7. NAME TYPE VALUE   
  8. ------------------------------------ ----------- ------------------------------   
  9. log_buffer integer 7028736   

關于shared strand的數量設置,16個cpu之內***默認為2,當系統中存在Oracle redo allocation latch等待時,每增加16個cpu可以考慮增加1個strand,***不應該超過8。并且_log_parallelism_max不允許大于cpu_count。

注意:在11g中,參數_log_parallelism被取消,shared strand數量由_log_parallelism_max、_log_parallelism_dynamic和cpu_count控制。

 

 

  1. Private strand 

為了進一步降低redo buffer沖突,在10g中引入了新的strand機制——Private strand。Private strand不是從log buffer中劃分的,而是在shared pool中分配的一塊內存空間?!?/p>

 

  1. HELLODBA.COM>select * from V$sgastat where name like '%strand%';  
  2. POOL NAME BYTES  
  3. ------------ -------------------------- ----------  
  4. shared pool private strands 2684928  
  5. HELLODBA.COM>select indx,strand_size_kcrfa from x$kcrfstrand where last_buf_kcrfa = '00';  
  6. INDX STRAND_SIZE_KCRFA  
  7. ---------- -----------------  
  8. 2 66560  
  9. 3 66560  
  10. 4 66560  
  11. 5 66560  
  12. 6 66560  
  13. 7 66560  
  14. 8 66560  
  15. ...  

Private strand的引入為Oracle的Oracle Redo/Undo機制帶來很大的變化。每一個Private strand受到一個單獨的redo allocation latch保護,每個Private strand作為“私有的”strand只會服務于一個活動事務。

獲取到了Private strand的用戶事務不是在PGA中而是在Private strand生成Redo,當flush private strand或者commit時,Private strand被批量寫入log文件中。如果新事務申請不到Private strand的redo allocation latch,則會繼續遵循舊的redo buffer機制,申請寫入shared strand中。事務是否使用Private strand,可以由x$ktcxb的字段ktcxbflg的新增的第13位鑒定:

 

  1. HELLODBA.COM>select decode(bitand(ktcxbflg, 4096),0,1,0) used_private_strand, count(*)  
  2. 2 from x$ktcxb  
  3. 3 where bitand(ksspaflg, 1) != 0  
  4. 4 and bitand(ktcxbflg, 2) != 0  
  5. 5 group by bitand(ktcxbflg, 4096);  
  6. USED_PRIVATE_STRAND COUNT(*)  
  7. ------------------- ----------  
  8. 1 10  
  9. 0 1  

對于使用Private strand的事務,無需先申請Oracle Redo Copy Latch,也無需申請Shared Strand的redo allocation latch,而是flush或commit是批量寫入磁盤,因此減少了Redo Copy Latch和redo allocation latch申請/釋放次數、也減少了這些latch的等待,從而降低了CPU的負荷。過程如下:

事務開始 -> 申請Private strand的redo allocation latch (申請失敗則申請Shared Strand的redo allocation latch) -> 在Private strand中生產Redo Enrey -> Flush/Commit -> 申請Redo Copy Latch -> 服務進程將Redo Entry批量寫入Log File -> 釋放Redo Copy Latch -> 釋放Private strand的redo allocation latch

注意:對于未能獲取到Private strand的Oracle redo allocation latch的事務,在事務結束前,即使已經有其它事務釋放了Private strand,也不會再申請Private strand了

責任編輯:佚名 來源: 互聯網
相關推薦

2010-01-06 09:30:51

Oracle Redo

2010-04-27 09:38:57

Oracle修改表ow

2010-07-06 16:45:39

SQL Server創

2010-04-27 10:32:54

Oracle優化CPU

2010-07-13 10:28:41

SQL Server

2010-07-06 17:02:45

SQL Server創

2012-11-21 17:19:55

2010-03-29 17:03:48

Oracle創建

2010-05-06 17:54:54

Oracle鎖

2010-08-18 14:44:24

JDBC連接DB2實例

2010-05-07 12:46:08

Oracle redo

2014-03-06 15:49:36

iOS開源庫匯總

2010-06-11 17:36:46

MySQL語句

2010-06-12 10:49:12

2010-08-17 11:03:01

DB2恢復誤刪除表

2010-08-16 15:06:15

DB2數據類型轉換

2010-08-12 17:23:20

DB2存儲過程編寫流程

2011-03-24 17:21:42

Oracle數據庫Redo故障

2010-10-27 13:54:18

Oracle并行查詢

2010-04-01 18:08:48

Oracle導入
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: av在线一区二区三区 | 国产精品18久久久久久久 | 亚洲一二三区免费 | 国产免费拔擦拔擦8x高清 | 中文字幕一区在线观看视频 | 精品国产久 | 成人亚洲精品 | 中文字幕av免费 | 欧美成人精品一区 | 亚洲成人久久久 | 国产精品不卡 | 日本精品视频一区二区 | 欧美成人精品在线观看 | 欧美日韩在线观看一区 | 一区二区三区免费在线观看 | 欧美精品a∨在线观看不卡 欧美日韩中文字幕在线播放 | 成人久久久 | 一区二区三区四区在线视频 | 日韩91| 免费视频99 | 精品久久久久久久久久 | 国产精品毛片一区二区三区 | 性高湖久久久久久久久aaaaa | 亚洲精品一区在线 | 国产精品高潮呻吟久久av野狼 | 91一区二区三区在线观看 | 成人国产精品久久 | 欧美日韩视频在线 | 九色网址 | 日韩在线视频播放 | 精品日韩在线 | 国产伦精品 | 国产欧美日韩视频 | 国产一级淫片免费视频 | 国产一区二区自拍 | 免费在线观看av网址 | 天堂资源最新在线 | 国产欧美一区二区在线观看 | 精品国产99 | 国产高清精品在线 | 在线视频 亚洲 |