|
发表于 2009-11-13 15:07:19
|
显示全部楼层
随着SQL Server 版软件越来越多,与此相关的数据备份与恢复的问题也越来越多,我们在解决问题的过程中总结了一些经验如下:
一、备份各种形式
①从系统管理里作备份,包括帐套的备份和年度帐的备份,这种份的优点是简单,易操作,压缩性好,占用硬盘空间小,但速度慢,并且如果是软件出现故障的情况下,可能无法进入系统管理.
②从Enterprise Manager里做数据库的备份.每个数据库都有一个单独的备份.这种备份的优点是备份速度快,如果对SQL Server有一定了解的话,也是很简单的.
③如果SQL Server无法启动的话,上述两种方法都是无效的,只能采用复制物理文件的方法,把用户帐套的ufdata.mdf ufdata.ldf 和ufsystem.mdf 和ufsystem.ldf
二、恢复数据的方法
①如果有帐套的备份的话,直接使用系统管理里的帐套引入功能就可以了。在这种情况下,一些操作员的权限信息可以丢失,可以重新赋予权限,也可心恢复原来的ufsystem系统控制库
②如果是年度帐的备份,并且软件中还有这个帐套和年度的话,可以用帐套主管注册,然后从年度帐菜单下引入;如果是没有这个帐套存在,就要在系统管理中新建一套帐,建帐时只要注意启用日期、行业性质、帐套主管即可,其他均可忽略,然后把备份中的ufdata.ba_ 用APP目录下的ufuncomp.exe 将它解压缩为ufdata.bak 再将此文件在enterprise manager 里restore 即可
③通过Enterprise Manager 做的单个数据库的备份的和年度帐的备份可以通过 restore database 功能来操作,具体过程为 右键该数据库—所有任务—还原数据库—从设备—选择设备—磁盘—添加—浏览该文件—确定, 在选项标签里把‘强制还原’选上,移至的物理文件名为 该帐套的目录和文件名。然后就可以正常恢复了。
④如果是从其他数据库的备份信息里恢复的话,就可以选择还原自数据库,然后在参数处查找该数据库和数据库的备份信息。在选项标签里把‘强制还原’选上,移至的物理文件名为 该帐套的目录和文件名。然后就可以正常恢复了。
⑤如果是帐套的备份,而该帐套又包含很多个年度,可以先将该文件解压缩,然后通过方法③所述找到该备份文件(备份设备),查看该设备的内容,选择要恢复数据库对应的备份号(每个年度一个号),在选项标签里选强制恢复,配置正确的物理文件位置
⑥如果只有ufdata.mdf(数据库文件),ufdata.ldf(日志文件)可以运用系统数据库(master)里的系统存储过程 sp_attach_db 来恢复,具体操作过程:在Query Analyzer 或者 Dos 里的osql 命令来实现,exec sp_attach_db ''数据库名'',''参数1(第一个物理文件的目录及文件名)'',''参数1(第二个物理文件的目录及文件名)'' 如 exec sp_attach_db ''ufsystem'',''D:\wf821\admin\ufsystem.ldf'',''D:\wf821\admin\ufsystem.mdf''
注:如果是该数据库为灰色,则需要先断开该物理文件与数据库的连接, 使用sp_detach_db 语法: exec sp_detach_db ''数据库名''
⑦如果是只有mdf 文件(数据库文件),则需要另外一个系统存储过程sp_attach_single_file_db
具体语法为 exec ap_attach_single_file_db ''ufsystem'',''D:\wf821\admin\ufsystem.mdf''
⑧stop SQL Server service ,replace physname by new files and start SQL server service. 其实这一种方法也可以应用于当数据库出现损坏的情况,利用SQL Server 在启动时主动检测数据库是否完好的功能。
SQL Server 备份及恢复的几种方法
当SQL Server数据库崩溃时如何恢复?任何数据库系统都无法避免崩溃的状况,即使你使用了Clustered,双机热备……仍然无法完全根除系统中的单点故障,何况对于大部分用户来说,无法承受这样昂贵的硬件投资。所以,在系统崩溃的时候,如何恢复原有的宝贵数据就成为一个极其重要的问题了。
在恢复的时候,最理想的情况就是你的数据文件和日志文件都完好无损了,这样只需要sp_attach_db,把数据文件附加到新的数据库上即可,或者在停机的时候把所有数据文件(一定要有master等)都copy到原有路径下也行,不过一般不推荐这样的做法,sp_attach_db比较好,虽然麻烦许多。
但是呢,一般数据库崩溃的时候系统是未必能有时间把未完成的事务和脏页等写入磁盘的,这样的情况sp_attach_db就会失败。那么,寄期望于DBA制定了一个良好的灾难恢复计划吧。按照你的恢复计划,还原最新的完全备份,增量备份或者事务日志备份,然后如果你的活动事务日志还能读得出来的话,恭喜你!你可以还原到崩溃前的状态。
一般的单位都是没有专职的DBA的,如果没有可用的备份,更可能是最近一次备份的时间过于久远而导致不可接受的数据损失,而且你的活动事务日志也处于不可用的状态,那就是最麻烦的情况了。
不幸的很的是,一般数据库崩溃都是由于存储子系统引起的,而这样的情况是几乎不可能有可用的日志用于恢复的。
那么就只好试一下这些方案了。当然,是要求至少你的数据文件是存在的,要是数据文件、日志文件和备份都没有了的话,别找我,你可以到楼顶上去唱“神啊,救救我吧”。
首先,你可以试一下sp_attach_single_file_db,试着恢复一下你的数据文件,虽然能恢复的可能性不大,不过假如这个数据库刚好执行了一个checkpoint的话,还是有可能成功的。
如果你没有好到有摸彩票的手气,最重要的数据库没有像你期盼的那样attach上去,不要气馁,还是有别的方案的。
我们可以试着重新建立一个log,先把数据库设置为emergency mode,sysdatabases的status为32768 就表示数据库处于此状态。
不过系统表是不能随便改的,设置一下先
Use Master
Go
sp_configure ''allow updates'', 1
reconfigure with override
Go
然后
update sysdatabases set status = 32768 where name = ''<db_name>''
现在,祈求满天神佛的保佑吧,重新建立一个log文件。成功的机会还是相当大的,系统一般都会认可你新建立的日志。如果没有报告什么错误,现在就可以松一口气了。
虽然数据是恢复了,可是别以为事情就算完成了,正在进行的事务肯定是丢失了,原来的数据也可能受到一些损坏。
先把SQL Server 重新启动一下,然后检查你的数据库吧。
先设置成单用户模式,然后做dbcc
sp_dboption ''<db_name>'', ''single user'', ''true''
DBCC CHECKDB(''<db_name>'')
如果没有什么大问题就可以把数据库状态改回去了,记得别忘了把系统表的修改选项关掉。
update sysdatabases set status = 28 where name = ''<db_name>'' --当然你的数据库状态可能不是这个,自己改为合适的值吧。也可以用sp_resetstatus
go
sp_configure ''allow updates'', 0
reconfigure with override
Go
checkdb的时候可能报告有一些错误,这些错误的数据你可能就只好丢弃了。
checkdb有几种修复选项,自己看着用吧,不过最后你可能还是得用REPAIR_ALLOW_DATA_LOSS,完成所有修复。
chekcdb并不能完成所有的修复,我们需要更进一步的修复,用DBCC CHECKTABLE对每一个表做检查吧。
表的列表可以用sysobjects里面得到,把OBJECTPROPERTY是IsTable的全部找出来检查一下吧,这样能够基本上解决问题了,如果还报告错误,试着把数据select into到另一张表检查一下。
这些都做完了之后,把所有索引、视图、存储过程、触发器等重新建立一下。DBCC DBREINDEX也许可以帮你一些忙。
然后,就可以向boss吹嘘一下你的丰功伟业,顺便小小的提一下加薪的要求,如果(很有可能)不得逞的话,也只好回家睡觉去:''(
记得下次别忘了做好备份哦~
上面提到的命令、对象在Books Online中均有详细说明,请注意参看。
SQL数据库技巧
一.怎样删除一个表中某个字段重复的列呀,举个例子
表[table1]
id name
1 aa
2 bb
3 cc
1 aa
2 bb
3 cc
我想最后的表是这样的
id name
1 aa
2 bb
3 cc
回答:
将记录存到临时表#t中,重复的记录只存一条,然后将临时表#t中的记录再存回原表中,注意“select distinct id,class,name”要包含你需要的所有字段,否则有些字段就被删掉了。
在查询管理器里执行下面代码:
-----------------------------
Select DISTINCT id,, name
INTO #t
FROM table1 Delete table1
Insert
INTO table1
Select *
FROM #t |
|