数据库日志太大,清理日志文件

如果你的数据库出现如下场景,那么你需要对数据库进行日志清理了。

注:清理后的数据库,可能无法对数据库进行还原,所以,清理之前需要对数据库进行完整备份;

1.没有做任何操作,数据库日渐查询缓慢。

2.数据库数据很少,但是日志文件很大

你就需要查看是否日志文件过大,如果日志文件太大,就需要对日志文件进行清理了。

清理输入框的脚本如下:

----查询数据库日志

USE 数据库名

SELECT NAME, size FROM sys.database_files

-----清空数据库日志

USE master

GO

ALTER DATABASE 数据库名 SET RECOVERY SIMPLE WITH NO_WAIT

GO

ALTER DATABASE 数据库名 SET RECOVERY SIMPLE

GO

USE ssyldb

GO

DBCC SHRINKFILE (N‘日志.log‘ , 2, TRUNCATEONLY)

GO

USE master

GO

ALTER DATABASE 数据库名 SET RECOVERY FULL WITH NO_WAIT

GO

ALTER DATABASE 数据库名 SET RECOVERY FULL

GO

时间: 2024-10-22 00:06:53

数据库日志太大,清理日志文件的相关文章

分享工作中遇到的问题积累经验 事务日志太大导致insert不进数据

原文:分享工作中遇到的问题积累经验 事务日志太大导致insert不进数据 分享工作中遇到的问题积累经验 事务日志太大导致insert不进数据 今天开发找我,说数据库insert不进数据,叫我看一下 他发了一个截图给我 然后我登录上服务器,发现了可疑的地方,而且这个数据库之前有一段经历 在月初的时候这个数据库曾经置疑过,启动不起来 Could not redo log record (163041:116859:5), for transaction ID (0:-1175226963), on

MongoDB 日志太大怎么办?

MongoDB的日志增长的很快,/var所在的空间马上就占满了,即便换到另一个磁盘分区保存日志,日志还是增长的很快,磁盘眼看要告磬. 有一个好办法,就是使用旋转日志. MongoDB的旋转日志有点怪,Linux下mongd服务接受一个kill -SGIUSR1命令后就立刻将当前日志文件重命名为带日期的文件,然后创建新的日志文件. 不想一般的旋转日志,可以配置旋转策略.不过没关系,经过测试,发送该命令时不会影响到MongoDB的服务. 下面是一个例子,先查找进程id, 然后发送命令. [email

SQL SERVER 数据日志太大,磁盘没有空间,直接删除数据库日志后,显示 恢复挂起。

问题简述: sharepoint的某个站点对应的数据库日志太大了,想把日志瘦身.于是我把整个数据库分离,然后附加数据库来重新生成日志文件.谁知道在附加的时候,居然报错"附加数据库报错:由于数据库没有完全关闭,无法重新生成日志" 问题原因:原因是数据库关闭时存在打开的事务/用户,该数据库没有检查点或者该数据库是只读的.如果事务日志文件被手动删除或者由于硬件或环境问题而丢失,则可能出现此错误. 处理办法: 一.把分离之前的日志文件也复制过来一齐附加嘛从错误提示看, 应该是你的日志文件中还包

MongoDB 日志太大的解决方法

MongoDB的日志增长的很快,/var所在的空间马上就占满了,即便换到另一个磁盘分区保存日志,日志还是增长的很快,磁盘眼看要告磬. 有一个好办法,就是使用旋转日志. MongoDB的旋转日志有点怪,Linux下mongd服务接受一个kill -SGIUSR1命令后就立刻将当前日志文件重命名为带日期的文件,然后创建新的日志文件. 不想一般的旋转日志,可以配置旋转策略.不过没关系,经过测试,发送该命令时不会影响到MongoDB的服务. 下面是一个例子,先查找进程id, 然后发送命令. [email

Kubernetes Pod日志太大导致空间问题

日志限制可以通过docker option来进行,但是先要把log-driver修改成json-file模式 # cat /etc/sysconfig/docker OPTIONS='--log-driver=json-file --log-opt max-size=50m --log-opt max-file=5' 清空日志通过 # cat /dev/null > /var/lib/docker/containers/CONTAINER_ID/CONTAINER_ID-json.log OR

SQL SERVER LDF日志文件太大的解决方法

如何压缩日志及数据库文件大小 /*--特别注意 请按步骤进行,未进行前面的步骤,请不要做后面的步骤 否则可能损坏你的数据库. 一般不建议做第4,6两步 第4步不安全,有可能损坏数据库或丢失数据 第6步如果日志达到上限,则以后的数据库处理会失败,在清理日志后才能恢复. --*/ --下面的所有库名都指你要处理的数据库的库名 1.清空日志 DUMP     TRANSACTION     库名     WITH     NO_LOG 2.截断事务日志: BACKUP   LOG   库名   WIT

Apache access.log error.log日志文件太大优化方法

有没有发现Apache生成的日志文件一天比一天大,不是一般大,若你apache安装在C盘,那可惨了,不几天硬盘就满了,太恐怖了,有没有办法优化一下日志,让它不那么大?答案是有的. 一.停止Apache服务,删除Apache下/logs/目录中的error.log和access.log文件. 二.打开Apache的conf/httpd.conf配置文件,找到以下配置信息: ErrorLog logs/error.log CustomLog logs/access.log common 请在上述两行

怎么解决apache日志文件太大的问题

原文地址:http://un173.blog.51cto.com/8263566/1598346 管理apache服务器有些年头,虽然最近几年被nginx抢了不少风头,但我依然钟爱apache. 喜欢它强劲的并发处理能力,以及forker与worker模式间自由选择的快感,哈哈. 熟悉linux下apache运维的朋友,多少都会遇到过apache日志文件太大的问题,网站刚上线时不会在意到这个问题,因为流量小,自然error.log与access.log文件内容也就少,文件容量不大,因此,配置时也

Oracle 11g 监听很慢,由于监听日志文件太大引起的问题(Windows 下)

现象:Windows 操作系统的Oracle 数据库,使用sqlplus 连接(不指定实例名)连接很快,程序连接或使用连接工具或在Net Manager 中测试连接都需要花费约三四十秒的时间(程序连接可能失败). 通过tsping localhost 测试,亦花费三四十秒. 查看监听警告日志(所在位置在文章后面介绍),有信息如下: <msg time='2017-05-16T16:57:51.811+08:00' org_id='oracle' comp_id='tnslsnr' type='U