2. 程式人生 > >OGG複製程序延遲高，優化方法一(使用索引)

OGG複製程序延遲高，優化方法一(使用索引)

阿新 • • 發佈：2020-08-10

日常運維過程中，可能發現OGG同步程序延遲很高；

本篇介紹其中的一種方式。

OGG複製程序，或者說同步程序及通過解析ogg trail檔案，輸出dml語句，在目標庫執行dml操作，那麼延遲高可能性其一、執行dml操作效率太低。 本篇不考慮併發過高或其它原因。 本次只考慮是執行update or delete的時候SQL效率執行太差！

導致OGG複製程序延遲很高。

 

GGSCI > info all

Program     Status      Group       Lag at Chkpt  Time Since Chkpt

MANAGER     RUNNING                                                                                    

REPLICAT    RUNNING     RP10        00:00:00      00:00:03  
延遲說明參考
https://www.onekbit.com/ViewBlog/blog/BID20200408100342

一 、Time Since Checkpoint 過高

       指ogg的extract或replicat程序產生最近的一個檢查點，再從這個檢查點到目前為止有多長時間沒有更新了，即最近一個檢查點與當前系統時間的時間差。該值可以通過info看到是在不斷變化(特別是當處理長會話時，會持續增長，直到處理完該長會話)。

       對於複製程序來說，如果Time Since Chkpt 延遲有2個小時，說明這個程序存在2個小時檢查點未更新，也就說明有一個或多個組合成的大事務，執行了2個小時，並未執行成功？？？

      正常情況下，OGG遇到異常報錯，導致OGG程序中斷Time Since Chkpt 50個小時後，解決報錯後，啟動該程序，一般來說2分內，會執行成功最少一個事務，會寫入新的檢查點，延遲的50個小時，會自動轉換為lag at chkpt 50小時延遲。

      異常情況或者說需要優化調整的情況是，啟動程序，發現time since chkpt 延遲一直遞增，不減少。說明存在事務未執行完畢。  

   實際遇到的情況1，程序同步4個表，其中一個表很大10G，並且目標端無主鍵！！！ 

    因此目標端執行一條update sql執行效率非常低。  如何處理？？？

     

1.表存在主鍵
select   *   from   user_cons_columns   
  where   constraint_name   =   (select   constraint_name   from   user_constraints   
              where   table_name   =   'BST_FAVORITE'  and   constraint_type   ='P');   
2.對OGG複製程序新增引數指定主鍵列
map source_owner.table_name target target_owner.table_name;
新增引數
map source_owner.table_name target target_owner.table_name，keycols(primary_column_name);
3.對於不存在主鍵的表呢？？？
select count(*) from xxx; 得到表的數量，如果表很大，不執行最好。
通過dba_tab_columns 根據NUM_DISTINCT 得到最多distinct的列，及選擇性好的列。
SQL> select COLUMN_NAME,NUM_NULLS,NUM_DISTINCT,to_char(LAST_ANALYZED,'yyyy-mm-dd') as "date" from dba_tab_columns where owner='cc' and table_name='cc' order by 3;
結合表的索引列
select a.uniqueness 索引型別,b.index_name 索引名稱,b.column_name 欄位 from user_indexes a ,user_ind_columns b
where a.table_name=b.table_name and a.index_name = b.index_name and a.table_owner=upper('SAPSR3') and  a.table_name='ANLU' order by a.uniqueness desc;   如果存在索引，並且選擇性足夠好，雖然不是主鍵列，但是可以直接使用keycols指定；   如果不存在索引？ 或者索引的選擇性不夠好，可以新增一個選擇性好的索引，隨後使用keycols進行指定。   ！！！ 缺陷或者風險在於，因為是非主鍵，及時選擇性好，如果存在null值,還是無法使用該索引，OGG 程序對應資料庫session 執行SQL還是慢。 但是正常情況下可以解決該問題。 並且存在一個疑問，如果假設源端修改了一條記錄，但是選擇性好的column_name 在目標端對應2條記錄，並且ogg複製程序使用keycols引數指定？  那麼目標端是修改更新2條記錄？ 還是1條記錄呢？？？ 後續進行測試。

 

