收缩数据库与收缩日志
请按步骤进行 未进行前面的步骤时 请不要做后面的步骤 以免损坏你的数据库
一般不建议做第 两步 第 步不安全 有可能损坏数据库或丢失数据 第 步如果日志达到上限 则以后的数据库处理会失败 在清理日志后才能恢复
清空日志
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语句的设置方式:
lishixin/Article/program/SQLServer/201311/22266
Ⅱ SQL Server实用经验技巧集（1）
此文是Sql Server实用操作小技巧集合 包括安装时提示有挂起的操作 收缩数据库 压缩数据库 转移数据库给新用户以已存在用户权限 检查备份集 修复数据库等 （一）挂起操作 在安装Sql或sp补丁的时候系统提示之前有挂起的安装操作 要求重启 这里往往重启无用 解决办法 到HKEY_LOCAL_ Manager删除PendingFileRenameOperations （二）收缩数据库 重建索引DBCC REINDEXDBCC INDEXDEFRAG 收缩数据和日志DBCC SHRINKDBDBCC SHRINKFILE （三）压缩数据库 dbcc shrinkdatabase(dbname) （四）转移数据库给新用户以已存在用户权限 exec sp_change_users_login update_one newname oldname go （五）检查备份集 RESTORE VERIFYONLY from disk= E:dvbbs bak （六）修复数据库 ALTER DATABASE [dvbbs] SET SINGLE_USERGODBCC CHECKDB( dvbbs repair_allow_data_loss) WITH TABLOCKGOALTER DATABASE [dvbbs] SET MULTI_USERGO CHECKDB 有 个参数: REPAIR_ALLOW_DATA_LOSS 执行由 REPAIR_REBUILD 完成的所有修复 包括对行和页进行分配和取消分配以改正分配错误 结构行或页的错误 以及删除已损坏的文本对象 这些修复可能会导致一些数据丢失 修复操作可以在用户事务下完成以允许用户回滚所做的更改 如果回滚修复 则数据库仍会含有错误 应该从备份进行恢复 如果由于所提供修复等级的缘故遗漏某个错误的修复 则将遗漏任何取决于该修复的修复 修复完成后 备份数据库 REPAIR_FAST 进行小的 不耗时的修复操作 如修复非聚集索引中的附加键 这些修复可以很快完成 并且不会有丢失数据的危险 REPAIR_REBUILD 执行由 REPAIR_FAST 完成的所有修复 包括需要较长时间的修复（如重建索引） 执行这些修复时不会有丢失数据的危险 DBCC CHECKDB( dvbbs ) with NO_INFOMSGS PHYSICAL_ONLY SQL SERVER日志清除的两种方法 在使用过程中大家经常碰到数据库日志非常大的情况 在这里介绍了两种处理方法…… 方法一 一般情况下 SQL数据库的收缩并不能很大程度上减小数据库大小 其主要作用是收缩日志大小 应当定期进行此操作以免数据库日志过大 设置数据库模式为简单模式 打开SQL企业管理器 在控制台根目录中依次点开Microsoft SQL Server >SQL Server组 >双击打开你的服务器 >双击打开数据库目录 >选择你的数据库名称（如论坛数据库Forum） >然后点击右键选择属性 >选择选项 >在故障还原的模式中选择 简单 然后按确定保存 在当前数据库上点右键 看所有任务中的收缩数据库 一般里面的默认设置不用调整 直接点确定 收缩数据库完成后 建议将您的数据库属性重新设置为标准模式 操作方法同第一点 因为日志在一些异常情况下往往是恢复数据库的重要依据 方法二 SET NOCOUNT ONDECLARE @LogicalFileName sysname @MaxMinutes INT @NewSize INTUSE tablename 要操作的数据库名SELECT@LogicalFileName = tablename_log 日志文件名@MaxMinutes = Limit on time allowed to wrap log @NewSize = 你想设定的日志文件的大小(M) Setup / initializeDECLARE @OriginalSize intSELECT @OriginalSize = sizeFROM sysfilesWHERE name = @LogicalFileNameSELECT Original Size of + db_name() + LOG is +CONVERT(VARCHAR( ) @OriginalSize) + K pages or +CONVERT(VARCHAR( ) (@OriginalSize* / )) + MB FROM sysfilesWHERE name = @LogicalFileNameCREATE TABLE DummyTrans(DummyColumn char ( ) not null)DECLARE @Counter INT @StartTime DATETIME @TruncLogVARCHAR( )SELECT@StartTime = GETDATE() @TruncLog = BACKUP LOG + db_name() + WITH TRUNCATE_ONLY DBCC SHRINKFILE (@LogicalFileName @NewSize)EXEC (@TruncLog) Wrap the log if necessary WHILE @MaxMinutes > DATEDIFF (mi @StartTime GETDATE()) time has not expiredAND @OriginalSize = (SELECT size FROM sysfiles WHERE name = @LogicalFileName)AND (@OriginalSize * / ) > @NewSizeBEGIN Outer loop SELECT @Counter = WHILE((@Counter < @OriginalSize / ) AND (@Counter < ))BEGIN updateINSERT DummyTrans VALUES ( Fill Log )DELETE DummyTransSELECT @Counter = @Counter + ENDEXEC (@TruncLog)ENDSELECT Final Size of + db_name() + LOG is +CONVERT(VARCHAR( ) size) + K pages or +CONVERT(VARCHAR( ) (size* / )) + MB FROM sysfilesWHERE name = @LogicalFileNameDROP TABLE DummyTransSET NOCOUNT OFF lishixin/Article/program/SQLServer/201311/22232
Ⅲ 收缩数据库日志的影响，数据库日志已满，如何处理
--此为数据文件、数据库日志文件收缩操作语句
--保存时间：2017-1-9
--使用说明：
--“DataBase”为数据库名称，在进行数据收缩操作前，先做好数据备份
--将语句中的“DataBase”替换为需要进行数据收缩的数据库名称，如：test
--在进行数据库收缩的时候，要留出操作时间，期间不要进行任何用户操作
--确认无误后，执行语句，即可进行数据收缩！
usemaster
go
_WAIT
go
go
declare@namevarchar(20)
declare@sqlvarchar(100)
select@name=namefromsys.database_fileswheretype=1
set@sql='DBCCSHRINKFILE(N'''+@name+''',11,TRUNCATEONLY)'
exec(@sql)
go
dbccshrinkdatabase(DataBase)
go
_WAIT
go
--设置恢复模式（'SIMPLE'表示简单；'FULL'表示完整）
go
--设置数据库兼容性级别为sql2008
_level=100
go
Ⅳ sql2008中如何收缩数据库日志文件
解决方法:
方法一
右键选择数据库-》任务-》收缩-》文件-》文件类型-》日志-》在释放未使用的空间前重新组织页
方法二（不推荐）
1 必须先改成简单模式
2 然后用
----Logical Files :
--CMS1.5_Data
--CMS1.5_Log
DBCC SHRINKFILE (N'CMS1.5_Log' , 1)
GO
注：Data是数据文件，Log是日志文件
Ⅳ 数据库日志文件过大如何收缩
网页链接我是用这个方法收缩的，可以将日志收缩到1MB
守得云开见月明,花了一个上午结合前辈的博客，终于弄好了sqlserver2008的数据库日志收缩到1MB，分享给大家
# 方法步骤
1、执行SQL语句改成“简单模式”
2、收缩数据库
3、执行SQL语句改回“完全模式”
## 第一步：执行SQL语句改成“简单模式”
USE [master]
GO
ALTER DATABASE SlowXWebDB (改成你需要进行收缩的数据库名) SET RECOVERY SIMPLE WITH NO_WAIT
GO
ALTER DATABASE SlowXWebDB (改成你需要进行收缩的数据库名) SET RECOVERY SIMPLE --改成简单模式
GO
## 第二步：进行数据库操作
相关界面截图和操作
假定：
数据库名：SlowXWebDB
日志文件名：SlowXWebDB_Log
## 第三步：执行SQL语句改成“完全模式”
USE [master]
GO
ALTER DATABASE SlowXWebDB (改成你需要进行收缩的数据库名)SET RECOVERY FULL WITH NO_WAIT
GO
ALTER DATABASE datebaseName(改成你需要进行收缩的数据库名)SET RECOVERY FULL --还原为完全模式
GO
==最后不要忘记实测下数据库是否能够正常使用==
网页链接
Ⅵ sql server怎么收缩日志
1、首先选中数据库右键--属性 点击
Ⅶ sql server 2008 r2如何收缩数据库和文件
1、右击数据库选择，打开Files窗口
2、Files窗口，File type 选择 Log，单击OK完成日志收缩。
按以上方法操作没有效果，原因是数据库的恢复模式不是简单模式，只需要将恢复模式改为简单模式即可用以上操作来收缩日志，方便又好用。
将数据库恢复模式改为简单模式方法：
1、右击数据库选择属性，弹出窗口如下图，选择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:/dd.bak'
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:48.72 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或者更大的话，则指定固定的增长量，如果比较小，则指定按百分比的增长量来进行。
详情参考
http://hi..com/lxiangshanyu/item/7057ce04081efae9fe240d64