GoldenGate 性能优化方法

从根本上讲,OGG复制性能和要复制的表是否存在主键和唯一索引有很大关系,所以从应用系统开发商对表结构的规范更为有效。OGG调优通常采用拆分进行的方式,拆分方法如下所述。

Extract拆分方法

1)        停止extract进程

2)        停止datapump、进程

GGSCI> INFO datapump_name

EXTRACT    DPEF      Last Started 2011-01-28 12:34   Status RUNNING

Checkpoint Lag       00:00:00 (updated 00:00:05 ago)

Log Read Checkpoint  File ./dirdat/ef000010

2011-01-28 12:47:45.000000  RBA 148645

直至RBA号不变化,才能停止

3)        停止replicat进程

GGSCI> INFO replicat_name

REPLICAT   RPEF      Last Started 2011-01-28 12:30   Status RUNNING

Checkpoint Lag       00:00:00 (updated 00:00:05 ago)

Log Read Checkpoint  File ./dirdat/ef000006

2011-01-28 12:47:45.000000  RBA 149258

直至RBA号不变化,才能停止

4)        记录extract检查点

Extract检查点包括:Recovery Checkpoint和Current Checkpoint

GGSCI> INFO extract_name, SHOWCH

EXTRACT    EXEE      Last Started 2011-01-28 09:58   Status STOPPED

Checkpoint Lag       00:00:00 (updated 00:01:02 ago)

Log Read Checkpoint  Oracle Redo Logs

2011-01-28 10:02:16  Seqno 26, RBA 7090688

Current Checkpoint Detail:

Read Checkpoint #1

Oracle Redo Log

Startup Checkpoint (starting position in the data source):

Sequence #: 26

RBA: 289296

Timestamp: 2011-01-28 09:27:31.000000

Redo File: C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02.LOG

Recovery Checkpoint (position of oldest unprocessed transaction in the data source):

Sequence #: 26

RBA: 7088144

Timestamp: 2011-01-28 10:02:16.000000

Redo File: C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02.LOG

Current Checkpoint (position of last record read in the data source):

Sequence #: 26

RBA: 7090688

Timestamp: 2011-01-28 10:02:16.000000

Redo File: C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02.LOG

Write Checkpoint #1

GGS Log Trail

Current Checkpoint (current write position):

Sequence #: 11

RBA: 31609

Timestamp: 2011-01-28 10:02:19.072000

Extract Trail: ./dirdat/ee

Header:

Version = 2

Record Source = A

Type = 4

# Input Checkpoints = 1

# Output Checkpoints = 1

File Information:

Block Size = 2048

Max Blocks = 100

Record Length = 2048

Current Offset = 0

Configuration:

Data Source = 3

Transaction Integrity = 1

Task Type = 0

Status:

Start Time = 2011-01-28 09:58:34

Last Update Time = 2011-01-28 10:02:19

Stop Status = G

Last Result = 400

5)        修改原有相应的参数文件,将拆分出的表从参数文件中删除

6)        增加新的extract,datapump和replicat

--source--------------------------------------------------

GGSCI (win2k364) 15> add ext exef, tranlog, begin now

EXTRACT added.

GGSCI (win2k364) 16> add exttrail ./dirdat/ef, ext exef, megabytes 50

EXTTRAIL added.

GGSCI (win2k364) 17> add ext dpef, exttrailsource ./dirdat/ef

EXTRACT added.

GGSCI (win2k364) 18> add rmttrail ./dirdat/ef, ext dpef, megabytes 50

RMTTRAIL added.

--target--------------------------------------------------

GGSCI (win2k364) 21> add rep rpef, exttrail ./dirdat/ef

REPLICAT added.

7)        修改新增extract进程的检查点

检查点为上面记录的两个检查点:

current read checkpoint and recovery checkpoint

--修改current read checkpoint

GGSCI (win2k364) 30> alter exef extseqno 26, extrba 7090688 [, thread n]

