数据库常见故障恢复

数据库常见故障恢复方法 SQL Server 有错误时，会把错误信息存在errorlog文件里，我们在升级数据库前，应先检查errorlog，在升级前解决数据库错误，以免错误扩大化。 现将我们在实际使用SQL Server中会遇到的问题整理如下1、 因为某种原因，要转移库到其它目录：数据库设备的路径放在master 库的sysdevices表中，下为其中sysdevices中的两行。low high status cntrltype name phyname mirrorname stripeset 721420288 721440767 2 0 aaa D:MSSQLDATAaaa.dat721444767 721464590 2 0 aaalog D:MSSQLDATAaaalog.dat 因此，移动库只要修改此表中的phyname。 例：要将以上aaa库从D:MSSQLDATA 移至 E:DATA ,运行： use master go sp_configure allow updates, 1 . . . . . . 允许更改系统库里数据 go RECONFIGURE WITH OVERRIDE . . . . . . 配置生效 go UPDATE sysdevices set phyname = E:DATAaaa.dat WHERE name = aaa UPDATE sysdevices set phyname = E:DATAaaalog.dat WHERE name = aaalog Go 如果log 和DB 在一个设备上，只要更新一个设备。 sp_configure allow updates, 0 . . . . . . 禁止更改系统库里数据 go RECONFIGURE WITH OVERRIDE Go 然后停SQL SERVER，将aaa.dat,aaalog.dat 文件拷至改变后目录,再启动SQL2、 如果数据库处于“suspect”，可先试一下对其恢复；恢复方法如下： use master go sp_configure allow updates,1 go reconfigure with override go update master.sysdatabases set status = status 256 WHERE name = dbname go sp_configure allow updates,0 go reconfigure with override go 重起SQL，如果还是不可恢复，则数据库已被损坏或库文件不存在，只有先删除，再重建，从备份恢复3、master被破坏，如何恢复master库： 有Master库备份： A、运行MSSQLBINNSETUP, rebulid master, 字符集和排序顺序一定要和以前一致，。 B、以单用户模式启动,在NT命令行下： C、sqlservr -c -dd:mssqldatamaster.dat m D、isql U sa -P E、执行 load database master from backup_device 2goF、SQL会自动杀死，重起SQL.没有Master备份: A、重建Master,同上A B、disk reinit 重新添加设备： disk reinit name=logical_name, 设备名 physname=physical_name, 设备文件名（包括路径） vdevno=virtual_device_number, 设备号 size=number_of_2K_block 设备大小，以2K 为单位 给出设备原大小，如果信息不对，将永久破坏原有数据。 C、disk refit 进行数据库的重新连接。 D、增加以前的登录和帐号。 F、重新进行对model、tempdb的任何改动。 G、以正常模式起SQL Server4、BCP的使用方法：在NT命令行下：BCP db_name.table_name out/in file_name c -U sa P S server_namedb_name: 数据库库名table_name: 要处理的表名out/in: out为导出, in为导入 file_name: 要导出导入的文件名 -c: 格式化,文件中的一行对应表中的一行5、每当数据库被修改时，就会有内容增加到日志上，如果日志满了，那么所有的修改工作就要被停止。这时可运行： dump transaction dblog_name with truncate_only 只截断日志而没做备份。如果以上也不行可运行 dump transaction dblog_name with no_log 截断日志而没做备份，这个操作本身也不记日志，如果在运行此命令时，数据库发生故障，则故障之前的操作都是不可恢复的。建议少使用。 如果磁盘空间较大，可扩展日志，此方法最安全。 在数据库配置中，直接将trunc log on chkpt打上沟，数据库在每次checkpoint时自动截断日志。