OGG复制进程延迟高，优化方法一(使用索引)

最新推荐文章于 2023-11-24 19:57:18 发布
最新推荐文章于 2023-11-24 19:57:18 发布
阅读量5.9k 收藏 7
点赞数
原文链接：https://www.cnblogs.com/lvcha001/p/13469500.html
版权

日常运维过程中，可能发现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 ······
KaTeX parse error: Expected 'EOF', got '#' at position 86: … s.sid,s.serial#̲,sql_id,p.progr…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. 

https://wx.renrenso.com/wx/so.php?ky=%E4%B8%BD%E6%B0%B4%E5%81%9A%E4%BE%9B%E5%8D%B5%E8%AF%95%E7%AE%A1%E5%A9%B4%E5%84%BF%E7%9A%84%E6%9C%BA%E6%9E%84%E3%80%90%E5%8A%A0%E8%96%87132.6813.2999%E3%80%91%E5%BE%97%E5%AE%9D%E4%B9%90%E5%AD%95%E8%82%B2%EF%B8%BE
https://www.wandoujia.com/search?key=%E5%B2%B3%E9%98%B3%E5%81%9A%E4%BE%9B%E5%8D%B5%E8%AF%95%E7%AE%A1%E5%A9%B4%E5%84%BF%E7%9A%84%E6%9C%BA%E6%9E%84%E3%80%90%E5%8A%A0%E8%96%87132.6813.2999%E3%80%91%E5%BE%97%E5%AE%9D%E4%B9%90%E5%AD%95%E8%82%B2%E2%97%A3
https://www.iqiyi.com/manhua/search-keyword=%E5%B2%B3%E9%98%B3%E5%81%9A%E4%BE%9B%E5%8D%B5%E8%AF%95%E7%AE%A1%E5%A9%B4%E5%84%BF%E7%9A%84%E6%9C%BA%E6%9E%84%E3%80%90%E5%8A%A0%E8%96%87132.6813.2999%E3%80%91%E5%BE%97%E5%AE%9D%E4%B9%90%E5%AD%95%E8%82%B2%EF%B8%BE
https://wx.renrenso.com/wx/so.php?ky=%E5%B2%B3%E9%98%B3%E5%81%9A%E4%BE%9B%E5%8D%B5%E8%AF%95%E7%AE%A1%E5%A9%B4%E5%84%BF%E7%9A%84%E6%9C%BA%E6%9E%84%E3%80%90%E5%8A%A0%E8%96%87132.6813.2999%E3%80%91%E5%BE%97%E5%AE%9D%E4%B9%90%E5%AD%95%E8%82%B2%20%E2%96%82
https://www.wandoujia.com/search?key=%E6%B8%85%E8%BF%9C%E5%81%9A%E4%BE%9B%E5%8D%B5%E8%AF%95%E7%AE%A1%E5%A9%B4%E5%84%BF%E7%9A%84%E6%9C%BA%E6%9E%84%E3%80%90%E5%8A%A0%E8%96%87132.6813.2999%E3%80%91%E5%BE%97%E5%AE%9D%E4%B9%90%E5%AD%95%E8%82%B2%E2%80%BB
https://www.iqiyi.com/manhua/search-keyword=%E6%B8%85%E8%BF%9C%E5%81%9A%E4%BE%9B%E5%8D%B5%E8%AF%95%E7%AE%A1%E5%A9%B4%E5%84%BF%E7%9A%84%E6%9C%BA%E6%9E%84%E3%80%90%E5%8A%A0%E8%96%87132.6813.2999%E3%80%91%E5%BE%97%E5%AE%9D%E4%B9%90%E5%AD%95%E8%82%B2%E2%91%A0
https://wx.renrenso.com/wx/so.php?ky=%E6%B8%85%E8%BF%9C%E5%81%9A%E4%BE%9B%E5%8D%B5%E8%AF%95%E7%AE%A1%E5%A9%B4%E5%84%BF%E7%9A%84%E6%9C%BA%E6%9E%84%E3%80%90%E5%8A%A0%E8%96%87132.6813.2999%E3%80%91%E5%BE%97%E5%AE%9D%E4%B9%90%E5%AD%95%E8%82%B2%E2%96%82
https://www.wandoujia.com/search?key=%E8%8D%86%E5%B7%9E%E5%81%9A%E4%BE%9B%E5%8D%B5%E8%AF%95%E7%AE%A1%E5%A9%B4%E5%84%BF%E7%9A%84%E6%9C%BA%E6%9E%84%E3%80%90%E5%8A%A0%E8%96%87132.6813.2999%E3%80%91%E5%BE%97%E5%AE%9D%E4%B9%90%E5%AD%95%E8%82%B2%E2%95%AF
https://www.iqiyi.com/manhua/search-keyword=%E8%8D%86%E5%B7%9E%E5%81%9A%E4%BE%9B%E5%8D%B5%E8%AF%95%E7%AE%A1%E5%A9%B4%E5%84%BF%E7%9A%84%E6%9C%BA%E6%9E%84%E3%80%90%E5%8A%A0%E8%96%87132.6813.2999%E3%80%91%E5%BE%97%E5%AE%9D%E4%B9%90%E5%AD%95%E8%82%B2%E3%80%8E
https://wx.renrenso.com/wx/so.php?ky=%E8%8D%86%E5%B7%9E%E5%81%9A%E4%BE%9B%E5%8D%B5%E8%AF%95%E7%AE%A1%E5%A9%B4%E5%84%BF%E7%9A%84%E6%9C%BA%E6%9E%84%E3%80%90%E5%8A%A0%E8%96%87132.6813.2999%E3%80%91%E5%BE%97%E5%AE%9D%E4%B9%90%E5%AD%95%E8%82%B2%E3%80%8F
https://www.wandoujia.com/search?key=%E6%B3%B0%E5%AE%89%E5%81%9A%E4%BE%9B%E5%8D%B5%E8%AF%95%E7%AE%A1%E5%A9%B4%E5%84%BF%E7%9A%84%E6%9C%BA%E6%9E%84%E3%80%90%E5%8A%A0%E8%96%87132.6813.2999%E3%80%91%E5%BE%97%E5%AE%9D%E4%B9%90%E5%AD%95%E8%82%B2%EF%B8%BC
https://www.iqiyi.com/manhua/search-keyword=%E6%B3%B0%E5%AE%89%E5%81%9A%E4%BE%9B%E5%8D%B5%E8%AF%95%E7%AE%A1%E5%A9%B4%E5%84%BF%E7%9A%84%E6%9C%BA%E6%9E%84%E3%80%90%E5%8A%A0%E8%96%87132.6813.2999%E3%80%91%E5%BE%97%E5%AE%9D%E4%B9%90%E5%AD%95%E8%82%B2%E2%96%B2
https://wx.renrenso.com/wx/so.php?ky=%E6%B3%B0%E5%AE%89%E5%81%9A%E4%BE%9B%E5%8D%B5%E8%AF%95%E7%AE%A1%E5%A9%B4%E5%84%BF%E7%9A%84%E6%9C%BA%E6%9E%84%E3%80%90%E5%8A%A0%E8%96%87132.6813.2999%E3%80%91%E5%BE%97%E5%AE%9D%E4%B9%90%E5%AD%95%E8%82%B2%20%E2%96%A0
https://www.wandoujia.com/search?key=%E8%A1%A2%E5%B7%9E%E5%81%9A%E4%BE%9B%E5%8D%B5%E8%AF%95%E7%AE%A1%E5%A9%B4%E5%84%BF%E7%9A%84%E6%9C%BA%E6%9E%84%E3%80%90%E5%8A%A0%E8%96%87132.6813.2999%E3%80%91%E5%BE%97%E5%AE%9D%E4%B9%90%E5%AD%95%E8%82%B2%20%E2%96%84
https://www.iqiyi.com/manhua/search-keyword=%E8%A1%A2%E5%B7%9E%E5%81%9A%E4%BE%9B%E5%8D%B5%E8%AF%95%E7%AE%A1%E5%A9%B4%E5%84%BF%E7%9A%84%E6%9C%BA%E6%9E%84%E3%80%90%E5%8A%A0%E8%96%87132.6813.2999%E3%80%91%E5%BE%97%E5%AE%9D%E4%B9%90%E5%AD%95%E8%82%B2%E3%8A%A3
https://wx.renrenso.com/wx/so.php?ky=%E8%A1%A2%E5%B7%9E%E5%81%9A%E4%BE%9B%E5%8D%B5%E8%AF%95%E7%AE%A1%E5%A9%B4%E5%84%BF%E7%9A%84%E6%9C%BA%E6%9E%84%E3%80%90%E5%8A%A0%E8%96%87132.6813.2999%E3%80%91%E5%BE%97%E5%AE%9D%E4%B9%90%E5%AD%95%E8%82%B2%CE%BE
https://www.wandoujia.com/search?key=%E7%9B%98%E9%94%A6%E5%81%9A%E4%BE%9B%E5%8D%B5%E8%AF%95%E7%AE%A1%E5%A9%B4%E5%84%BF%E7%9A%84%E6%9C%BA%E6%9E%84%E3%80%90%E5%8A%A0%E8%96%87132.6813.2999%E3%80%91%E5%BE%97%E5%AE%9D%E4%B9%90%E5%AD%95%E8%82%B2%20%E2%96%88
https://www.iqiyi.com/manhua/search-keyword=%E7%9B%98%E9%94%A6%E5%81%9A%E4%BE%9B%E5%8D%B5%E8%AF%95%E7%AE%A1%E5%A9%B4%E5%84%BF%E7%9A%84%E6%9C%BA%E6%9E%84%E3%80%90%E5%8A%A0%E8%96%87132.6813.2999%E3%80%91%E5%BE%97%E5%AE%9D%E4%B9%90%E5%AD%95%E8%82%B2%E2%94%B3
https://wx.renrenso.com/wx/so.php?ky=%E7%9B%98%E9%94%A6%E5%81%9A%E4%BE%9B%E5%8D%B5%E8%AF%95%E7%AE%A1%E5%A9%B4%E5%84%BF%E7%9A%84%E6%9C%BA%E6%9E%84%E3%80%90%E5%8A%A0%E8%96%87132.6813.2999%E3%80%91%E5%BE%97%E5%AE%9D%E4%B9%90%E5%AD%95%E8%82%B2%E2%86%92
https://www.wandoujia.com/search?key=%E4%B8%9C%E8%90%A5%E5%81%9A%E4%BE%9B%E5%8D%B5%E8%AF%95%E7%AE%A1%E5%A9%B4%E5%84%BF%E7%9A%84%E6%9C%BA%E6%9E%84%E3%80%90%E5%8A%A0%E8%96%87132.6813.2999%E3%80%91%E5%BE%97%E5%AE%9D%E4%B9%90%E5%AD%95%E8%82%B2%E3%80%90
https://www.iqiyi.com/manhua/search-keyword=%E4%B8%9C%E8%90%A5%E5%81%9A%E4%BE%9B%E5%8D%B5%E8%AF%95%E7%AE%A1%E5%A9%B4%E5%84%BF%E7%9A%84%E6%9C%BA%E6%9E%84%E3%80%90%E5%8A%A0%E8%96%87132.6813.2999%E3%80%91%E5%BE%97%E5%AE%9D%E4%B9%90%E5%AD%95%E8%82%B2%E2%96%83
https://wx.renrenso.com/wx/so.php?ky=%E4%B8%9C%E8%90%A5%E5%81%9A%E4%BE%9B%E5%8D%B5%E8%AF%95%E7%AE%A1%E5%A9%B4%E5%84%BF%E7%9A%84%E6%9C%BA%E6%9E%84%E3%80%90%E5%8A%A0%E8%96%87132.6813.2999%E3%80%91%E5%BE%97%E5%AE%9D%E4%B9%90%E5%AD%95%E8%82%B2%E2%94%B7
https://www.wandoujia.com/search?key=%E5%8D%97%E9%98%B3%E5%81%9A%E4%BE%9B%E5%8D%B5%E8%AF%95%E7%AE%A1%E5%A9%B4%E5%84%BF%E7%9A%84%E6%9C%BA%E6%9E%84%E3%80%90%E5%8A%A0%E8%96%87132.6813.2999%E3%80%91%E5%BE%97%E5%AE%9D%E4%B9%90%E5%AD%95%E8%82%B2%E2%96%84
https://www.iqiyi.com/manhua/search-keyword=%E5%8D%97%E9%98%B3%E5%81%9A%E4%BE%9B%E5%8D%B5%E8%AF%95%E7%AE%A1%E5%A9%B4%E5%84%BF%E7%9A%84%E6%9C%BA%E6%9E%84%E3%80%90%E5%8A%A0%E8%96%87132.6813.2999%E3%80%91%E5%BE%97%E5%AE%9D%E4%B9%90%E5%AD%95%E8%82%B2%E2%8A%95
https://wx.renrenso.com/wx/so.php?ky=%E5%8D%97%E9%98%B3%E5%81%9A%E4%BE%9B%E5%8D%B5%E8%AF%95%E7%AE%A1%E5%A9%B4%E5%84%BF%E7%9A%84%E6%9C%BA%E6%9E%84%E3%80%90%E5%8A%A0%E8%96%87132.6813.2999%E3%80%91%E5%BE%97%E5%AE%9D%E4%B9%90%E5%AD%95%E8%82%B2%E2%86%93
https://www.wandoujia.
最低0.47元/天 解锁文章
wuyunmeng
关注
  • 0
    点赞
  • 踩
  • 7
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
OGG复制进程延迟处理思路与方法
weixin_33933118的博客
04-09 3698
可能问题分析：1、源端E进程处于abend状态且长时间未解决，导致pump和Replicat进程均出现延迟2、源端有大表做批量更新操作（比如对历史数据插入、更新、删除几千万上亿条数据）3、表没有主键或唯一索引，导致同步更新时出现全表扫描4、Replicat进程里面的表过多，处理不过来5、MGR管理进程挂死6、网络中断或主机故障，导致目标端与源端通讯异常 解决问题一系列办法：我们通过数据库与OGG进...
ogg配置多对一复制-实际配置过程
02-21
ogg配置多对一复制-实际配置过程 主要讲解linux下两个节点配置向同一个目标节点同步同一张表的过程
ogg出现大量延迟处理流程
最新发布
cmx996007的博客
11-24 604
ogg进程异常处理流程
OGG 21c 远程捕获进程延迟问题处理
JiekeXu的博客
11-15 737
作者 | JiekeXu来源 |公众号 JiekeXu DBA之路（ID: JiekeXu_IT）如需转载请联系授权 |(个人微信 ID：JiekeXu_DBA)大家好，我是 JiekeXu,很高兴又和大家见面了,今天和大家一起来看看 OGG 21c 远程捕获进程延迟问题处理，欢迎点击上方蓝字“JiekeXu DBA之路”关注我的公众号，标星或置顶，更多干货第一时间到达！前面几天发布了一篇使用 ...
【大数据开发运维解决方案】GoldenGate replicat进程延迟分析步骤
热门推荐
赵延东的一亩三分地
03-17 17万+
使用Oracle GoldenGate将各个业务生产库汇聚到一起做数仓实时ODS平台, 我们采用异构同步，即源端同步过来的表在ODS新增了一个etltime字段，用来记录当前数据变更时间。为了记录数据的事务变更历史记录，我们将数据的变更记录映射同步到一张tab_name_audit表中。为了防止源端业务库误删数据，我们将被删除的数据映射同步到一张tab_name_his表中。最近源端库有一批大表做了DML变更，然后发现某个replicat进程一直在延迟，但是数据库整体挺空闲，就怀疑是否卡在某个大表的dml同
【OGG】OGG的单向DML复制配置(一)
07-31
【OGG】OGG的单向DML复制配置(一)【OGG】OGG的单向DML复制配置(一)
【OGG】Rac管理OGG高可用.pdf
02-13
通过本文档，可以完成通过集群软件管理ogg的功能，实现ogg软件的高可用 [oracle@racdb1 ogg]$ crsctl stat res -t ... Cluster Resources -------------------------------------------------------------------...
利用zabbix监控ogg进程(Linux平台)
01-08
因此很有必要监控下ogg的进程，这里给大家介绍如何使用zabbix监控oracle的ogg的进程。思路就是利用oracle用户去查ogg的相关状态，并把状态写入一个临时文件，供zabbix用户访问。如果ogg状态都是RUNNING，那么该文件...
OGG 应用进程模式转换（非集成模式→集成模式）
01-09
说明：本文为Oracle GoldenGate应用进程模式转换指导手册 温馨提示：如果您发现本文哪里写的有问题...※ 如果目标端“复制”进程不需要合并的话直接执行STOP命令即可，如果想合并的话可以使用eventactions(ignore,sto
Oracle Goldengate性能优化方案
12-17
针对XXXX容灾项目中Goldengate目标端数据入库时间与源端有较大延迟而给出的一个优化方案
一次ogg pump extract lag time延迟大的调优记录
wonder191的博客
12-17 5162
一次ogg pump extract lag time延迟大的调优记录1.环境说明 源端：DB2v10.1.4数据库 安装12.1的ogg 目标：oracle 9i数据库 安装11.1的ogg2.性能问题描述 在db2端，配置的一个primary extract进程，一个pump extract进程，primary进程抽取DB2的数据没有lag延迟，但是pump进程的lag time有2
ogg pump 进程 Lag at Chkpt 时间延迟解决
weixin_41229271的博客
06-25 5103
上午遇见ogg数据同步不及时问题，查看抽取投递应用三进程状态正常，但是投递进程Lag at Chkpt（时间延迟）较大 再比对查看抽取和投递进程的日志（均正常抽取投递），但抽取文件号到了7400多，但投递刚过7300，相差一百多队列文件没有投递 再在目标端的dirdat查看，队列文件每半个小时才接收到一个，确定是pump进程投递投递过慢，文件出现延迟 （但查看网络应该是正常的，不是网络IO问题）...
ogg管理-抓取延迟处理
oradbm的博客
01-13 1329
1查看BR需要的归档日志 BR Begin Recovery Checkpoint: Thread #: 1 Sequence #: 886689 RBA: 211208720 Timestamp: 2020-01-10 20:16:05.000000 SCN: 3009.3346484643 (12926903078307) Redo File...
【Goldengate性能优化】优化Extract抽取进程性能，解决OGG抽取日志延迟
我的Oracle DBA之路
05-22 1504
http://www.askmaclean.com/archives/ogg-goldengate-extract-slow.html 【Goldengate性能优化】优化Extract抽取进程性能，解决OGG抽取日志延迟 2013/04/22 BY MACLEAN LIU 3条评论 一般来说OGG Goldengate 抽取进程对CPU的压力非常小， 而对于I/O
OGG由于GGS处理SEQUENCE方式导致Ext延时_NOAUTOMATICSEQUENCEFLUSH处理
lbyyy的专栏
05-11 1258
OGG由于GGS处理SEQUENCE方式导致Ext延时_NOAUTOMATICSEQUENCEFLUSH
从某个trail文件重新开始ogg
乡下人
04-19 2147
源端: GGSCI (dbserver) 27> stop EORA_1 Sending STOP request to EXTRACT EORA_1 ... Request processed. GGSCI (dbserver) 28> stop PORA_1 Sending STOP request to EXTRACT PORA_1 ... Request process...
因大表无索引致ogg同步延迟几十小时
weixin_41561946的博客
01-13 1158
系统环境 oracle 11.2.0.4+ogg12.2.0.1.0 延迟现象 GGSCI (cluster-10-176-50-29 as ogg@yjgk2) 169> info all Program Status Group Lag at Chkpt Time Since Chkpt MANAGER RUNNING REPLICAT RUNNING REP_PS1 14:27:09 00:00:57 REPLICAT
ogg投递进程延迟太高怎么解决
06-10
OGG（Oracle GoldenGate）投递进程延迟高的问题可能由多种原因引起，以下是一些可能的解决方案： 1. 网络问题：如果您的网络连接不稳定或者网络带宽不足，可能会导致OGG投递进程延迟高。您可以尝试增加带宽或者检查...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值