EXTRACT altered.

--修改recovery checkpoint

GGSCI (win2k364) 4> alter exef ioextseqno 26, ioextrba 7088144 [, thread n]

2011-01-28 10:46:18  INFO    OGG-00989  WARNING: Unsupported operation. This might cause transactional inconsistency. Modifying iocheckpoint: ioseq = 26 iorba = 7088144.

Are you sure you want to continue? y

EXTRACT altered.

8)        确认所有参数文件正确,启动进程即可

Datapump和replicat拆分方法

下面以拆分replicat为例,datapump拆分方法相同。

1)        停止replicat进程

2)        查看检查点

GGSCI> INFO replicat_name, SHOWCH

REPLICAT   RPEF      Last Started 2011-01-28 12:30   Status RUNNING

Checkpoint Lag       00:00:00 (updated 00:00:03 ago)

Log Read Checkpoint  File ./dirdat/ef000006

2011-01-28 12:47:45.000000  RBA 149258

Current Checkpoint Detail:

Read Checkpoint #1

GGS Log Trail

Startup Checkpoint (starting position in the data source):

Sequence #: 4

RBA: 1845

Timestamp: 2011-01-28 11:32:10.556000

Extract Trail: ./dirdat/ef

Current Checkpoint (position of last record read in the data source):

Sequence #: 6

RBA: 149258

Timestamp: 2011-01-28 12:47:45.000000

Extract Trail: ./dirdat/ef

Header:

Version = 2

Record Source = A

Type = 1

# Input Checkpoints = 1

# Output Checkpoints = 0

File Information:

Block Size = 2048

Max Blocks = 100

Record Length = 2048

Current Offset = 0

Configuration:

Data Source = 0

Transaction Integrity = -1

Task Type = 0

Database Checkpoint:

Checkpoint table = GGS.GGSCHKPT

Key = 746337239 (0x2c7c33d7)

Create Time = 2011-01-28 10:20:18

Status:

Start Time = 2011-01-28 12:30:23

Last Update Time = 2011-01-28 13:25:34

Stop Status = A

Last Result = 400

3)        修改原有参数文件,将拆分出的表删除

4)        新增replicat,和拆分前的进程读取相同的队列文件

5)        修改检查点

6)        GGSCI>alter replicat_new extseqno 6, extrba 149258

7)        确认所有参数文件无误,启动进程即可

OGG的Replicat进程性能调优

OGG的Replicat负责将队列文件中的数据读取出来然后按照原来的顺序一条条投递到目标数据库,当数据变化量较大时可能无法跟上队列的产生速度,此时需要进行调优。

OGG提供几个参数用于调节Replicat的性能,如batchsql/ MAXTRANSOPS /GROUPTRANSOPS等。

Replicat的性能问题除去数据变化量的大小,还跟数据库本身执行SQL的速度有关。例如,表是否有主键或者唯一索引,是否有普通索引等,也可以通过这些方面进行调优。

确认Replicat进程运行正常

可以使用stats myrep来查看进程的统计信息,或者使用send myrep,report强制执行一个报告,然后使用view report查看报告里面的各表的统计信息,观察数据变化量是否比较大。

如果replicat长时间不动,可以尝试重启该进程,观察是否正常响应,有可能该进程正在处理一个长事务,会报告正在处理长交易和已经处理了多少条。

Replicat进程的拆分

拆分原则

Replicat如需拆分,按照schema、业务所涉及表范围、表名称前缀、表名等方法进行依次拆分。

拆分进程的评估

可以在extract运行几天后,查看源端extract的报告或者使用stats命令找出变化最为频繁的表,为一个或几个这些大数量级表单独配置投递进程;也可根据数据库定期收集的统计信息将变化较多的表拆分出来;无主键表往往性能较差,对于单个或多个频繁变化的无主键表一般也需要拆分为独立的进程;同时也可以根据Trail产生的速度和实际Replicat的速度来估算需要多少个进程。Repliat的拆分一般很难一次到位,经常需要多次拆分方能达到最佳效果。

