数据库还原问题..请高手们帮帮忙. 100cywarson]

发布时间:2014-1-1 0:09:55编辑:www.fx114.net 分享查询网我要评论
本篇文章主要介绍了"数据库还原问题..请高手们帮帮忙. 100cywarson]",主要涉及到数据库还原问题..请高手们帮帮忙. 100cywarson]方面的内容,对于数据库还原问题..请高手们帮帮忙. 100cywarson]感兴趣的同学可以参考一下。

数据库名为:cs 数据库文件有: cs.mdf            e:\program files\microsoft sql server\mssql.1\mssql\data cs1.ndf           f:\backup cs_log.ldf        e:\program files\microsoft sql server\mssql.1\mssql\data cs_log1.ldf f:\backup 现在日志文件太大了,想用分离方法分离数据库,删除日志文件,但却没法还原. (正常情况:一个数据文件与日志文件是可以还原的) 在sqlServer 2005与sqlserver 2000都是一样没法还原. 请问高手们是否遇过类似的问题,有何解决方法. 是否有何删除日志与压缩日志的解决方案呢. 谢谢!~

压缩日志及数据库文件大小 /*--特别注意 请按步骤进行,未进行前面的步骤,请不要做后面的步骤 否则可能损坏你的数据库. 一般不建议做第4,6两步 第4步不安全,有可能损坏数据库或丢失数据 第6步如果日志达到上限,则以后的数据库处理会失败,在清理日志后才能恢复. --*/ --下面的所有库名都指你要处理的数据库的库名 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 7.0,这步只能在查询分析器中进行) a.分离数据库: 企业管理器--服务器--数据库--右键--分离数据库 b.在我的电脑中删除LOG文件 c.附加数据库: 企业管理器--服务器--数据库--右键--附加数据库 此法将生成新的LOG,大小只有500多K 或用代码:  下面的示例分离 pubs,然后将 pubs 中的一个文件附加到当前服务器。 a.分离 EXEC sp_detach_db @dbname = '库名' b.删除日志文件 c.再附加 EXEC sp_attach_single_file_db @dbname = '库名',     @physname = 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\库名.mdf' 5.为了以后能自动收缩,做如下设置: 企业管理器--服务器--右键数据库--属性--选项--选择"自动收缩" --SQL语句设置方式: EXEC sp_dboption '库名', 'autoshrink', 'TRUE' 6.如果想以后不让它日志增长得太大 企业管理器--服务器--右键数据库--属性--事务日志 --将文件增长限制为xM(x是你允许的最大数据文件大小)

学习了

TO LouisXIV 是按1,2,3..的步骤完成压缩日志及数据库文件大小嘛.. 我想不是吧. 还是1,2,3..每一个都是一个压缩日志及数据库文件大小的方法呢. 第3个方法收缩的空间不大. 我想问,能否把日志文件清空后,生成一个新的日志文件呢(类似于分离数据库的做法) 请高手们帮帮忙...(急用) 有好的解决方案另开贴给分. 现在之所有分离不了,是因为数据库cs有四个文件,路径不同. cs.mdf            e:\program files\microsoft sql server\mssql.1\mssql\data cs1.ndf           f:\backup cs_log.ldf        e:\program files\microsoft sql server\mssql.1\mssql\data cs_log1.ldf    f:\backup

用分离方法分离数据库,删除日志文件 这个方法在论坛流行,至少造成了多例没法恢复的情况,再次呼吁,非正常的方法不要在一般情况推荐。

