如何配置GOLDENGATE的数据库日志策略、TRAILFILE策略以及存在坑

【背景】

对于基于日志复制的主备数据库来说，由于配置不当或者备库空间问题造成主数据库的日志被自动清理，造成主备数据库同步中断，对于管理人员来说，也许就是一种失责甚至灾难(如果主发生故障),同样基于日志复制的同步软件来说，存在同样的问题，日志由于各种原因被删除,造成同步数据被中断，如果有定时备份日志，无非就是延迟的问题，如果无日志，可能重新初始化，尤其对于架构复杂以及多链路的复制，修复数据也是头疼事情。

同样，由于配置基于日志复制数据设置不当，造成数据库归档满或者复制软件配置参数不当造成复制软件本身中转数据所在磁盘空间满，从而造成业务中断。只要做好监控告警，这些问题都可以及时被发现并被处理，如果我们能够做到追求root cause，了解事物本质，通过果来分析因来关键。今天主要通过归档日志归档配置以及TRAILFLE规范配置来分享下。

【ORACLE 归档、GOLDENGATE以及RMAN策略】

ORACLE 主备数据是基于事务日志来同步的，主库删除还没有传输到备库的日志，那么备库与主库同步关系会中断.从oracle 11g开始可以使用基于SCN增量来恢复备库，12c更加方便，可以通过service直接恢复备库。

在RMAN工作参数中，针对archive log，是可以设置专门的删除策略（Deletion）。对于自动删除archive log的策略，比较常见的是applied to standby和shipped to standby，也就是Data Guard场景下。针对主库存在备库的情况下，采用RMAN来管理日志;主库rman：

configure archivelog deletion policy to shipped on all standby;--配置这个参数，通过rman正常删除归档时，对于没有传输备库的归档是无法删除的,提示如下:

RMAN-08137: WARNING: archived log not deleted,needed for standbyorupstream capture process

针对rman删除日志策略其实存在2个功能:一个是针对standby，还存在capture process的功能，这个功能就是说的oracle goldengate或者stream(这个oracle数据库自带功能，由于配置复杂以及会复制没有提交事务等缺点，后oracle收购goldengate取代stream来作为专门复制数据)等复制依赖的归档。

ORACLE GOLDENGATE作为中间产品，并不是ORACLE数据库数据库产品，完全独立，stream作为ORACLE内部组件。那么GOLDENGATE作为独立中间产品与如何RMAN配置使用，确保归档不被误删除，虽然是独立产品，主要还是调用oracle stream api接口进行封装后实现与ORACLE RMAN配合使用.

【GOLDENGATE如何实现ORACLE归档保留策略以及配置不当带来影响】

--goldengate模式

ORACLE GOLDENGATE配置模式存在经典模式和集成模式，经典模式是ORACLE没有收购GOLDENGATE之前的通用模式，ORACLE收购GOLDENGATE后，取代STREAM成为主导复制数据产品，与ORACLE数据库整合后推出集成模式。通过注册抽取进程到oracle database,能够如下2个功能：

对于采用GOLDENGATE经典模式，通过LOGRETENTION参数来实现RMAN管理归档日志不被正常删除(如果删除归档通过操作系统或者FORCE参数，则无法保证归档)

对于采用GOLENGATE集成模式，register extract group_name database，使用抽取进程在集成模式下，使用oracle logmining server接收LCR,不用去读取redo log.

--如何判断进程注册是logretention还是database

可以通过capture_name来extract注册的logretention还是database，OGG$CAP_开头是注册使用database参数，另外OGG$_开头以一串数字结尾是使用logretention注册的。

--注册extract到数据库好处与弊端

好处:如果goldengate延迟或者其他原因，只要goldengate需要的归档都无法被删除，通过归档日志包含scn大于first_scn,归档日志就无法被删除。避免因为goldengate日志被删除，造成goldengate无法同步数据,需要注意归档日志空间。

通过rman删除日志会提示如下报错：

Getting RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process

弊端:如果是需要的归档无法被删除，对于goldengate运维来说，是一件好事情，毕竟没有因为rman保留策略造成归档被删除，如果goldengate已经被删除、注册进程通过delete extract命令删除，但是没有unregister导致残留capture新一直保留数据库，导致归档日志永远无法被删除，造成归档空间满，从而造成数据库hang，又得不偿失了。