进程拆分的目标

进程拆分一般以表为单位,当对某一个进程进行拆分后,其所负责的全部表应当被分布到各个拆分后的进程去,既要保证全部被包含到这些进程,又要确保不会有表被重复包含在多个进程中。例如,对原来一个Schema进行拆分,将其中一个大表拆分为一个单独进程:

拆分之前的Replicat中的map:

map UCR_UIF1.*, target UCR_UIF1.*;

拆分后的两个Replicat中的map:

第一个replicat,只包含拆分出来的大表(需要新加一个replicat,可以copy原有replicat创建的命令和参数,注意替换掉所有与进程名有关的参数):

Map UCR_UEC.TF_O_SELFSERVICE_STATE, target UCR_UEC.TF_O_SELFSERVICE_STATE;

第二个replicat,将该大表排除出去后的所有该schema下的表(可以直接用旧的replicat,只需添加mapexclude参数即可):

MAPEXCLUDE UCR_UEC.TF_O_SELFSERVICE_STAT

map UCR_UEC.*, target UCR_UEC.*;

拆分的步骤

以下为一个replicat进行拆的步骤:

1)        停止所要拆分的replicat;

2)        使用info myrep查看该replicat的检查点,将该检查点所有内容记录下来。如下示例,记住当前的队列号seqno和RBA:

Last Started 2006-01-21 11:40 Status RUNNING

00:00:00 (updated 232:39:41 ago)

C:\GGS\DIRDAT\RT000123

2006-01-11 18:54:33.000000 RBA 4735245

3)        根据评估决定要拆分为几个进程,为每个进程准备创建命令和参数文件,务必要仔细检查,确保其正确性;

4)        执行ggsci命令创建replicat进程,通过edit param myrep编辑参数文件或直接将参数文件放到dirprm目录下;

5)        针对新增的replicat(原有的replicat就不用动了),逐个修改其检查点到原replicat指定的extseqno和extrba。例如,针对上面的示例:

ALTER REPLICAT mynewrep, EXTSEQNO 123, EXTRBA 4735245

6)        检查各replicat的参数和进程信息,确保表已经被散步到各个进程,确保各进程检查点已经与原有replicat保持一致;

7)        启动replicat,观察是否正常。

说明:进程的拆分需要对replicat的检查点进行操作,一定要特别注意,如有可能需求技术支持。

针对单个表的拆分

如果某些表特别大,拆分到一个单独进程依然无法满足要求,可以根据主键将该表拆分为多个进程。

注意:单个表的拆分是依据某个字段的值做hash进行拆分的(默认为主键,但也可以自定义为其它列,前提是该列必须被记录在附加日志里面),所以必须要保证该字段日常是固定不变的。否则,作为拆分依据的这些字段的变化将会引起记录在不同的replicat中处理,有可能各进程之间的不同不会引起数据修改顺序的紊乱,导致replicat出错。

下面是一个拆分后的replicat参数示例,原有进程被拆分为2个进程:

原来的replicat:

MAP sales.acct, TARGET sales.acct;

拆分后的Replicat1(可使用原有的replicat):

MAP sales.acct, TARGET sales.acct, FILTER (@RANGE (1, 2));

拆分后的replcat2(新增):

MAP sales.acct, TARGET sales.acct, FILTER (@RANGE (2, 2));

具体拆分步骤与依据表的拆分相同,不再详述。

单个Replicat进程的调优

OGG提供了几个参数可以对单个的replicat进行调优,如下所示:

1)        使用操作合并 - BATCHSQL

BATCHSQL

该参数可以将类似的SQL放在一起进行批量提交。该参数适用的条件:

ü  Replicat进程里面只有一张或者几张表;

ü  这些表没有BLOB/CLOB/LONG等大对象;

