lianglei0348 发表于 2009-07-22 16:58

启动出错

启动DB时候,提示
00:00000:00011:2009/07/22 16:38:09.25 serverRecovering database 'cxsrv2009'.
00:00000:00011:2009/07/22 16:38:09.25 serverStarted estimating recovery log boundaries for database 'cxsrv2009'.
00:00000:00011:2009/07/22 16:38:09.25 serverStarted ANALYSIS pass for database 'cxsrv2009'.
00:00000:00011:2009/07/22 16:38:09.25 serverCompleted ANALYSIS pass for database 'cxsrv2009'.
00:00000:00011:2009/07/22 16:38:09.25 serverStarted REDO pass for database 'cxsrv2009'. The total number of log records to process is 13.
00:00000:00011:2009/07/22 16:38:09.25 serverError: 21, Severity: 21, State: 1
00:00000:00011:2009/07/22 16:38:09.25 serverWARNING - Fatal Error 3474 occurred at Jul 22 20094:38PM.Please note the error and time, and contact a user with System Administrator (SA) authorization.
00:00000:00011:2009/07/22 16:38:09.25 serverError: 3474, Severity: 21, State: 1
00:00000:00011:2009/07/22 16:38:09.25 serverDuring redo the page timestamp value is less than old timestamp from log. Page #=290204, object id = 1621577784, page timestamp=0000 2a3ba82f9d. Log old timestamp=0000 2a44f4fb6a. Log record marker = (5827351, 0).
00:00000:00011:2009/07/22 16:38:09.25 serverError: 21, Severity: 21, State: 1
00:00000:00011:2009/07/22 16:38:09.25 serverWARNING - Fatal Error 3414 occurred at Jul 22 20094:38PM.Please note the error and time, and contact a user with System Administrator (SA) authorization.
00:00000:00011:2009/07/22 16:38:09.26 serverError: 3414, Severity: 21, State: 1
00:00000:00011:2009/07/22 16:38:09.26 serverDatabase 'cxsrv2009' (dbid 5): Recovery failed. Check the SQL Server errorlog for further information as to the cause.

改成-32768后截断日志提示:
Server Message:Number3908, Severity16
Server 'HFMIS', Line 1:
Attempt to BEGIN TRANSACTION in database 'cxsrv2009' failed because database is in BYPASS RECOVERY mode.

请教现在该如何处理?

WFCJZ 发表于 2009-07-22 17:49

SYBASE官方网站关于3908错误的解决办法:


Error 3908
Severity
16
Error Message

Attempt to BEGIN TRANsaction in database \'%.*s\' failed because database is in BYPASS RECOVERY mode.
Explanation
Adaptive Server can start various types of transactions such as local (in response to a local command), internal (for the server\'s own use), external (started by an external client like a TP Monitor) and subordinate (child transactions started by a parent transaction in parallel).
Bypass recovery starts Adaptive Server without recovering one or more databases. A database in this mode can be accessed even though it is not recovered. You use this mode to allow access to the database for problem analysis, to copy out data, and so on.
Error 3908 is raised when a transaction is attempted while the database is in bypass recovery. Although certain commands are permissible in this mode, no transactions - regardless of type - can be started when the database is in bypass recovery.
Error 3908 is raised in the following states:



State Meaning
1 Attempted to start a transaction when the database is not available for update. Applies to all possible transaction types.
2 Attempted to start a subordinate transaction when the database is not available for update.
Action
Do not attempt to start a transaction while the database is in bypass recovery. Check if any automated jobs may have submitted a batch job that attempted such a transaction. First restore the database to the original working status it had (prior to bypass status) before attempting any transactions.


Use the following steps to reset the database status:
Note Although a status of zero is usually appropriate, it is not the only possible status value you can use. Reset the database to the actual, normal status it had prior to entering bypass recovery status.

1. Reset the database status to 0:
1> sp_configure "allow updates", 1
2> go
1> begin tran
2> go
1> use master
2> go
1> update sysdatabases set status=0 where name=<database_name>
2> go
Check that the above update command affected only one row (if more than one row was affected, issue a rollback transaction.) Then commit the transaction and shut down Adaptive Server as follows:
1>commit tran
2>go
1>shutdown with nowait
2>go
2. Restart Adaptive Server. Run dbcc checkdb and dbcc checkalloc on the affected database to make sure there are no errors.
Version in Which This Error is Raised
All versions.



完成之后,你的日志里应该还有3414和3474的报错,你可以看一下的前面的报错日志是:
00:00000:00011:2009/07/22 16:38:09.25 serverError: 3474, Severity: 21, State: 1
00:00000:00011:2009/07/22 16:38:09.25 serverDuring redo the page timestamp value is less than old timestamp from log. Page #=290204, object id = 1621577784, page timestamp=0000 2a3ba82f9d. Log old timestamp=0000 2a44f4fb6a. Log record marker = (5827351, 0).
00:00000:00011:2009/07/22 16:38:09.25 serverError: 21, Severity: 21, State: 1
00:00000:00011:2009/07/22 16:38:09.25 serverWARNING - Fatal Error 3414 occurred at Jul 22 20094:38PM.Please note the error and time, and contact a user with System Administrator (SA) authorization.
00:00000:00011:2009/07/22 16:38:09.26 serverError: 3414, Severity: 21, State: 1
00:00000:00011:2009/07/22 16:38:09.26 serverDatabase 'cxsrv2009' (dbid 5): Recovery failed. Check the SQL Server errorlog for further information as to the cause.

其实你做截断日志是错误的做法,按照上面这个报错,你可以这样处理:

解决办法:

重建数据库日志,方法如下:
 (1)赋予sa用户sybase_ts_role的角色
isql -Usa -P
1>sp_role "grant","sybase_ts_role",sa
2>go
1>quit

(2)将数据库置为"bypass recovery"状态
isql -Usa -P
1>sp_configure "allow updates",1
2>go
1>use master
2>go
1>update sysdatabases set status=-32768
2>where name="database_name"
3>go
1>shutdown with nowait
2>go

(3)rebuild数据库日志
重启Server
isql -Usa -P
1>use master
2>go
1>dbcc rebuild_log(database_name,1,1)
2>go
1>shutdown with nowait
2>go

(4)重启server
1>use master
2>go
1>update sysdatabases set status=0 where name="database_name"
2>go
1>sp_configure "allow updates",0
2>go
1>shutdown with nowait
2>go

(5)在重启server之后,如果数据库恢复正常,rebuild log工作将会成功完成,否则要恢复数据库备份,使用dump database或bcp命令。


祝你好运!

[ 本帖最后由 WFCJZ 于 2009-7-22 18:15 编辑 ]

hobbylu 发表于 2009-07-23 08:21

WFCJZ的这个段回复很经典,基本上可以解决你的问题了

WFCJZ 发表于 2009-07-23 08:46

hobbylu 夸我,有些汗颜!
页: [1]
查看完整版本: 启动出错