一、OGG自动清理trail文件方法。
ogg源端和目标端是通过trail文件存放抽取的数据并复制,对于比较大的数据库,每天产生的trail文件可能达到几百G。如果不定期清理,存储很快就会被耗尽。如果人工删除dirdat目录下的文件,很容易把有用的trail文件删掉导致无法应用,或者由于遗忘导致磁盘空间报警。
ogg manager提供检查和清理trail文件的功能,使用十分方便,具体配置如下:
源端和目标端方法类似。
1. 停止MGR进程
GGSCI 1>stop mgr
Manager process is required by other GGS processes.
Are you sure you want to stop it (y/n)? y
Sending STOP request to MANAGER ...
Request processed.
Manager stopped.
2. 编辑MGR配置文件,添加如下参数。
GGSCI 2>edit params mgr
....
PURGEOLDEXTRACTS ./dirdat/et*, USECHECKPOINTS, MINKEEPHOURS 1
......
参数说明:定期清理dirdat路径下的本地队列(local trail)。指定路径和文件名通配符。
其中
MINKEEPHOURS n 自动删除超过n小时并且已经被应用过的trail文件。
MINKEEPDAYS n 自动删除超过n天并且已经被应用过的trail文件。
MINKEEPFILES n 只保留n个处理过的队列文件(不建议使用)
如果MINKEEPHOURS ,MINKEEPDAYS ,MINKEEPFILES 同时使用,如果发生冲突时,那么系统接受MINKEEPHOURS和MINKEEPDAYS 参数将对MINKEEPFILES 参数做忽略。
3. 启动MGR进程
GGSCI 3>start mgr
Manager started.
4. 启动MGR之后,策略就已经生效,可以到dirdat目录下面检查相关trail文件清理情况。
二、 OGG自动trail清理遇到的问题和解决方法
在搭建资源池数据库时由于数据量较大,因此在目标段安装了RAC。两个节点上安装golden软件的时候分别安装到了golden1和golden2目录下。按照一中的方法配置了日志定时清理参数,但发现1节点正常,2节点却总是不能自动清理。检查了两个节点配置均正常,~/dirchk下的检查文件也正常。
后来尝试了一下,在PURGEOLDEXTRACTS ./dirdat/et*, USECHECKPOINTS, MINKEEPHOURS 1中将./dirdat/et* 改成了/golden2/dirdat/* ,也就是说必须要用全路径,重启MGR后发现问题解决。
我的理解是由于为了方便管理(包括一些脚本),我们在每个节点上建立了一个/golden目录,并链接到了真实的安装目录上,有可能导致mgr找不到真正的dirdat目录,所以无法删除。但是无法解释的是第一节点正常,只有第二节点有问题。后续再进行跟踪吧。
大家遇到类似的情况可以尝试修改为全路径试试。