ü  这些表的列定义长度在1K以下,例如如果有几个varchar(4000)则不合适;

更多信息请参考OGG的参考手册,如需使用请联系技术支持。

2)        对大交易使用交易分拆 - MAXTRANSOPS

MAXTRANSOPS     1200

将超过指定的记录变化数的交易拆分为多个小一些的交易进行提交,可以不必等待OGG读完全部的交易记录,能够看到检查点的持续前进。

如果有时候Replicat很长时间不往前移动,可以考虑调整该参数。

3)        对于密集小交易使用交易合并 - GROUPTRANSOPS

GROUPTRANSOPS 1200

该参数的作用是将小交易合并为一个大一些的交易,示例是将若干小交易拼在一起直到所有的记录超过500个则将这些交易一起提交。可以有效降低密集小交易带来的密集IO,提升投递性能。对于大交易不起作用,一般性能调优在IO有瓶颈时使用。

数据库及SQL的调优

OGG的复制机制是将源端发生的变化拼装为SQL在目标端重现,其执行的速度与本身sql的速度有关。尤其是对于update和delete,对于执行计划的优化可以极大的提高sql执行的速度。

一个典型的问题是无主键表,当执行一个update或这delete时,无主键表会执行全表扫描去定位一条记录,速度非常慢。因此,当无主键表拆分为一个进程依然无法满足其性能要求时,其最佳方法就是给该表加入主键或唯一索引。

其它对于目标库的sql执行效率优化也同样能提高OGG replicat的性能。

申请技术支持

如经过以上排查仍然无法解决性能问题,可以联系Oracle予以协助。

OGG进程拆分与交易一致性说明

1)        问题描述

国网部分网省对于OGG进程拆分会不会影响交易一致性比较关心,特在此予以说明。

2)        问题说明

OGG的extract/data pump/replicat进程均可以拆分为多个进程同时并发执行,以提高数据复制的性能和处理能力。在Oracle提供的《国家电网网省数据级灾备GoldenGate设计原则》一文中对于进程的拆分原则进行了详细的规定。下面对于各个进程的拆分及其交易一致性的影响进行分析:

ü  主Extract的拆分

在前期提供的OGG链路设计原则中提到,OGG的主Extract进程处理能力较强,一般依据硬件平台不同可以处理约每小时20-40G以上的日志,对于中小型应用无需拆分;而如果数据量较大,确实需要拆分的话,优先选择的是以业务或schema作为拆分的依据,即按照不同的业务所设计的表范围拆分extract进程。

按照业务拆分完成后,各extract进程之间没有交互,相互独立运行,之间可能会有时间差,但是由于各进程是以业务为依据进行拆分的,只会在不同的业务之间产生时间上的短暂差异,并不影响交易的一致性;

如果拆分时打破了业务界限,同一个业务被拆分到了不同的extract进程里面,则出现灾难时可能会出现不同进程之间的数据不平衡。如果确有这种情况,可以通过OGG的logdump工具对最后的几条数据进行检验,人工处理掉这几条不一致的数据。需要说明的是OGG处理日志速度很快,这种几率是非常低的。

总而言之,当extract没有拆分或者按照业务进行拆分,则不会带来交易的不一致性;如果打破了业务范围进行拆分,则有可能会带来交易不一致性,可通过logdump找出不一致的数据进行人工处理,而实际发生的概率是非常低的。

ü  Data pump的拆分

Data Pump是跟extract严格一对一的,目前不针对data pump进行拆分,对于它们没有该问题。

ü  Replicat的拆分

由于单个replicat相对于extract处理能力较慢,当前大部分网省都对replicat进行了拆分。拆分后的replicat单独运行,相互不进行交互,彼此之间同样可能存在不同步现象,依据extract的拆分情况分析如下:

