goldengate是怎样解析db2日志的

db2diag.log没有两天前的记录了，应该是被删除了，默认DB2数据库不会自动清理db2diag.log日志。

清理后没办法找回了，不过与db2diag.log一起的还有一个文件 <instance_name>.nfy也记录了一些日志

db2diag.log文件权限在unix上是666，好像有权登录系统的用户都可以修改，要查谁清理了比较麻烦，因为只有 *** 作系统会记录用户这种行为。

如果只是定期发生的行为，可以看看是不是有定时任务进行了备份清理

如果是偶然发生的，你可以这么做（假如是unix系统）：

cat /etc/passwd|awk -F: '{print $1,$6}'|while read user home

do

cd $home

echo $user history include db2diag

cat .sh_history |grep -i db2diag

done

如果有人进行了清理，就会有类似 rm db2diag.log 或 >db2diag.log这样的命令，但具体是什么时候清理的，用户的history文件不会记录。

为了安全审计，一般借助第三方工具，记录用户在 *** 作系统上的所有行为（包括时间）。

1、检查实例home目录下的db2diag.log日志，可能会有比较详细的报错日志；

2、SQL6030N reason code 13报错可能与DBM参数SVCENAME有关，检查SVCENAME参数的配置是端口号还是servicename配置：

db2 get dbm cfg|grep SVCENAME

可利用上述信息再分析具体原因。

由于数据库管理器发生了错误或者被强制中断，从而无法接受新的请求，已终止正在处理的所有请求或者已终止所指定的请求。

重新连接至数据库。

如果此连接仍失败，请在数据库管理员的帮助下执行下列故障诊断步骤：

仅限于联合环境：确定是联合数据源返回了错误还是联合数据库服务器返回了错误。

确保客户机/服务器配置正确：

确认通信子系统（包括网络电缆、网卡以及 TCP/IP 之类的通信协议）是否已启动并处于运行状态。

在使用 TCP/IP 协议的客户机/服务器环境中：请对客户机上的 TCP/IP 服务名称指定与服务器上的端口号相同的端口号。

确保数据库管理器已启动并处于运行状态：

确认 DB2 数据库管理器是否已启动并处于运行状态。

在 db2diag 日志文件中查找有关数据库管理器进程已中断或异常终止的证据。

如果数据库管理器已停止，或者诊断日志中存在有关任何数据库管理器代理程序已中断或异常终止的证据，请重新启动数据库管理器。

2

---