ogg源端trial文件大量囤积的处理

本文部分转载，查看全文请点击文章出处：http://blog.csdn.net/msdnchina/article/details/38346435

在OGG源数据库上，检查文件系统使用率的过程中，发现$OGG_HOME的使用率相当高，于是追查原因，查到dirdat目录下有大量的trail文件没有删除。这些trail文件都是去年产生的，早就被传输到目的端了。但是为什么没有被mgr 的PURGEOLDEXTRACTS 参数正常删除呢？

后来检查发现：源头的trail file（/u02/ggs/dirdat/aa）和目的端的trail file（u02/ggs/dirrdat/aa）的名字一样，这是导致源头os上 trail文件没有删除的原因。

具体是这么回事：比如说源头trail file（/u02/ggs/dirdat/aa）到了aa001000，此时目的端的trail file（/u02/ggs/dirrdat/aa）却只到了aa000010。

OGG的mgr进程删除trail文件的判断逻辑为：

检查整个复制环境（包括源头和目的端）中的相同trail文件名的trail，获得最小的那个trail文件号，在此号之前的那些trail文件就会被OGG的mgr进程的PURGEOLDEXTRACTS 参数正常删除掉。

这里有人会问：为啥源头到了/u02/ggs/dirdat/aa001000，目的端却只到了/u02/ggs/dirdat/aa000010 ？这是不是意味着丢了数据？
这个很好解释，包括但是不限于如下的原因：
1.源头trail文件最大大小是20M一个，目的端trail文件的最大大小是2M一个。
2.源头trail文件中包括10个表的信息，目的端trail文件中包括2个表的信息（即：传输进程的参数文件起到了过滤需要同步的table的作用）

因此，如上的情况不代表传丢了数据。

本文的思路就是调整目的端trail文件的大小，让目的端trail文件号的生成速度加快，即：让目的端的trail文件号尽快的追上源头的trail文件号，从而让OGG的mgr进程尽快的删除源头的trail文件。

额外注意：
1.调整目的端trail文件的大小 是在源头进行的，具体来说就是：修改源头的传输进程
2.在整个过程中，只需要停止一下传输进程，然后修改rmttrail文件大小，然后再启动传输进程即可。可以说风险极其微小。

调整步骤（以下均在源头机器上进行）

1.info 传输进程, showch
2.info 传输进程, detail
3.stop 传输进程
4.alter rmttrail /u02/ggs/dirdat/aa, extract 传输进程, megabytes 1
--->这个alter命令是修改远程的trail file /u02/ggs/dirdat/aa 的最大大小为1MB
5.info 传输进程, showch
6.info 传输进程, detail
7.start 传输进程