免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 2787 | 回复: 3
打印 上一主题 下一主题

启动出错 [复制链接]

论坛徽章:
0
跳转到指定楼层
1 [收藏(0)] [报告]
发表于 2009-07-22 16:58 |只看该作者 |倒序浏览
启动DB时候,提示
00:00000:00011:2009/07/22 16:38:09.25 server  Recovering database 'cxsrv2009'.
00:00000:00011:2009/07/22 16:38:09.25 server  Started estimating recovery log boundaries for database 'cxsrv2009'.
00:00000:00011:2009/07/22 16:38:09.25 server  Started ANALYSIS pass for database 'cxsrv2009'.
00:00000:00011:2009/07/22 16:38:09.25 server  Completed ANALYSIS pass for database 'cxsrv2009'.
00:00000:00011:2009/07/22 16:38:09.25 server  Started 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 server  Error: 21, Severity: 21, State: 1
00:00000:00011:2009/07/22 16:38:09.25 server  WARNING - Fatal Error 3474 occurred at Jul 22 2009  4: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 server  Error: 3474, Severity: 21, State: 1
00:00000:00011:2009/07/22 16:38:09.25 server  During 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 server  Error: 21, Severity: 21, State: 1
00:00000:00011:2009/07/22 16:38:09.25 server  WARNING - Fatal Error 3414 occurred at Jul 22 2009  4: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 server  Error: 3414, Severity: 21, State: 1
00:00000:00011:2009/07/22 16:38:09.26 server  Database 'cxsrv2009' (dbid 5): Recovery failed. Check the SQL Server errorlog for further information as to the cause.

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

请教现在该如何处理?

论坛徽章:
33
ChinaUnix元老
日期:2018-07-04 15:10:362015年亚洲杯之阿联酋
日期:2015-02-06 17:15:532015亚冠之武里南联
日期:2015-06-06 15:40:252015亚冠之北京国安
日期:2015-06-17 15:42:412022北京冬奥会纪念版徽章
日期:2015-08-10 16:30:322015亚冠之阿尔纳斯尔
日期:2015-09-20 09:42:1215-16赛季CBA联赛之北京
日期:2016-01-15 10:03:5915-16赛季CBA联赛之青岛
日期:2016-04-26 16:44:4915-16赛季CBA联赛之广夏
日期:2018-07-04 15:33:21C
日期:2016-10-25 16:12:142017金鸡报晓
日期:2017-01-10 15:19:5615-16赛季CBA联赛之同曦
日期:2017-02-22 22:41:10
2 [报告]
发表于 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 server  Error: 3474, Severity: 21, State: 1
00:00000:00011:2009/07/22 16:38:09.25 server  During 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 server  Error: 21, Severity: 21, State: 1
00:00000:00011:2009/07/22 16:38:09.25 server  WARNING - Fatal Error 3414 occurred at Jul 22 2009  4: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 server  Error: 3414, Severity: 21, State: 1
00:00000:00011:2009/07/22 16:38:09.26 server  Database '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 编辑 ]

论坛徽章:
0
3 [报告]
发表于 2009-07-23 08:21 |只看该作者
WFCJZ的这个段回复很经典,基本上可以解决你的问题了

论坛徽章:
33
ChinaUnix元老
日期:2018-07-04 15:10:362015年亚洲杯之阿联酋
日期:2015-02-06 17:15:532015亚冠之武里南联
日期:2015-06-06 15:40:252015亚冠之北京国安
日期:2015-06-17 15:42:412022北京冬奥会纪念版徽章
日期:2015-08-10 16:30:322015亚冠之阿尔纳斯尔
日期:2015-09-20 09:42:1215-16赛季CBA联赛之北京
日期:2016-01-15 10:03:5915-16赛季CBA联赛之青岛
日期:2016-04-26 16:44:4915-16赛季CBA联赛之广夏
日期:2018-07-04 15:33:21C
日期:2016-10-25 16:12:142017金鸡报晓
日期:2017-01-10 15:19:5615-16赛季CBA联赛之同曦
日期:2017-02-22 22:41:10
4 [报告]
发表于 2009-07-23 08:46 |只看该作者
hobbylu 夸我,有些汗颜!
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP