数据库为什么要进行收缩，怎样收缩收缩能否达到效果

数据库使用很长时间以后，会产生大量的数据，既占空间又影响访问速度，所以进行数据库收缩。

收缩过程：

收缩前一定要做好备份。

把不用的数据删除。

删除完成后数据文件还不会变小。这时你得进企业管理器选择你要收缩的数据库，

所有任务中有个收缩数据库，然后选文件，进去之后有个数据库文件，后有个下拉菜单，先选择日志文件，(以LOG结尾)，点收缩文件致MB后面有个最小多少，输入那个值，点确定，完成后再进来，选择数据库文件，步骤同上。

重启电脑，重新分配内存。

--1日常要做数据库压缩

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

/--特别注意

请按步骤进行,未进行前面的步骤,请不要做后面的步骤

否则可能损坏你的数据库

--/

1清空日志

DUMP TRANSACTION 库名 WITH NO_LOG

2截断事务日志：

BACKUP LOG 数据库名 WITH NO_LOG

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

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

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

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

也可以用SQL语句来完成

--收缩数据库

DBCC SHRINKDATABASE(客户资料)

--收缩指定数据文件,1是文件号,可以通过这个语句查询到:select from sysfiles

DBCC SHRINKFILE(1)

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

a分离数据库:

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

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

c附加数据库:

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

此法将生成新的LOG，大小只有500多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\pubsmdf'

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

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

--SQL语句设置方式:

EXEC sp_dboption '数据库名', 'autoshrink', 'TRUE'

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

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

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

--SQL语句的设置方式:

alter database 数据库名 modify file(name=逻辑文件名,maxsize=20)

1、右击数据库选择，打开Files窗口

2、Files窗口，File type 选择 Log，单击OK完成日志收缩。

按以上方法 *** 作没有效果，原因是数据库的恢复模式不是简单模式，只需要将恢复模式改为简单模式即可用以上 *** 作来收缩日志，方便又好用。

将数据库恢复模式改为简单模式方法：

1、右击数据库选择属性，d出窗口如下图，选择Options选项，将 Recovery Model 改为 Simple 即可。

按如下方法 *** 作也可收缩日志：

1、当数据库恢复模式为简单时。使用dbcc shrinkfile (logfile_name,target_size)命令来完成。如

use mydb

dbcc shrinkfile (mydb_log,10) --将mydb_log收缩至10m

2、当数据库恢复模式为完全时。可以先将数据库模式改为简单模式，再使用上述方法来进行。

use master

alter database mydb set recovery simple

dbcc shrinkfile (mydb_log,10) --将mydb_log收缩至10m

也可以直接备份事务日志文件后再收缩：

use master

backup log mydb to disk='d:/ddbak'

use mydb

dbcc shrinkfile (mydb_log,10) --将mydb_log收缩至10m;

3、通过分离数据库，然后再删除事务日志文件，再附加mdf数据文件，也可以达到某种意义上的事务日志收缩。

以下是有关日志文摘

对于每一个数据库来讲，都需要至少一个事务日志文件。事务日志文件是整个数据库的血液，如果没有事务日志的话，那么将无法进行任何 *** 作。

事务日志有什么东西？

事务日志记录着在相关数据库上的 *** 作，同时还存储数据库恢复(recovery)的相关信息。

事务日志与数据库恢复(recovery)是密切相关的，其实数据库在启动时，便会进行相关的恢复(recovery) *** 作，如下所示。当然，在数据库还原时，也可以指定手工恢复(recovery)任何在数据库上的改变，如果在事务日志内被标记为已提交，并用一个LSN(LOG SEQUENCE NUMBER)来标识，同时相关改变就会体现在数据文件上，而被标记为未提交的改变将不会体现在数据文件上。

2010-01-12 18:31:4872 spid7s Recovery is complete This is an informationa message only No user action is required

事务日志文件还存储着数据库需要回滚的相关信息。在SQL Server数据库上，默认是隐式提交的，也就是说在查询分析器里面进行的每一个 *** 作，在 *** 作完成后，都是默认已经commit，但如果通过指定begin tran 和rollback tran的命令来标识事务时，rollback tran就需要使用事务日志内的相关信息才可以回滚。当然，如果SQL Server遇到相关错误时，如死锁，那么也会产生一个内部回滚，这些都需要用到事务日志文件。

为什么要收缩事务日志？

收缩日志的原因有很多种，有些则是考虑空间不足，有些则是应用程序限制导致的，一般情况下，是不建议对事务日志进行其他改变的，如需要控制事务日志的大小，则可以通过安排事务日志备份来解决。如果确定事务日志包含将不再使用的未使用空间，则可以通过减少事务日志的大小，以便回收过多空间。但这种情况对于一个DBA来讲，应该要尽量避免。

