使用Oracle GoldenGate 将sql Server 表数据同步到Oracle 中。
偶尔检查MSsql日志使用情况,发现日志越来越大,17GB了。(之前没怎么注意)
DBCC sqlperf(logspace) go
再看看日志处于什么状态:
SELECT name,recovery_model_desc,log_reuse_wait_desc,is_auto_shrink_on,is_cdc_enabled FROM sys.databases go
发现日志一直处于活动事务中,即日志中应该还有一个长的事务没有提交。
看看当前有哪些会话有打开的事务(执行多几遍,确认有3个没关闭的连接和事务)
select spid,blocked,waittime,waittype,waitresource,p.dbid,cpu,physical_io,memusage,open_tran,status,login_time,last_batch,hostname,program_name,hostprocess,loginame,cmd,text from master.dbo.sysprocesses p cross apply sys.dm_exec_sql_text(p.sql_handle) s where open_tran <> 0 go
这3个连接并非当前请求,status='sleeping' ,cmd = ‘AWAITING COMMAND’,open_tran > 0 ,这表明客户端连接已经中断了,但是数据库中仍然保留该连接,而客户端中断时没有正确处理事务的提交或回滚情况,导致数据库中事务仍然在打开中。对于spid = 51 和spid=97 的,看到最后批处理执行时间已经很多天之前了,主要是数据仓库来查询数据的,这连接也没什么用了,可以直接 kill 掉。 对于spid = 95 的,为GoldenGate 数据库用户执行的,也是一直在执行的,但不应该一直保留着。
pid = 95 的连接,重启ogg 的复制进程,如图:
重启完后,在查看日志,事务日志使用率变为了 0.35%,这时就等着收缩吧!
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。