二、Lag at Chkpt

 lag是複製程序處理最後一條記錄的作業系統時間和此條記錄在trail檔案中記錄的時間戳的差值，這裡需要注意的是lag延遲只有在檢查點更新時才會更新，所以這個值不是實時更新的，具有一定的離散性，實際上應該理解成最後一個檢查點的最後一條記錄與當前系統時間的時間差。 

借鑑

 Replicat負責資料的入庫，一般速度相對於主extract和data pump較慢，容易產生較大延遲。當replicat出現延遲後，需要對程序進行調優或者拆分，具體步驟參照本文件上一節。一般調優完成後，在日常業務狀態下應當不存在較大延遲（一般幾秒到一分鐘以內）；
當出現批處理時，可以允許一定的延遲，一般以不影響第二天的正常業務為準 – 例如，如果批處理每天早上4點前結束，可以控制延遲在2小時以內。

        因此，首先需要確定OGG複製所允許的最大延遲在日常業務和批處理時的目標是什麼，然後一旦達不到此目標就要依據上上面介紹的方法進行效能的調優。

自我理解：  按照我們實際運維的情況，OGG同步資料也是根據業務要求分級別的。

    例如OGG鏈路1，是用於資料報表生成，那麼必須保證業務每天在8點~10點之間是OGG無延遲，否則延遲高哪怕是10分鐘，也可能導致報表不準確，因此這種OGG鏈路的複製 不允許在7~10點存在明顯延遲。

   例如OGG鏈路2，用於OGG災備環境，重要性沒那麼重要，因此保證OGG複製程序1天內或者3天內資料同步即可。 

   站在運維的角度，需要結合實際情況考慮OGG重要程度，進行評估。  如果不影響業務，純粹的延遲可以忽略。

   實際遇到延遲50小時。
 本次講述通過索引加快OGG同步方式；

2.1 定位OGG複製程序在oracle資料庫中的Session


$ps -ef|grep RP10
PID
20  RP10 ······
$ps -ef|grep 20
PID
60864  LOCAL=NO   [OGG Session process]
SQL> select s.sid,s.serial#,sql_id,p.program from v$process p,v$session s where p.addr=s.paddr and p.spid=60864;

       SID    SERIAL# SQL_ID         PROGRAM
------------------------------------------------
      2276    37851 2j664   oracle@cc (TNS V1-V3)

2.2 定位造成OGG複製程序延遲過高的SQL

通過ash檢視，查詢1天內這個OGG程序 session ，都在執行什麼sql ,event資訊。 ash檢視間隔1s取樣 active session 1次。因此捕捉到的次數越多，說明消耗花費的時間越多。
select sql_id,event,BLOCKING_SESSION,CURRENT_OBJ#,count(*) from v$active_session_history where SAMPLE_TIME>sysdate-1 and SESSION_ID=2276  and SESSION_SERIAL#=37851
 group by sql_id,event,BLOCKING_SESSION,CURRENT_OBJ# order by 5,4;
SQL_ID          EVENT                                   BLOCKING_SESSION CURRENT_OBJ#   COUNT(*)
------------- ---------------------------------------------------------------- ---------------- ------------ ----------
1n7zz8wb86jpw                                                   0         16
088mh1tws6wtm                                                  -1         19
2jt8ttg6b42b4                                                   0         75
9y2087cvvr4r9                                                   0        115
1n7zz8wb86jpw                                                  -1       4575
2cc4                                                           -1      18877
9y2087ccc9                                                     -1      62497
10 rows selected.

select * from table(dbms_xplan.display_cursor('2ccb4'));
SQL> select * from table(dbms_xplan.display_cursor('9ycc'));
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID    xx, child number 0
-------------------------------------
DELETE FROM "W"."DT"  WHERE "U_ID"
= :b0 AND 多個列  ······ AND "C_SORT"
= :b18 AND ROWNUM = 1
PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
Plan hash value: 3610703515
----------------------------------------------------------------------------------------------------
| Id  | Operation        | Name               | Rows  | Bytes | Cost (%CPU)| Time       |
----------------------------------------------------------------------------------------------------
|   0 | DELETE STATEMENT    |                   |       |       | 24025 (100)|       |
|   1 |  DELETE         | DT |       |       |        |       |
|*  2 |   COUNT STOPKEY     |                   |       |       |        |       |
|*  3 |    TABLE ACCESS FULL| DT |     1 |  3312 | 24025   (1)| 00:04:49 |
----------------------------------------------------------------------------------------------------
PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - filter(ROWNUM=1)
   3 - filter(("U_ID"=:B0 AND 多個列······ "O_SORT"=TO_NUMBER(:B18))) 35 rows selected. 

