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

SQL Server 压缩日志及数据库文件大小,第1张

请按步骤进行 未进行前面的步骤时 请不要做后面的步骤 以免损坏你的数据库

一般不建议做第 两步 第 步不安全 有可能损坏数据库或丢失数据 第 步如果日志达到上限 则以后的数据库处理会失败 在清理日志后才能恢复

清空日志

DUMP TRANSACTION 库名 WITH NO_LOG

截断事务日志

BACKUP LOG 数据库名 WITH NO_LOG

收缩数据库文件(如果不压缩 数据库的文件不会减小

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

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

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

也可以用SQL语句来完成

收缩数据库

DBCC SHRINKDATABASE(客户资料)

收缩指定数据文件 是文件号 可以通过这个语句查询到:

select from sysfiles

DBCC SHRINKFILE( )

为了最大化的缩小日志文件(如果是sql 这步只能在查询分析器中进行)

a 分离数据库:

企业管理器 服务器 数据库 右键 分离数据库

b 在我的电脑中删除LOG文件

c 附加数据库:

企业管理器 服务器 数据库 右键 附加数据库

此法将生成新的LOG 大小只有 多K

或用代码

下面的示例分离 pubs 然后将 pubs 中的一个文件附加到当前服务器

a 分离

EXEC sp_detach_db @dbname = pubs

b 删除日志文件

c 再附加

EXEC sp_attach_single_file_db @dbname = pubs

@physname = c:/Program Files/Microsoft

SQL Server/MSSQL/Data/pubs mdf

为了以后能自动收缩 做如下设置

企业管理器 服务器 右键数据库 属性 选项 选择 自动收缩

SQL语句设置方式:

EXEC sp_dboption 数据库名

autoshrink TRUE

如果想以后不让它日志增长得太大

企业管理器 服务器 右键数据库 属性 事务日志

将文件增长限制为xM(x是你允许的最大数据文件大小)

SQL语句的设置方式:

lishixinzhi/Article/program/SQLServer/201311/22266

守得云开见月明,花了一个上午结合前辈的博客,终于弄好了sqlserver2008的数据库日志收缩到1MB,分享给大家# 方法步骤1、执行SQL语句改成“简单模式”2、收缩数据库3、执行SQL语句改回“完全模式”## 第一步:执行SQL语句改成“简单模式”USE [master]GOALTER DATABASE  SlowXWebDB (改成你需要进行收缩的数据库名) SET RECOVERY SIMPLE WITH NO_WAITGOALTER DATABASE SlowXWebDB (改成你需要进行收缩的数据库名) SET RECOVERY SIMPLE --改成简单模式GO## 第二步:进行数据库 *** 作相关界面截图和 *** 作假定:数据库名:SlowXWebDB 日志文件名:SlowXWebDB_Log

数据库日志文件过大需要清理1选择数据库右键点击任务-收缩-文件   注意:文件类型选为日志

2如下图选择需要收缩的大小,最小为0MB,本人实测最小只能到1MB,不过已经很满足了哈哈

3点击确认,几十G的日志文件,嗖的一下就瘦身完成了看下数据库日志文件清理后的效果!

## 第三步:执行SQL语句改成“完全模式”USE [master]GOALTER DATABASE SlowXWebDB (改成你需要进行收缩的数据库名)SET RECOVERY FULL WITH NO_WAITGOALTER DATABASE datebaseName(改成你需要进行收缩的数据库名)SET RECOVERY FULL --还原为完全模式GO==最后不要忘记实测下数据库是否能够正常使用==

非root用户运行MySQL,当MySQL配置比较高时,MySQL运行中生效的参数值与配置的值不一样,所以具体分析一下MySQL是怎么调整这些参数值的。 

这篇文章的目的是为了说明在系统资源不够的情况下,MySQL 是怎么调整者三个参数的。说明此文涉及到三个参数open_files_limit、 max_connections、 table_open_cache。与这三个参数相关的系统资源是打开文件数限制,即文件描述符(fd)限制。系统参数与文件描述符的关系 - max_connection & fd : 每一个MySQL connection      都需要一个文件描述符;

- table_open_cache & fd 打开一张表至少需要一个      文件描述符,如打开MyISAM需要两个fd ;

- 系统最大打开文件数可以通过 ulimit -n查看。MySQL调整参数的方式

根据配置(三个参数的配置值或默认值)计算 request_open_files(需要的文件描述符);

  2获取有效的系统的限制值effective_open_files;  3根据effective_open_files调整request_open_files;  4根据调整后的request_open_files,计算实际生效的参数值(show variables 可查看参数值)。计算request_open_filesrequest_open_files有三个计算公式:1      // 最大连接数+同时打开的表的最大数量+其他(各种日志等等)2     limit_1= max_connections+table_cache_size 2 + 10;3   4      //假设平均每个连接打开的表的数量(2-4)5      //源码中是这么写的:6      //We are trying to allocate no less than 7      // max_connections5 file handles8      limit_2= max_connections 5;9   10    //mysql 默认的默认是500011    limit_3= open_files_limit open_files_limit : 5000;12  13     所以open_files_limit期待的最低14     request_open_files= max(limit_1,limit_2,limit_3);计算effective_open_files:MySQL 的思路: 

在有限值的的范围内MySQL 尽量将effective_open_files的值设大。修正request_open_files

requested_open_files= min(effective_open_files, request_open_files)

重新计算参数值

修正open_files_limit

open_files_limit = effective_open_files

修正max_connections

max_connections 根据 request_open_files 来做修正。1  limit = requested_open_files - 10 - TABLE_OPEN_CACHE_MIN 2;

如果配置的max_connections值大于limit,则将max_connections 的值修正为limit

其他情况下 max_connections 保留配置值

修正table_cache_size

table_cache_size 会根据 request_open_files 来做修正1   // mysql table_cache_size 最小值,4002   limit1 = TABLE_OPEN_CACHE_MIN3   // 根据 requested_open_files 计算4   limit2 = (requested_open_files - 10 - max_connections) / 25   limit = max(limit1,limt2);

如果配置的table_cache_size 值大于limit,则将 table_cache_size 的值修正为limit

其他情况下table_cache_size 保留配置值

举例

以下用例在非 root 用户下运行

参数设置:

   //mysql

max_connections = 500

         table_open_cache = 999

//ulimit -n

1500

生效的值:

   open_files_limit = 1500   max_connections = min[(1500 - 10 - 800),500] = 500

table_open_cache = ( 1500 - 10 - 500) / 2 =495

以上就是关于SQL Server 压缩日志及数据库文件大小全部的内容,包括:SQL Server 压缩日志及数据库文件大小、SQL SERVER 2000数据库日志文件过大如何解决、怎样限制MySQL数据库文件的大小等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址:https://54852.com/sjk/10195499.html

(0)
打赏 微信扫一扫微信扫一扫 支付宝扫一扫支付宝扫一扫
上一篇 2023-05-06
下一篇2023-05-06

发表评论

登录后才能评论

评论列表(0条)

    保存