仅当数据库处于联机状态，而且至少一个虚拟日志文件可用时，收缩才会发生。在某些情况下，直到下一个日志截断后，才能收缩日志。

事务日志收缩的原理:

每个事务日志由多个虚拟日志文件组成(virtual log file)虚拟日志文件没有固定的大小，也没有固定的个数。在创建事务日志文件或者扩展事务日志文件时，SQL SERVER便会自动创建合适大小的虚拟日志文件，DBA无法控制虚拟日志文件的大小和个数。在扩展日志文件后，虚拟文件的大小是现有日志大小和新文件增量大小之和。因此，如果在创建数据库时，对数据库指定了比较小的初始大小，又指定了比较小的日志增长量，随着事务日志的自动扩展，虚拟日志文件个数会越来越多，从而影响了数据库性能。因此，在创建数据库时，尽量指定比较合适的初始事务日志大小，同时指定合理的事务日志增长量，这点可以参考数据文件的标准。如果大于10G或者更大的话，则指定固定的增长量，如果比较小，则指定按百分比的增长量来进行。

详情参考

>

：

第1步，在SQL Server服务器上依次单击“开始”→“所有程序”→Microsoft SQL Server→“企业管理器”菜单命令，打开SQL Server Enterprise Manager窗口。使用Windows身份验证连接上SQL Server。

第2步，在左窗格中依次展开Microsoft SQL Server→“SQL Server组”→“SQL Server服务器”→“数据库”目录，然后右键单击目标数据库名称（如CPCW data），选择“属性”快捷命令。在打开的“CPCW data 属性”对话框中单击“选项”标签，并在“故障还原”模型下拉菜单中选择“简单”模型。最后单击“确定”按钮使设置生效，如图2008120233所示。

图2008120233 选择“简单”数据还原模型

第3步，返回企业管理器窗口，右键单击目标数据库名称，选择“所有任务”→“收缩数据库”快捷命令，如图2008120234所示。

图2008120234 选择“收缩数据库”命令

第4步，在打开的“收缩数据库”对话框中无须调整参数，直接单击“确定”按钮开始收缩数据库的 *** 作。完成后单击“确定”按钮即可。日志在一些异常情况下往往是恢复数据库的重要依据，收缩数据库 *** 作并不能在很大程度上减小数据库大小，其主要作用是收缩日志大小。因此应当定期进行上述 *** 作，以免数据库日志过大，如图2008120235所示。

图2008120235 执行“收缩数据库” *** 作

-- 清空日志

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

/--特别注意

请按步骤进行,未进行前面的步骤,请不要做后面的步骤

否则可能损坏你的数据库

--/

selectfromsysfiles

--1清空日志

DUMPTRANSACTIONusernameWITHNO_LOG

--2截断事务日志：

BACKUPLOGusernameWITHNO_LOG

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

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

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

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

-- 也可以用SQL语句来完成

--收缩数据库

DBCCSHRINKDATABASE(username)

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

DBCCSHRINKFILE(2)

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

-- a分离数据库:

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

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

-- c附加数据库:

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

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

-- 或用代码：

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

execsp_dboptionusername,'singleuser',true

a分离

EXECsp_detach_db@dbname='username'

b删除日志文件

execmasterxp_cmdshell'delD:\ProgramFiles\SQL\database\username_LOGldf'

c再附加

EXECsp_attach_single_file_db@dbname='username',

@physname='D:\ProgramFiles\SQL\database\username_DataMDF'

--5为了以后能自动收缩,做如下设置:

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

--SQL语句设置方式:

EXECsp_dboption'数据库名','autoshrink','TRUE'

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

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

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

--SQL语句的设置方式:

alterdatabase数据库名modifyfile(name=逻辑文件名,maxsize=20)

企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件--选择日志文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了

15 g 的数据库是很小的库了！这个量级正常是不应该存在慢的问题。

1慢可能是服务器的配置过低，尤其是阿里云服务器租用的配置太低了！感觉你说所的找不到存储过程好像就是阿里云最低配的问题。

2你们还用存储过程，和我们以前的系统一样，所有的业务逻辑都是存储过程完成，所以所有的压力都在数据库服务器上，服务器就容易卡，用存储过程还无法负载均衡。

3表的索引缺失或不合理，很重要的原因。

4使用了大量的触发器，触发器是开始一下爽，后来苦一生。坚决不用触发器，数据量大这个是要命的。

5存储过程里使用大量的link 访问其他数据库服务器，尤其是link 给远程库写数据；如果还写远程数据包含在分布式事务里这就更要命了。

日志1g 慢和它没一毛钱关系，就是占一点空间而已

以上就是关于数据库为什么要进行收缩，怎样收缩收缩能否达到效果全部的内容，包括:数据库为什么要进行收缩，怎样收缩收缩能否达到效果、SQL数据库太大怎么办、sql server 2008 r2如何收缩数据库和文件等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！