正常情况下: 2.截断事务日志: BACKUP LOG 库名 WITH NO_LOG 3.收缩数据库文件(如果不压缩,数据库的文件不会减小 企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件 --选择日志文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了 --选择数据文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了 也可以用SQL语句来完成 --收缩数据库 DBCC SHRINKDATABASE(库名) 就够了

--截断日志  backup log 数据库名 with no_log  --提供有关所有数据库中的事务日志空间使用情况的统计信息。  dbcc sqlperf (logspace)  --收缩数据库  dbcc shrinkdatabase (数据库名, truncateonly)  说明: TRUNCATEONLY 将数据文件中的任何未使用的空间释放给操作系统,并将文件收缩到上一次所分配的大小,从而减少文件大小,而不移动任何数据。 特定数据库的所有数据和日志文件。执行 DBCC SHRINKDATABASE 一次一个特定数据库中的数据或日志文件。执行 DBCC SHRINKFILE

/*--压缩数据库的通用存储过程      压缩日志及数据库文件大小   因为要对数据库进行分离处理   所以存储过程不能创建在被压缩的数据库中  --邹建 2004.3--*/  /*--调用示例   exec p_compdb 'test'  --*/  use master--注意,此存储过程要建在master数据库中  go  if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[p_compdb]') and OBJECTPROPERTY(id, N'IsProcedure') = 1)  drop procedure [dbo].[p_compdb]  GO  create proc p_compdb  @dbname sysname, --要压缩的数据库名  @bkdatabase bit=1, --因为分离日志的步骤中,可能会损坏数据库,所以你可以选择是否自动数据库  @bkfname nvarchar(260)='' --备份的文件名,如果不指定,自动备份到默认备份目录,备份文件名为:数据库名+日期时间  as  --1.清空日志  exec('DUMP TRANSACTION [[email protected]+'] WITHNO_LOG')  --2.截断事务日志:  exec('BACKUP LOG [[email protected]+'] WITH NO_LOG')  --3.收缩数据库文件(如果不压缩,数据库的文件不会减小  exec('DBCC SHRINKDATABASE([[email protected]+'])')  --4.设置自动收缩  exec('EXEC sp_dboption [email protected]+''',''autoshrink'',''TRUE''')  --后面的步骤有一定危险,你可以可以选择是否应该这些步骤  --5.分离数据库  if @bkdatabase=1  begin   if isnull(@bkfname,'')=''    set @[email protected]+'_'+convert(varchar,getdate(),112)   +replace(convert(varchar,getdate(),108),':','')   select 提示信息='备份数据库到SQL 默认备份目录,备份文件名:[email protected]   exec('backup database [[email protected]+'] to [email protected]+'''')  end  --进行分离处理  create table #t(fname nvarchar(260),type int)  exec('insert into #t select filename,type=status&0x40 from [[email protected]+']..sysfiles')  exec('sp_detach_db [email protected]+'''')  --删除日志文件  declare @fname nvarchar(260),@s varchar(8000)  declare tb cursor local for select fname from #t where type=64  open tb  fetch next from tb into @fname  while @@fetch_status=0  begin   set @s='del "'+rtrim(@fname)+'"'   exec master..xp_cmdshell @s,no_output   fetch next from tb into @fname  end  close tb  deallocate tb  --附加数据库  set @s=''  declare tb cursor local for select fname from #t where type=0  open tb  fetch next from tb into @fname  while @@fetch_status=0  begin   set @[email protected]+','''+rtrim(@fname)+''''   fetch next from tb into @fname  end  close tb  deallocate tb  exec('sp_attach_single_file_db [email protected][email protected])  go 

在有多个日志时,是不能使用sp_attach_single_file_db进行附加的

还是参考“海阔天空”的方法, 也可以通过修改数据库的恢复模型来截断日志,但不建议。 方法: 将恢复模型改为“简单模式” 然后使用 dbcc shrinkfile 收缩完后,再改回“完全模式” !!最后这一步很重要: 在改回“完全模式”后一定要作一次全盘的备份

TO suntt(两条腿的狗)  请问日志文件能否压缩至1M呢. 如果40G的日志,被我手动设置为只有1M.会有何影响呢. 之后改回“完全模式”产生的日志,会对之后更新的记录进行日志恢复嘛.

日志文件能压缩到多少,这不重要也说不准,这和当前还有多少未提交的事务的日志量有关,压缩的时候只能删除当前完成的事务的日志。 长久来说,最有效防止日志文件过大的方法是制订周密的备份计划,用作业安排好完全备份和日志备份,这两个备份都能够自动清除日志,只要定时备份了,日志文件的空间及时清理出来,日志文件就不会太大,也就没必要收缩了,至于多长时间一次完全备份,多长时间一次日志备份,看你自己的数据库应用情况。

使用 dbcc shrinkfile压缩,是否能够压缩到1M主要看活动的事务日志是否<=1M,若小于的话可能会压缩到1M的 当改回完全模式后,以后所作的日志备份与以前你所作的日志备份是不能够一起使用的。 因此我在上面写的:当改回完全模式后,一定要作一次全盘的备份,避免日志的恢复的不连续性

同意海阔天空的意见: 经常的作日志备份,就会自己阶段日志的,日志增长的会比较缓慢一些。

Study!!!UP!!!

八神苍月的这篇文章或许对你有帮助 浅谈几个SQL的日志概念 八神苍月    解释几个关于SQL日志的概念,他们也经常使初学者望而止步,反正计算机的术语都是很抽象的,所以第一感觉就是头疼,然后然后几次后就没感觉了 物理日志文件:     这个比较好理解,实实在在的东西,数据库目录下面的.ldf文件就是,有些人喜欢改后缀,感觉不大好,数据库的事务日志记录就在这里面 虚拟日志:     相信多数人有这个感觉,虚拟这个字眼总是神秘的代名词,虚拟个饭岛爱我喜欢,但虚拟日志,虚拟内存,虚拟。。。。,看了就讨厌。解释应该是这样的,对于一个或多个连续的物理日志文件,SQL SERVER在这些文件的内部又划分成了多个小的文件,称为虚拟日志文件,他是日志文件收缩和日志截断的最小单位,比如物理日志文件是400M,内部划分了4个100M的虚拟文件,收缩时你得到的是300M,200M,不可能得到239M,对于一个物理文件,会划分成多少个虚拟文件,这个由SQL自己维护,唯一可以人工干预的是指定较大的物理日志文件,并指定较大的增长比例,这样可能虚拟文件的块头会大点,数量会少点,系统的维护开销会低一点 逻辑日志:     不要头晕,硬着头皮看吧!!!感觉这个应该是数据库事务日志的真实写照,物理日志文件好比是一个容器,里面容纳的是日志记录,这些记录就称为逻辑日志,从物理日志文件的起点开始,逻辑日志顺序的生成,记录下数据库里发生的每个事务,这些事务被打上一个标签,LSN,顺序的排列下来,这样逻辑日志就在物理日志文件内慢慢的成长,直到充满了他,这个时候物理日志文件就会自动添加新的空间,以继续前面的步骤,这种情况是最直接的一种(从来不截断日志,基本上就是这样的),但事实上往往是复杂的多 检测点(checkpoint)和恢复周期(recovery interval):     checkpoint不是用于检查数据是否完整,页面连接是否正确的,他是由系统维护的一个进程(你也可以手工的执行),用于将高速缓存里的脏页刷新到磁盘,两者的配合算是惟妙惟肖,当缓存中的脏页积累到一定的数量,SQL估计演算这些脏页要花的时间快要接近设定的recovery interval(分钟)时,系统就会产生一个checkpoint,所以checkpoint的产生不是定时的,它由recovery interval和数据库的更新频繁度决定。如果你的数据库永远不用重启,永远不会出现什么故障,就这么一直运行下去,那么checkpoint和 recovery interval就没有想象中的重要了,SQL总是先写日志,情况应该是这样的:用户提交一个更新操作,SQL在高速缓存里缓冲了需要的数据页和日志页,然后打上begin tran标签,对日志进行修改,再修改数据页,然后打上commit tran标签,最后把修改过的日志页刷新到磁盘上,在保证了这个步骤完成后,数据页才被写入磁盘,如果这个时候机器突然断电导致高速缓存中数据页的丢失,那么重启机器时SQL的恢复进程将根据已经刷新的日志记录来演算刚才的数据页,保证数据的完整性,这就好比支票已经开到了,但货却在路上丢了,凭借支票,你还是可以得到你的东西,像这种提交了又还没来得及刷新数据页到磁盘的日志事务可以称为活动日志,虽然概念不是这么定义的,但可以这么理解,因为一旦日志记录和其对应的数据页被刷新到磁盘的话,这条日志的作用也就完成了,并称为非活动的日志,他的唯一用处就是备份下来留着以后做日志恢复,所以SQL的逻辑日志你就应该知道大概是怎么个样子了,前面一大部分,是已经演算的日志记录(非活动日志),后面一部分,是还没有演算的(活动日志),活动部分的第一条事务称为MinLSN,系统会搁段时间利用检测点(checkpoint)演算活动日志,来缩短数据库重启时的恢复时间,在演算结束后, checkpoint会在日志里打上一个结束语,并将MinLSN标识给下一个紧跟着的活动事务日志,这也是下一个checkpoint的起点 截断事务日志:     这个概念很是让初学者费解,截断是什么意思???截断后日志还会增长吗???截断总有个断点吧,他是从哪里开始截断的阿???截断后会释放日志空间吗???等等。。。。现在逐一击破     首先截断是对SQL逻辑日志的一个清除过程,清除非活动的逻辑事务日志。可以想象断点应该是活动与非活动的边界处--MinLSN,他会将 MinLSN前面的这段日志清除掉,逻辑日志的起点也会指向断点MinLSN处,清除出来的空间并不会返还给操作系统,而是被标识为非活动的虚拟日志文件,他表示当有新的日志记录进来时,这些空间可以被再次利用,所以截断日志并不会减小物理日志文件的大小,只是清理了里面的一些内容,以便新的日志记录可以进来,SQL总是以循环链表的方式使用物理日志文件的,当逻辑日志增长到物理日志文件的尽头时,他会循环到日志文件的首部搜索被截断而释放出来的空间,如果这个时候没有空间的话,说明物理日志已经用完了,就得增加物理日志的大小,如果磁盘也用尽了,系统就会返回一个错误提示。至于截断后日志是否还会增长,疑点可能存在于trunc log on chkpt上,当数据库处于这种状态时用户会发现他们的日志文件总是那么小一点点,道理很简单,检查点截断日志后,日志文件里面总会有空间容纳新的日志记录,自然是不会变大了,但也有特殊情况,当一个较长的事务运行时(比如一个长达2个小时的UPDATE语句),他会迅速的充满日志,并补充新的空间进来,这个时候系统是来不及截断的,这样物理日志文件就马上变大了,当事务完成后,截断再进行时,对文件的大小他是无能为力了,只是清理下刚才的战场而已,所以截断日志后逻辑日志是继续增长的,至于物理日志,要看你提交事务的大小了 最后的话题:     经常听到这样的说法,定期转存事务日志,以释放日志空间,backup log...with no_log,backup log...with truncate_only,这些只能使日志文件不变大,要想减小日志文件,还的收缩日志文件,这样才真正将空间返还给操作系统,在sybase里面 truncate_only和no_log还是有区别的,都是截断日志,但前者在截断之前会启动checkpoint,所以当你的日志完全被充满, truncate_only是不能成功的,他已经没有空间让你checkpoint,这时只能采用no_log(SQL里面我还不知道),还有一个关键字就是no_truncate,他表示备份但不截断日志(默认是截断的),在数据库因故障损坏时用这个备份日志特别有效 好了,就说这么多了,由于这部分的概念实在是太抽象,本人能力也非常有限,所以表述可能不大清楚,错误的地方请多多指教!!!

在sybase里面 truncate_only和no_log还是有区别的…… 倒,sybase阿

to:楼上 这篇是针对mssql说的 毕竟sybase中是没有backup log 这种语法的

还是收缩数据库比较保险吧。

-------------------------------------------------------------- 您好,我们是“2006中国杰出数据库工程师评选”活动组委会。 您的帖子已经被我们转载到本次评选官方网站的“专家在线答疑”区。 http://www.bestdba.cn/match_discussion.aspx 在那里,进入本次评选终选的30位数据库工程师将与您展开积极的互动。他们会为您的问题提供满意的答案, 此外,您还可以在“专家在线答疑”区提出新的问题并参与讨论。 您的帖子位于: http://www.bestdba.cn/match_discussion3.aspx?pointid=445&pointid2=1&pointid3=5&pcount=stc 非常感谢您对本次活动的支持! --------------------------------------------------------------

mask


上一篇:数据库恢复问题 20CSDN]
下一篇:格式化日期类型 20CSDN]

相关文章

相关评论

本站评论功能暂时取消,后续此功能例行通知。

一、不得利用本站危害国家安全、泄露国家秘密,不得侵犯国家社会集体的和公民的合法权益,不得利用本站制作、复制和传播不法有害信息!

二、互相尊重,对自己的言论和行为负责。

好贷网好贷款