请按步骤进行 未进行前面的步骤时 请不要做后面的步骤 以免损坏你的数据库
一般不建议做第 两步 第 步不安全 有可能损坏数据库或丢失数据 第 步如果日志达到上限 则以后的数据库处理会失败 在清理日志后才能恢复
清空日志
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
具体方法有3种。
方法一:
第一步:
backup
log
database_name
with
no_log
或者
backup
log
database_name
with
truncate_only
--
no_log和truncate_only是在这里是同义的,随便执行哪一句都可以。
第二步:
1收缩特定数据库的所有数据和日志文件,执行:
dbcc
shrinkdatabase
(database_name,[,target_percent])
--
database_name是要收缩的数据库名称;target_percent是数据库收缩后的数据库文件中所要的剩余可用空间百分比。
2收缩一次一个特定数据库中的数据或日志文件,执行
dbcc
shrinkfile(file_id,[,target_size])
--
file_id是要收缩的文件的标识
(id)
号,若要获得文件
id,请使用
file_id
函数或在当前数据库中搜索
sysfiles;target_size是用兆字节表示的所要的文件大小(用整数表示)。如果没有指定,dbcc
shrinkfile
将文件大小减少到默认文件大小。两个dbcc都可以带上参数notruncate或truncateonly,具体意思查看联机帮助
方法二:
第一步:
先备份整个数据库以备不测
。
第二步:
备份结束后,在query
analyzer中执行如下的语句:
exec
sp_detach_db
yourdbname,true
--卸除这个db在mssql中的注册信息
第三步:
到日志的物理文件所在的目录中去删除该日志文件或者将该日志文件移出该目录
第四步:
在query
analyzer中执行如下的语句:
exec
sp_attach_single_file_db
yourdbname,'
d:\mssql\data\yourdbname_datamdf
'
--以单文件的方式注册该db,如果成功则mssql将自动为这个db生成一个500k的日志文件。
方法三:
1
进入企业管理器,选中数据库,比如demo
2
所有任务->分离数据库
3
到数据库文件的存放目录,将muonline_logldf文件删除,以防万一,你可以拷出去
4
企业管理器->附加数据库,选muonline,这个时候你会看见日志文件这项是一个叉,不要紧,继续,此时数据库就会提示你该数据库无日志是否创建一个新的,确定就是了。
5
记得数据库重新附加后用户要重新设置一下。
如果以后,不想要它变大:
sql2000下使用:
在数据库上点右键->属性->选项->故障恢复-模型-选择-简单模型。
或用sql语句:
alter
database
数据库名
set
recovery
simple
下面有两个SQL语句可以达到在SQL Server 2005/2008压缩指定数据库文件和日志的大小的效果:
1、DBCC SHRINKDATABASE (Transact-SQL)
收缩指定数据库中的数据文件和日志文件的大小。
语法
DBCC SHRINKDATABASE
( 'database_name' | database_id | 0
[ ,target_percent ]
[ , { NOTRUNCATE | TRUNCATEONLY } ]
)
[ WITH NO_INFOMSGS ]
参数
'database_name' | database_id | 0 要收缩的数据库的名称或 ID。如果指定 0,则使用当前数据库。
target_percent 数据库收缩后的数据库文件中所需的剩余可用空间百分比。
NOTRUNCATE 通过将已分配的页从文件末尾移动到文件前面的未分配页来压缩数据文件中的数据。target_percent 是可选参数。 文件末尾的可用空间不会返回给 *** 作系统,文件的物理大小也不会更改。因此,指定 NOTRUNCATE 时,数据库看起来未收缩。 NOTRUNCATE 只适用于数据文件。日志文件不受影响。
TRUNCATEONLY 将文件末尾的所有可用空间释放给 *** 作系统,但不在文件内部执行任何页移动。数据文件只收缩到最近分配的区。如果与 TRUNCATEONLY 一起指定,将忽略 target_percent。 TRUNCATEONLY 只适用于数据文件。日志文件不受影响。
WITH NO_INFOMSGS 取消严重级别从 0 到 10 的所有信息性消息。
结果集
列名 说明
DbId 数据库引擎试图收缩的文件的数据库标识号。
FileId 数据库引擎尝试收缩的文件的文件标识号。
CurrentSize 文件当前占用的 8 KB 页数。
MinimumSize 文件最低可以占用的 8 KB 页数。这与文件的最小大小或最初创建时的大小相对应。
UsedPages 文件当前使用的 8 KB 页数。
EstimatedPages 数据库引擎估计文件能够收缩到的 8 KB 页数。
没什么影响。
ACCESS就是要经常压缩的。
否则过于庞大。运行起来很慢的
只要压缩方法得当,只会更好不会变坏~~
ACCESS数据库在对数据的删除 *** 作时,并不会自动减小体积,也就是说,只会增加,不会减小,这时候使用压缩和修复数据库就可以减小被已删除的记录所占的体积,对数据本身并没有影响。可以说没有什么坏处,至少我还没发现有什么不好的地方。
这个 *** 作完全可以通过FSO来在线执行。
利用FSO在线压缩一定要记得在压缩前要断开所有的数据库链接,最好将数据库改名再压缩,或压缩备份数据库,不然会损坏数据。
关闭查询再压缩
^_^
以上就是关于SQL Server 压缩日志及数据库文件大小全部的内容,包括:SQL Server 压缩日志及数据库文件大小、SQL数据库如何压缩、如何压缩SQL Server 2005指定数据库文件和日志的大小等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)