logship辅助数据库显示为[可疑] 状态如何解决

lilinew 2011-03-30 03:05:26

2台在线机器 sqlserver2008 logship (a b )a 是主数据库 b 是辅助数据库 2边库名都是mydb
现在作业发生异常

a 主数据库备份正常 job正常
b 辅助数据库现在发现 mydb database can't be opened ? (辅助数据库 2个job 第一个copy正常, 第2个错误 )
后来在辅助数据库我刷新这库mydb 他显示为 [可疑] 状态问该如何让这个库正常能让logship正常.

...全文

118 11 打赏收藏转发到动态举报

写回复

用AI写文章

11 条回复

切换为时间正序

请发表友善的回复…

发表回复

lilinew 2011-04-07

打赏
举报

我是镜像+日志同时做 . 镜像不能实现读写分离.所以我只能2者一起用

楼上有人用过镜像+复制没有 (我有意用镜像+复制来做 ? 可以实现同步)

-狙击手- 2011-03-31

打赏
举报

[Quote=引用 9 楼 perfectaction 的回复:]
logship实际用起来不是很爽，多数情况下出故障，只能重做。
所以，我现在用镜像。
[/Quote]

+1

nzperfect 2011-03-31

打赏
举报

logship实际用起来不是很爽，多数情况下出故障，只能重做。
所以，我现在用镜像。

lilinew 2011-03-31

打赏
举报

上面说的单机器项目. 我说的是 logship辅助库为可疑状态下的恢复.

遇到这个情况直接重新做是最好的.
主库 full backup with format
副库 standby回复

注意网络路径一定要本地测试.遇到域环境下很麻烦, \\net.add.com\sever1\backup能访问
但是 \\10.0.1.1\sever1\backup不能访问
所有的必须测试

--小F-- 2011-03-30

打赏
举报

--常规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

lilinew 2011-03-30

打赏
举报

没有重新回复的机会?

nzperfect 2011-03-30

打赏
举报

重做吧！

lilinew 2011-03-30

打赏
举报

我需要确认SP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDE
这句话是否对当前辅助数据库的其他库a b c有影响. 因为其中 a 库又和另外1台机器组成 logship 是否ecovery model ..?

lilinew 2011-03-30

打赏
举报

如何查原因 ?? 辅助数据很多的库如 a b c mydb. 其他库都是正常的
可以推断物理文件是好

估计是logship德日志换乱造成(我之前手工作了一个全备份)导致失败
现在如何恢复logship 和把这个[可疑] 状态 ---->[备用/只读].

rucypli 2011-03-30

打赏
举报

可疑的原因是什么如果是物理文件损坏只能重做辅库了

lilinew 2011-03-30

打赏
举报

正常的状态他应该是 [备用/只读] , 现在是 [可疑] 状态 ,如何才能让他恢复到 [备用/只读].
有人说在单机应用俄可以这样做(但是当前我的生产库不能下面这样做的按道理应该logship环境不能影响其他主库 ). 当前的辅助数据库还有1个主库
所以不敢动sp_configure 'allow', 1
reconfigure with override 担心有影响

1、新建一同名数据库（文件名，文件组都和原来的一样），然后停止数据库服务，用原来文件替换新建的数据库文件，启动数据库，该数据库被设为suspect

2、把数据库改成紧急模式：
sp_configure 'allow', 1
reconfigure with override
update sysdatabases set status = 32768 where name = '数据库名'
3、把LDF文件改名，再执行
DBCC REBUILD_LOG ('数据库名', 'E:\fdzz\database\fdzz1204_Log.LDF' )
4、恢复数据库紧急模式
update sysdatabases set status = 0 where name = '数据库名'
执行
restore database 数据库名 WITH RECOVERY
sp_configure 'allow', 0
reconfigure with override
5、然后用DBCC CHECKDB ('数据库名')看看有没有错误
6、如果上面还是不行，试试吧数据库设为紧急模式，应该可以看到数据了，在把数据导出到一个新的数据库。

本套视频教程主要讲的linux入侵检测视频教程，从进程、网络、目录、文件、用户、日志等几大要素展开，深入浅出带领大家学习linux入侵检测。本套视频比较基础，适用于安全从业人员，特别是安全运维人员。

【代码】SQL SERVER 数据库显示可疑解决方法。