当extract不拆分或者按照业务拆分时,能够保证交易的一致性,其对应的trail文件所包含数据均是一致的,而被传输到目标端后,replicat虽然彼此之间速度稍有差异(一般在几秒或者零点几秒之内),但是在接管过程中,由于切换需要至少几分钟或者几十分钟时间,此过程中由于trail已经停止增长,各replicat已经完全可以处理完队列中的数据,这样虽然入库时间稍有差异,但最终数据是全部队列中数据均已进入数据库,而队列中数据的交易一致性已经由extract进行保证,不会带来交易不一致;

只有当源端extract没有按照业务拆分时,目标的多个trail可能会有短暂的数据差异,replicat会把这些交易全部提交到目标端。此时可以通过logdump查看队列中最后的几笔交易,确认其scn号是否一致,如确有不一致可以人工进行处理,该情况只在极端情况下出现。

OGG延迟lag较大的说明

1)        问题描述

对于有lag的进程,显示为running,属于正常状态。但是如果lag时间过长,是否还正常,多长时间的范围属于正常。这个需要oracle工程师做出解释。

2)        问题说明

OGG的lag指的是数据复制的延迟,对于不同的进程lag较长时分析如下:

ü  主Extract的lag较大

主Extract负责对于数据库的日志做解析获取数据变化,只要正常运行时其延迟一般都在秒一级左右。如果出现了较大的延迟,首先排查是否存在大交易,可能进程正在处理中;如果没有大交易,但是延迟却非常大,请联系技术支持予以调查。

ü  Data Pump的lag较大

Data Pump负责数据的传输,如果出现较大延迟可能是因为网络出现问题,首先可以观察网络带宽是否被占满,也有可能短时间内产生了较多的数据变化。

ü  Replicat的lag较大

Replicat负责数据的入库,一般速度相对于主extract和data pump较慢,容易产生较大延迟。当replicat出现延迟后,需要对进程进行调优或者拆分,具体步骤参照本文档上一节。

一般调优完成后,在日常业务状态下应当不存在较大延迟(一般几秒到一分钟以内);当出现批处理时,可以允许一定的延迟,一般以不影响第二天的正常业务为准 – 例如,如果批处理每天早上4点前结束,可以控制延迟在2小时以内。

因此,首先需要确定OGG复制所允许的最大延迟在日常业务和批处理时的目标是什么,然后一旦达不到此目标就要依据上一节的方法进行性能的调优。

时间: 2024-10-21 18:45:27

GoldenGate 性能优化方法的相关文章

Linux网络性能优化方法简析

Linux网络性能优化方法简析 2010-12-20 10:56 赵军 IBMDW 字号:T | T 性能问题永远是永恒的主题之一,而Linux在网络性能方面的优势则显而易见,这篇文章是对于Linux内核中提升网络性能的一些优化方法的简析,以让我们去后台看看魔术师表演用的盒子,同时也看看内核极客们是怎样灵活的,渐进的去解决这些实际的问题. AD:2014WOT全球软件技术峰会北京站 课程视频发布 对于网络的行为,可以简单划分为 3 条路径:1) 发送路径,2) 转发路径,3) 接收路径,而网络性

DevExpress ChartControl大数据加载时有哪些性能优化方法

DevExpress ChartControl加载大数据量数据时的性能优化方法有哪些? 关于图表优化,可从以下几个方面解决: 1.关闭不需要的可视化的元素(如LineMarkers, Labels等): Series.View.LineMarkerOptions.Visible =false. 2. 关闭图表的滚动与缩放功能,手动调整范围,这样将大大减少所需计算的个数. 3. 将 ChartControl.RefreshDataOnRepaint属性设为false 4. 将 ChartContr

Android性能优化方法(七)

