由于Replication,DBCC Shrink不能收缩Log File

使用Backup创建测试环境之后,发现testdb的Log File过大,达到400GB,由于测试环境实际上不需要这么大的Log Space,占用400GB的Disk Space实在浪费Disk Resource,于是使用DBCC Shrink收缩Log File:

dbcc shrinkfile(testdb_log_5,10240,notruncate)
dbcc shrinkfile(testdb_log_5,10240,truncateonly)

命名执行完成之后,发现还有300多GB,实际Log File占用的空间的百分比十分低,0.000428%

DBCC SQLPERF(LOGSPACE)

由于test db的还原模式是Simple,并且没有active user,最大的可能性是db的Trasaction log被标记为Replication,使用以下函数统计,发现有大量的log未被LogReader读取。

select count(0)
from sys.fn_dblog(null,null) f
where f.Description =‘REPLICATE‘

在Publisher database中,使用 sp_repltrans 查看没有被LogReader标记为Distributed的Transaction。

sp_repltrans returns a result set of all the transactions in the publication database transaction log that are marked for replication but have not been marked as distributed.

exec sys.sp_repltrans

Unable to execute procedure. The database is not published. Execute the procedure in a database that is published for replication.

由于testdb是使用backup还原的测试数据库,没有在master中注册为Publisher database,必须设置 database 为publish,表示 Database can be used for other types of publications.

exec sys.sp_replicationdboption
        @dbname = N‘testdb‘,
        @optname = N‘publish‘,
        @value = N‘true‘ 

注册成功之后,使用 sp_repldone,将所有的Transaction Log 标记为Distributed。

sp_repldone updates the record that identifies the last distributed transaction of the server.

EXEC sys.sp_repldone
        @xactid = NULL,
        @xact_segno = NULL,
        @numtrans = 0,
        @time = 0,
        @reset = 1  

When xactid is NULL, xact_seqno is NULL, and reset is 1, all replicated transactions in the log are marked as distributed. This is useful when there are replicated transactions in the transaction log that are no longer valid and you want to truncate the log,

最后,使用DBCC ShrinkFile命令,Transaction Log File收缩完成。

参考doc:

sp_repltrans (Transact-SQL)

sp_replicationdboption (Transact-SQL)

sp_repldone (Transact-SQL)

时间: 2024-08-12 08:45:59

由于Replication,DBCC Shrink不能收缩Log File的相关文章

Could not find first log file name in binary log

Scenario Master – Master replication MasterA is a client facing serverMasterB is a warm standby server (read only) MasterB restarted abruptly and when instances were braught back up MasterA (it's slave) was showing the following error: MasterA has th

Linux/Unix shell 监控Oracle告警日志(monitor alter log file)

使用shell脚本实现对Oracle数据库的监控与管理将大大简化DBA的工作负担,如常见的对实例的监控,监听的监控,告警日志的监控,以及数据库的备份,AWR report的自动邮件等.本文给出Linux 下使用 shell 脚本来监控 Oracle 告警日志(monitor alter log file). Linux Shell的相关参考:        Linux/Unix shell 脚本中调用SQL,RMAN脚本        Linux/Unix shell sql 之间传递变量   

RAC 性能分析 - 'log file sync' 等待事件

简介 本文主要讨论 RAC 数据库中的'log file sync' 等待事件.RAC 数据库中的'log file sync' 等待事件要比单机数据库中的'log file sync' 等待事件复杂,主要原因是由于RAC 数据库需要将SCN同步到所有实例. 首先,回顾一下单机数据库中的'log file sync' 等待事件,当user session 提交(commit)时,user session会通知LGWR进程将redo buffer中的信息写入到redo log file,当LGWR

eclipse启动出现“An Error has Occurred. See the log file”解决方法

最近在启动eclipse时出现了“An Error has Occurred. See the log file”的错误,点击确定后也不能启动eclipse.查看log文件,出现类似: java.lang.ClassNotFoundException: javax.xml.parsers.SAXParserFactory at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPri

InnoDB: Error: log file .\ib_logfile0 is of different size 0 10485760 bytes

启动WAMP Server的时候报例如以下的错误: 140618 23:12:32 [Note] Plugin 'FEDERATED' is disabled. 140618 23:12:32 InnoDB: The InnoDB memory heap is disabled 140618 23:12:32 InnoDB: Mutexes and rw_locks use Windows interlocked functions 140618 23:12:32 InnoDB: Compres

Oracle db file parallel write 和 log file parallel write 等待事件

一. db file parallel write等待事件 引自如下blog: http://oradbpedia.com/wiki/Wait_Events_-_db_file_parallel_write db文件并行写 db文件并行写等待事件属于Oracle数据库写入程序(DBWR)进程,因为它是将块从SGA写入数据文件的唯一进程.当是写入时,DBWR进程编译一组脏块,将批处理交给操作系统,并等待db文件并行写事件以完成I / O.虽然用户会话从来没有遇到db文件并行写等待事件,但这并不意味

MYSQL 5.7 无法启动(Could not open error log file errno 2)

前两天电脑中毒, 病毒好像把mysql的 log.err 文件给删掉了.然后服务一直启动不了:Could not open error log file errno 2. 然后疯狂百度,搜索的结果大多都不是我这种情况,只有很少一部分和我的情况一样. 出现和我相同情况的同学: mysql启动错误之 Can't init tc log  Failed to open log (file '', errno 2) ... 发现他们的方法并不能解决我的问题〒_〒,忙活了一上午还是没有找到解决办法. 没有

ORACLE AWR报告之 log file sync等待事件优化的总结【转自ITPUB】

来自白大师(白鳝)对log file sync等待事件优化的总结,供各位puber们学习参考: 一. log file sync平均等待事件时间超过7ms,如果等待时间过长,说明log write每次写入的时间过长,如果能够优化redo日志文件存储,使之存放在更快的磁盘上,就可以减少这个等待事件的单次等待时间.(RAID 5--> RAID 10)   当无法通过优化redo日志的I/O性能来解决问题,或者优化了redo日志的I/O性能后还是无法达到我们的预期,那么该如何处理呢? 二. 有经验的

How to calculate a good InnoDB log file size

Peter wrote a post a while ago about choosing a good InnoDB log file size.  Not to pick on Peter, but the post actually kind of talks about a lot of things and then doesn’t tell you how to choose a good log file size!  So I thought I’d clarify it a