综合来讲，要谨慎使用，尤其goldengate涉及不同运维人员，对于喜欢尝试与折腾的小伙伴来讲，一定要知其所以然，否则就是挖坑。

案例：【extract进程被删除，但是没有unregister extract导致归档一直无法删除】

1、有个朋友公司，goldengate没有任何延迟，dataguard也没有任何延迟，但通过rman删除归档，不管是删除1个月前还是多少天前，都是无法删除，提示如下错误:

rman>delete archivelog until time 'sysdate -7';

Getting RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process

针对这个错误，一直使用如下命令:

rman>delete force archivelog until time 'sysdate -7';

这个命令好处是至少主库不会出现任何问题，备库不同步不要紧.(针对这种缺乏有效监控或者巡检机制的，也未尝不是坏处,优先保证生产环境)

2、检查goldengate运行情况

Program Status Group Lag at Chkpt Time Since Chkpt

MANAGER RUNNING

EXTRACT RUNNING EXIOAXU 00:00:00 00:00:00

REPLICAT RUNNING RXIAOXU 00:00:00 00:00:00

3、检查数据库中catpure信息

发现这个进程已经被删除,但数据库中还是历史注册信息，导致所有这个时间点之后归档都无法删除.

4、处理方式，使用unregister

5、再次删除归档，无任何报错

rman>delete archivelog until time 'sysdate -7';

【GOLDENGATE通过MGR配置参数设置TRAILFILE保留策略】

goldengate源端抽取日志然后保留到trailfile中，然后传输目标端，replicate应用trailfile，正常架构是extract-pump-replicate(当然也可以没有pump进程，甚至初始化也不要生成trailfile),对于pump进程传输完trailfile以及replicate应用完trailfile后，理论上可以删除trailfile,对于删除trailfile,goldengate提供针对进程本身和其中MGR管理方式，其中针对pump和replicate使用purgeoldextracts参数，只适应用于进程与trailfile一一匹配，如果存在多个进程读取一个trailfile,可能导致trailfile被其中一个进程删除，其他进程还没有使用，所以不建议使用进程级别purgeoldextracts配置，建议使用MGR集中式来管理：

通过mgr中配置参数保留策略，如果存在多个目录，配置多条策略.

PURGEOLDEXTRACTS /oggtrail/dr*,USECHECKPOINTS, MINKEEPDAYS 1

对于使用usecheckpoints参数，默认10分钟执行一次清理任务,这个可以更改，可以1、使用CHECKMINUTES xx更改checkpint频率。时间刚好是10分钟。(一般可以不改)

2、使用purgeoldextracts末尾加上FREQUENCYMINUTES或者FREQUENCYHOURS 来控制purge的频率。

基于保留策略，保留策略可以是MINKEEPDAYS、MINKEEPHOURS、MINKEEPFILES,其中保留时间设置多个值，以最后一个为准，例如

PURGEOLDEXTRACTS /oggtrail/dr*,USECHECKPOINTS, MINKEEPDAYS 1，MINKEEPHOURS 6--则是6小时生效

如果是保留时间与保留个数同时存在，则保留时间生效.

对于MGR中使用注意事项:

1、不建议手动清理或者程序清理trailfile,否则可能造成mgr purgeoldextracts无法情况

2、当trailfile存在nfs上，nfs driver时间与local文件系统时间差异比较大，清理trailfile时，keepmin可能不准确。

坑:不建议使用NOUSECHECKPOINTS.

【GOLDENGATE MGR无法清理TRAILFLE】

正常情况下，MGR正确配置purgeoldextracts时，都可以正常清理trailfile,但是却出现无法清理trailfile情况:

1、goldengate mgr bug这个也是存在，可以先忽略。

2、goldengate使用checkpoint来清理trailfile是按照文件号来计算，如果采用KEEPMINFILES 10，且trailfile采用相对路径.

例如extractA -pumpA -replicatA.

pumpA 读取-- 100 write --100

此时增长一个pumpB --读取--100 write --1，

后续继续增长到

pumpA 读取-- 1000 write --1000

此时增长一个pumpB --读取--1000 write --120，

此时mgr无法就清理日志：110-1000之间,只能清理：1-110之间trailfile.

【解决方案】

1、goldengate增加trailfile时采用绝对路径，可以解决这个问题，但是绝对路径后续迁移必须保持路径一致，否则需要重建extract,trailfle。

2、增加pump时候指定读写trailfile 号即可.