Java从JDK1.2版本开始,就把对象的引用分为四种级别,从而使程序能更加灵活的控制对象的生命周期.这四种级别由高到低依次为:强引用.软引用.弱引用和虚引用. 这里重点介绍一下软引用和弱引用. 如果一个对象只具有软引用,那么如果内存空间足够,垃圾回收器就不会回收它:如果内存空间不足了,就会回收这些对象的内存.只要垃圾回收器没有回收它,该对象就可以被程序使用.软引用可用来实现内存敏感的高速缓存.软引用可以和一个引用队列(ReferenceQueue)联合使用,如果软引用所引用的对象被垃圾回收,J

Android性能优化方法(八)

Android SDK tools目录下提供一个观察布局的工具,层级观察器(Hierarchy Viewer).Hierarchy Viewer工具是一个非常好的布局优化工具,同时,你也可以通过它学习他人的布局.应该说是一个非常实用的工具. AD:WOT2014:用户标签系统与用户数据化运营培训专场 层级观察器(Hierarchy Viewer): Android SDK tools目录下提供一个观察布局的工具,层级观察器(Hierarchy Viewer).Hierarchy Viewer工具

Android性能优化方法(九)

通常我们写程序,都是在项目计划的压力下完成的,此时完成的代码可以完成具体业务逻辑,但是性能不一定是最优化的.一般来说,优秀的程序员在写完代码之后都会不断的对代码进行重构.重构的好处有很多,其中一点,就是对代码进行优化,提高软件的性能.下面我们就从几个方面来了解Android开发过程中的代码优化. 1)静态变量引起内存泄露 在代码优化的过程中,我们需要对代码中的静态变量特别留意.静态变量是类相关的变量,它的生命周期是从这个类被声明,到这个类彻底被垃圾回收器回收才会被销毁.所以,一般情况下,静态变量

sqlserver2008 死锁解决方法及性能优化方法

sqlserver2008 死锁解决方法及性能优化方法 原文: http://blog.csdn.net/kuui_chiu/article/details/48621939 十步优化SQL Server中的数据访问 http://tech.it168.com/a2009/1125/814/000000814758_2.shtml 关于死锁: [sql] view plain copy sp_who active  --看看哪个引起的死锁, blk里面即阻塞的spid: dbcc inputbu

Android性能优化方法(三)

在Android应用开发过程中,屏幕上控件的布局代码和程序的逻辑代码通常是分开的.界面的布局代码是放在一个独立的xml文件中的,这个文件里面是树型组织的,控制着页面的布局.通常,在这个页面中会用到很多控件,控件会用到很多的资源.Android系统本身有很多的资源,包括各种各样的字符串.图片.动画.样式和布局等等,这些都可以在应用程序中直接使用.这样做的好处很多,既可以减少内存的使用,又可以减少部分工作量,也可以缩减程序安装包的大小. 下面从几个方面来介绍如何利用系统资源. 1)利用系统定义的id

Android性能优化方法(六)

ContentProvider优化改进 1.索引简单的说,索引就像书本的目录,目录可以快速找到所在页数,数据库中索引可以帮助快速找到数据,而不用全表扫描,合适的索引可以大大提高数据库查询的效率.(1). 优点大大加快了数据库检索的速度,包括对单表查询.连表查询.分组查询.排序查询.经常是一到两个数量级的性能提升,且随着数据数量级增长. (2). 缺点索引的创建和维护存在消耗,索引会占用物理空间,且随着数据量的增加而增加.在对数据库进行增删改时需要维护索引,所以会对增删改的性能存在影响. (3).

Android性能优化方法(五)

有时候,我们的页面中可能会包含一些布局,这些布局默认是隐藏的,当用户触发了一定的操作之后,隐藏的布局才会显示出来.比如,我们有一个Activity用来显示好友的列表,当用户点击Menu中的“导入”以后,在当前的Activity中才会显示出一个导入好友的布局界面.从需求的角度来说,这个导入功能,一般情况下用户是不使用的.即大部分时候,导入好友的布局都不会显示出来.这个时候,就可以使用延迟加载的功能. ViewStub是一个隐藏的,不占用内存空间的视图对象,它可以在运行时延迟加载布局资源文件.当Vi