压缩数据库日志及数据库文件大小

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介:

压缩数据库日志及数据库文件大小

    我无论看什么样的书籍总想和自己的工作挂上钩,在繁密的文字中来查找自己所要的信息,在自己工作中所遇到的一些难题总想在其他资料中找到相关的文字,所以我们懂得的越少就要看越多的书籍,谁也不知道什么时候能用得上,单位的数据库越来越庞大,查询速度越来越慢,我结合单位数据库的真实情况来操作如何压缩数据库日志及其数据库文件,这些内容虽然大家都熟悉,如果静下心来再看一遍我自己的这篇文章,就能感觉到他的实践性和针对性是多么的强,直接按这些步骤去执行就可以了,不要问关于这方面的知识点是什么。

    因为单位用的数据库名为svw,如果其他单位或个人想快捷方便无误的压缩数据库日志,就把数据库名更改为你们自己的数据库名,压缩数据库日志的操作步骤:

 

1、打开企业管理器
2、打开要处理的数据库
3、点击菜单>工具>SQL查询分析器
4、在输入窗口里面输入:
DUMP TRANSACTION [数据库名] WITH NO_LOG
BACKUP LOG [数据库名] WITH NO_LOG
DBCC SHRINKDATABASE([数据库名])
点击执行!这样子数据库就操作成功了。

 

上面操作我一直在用,不会出现任何问题,而我这些天想找能够直接压缩数据库文件的方法都不大理想,下面我刚采用了如下方式进行数据库日志及其数据库文件压缩操作,日志压缩的比较理想,数据库文件也有效果,可是不能直接填写你想压缩数据库文件的数字,无论怎么样,还是写出来与大家分享。

 


  下面的所有库名都指你要处理的数据库的库名。

  1.清空日志

  DUMP TRANSACTION 库名 WITH NO_LOG

  2.截断事务日志:

  BACKUP LOG 库名 WITH NO_LOG

  3.收缩数据库文件(RU 不压缩,数据库的文件不会减小 )

 

  企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件-数据库文件 :

  --选择日志文件--收缩操作-收缩文件至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了

  --选择数据文件--收缩操作-收缩文件至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了

 

    看起来好像操作复杂,其实实际应用中很简单,这样数据库文件就能压缩了,我的数据库文件压缩前是3.92G,压缩后为3.66G,而在收缩操作里不能随意填写你想压缩的数字,后面告诉你最小压缩数字,不能填写比压缩数字在小的数字了。


 

本文转自 jiangxuezhi2009 51CTO博客,原文链接:http://blog.51cto.com/jiangxuezhi/744732,如需转载请自行联系原作者

相关实践学习
日志服务之数据清洗与入湖
本教程介绍如何使用日志服务接入NGINX模拟数据,通过数据加工对数据进行清洗并归档至OSS中进行存储。
相关文章
|
19天前
|
SQL 存储 关系型数据库
|
19天前
|
存储 关系型数据库 MySQL
|
19天前
|
存储 SQL 关系型数据库
|
20天前
|
存储 关系型数据库 MySQL
|
16天前
|
存储 关系型数据库 MySQL
|
20天前
|
SQL 运维 关系型数据库
|
20天前
|
存储 关系型数据库 MySQL
|
11天前
|
存储 关系型数据库 MySQL
探索MySQL:关系型数据库的基石
MySQL,作为全球最流行的开源关系型数据库管理系统(RDBMS)之一,广泛应用于各种Web应用、企业级应用和数据仓库中
|
8天前
|
关系型数据库 MySQL 网络安全
Mysql 数据库主从复制
在MySQL主从复制环境中,配置了两台虚拟机:主VM拥有IP1,从VM有IP2。主VM的`my.cnf`设置server-id为1,启用二进制日志;从VM设置server-id为2,开启GTID模式。通过`find`命令查找配置文件,编辑`my.cnf`,在主服务器上创建复制用户,记录二进制日志信息,然后锁定表并备份数据。备份文件通过SCP传输到从服务器,恢复数据并配置复制源,启动复制。检查复制状态确认运行正常。最后解锁表,完成主从同步,新用户在从库中自动更新。
975 6
Mysql 数据库主从复制
|
9天前
|
缓存 运维 关系型数据库
数据库容灾 | MySQL MGR与阿里云PolarDB-X Paxos的深度对比
经过深入的技术剖析与性能对比,PolarDB-X DN凭借其自研的X-Paxos协议和一系列优化设计,在性能、正确性、可用性及资源开销等方面展现出对MySQL MGR的多项优势,但MGR在MySQL生态体系内也占据重要地位,但需要考虑备库宕机抖动、跨机房容灾性能波动、稳定性等各种情况,因此如果想用好MGR,必须配备专业的技术和运维团队的支持。 在面对大规模、高并发、高可用性需求时,PolarDB-X存储引擎以其独特的技术优势和优异的性能表现,相比于MGR在开箱即用的场景下,PolarDB-X基于DN的集中式(标准版)在功能和性能都做到了很好的平衡,成为了极具竞争力的数据库解决方案。