距離，兩個SQL 同一個表，都是delete操作，幾乎相同。 執行幾乎全表掃描，表10G，當然慢了，對吧？  執行刪除1條記錄，需要訪問10G的資料。。。不慢才怪。

2.3 建立索引，加快OGG程序同步速度。

查詢表相關索引,不存在。
select index_owner,index_name,table_name,column_name,column_position from dba_ind_columns where table_name='DT' order by index_name,column_position;
null

查詢列的選擇性

select * from dba_tab_col_statistics where table_name='DT' order by column_name;
```````
OWNER                   TABLE_NAME              COLUMN_NAME             NUM_DISTINCT LOW_VALUE
------------------------------ ------------------------------ ------------------------------ ------------ ----------------------------------------------------------------
HIGH_VALUE                                DENSITY  NUM_NULLS NUM_BUCKETS LAST_ANAL SAMPLE_SIZE GLO USE AVG_COL_LEN HISTOGRAM
---------------------------------------------------------------- ---------- ---------- ----------- --------- ----------- --- --- ----------- ---------------
W                           DT                     U_ID                    0
                                      0         0         0 10-JUL-20         YES NO        0 NONE
······
19 rows selected.

SQL> select count(*) from "W"."DT";
  COUNT(*)
----------
    724643

GGSCI > stop Ogg_process

！注意，本次知道OGG對應是災備，不存在大量相關業務，慎用no_invalidate>false
exec dbms_stats.gather_table_stats(ownname=>'W',tabname=>'DT',cascade=>true,degree=>8,estimate_percent=>10,no_invalidate=>false) ;

再次查詢

OWNER                   TABLE_NAME              COLUMN_NAME             NUM_DISTINCT LOW_VALUE
------------------------------ ------------------------------ ------------------------------ ------------ ----------------------------------------------------------------
HIGH_VALUE                                DENSITY  NUM_NULLS NUM_BUCKETS LAST_ANAL SAMPLE_SIZE GLO USE AVG_COL_LEN HISTOGRAM
---------------------------------------------------------------- ---------- ---------- ----------- --------- ----------- --- --- ----------- ---------------
W                           DT                     U_ID      59346 3030303039366339386466663436356439636636653430663366323138383365 

6666666561356132333564363430616462303462643861393832383734303361 .00001685 0 1 08-AUG-20 70833 YES NO 32 NONE 19 
rows selected. 
exec dbms_stats.gather_table_stats(ownname=>'W',tabname=>'DT',cascade=>true,degree=>8,estimate_percent=>10,no_invalidate=>false) ;

查詢列的選擇性
select OWNER,TABLE_NAME,COLUMN_NAME,NUM_DISTINCT,NUM_NULLS,LAST_ANALYZED from dba_tab_col_statistics where table_name='DT' order by NUM_DISTINCT; 
OWNER TABLE_NAME COLUMN_NAME NUM_DISTINCT NUM_NULLS LAST_ANAL 

------------------------------ ------------------------------ ------------------------------ ------------ ---------- 
xx O_SORT 49853 0 08-AUG-20
xx U_ID   60063 0 08-AUG-20 19 
rows selected. 


select count(*) from ( select distinct U_ID,O_SORT from xx.xx);
 COUNT(*) 
---------- 
692924 
create index xx.xxon xx.cc(U_ID,O_SORT) parallel 6; 
alter index xx.xx parallel 1; 
exec dbms_stats.gather_table_stats(ownname=>'W',tabname=>'DT',cascade=>true,degree=>8,estimate_percent=>10,no_invalidate=>false) ;

GGSCI (obcdb36) 3> start ogg_process 
SQL> select * from table(dbms_xplan.display_cursor('2jt8ttg6b42b4'));
 ----------------------------------------------------------------------------------
 Plan hash value: 969284704 
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | 
-------------------------------------------------------------------------------------------------------------- 
| 0 | DELETE STATEMENT | | | | 2 (100)| | 
| 1 | DELETE | cc| | | | | 
|* 2 | COUNT STOPKEY | | | | | | 
|* 3 | TABLE ACCESS BY INDEX ROWID| cc| 1 | 191 | 2 (0)| 00:00:01 |
|* 4 | INDEX RANGE SCAN | IND_ID_SORT | 1 | | 2 (0)| 00:00:01 

至此，OGG使用索引加快了資料同步delete速度。

&n

相關推薦

OGG複製程序延遲高，優化方法一(使用索引)

日常運維過程中，可能發現OGG同步程序延遲很高； 本篇介紹其中的一種方式。 OGG複製程序，或者說同步程序及通過解析ogg trail檔案，輸出dml語句，在目標庫執行dml操作，那麼延遲高可能性其一、執行dml操作效率太低。 本篇不考慮併發過高或其它原因。 本次只考慮是執行update or delete的

OGG複製程序延遲高，優化方法二(存在索引),SQL選擇不好的索引

https://www.cnblogs.com/lvcha001/p/13469500.html 接前序，本次場景中有索引，但是OGG複製程序使用了低效率的索引？  類似SQL使用低效索引，如何讓Oracle使用好的索引，從而加快複製程序的效率呢？ 疑問？ Oracle為什麼有好的索引，但是還是選擇

php複製整個資料夾，此方法可鍋爐掉.svn資料夾

直接上程式碼，供大家參考使用。 //整個資料夾複製 $src原目錄資料夾，$dst目標資料夾 public function recurse_copy($src,$dst) { $dir = opendir($src); @mkdir($dst)

slave延遲很大優化方法

轉載自原文：http://imysql.com/2015/04/12/mysql-optimization-case-howto-resolve-slave-delay.shtml 一般而言，slave相對master延遲較大，其根本原因就是slave上的複製執行緒

MySQL性能優化方法一：緩存參數優化

內存大小 提高 算法 mysq 表數據 沒有 級別 data val 原文鏈接：http://isky000.com/database/mysql-perfornamce-tuning-cache-parameter 數據庫屬於 IO 密集型的應用程序，其主要職責就是數據的

svn IP地址變更後，解決方法(一)

（百度一下：svn 資訊改變後 eclipse右鍵卡死）在Eclipse開發平臺中，任意右鍵卡死，強制關閉Eclipse程序。（嘗試多次後發現是專案的svn伺服器地址變了，而我本地地址還沒有更新，結果一點選右鍵可能是eclipse svn外掛會去訪問這個不存在的svn伺

Python：類屬性，例項屬性，私有屬性與靜態方法，類方法，例項方法 屬性分為例項屬性與類屬性 方法分為普通方法，類方法，靜態方法 一：屬性： 　　儘量把需要使用者傳入的屬性作為例項屬性，而

屬性分為例項屬性與類屬性 方法分為普通方法，類方法，靜態方法 一：屬性： 　　儘量把需要使用者傳入的屬性作為例項屬性，而把同類都一樣的屬性作為類屬性。例項屬性在每創造一個例項時都會初始化一遍，不同的例項的例項屬性可能不同，不同例項的類屬性都相同。從而減少記憶體。 　　1：例項屬性： 　　　　最

基於Easyui框架的datagrid繫結資料，新增，修改，刪除方法(一)

基於Easyui框架的datagrid繫結資料，新增，修改，刪除方法 第一種：https://blog.csdn.net/u012949335/article/details/81943387 第二種：https://blog.csdn.net/u012949335/arti

JAVA程序佔用高記憶體原因分析與優化方法

首先看一下一個java程序的jmap輸出： 程式碼如下: [[email protected] ~]$ jmap -heap 837 Attaching to process ID 837, please wait... Debugger attached suc

安裝VMware,出現Microsoft Runtime DLL 安裝程序未能完成安裝，解決方法

程序 runtime time 找到 .com 運行 src 文件夾 color 　　安裝VMware Workstation 12 Player出現如下問題： 　　 　　解決方法： 　　　　1.出現這個問題的時候不要點確定（如果點了確定，會找不到步驟4中的文件夾） 　　　

Linux基礎管理——軟件包管理：rpm，yum高級使用方法（史上最全，沒有之一）

rpm yum 軟件包管理 yum倉庫 yum源地址配置 前言： GRU Linux操作系統中，實現軟件包管理的常見工具有RPM和yum；本專題將就Centos系統中安裝包的命名、校驗、密鑰導入導出、包安裝、卸載、升級、查詢等眾多rpm包管理相關的操作實現進行總結。1、安裝包1.1、

Mysql占用CPU過高如何優化，如何解決

lang 主服務器 disable mission 帳號 知識 用戶 clean oca 2017-02-28 15:13 331人閱讀 評論(0) 收藏 舉報 MySQL占用CPU過高如何優化 一次生產DB服務器的 超負荷運行問題解決： 1.查看生產

大數據量高並發訪問的數據庫優化方法

關聯表 cto 限制 數據庫中獲取數據 nio 返回 是個 ims 的確 ????假設不能設計一個合理的數據庫模型。不僅會添加client和server段程序的編

別在看不起女程序媛了，一個高顏值女程序媛的日常

歷史 所見 嘗試 女生 tro 想想 不堪 標簽 集中 我的日常 日常的上班狀態是這樣的 早晨到公司，打開電腦，打開知乎微博簡書先刷一遍，然後進入狀態，開始敲代碼，做自己的項目，在這個過程之中，上面扔過來一張圖，來我要這個這個效果，後臺發來一條消息，這有個不是後臺的bu

CAD圖紙轉換成高質量的PDF文件，兩種方法一步搞定哦

設計 彈出 雙擊 下載 顯示 快捷 pdf 搜索 鼠標 其實提到CAD，可能大家都大致的了解，CAD現在已經是建築行業運用的非常廣泛的一個設計軟件了，其實CAD就是一種計算機輔助軟件，可以高效的幫助我們進行圖紙的繪制。我們一般在設計完圖紙，可能定會轉換格式，以至於可以方便的

刪除掉了一個元素後，數組的索引發生的變化，造成了程序的異常解決方法

ble 變化 cti spl log this 索引 解決 del sureRuleDelete () { 　　this.deleteRuleDialog = false 　　for ( let i=this.tableData.length; i>=0; i--

nginx是什麼，能做什麼，tengine於它的關係，網站設計的優化方法

一說到nginx我們可能想到它跟伺服器掛鉤： 那麼具體他有哪些功能呢： 1：反向代理 2：負載均衡 3：資源伺服器： 接下來具體說說不同功能下都做了哪些事情： 一說到反向代理我們可能會想到的是代理了，那麼代理和反向代理的區別到底是什麼呢： 我們一般說到的代理很大程度上跟翻

HTTP2.0，HTTP1.1，HTTP1.0三者在通性效能上的優化方法

本文從從通訊效能角度，來分析對比HTTP1.0和HTTP1.1之間的區別。以及HTTP1.1與HTTP2.0之間的區別。本文詳細內容組織如下 目錄 一丶HTTP1.0與HTTP1.1通訊效能上的區別 持久化連線 管線化技術 二丶HTTP2.0與HTTP1.1通訊效能上的區別 多路

Hibernate延遲載入(查詢優化)，關聯級別延遲載入優化策略

1. 類級別延遲載入： 類級別使用延時載入，可以在class標籤上修改是否使用延遲載入 <class name="com.ssh.domain.Customer" table="cst_customer"> 2 關聯級別延遲載入：預設使用到的時候才進行查詢()

搬瓦工香港測評，延遲低/1G頻寬/穩定性高，吃雞遊戲加速器

搬瓦工香港是搬瓦工目前提供的唯一一個亞洲機房，香港PCCW線路，三網直連，延遲一般都在50ms左右，1G頻寬，而且非常穩定，不掉包，不跳ping，非常適合做遊戲加速器，以及對速度要求比較高的建站使用者。 原文：搬瓦工香港PCCW線路測評 效能/ping延時/路由/速度 & 搬瓦工香港做遊