数据库恢复后的问题

zoufanxx 2009-09-03 10:29:53
不小心删除了数据库的备份
数据库被质疑了
通过替换数据库的数据文件之后 数据库又显示正常了
但是对其中的表执行如update语句时
Could not run BEGIN TRANSACTION in database 'MY_DB' because the database is in bypass recovery mode.
The statement has been terminated.
怎么办?

...全文
305 9 打赏 收藏 转发到动态 举报
写回复
用AI写文章
9 条回复
切换为时间正序
请发表友善的回复…
发表回复
lihan6415151528 2009-09-03
  • 打赏
  • 举报
回复
再重新附加一遍数据库吧 ,不要替换原来的文件
--小F-- 2009-09-03
  • 打赏
  • 举报
回复
--常规SQL SERVER数据库置疑后恢复步骤   
--1. 恢复步骤:
--a.将smlog_log.ldf文件备份到其它目录下;
--b.将源目录下的smlog_log.ldf文件改名为smlog_log_bak.ldf;
--c.执行以下语句修改数据库的状态:
use Master
go
update sysdatabases set status=32768 where name='数据库名称' --修改状态,設為緊急狀態
go
shutdown with nowait --停止数据库服务器
go
--d.退出SQL并在(COMMAND)命令行模式中通过下面的代码重新启动SQL:
sqlservr -c -T3608 -T4022 --安全模式启动SQL SERVER
--e.在查询分析器中执行以下语句来查看刚刚修改过状态的数据库状态:
select Name,Status from sysdatabases where Name='数据库名稱'
--f.执行以下代码新建日志文件:
dbcc traceon(3604)--跟踪
dbcc rebuild_log('数据库名称','日志文件全路徑') --文件名要有全路径和扩展名
--dbcc rebuild_log('prs_msc','d:\mscsql\mssql\data\prs_msc_log.ldf
--g.将数据库置回正常状态:
update sysdatabases set status=0 where name='数据库名称'
--h.重新启动数据库后执行以下语句检查数据库:
DBCC CHECKDB --如果执行完有错误用以下语句修复
--i.要修复数据库必需将数据库改为单用户模式:
Exce sp_dboption '数据库名称','single user','true'---('false'恢复多用户)
--j.执行以下语句修复数据库:
DBCC CHECKDB('数据库名称',REPAIR_ALLOW_DATA_LOSS)
REPAIR_ALLOW_DATA_LOSS:是比较高级的修复方式
REPAIR_FAST:是简单快速的修复方式
/*
處理状态就为"置疑"的數據庫
备份数据文件,然后按下面的步骤处理:
1.新建一个同名的数据库(数据文件与原来的要一致)
2.再停掉sql server(注意不要分离数据库)
3.用原数据库的数据文件覆盖掉这个新建的数据库
4.再重启sql server
5.此时打开企业管理器时会出现置疑,先不管,执行下面的语句(注意修改其中的数据库名)
6.完成后一般就可以访问数据库中的数据了,这时,数据库本身一般还要问题,解决办法是,利用数据库的脚本创建一个新的数据库,并将数据导进去就行了.

*/
USE MASTER
GO
SP_CONFIGURE 'ALLOW UPDATES',1
GO
RECONFIGURE WITH OVERRIDE
GO
UPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='置疑的数据库名'
Go
sp_dboption '置疑的数据库名','single user','true'
Go
DBCC CHECKDB('置疑的数据库名')
Go
update sysdatabases set status=28 where name='置疑的数据库名'
Go
sp_configure 'allow updates',0
GO
reconfigure with override
Go
sp_dboption '置疑的数据库名', 'single user','false'
Go
dawugui 2009-09-03
  • 打赏
  • 举报
回复
不是替换,是还原或附加数据库.

删除了库重来.
xman_78tom 2009-09-03
  • 打赏
  • 举报
回复
日志文件过大?
执行日志备份时会截断日志文件,再用 dbcc shrinkfile 收缩日志文件。
也可以使用分离/附加数据库,直接重建日志文件。附加数据库时不要附加日志文件就可以了。
zoufanxx 2009-09-03
  • 打赏
  • 举报
回复
那个我重建库再导入数据算了
其实起因是因为将库的日志文件 db_mydb_log1.dat直接删除了
是建库的时候指定的LOG ON ../db_mydb_log1.dat 的
因为他目前实在太大了 快10G了
怎么将他减小呢?
xman_78tom 2009-09-03
  • 打赏
  • 举报
回复
如果是 sql server 2000,可以尝试使用 dbcc rebuild_log(dbname, logfile) 重建日志文件。
执行前,必须将数据库置于 EMERGENCY 状态(UPDATE master..sysdatabases SET status=32768 WHERE name=dbname)。
执行后,需要使用 dbcc checkdb(dbname, repair_allow_data_loss) 修复数据库的一致性,可能会造成原有数据的丢失。
zoufanxx 2009-09-03
  • 打赏
  • 举报
回复
而且日志和备份文件被删除了 只有数据文件
zoufanxx 2009-09-03
  • 打赏
  • 举报
回复
[Quote=引用 2 楼 fredrickhu 的回复:]
/*
處理状态就为"置疑"的數據庫
备份数据文件,然后按下面的步骤处理:
1.新建一个同名的数据库(数据文件与原来的要一致)
2.再停掉sql server(注意不要分离数据库)
3.用原数据库的数据文件覆盖掉这个新建的数据库
4.再重启sql server
5.此时打开企业管理器时会出现置疑,先不管,执行下面的语句(注意修改其中的数据库名)
6.完成后一般就可以访问数据库中的数据了,这时,数据库本身一般还要问题,解决办法是,利用数据库的脚本创建一个新的数据库,并将数据导进去就行了.

*/
USE MASTER
GO
SP_CONFIGURE 'ALLOW UPDATES',1
GO
RECONFIGURE WITH OVERRIDE
GO
UPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='置疑的数据库名'
Go
sp_dboption '置疑的数据库名','single user','true'
Go
DBCC CHECKDB('置疑的数据库名')
Go
update sysdatabases set status=28 where name='置疑的数据库名'
Go
sp_configure 'allow updates',0
GO
reconfigure with override
Go
sp_dboption '置疑的数据库名', 'single user','false'
Go
[/Quote]


用的就是这个方法。最后数据库是显示正常了 也可以查询
但是执行update 就会报上面那个异常

xman_78tom 2009-09-03
  • 打赏
  • 举报
回复
不能用简单的文件替换还原数据库,这样会造成事务上的不一致。
如果你有连续的日志备份,可以尝试备份当前数据库的尾日志(backup log with norecovery),再依次还原日志备份(restore database with norecovery),最后还原尾日志(restore database with recovery),也许可以修复现在的问题。

22,210

社区成员

发帖
与我相关
我的任务
社区描述
MS-SQL Server 疑难问题
社区管理员
  • 疑难问题社区
  • 尘觉
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