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

Question

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

Answer 1

正常的状态他应该 是  [备用/只读]  , 现在是 [可疑] 状态 ,如何才能让他恢复到   [备用/只读].
有人说在单机应用俄可以这样做(但是当前我的生产库 不能下面这样做 的  按道理应该logship环境不能影响其他主库 ).  当前的辅助数据库还有1个主库
所以不敢动sp_configure 'allow', 1
reconfigure with override 担心有 影响
  1、新建一同名数据库（文件名，文件组都和原来的一样），然后停止数据库服务，用原来文件替换新建的数据库文件，启动数据库，该数据库被设为suspect2、把数据库改成紧急模式：
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、如果上面还是不行，试试吧数据库设为紧急模式，应该可以看到数据了，在把数据导出到一个新的数据库。 

Answer 2

如何查原因 ?? 辅助数据很多的库 如 a b c mydb. 其他库都是正常的
可以推断物理文件是好估计是logship德日志 换乱造成(我之前手工作了一个全备份)导致失败
现在如何恢复logship 和把这个[可疑] 状态  ---->[备用/只读].

Answer 3

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

Answer 4

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

Answer 5

上面说的单机器项目. 我说的是 logship辅助库为可疑状态下的恢复.遇到这个情况直接重新做是最好的.
主库   full backup with format
副库  standby回复注意网络路径一定要本地测试.遇到域环境下很麻烦, \\net.add.com\sever1\backup能访问
但是 \\10.0.1.1\sever1\backup不能访问
所有的必须测试

Answer 6

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