方法一:
第一步:
backup
log
database_name
with
no_log
或者
backup
log
database_name
with
truncate_only
--
no_log和truncate_only是在这里是同义的,随便执行哪一句都可以。
第二步:
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_data.mdf
'
--以单文件的方式注册该db,如果成功则mssql将自动为这个db生成一个500k的日志文件。
方法三:
1.
进入企业管理器,选中数据库,比如demo
2.
所有任务->分离数据库
3.
到数据库文件的存放目录,将muonline_log.ldf文件删除,以防万一,你可以拷出去
4.
企业管理器->附加数据库,选muonline,这个时候你会看见日志文件这项是一个叉,不要紧,继续,此时数据库就会提示你该数据库无日志是否创建一个新的,确定就是了。
5.
记得数据库重新附加后用户要重新设置一下。
如果以后,不想要它变大:
sql2000下使用:
在数据库上点右键->属性->选项->故障恢复-模型-选择-简单模型。
或用sql语句:
alter
database
数据库名
set
recovery
simple
1.打开查询分析器,输入命令DUMP TRANSACTION 数据库名 WITH NO_LOG2.再打开企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件--选择日志文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了。清除Log有两种方法:1.自动清除法开放数据库选项 Trunc Log on Chkpt,使数据库系统每隔一段时间自动清除Log。此方法的优点是无须人工干预,由SQL Server自动执行,并且一般不会出现Log溢满的情况;缺点是只清除Log而不做备份。2.手动清除法执行命令“dump transaction”来清除Log。以下两条命令都可以清除日志:dump transaction with truncate_onlydump transaction with no_log通常删除事务日志中不活跃的部分可使用“dump transaction with trancate_only”命令,这条命令写进事务日志时,还要做必要的并发性检查。SYBASE提供“dump transaction with no_log”来处理某些非常紧迫的情况,使用这条命令有很大的危险性,SQL Server会d出一条警告信息。为了尽量确保数据库的一致性,你应将它作为“最后一招”。收缩数据库一般情况下,SQL数据库的收缩并不能很大程度上减小数据库大小,其主要作用是收缩日志大小,应当定期进行此 *** 作以免数据库日志过大
1、设置数据库模式为简单模式:打开SQL企业管理器,在控制台根目录中依次点开Microsoft
SQL
Server-->SQL
Server组-->双击打开你的服务器-->双击打开数据库目录-->选择你的数据库名称(如论坛数据库Forum)-->然后点击右键选择属性-->选择选项-->在故障还原的模式中选择“简单”,然后按确定保存
2、在当前数据库上点右键,看所有任务中的收缩数据库,一般里面的默认设置不用调整,直接点确定
3、收缩数据库完成后,建议将您的数据库属性重新设置为标准模式, *** 作方法同第一点,因为日志在一些异常情况下往往是恢复数据库的重要依据
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)