Chinaunix

标题: 关于数据库置疑的解决! [打印本页]

作者: youwei    时间: 2011-11-17 14:06
标题: 关于数据库置疑的解决!
环境:sybase11.5 +windows xp
sqladv 下执行

dbcc checkdb (wugenius)后报以下错误!
现在这个库打不开了,请教高手这个问题如何才把把数据找回来!
。。。。。。。。
Table has 1 data rows.
Checking RECEIVE_REPO
The total number of data pages in this table is 258.
Table has 6824 data rows.
DBCC execution completed. If DBCC printed error messages, contact a user with System Administrator (SA) role.
Server Message:  Number  692, Severity  16
Line 1:
Uninitialized logical page '1115655' was read while accessing object '8' in database '6'. Please contact Sybase Technical Support.
Table Corrupt: The values in adjust table should be in ascending order starting from the end of the table (page#=165928  row#=3); check adjust table in this row
Table Corrupt: The values in adjust table should be in ascending order starting from the end of the table (page#=165928  row#=3); check adjust table in this row
Table Corrupt: Row length is inconsistent between the computed row length and the recorded row length on page; check the following page and row: pageno=165928 row#=3 computed row length=655 row length on page=141
Table Corrupt: Row length is inconsistent between the computed row length and the recorded row length on page; check the following page and row: pageno=165928 row#=4 computed row length=49 row length on page=141
Table Corrupt: The values in adjust table should be in ascending order starting from the end of the table (page#=165928  row#=5); check adjust table in this row
Table Corrupt: Row length is inconsistent between the computed row length and the recorded row length on page; check the following page and row: pageno=165928 row#=5 computed row length=398 row length on page=141
Table Corrupt: The values in adjust table should be in ascending order starting from the end of the table (page#=165928  row#=6); check adjust table in this row
Table Corrupt: Row length is inconsistent between the computed row length and the recorded row length on page; check the following page and row: pageno=165928 row#=6 computed row length=398 row length on page=141
Table Corrupt: The values in adjust table should be in ascending order starting from the end of the table (page#=165930  row#=11); check adjust table in this row
Table Corrupt: Row length is inconsistent between the computed row length and the recorded row length on page; check the following page and row: pageno=165930 row#=11 computed row length=408 row length on page=151
Keys of index id 1 for table 'ACCOUNT' in data page not in correct order. Drop and re-create the index. (index page 165930)
Table Corrupt: The values in adjust table should be in ascending order starting from the end of the table (page#=165930  row#=12); check adjust table in this row
Table Corrupt: Row length is inconsistent between the computed row length and the recorded row length on page; check the following page and row: pageno=165930 row#=12 computed row length=407 row length on page=151
Keys of index id 1 for table 'ACCOUNT' in data page not in correct order. Drop and re-create the index. (index page 165930)
Table Corrupt: Offset table is incorrect (page#=165931  row#=0 offset in offset table is=37  correct offset is=13)
Table Corrupt: The values in adjust table should be in ascending order starting from the end of the table (page#=165931  row#=0); check adjust table in this row
Table Corrupt: The values in adjust table should be in ascending order starting from the end of the table (page#=165931  row#=0); check adjust table in this row
Table Corrupt: The values in adjust table should be in ascending order starting from the end of the table (page#=165931  row#=0); check adjust table in this row
Table Corrupt: Row length is inconsistent between the computed row length and the recorded row length on page; check the following page and row: pageno=165931 row#=0 computed row length=795 row length on page=147
Server Message:  Number  614, Severity  16
Line 1:
Adaptive Server accessed a row that has an illegal length of -2560 while in data base 'wugenius'. Page pointer = 0x211A2000, pageno = 165931, status = 0x101, objectid = 400004456, indexid = 0, level = 0.
Failure has occurred in CT-Library call. Connection is no longer usable and will be automatically dropped.
作者: andkylee    时间: 2011-11-17 14:28
ASE11.5版本比较老了。
通过你的错误日志,报error692的objid=8,可以通过截断日志来打开数据库。
pageno = 165931, status = 0x101, objectid = 400004456, indexid = 0, level = 0.
需要确认页面165931的objid是否为400004456。如果页面165931损坏的话,可以通过一定的手段抽取出来165931的数据。
作者: youwei    时间: 2011-11-17 14:32
你好,我对sybase 的系统表,不太了解,可以麻烦给出具体的操作步骤!谢谢!
作者: youwei    时间: 2011-11-17 15:03
执行以下命令:
sp_configure "allow updates",1
        go
        reconfigure with override
        go
        update master..sysdatabases
        set status=-32768
        Where name="wugenius"
        go
        shutdown with nowait
        go

重启后:
use wugenius
go
dump tran wugenius with no_log
go
报以下错误:
Server Message:  Number  950, Severity  14
Line 1:
Database 'wugenius' is currently offline. Please wait and try your command again later.
Server Message:  Number  5702, Severity  10
Line 1:
The SQL Server is terminating this process.
Server Message:  Number  692, Severity  20
Line 1:
Uninitialized logical page '1115036' was read while accessing object '8' in database '6'. Please contact Sybase Technical Support.
Client Message:  Layer  1, Origin  1, Severity  1, Number  60
ct_cmd_drop(): user api layer: external error: There is a usage error.  This routine has been called at an illegal time.
Failure has occurred in CT-Library call. Connection is no longer usable and will be automatically dropped.
作者: youwei    时间: 2011-11-17 15:04
请教各位,能看出具体是哪方面出了问题了吗?
作者: andkylee    时间: 2011-11-17 15:25
standby状态下,执行 dbcc rebuild_log() 慎用!
作者: youwei    时间: 2011-11-17 15:37
你好,这个命令之前,先执行
update master..sysdatabases
        set status=0
        Where name="wugenius"
        go
        sp_configure "allow updates",0
        go
        reconfigure with override
        go
重启之前,才执行dbcc rebuild_log() 吗!
作者: youwei    时间: 2011-11-17 15:43
你好,不好意思!用什么命令修改为standby状态呢 ?
作者: hobbylu    时间: 2011-11-17 17:00
update sysdatabases set status=-32768 where name='xxxxx'
go
shutdown with nowait
go
reboot
作者: liyongquan    时间: 2011-11-18 10:18
Some information about error 692,for reference only.

Take the following steps:
1 Check the server error log for other errors that may have been raised prior
to the 692 error. Save the entire error log.
2 Obtain page information by running dbcc page as soon as possible, using
the database ID and page number shown in the message:
1> dbcc page (<db_id>, <page_number>, 0, 1, 1, -1)
2> go
Warning! Use the dbcc page command only as directed above.
3 Identify the object named in the error message using the following isql
commands:
1> use <database name>
2> go
1> select name from sysobjects where id=<object_id>
2> go
4 Find information about this object in sysindexes:
1> select first, root, doampg, ioampg from sysindexes
2> where name = object_name(<object_id>)
3> go
5 To determine the full extent of the corruption, run the dbcc checkdb and
dbcc checkalloc commands (or dbcc checktable and dbcc tablealloc) as soon
as possible. On version 11.5 and higher, you can also run dbcc
checkstorage.
6 To check if this error is a result of hardware failure, examine your
operating system error log and correct hardware problems. See Chapter 2,
“Checking the Operating System Error Log” for assistance.
If the 692 error is not a soft error (one that exists only in memory), the problem
is severe. Sybase Technical Support may be able to help you recover from the
error. However, this recovery procedure often results in loss of data; if this is
unacceptable, you will probably need to restore from backups.
Additional information Refer to the Error 605 writeup for a discussion of potential causes of hardware
error. Refer to Chapter 2, “Useful dbcc Commands” for more dbcc
information.
Have the following information ready before calling Sybase Technical
Support:
? Adaptive Server version and SWR version level
? Server error log
? Operating System error log
? Output of the sysindexes query and dbcc checks from Steps 2, 4, and 5
above.
A database dump and transaction log dumps may also be required.
Version in which this
error is raised
11.0.3 and later
作者: youwei    时间: 2011-11-21 14:17
在执行了:dump transaction  wugenius  with no_log
go
后报了以下错误,看提示,应该是,wugenius  这个库的日志出了问题
wugenis这个库是对应有二个数据为设备:
wugenius_dat和wugenius_log
报以下的错误,是不是wugenius_log 这个设备出一问题了呢!
请教,是否有什么办法,可以在不用访问数据库日志的情况下把数据库打开呢提取数据呢!?
谢谢!


The SQL Server is terminating this process.
Server Message:  Number  692, Severity  20
Line 1:
Uninitialized logical page '1115655' was read while accessing object '8' in database '6'. Please contact Sybase Technical Support.
Client Message:  Layer  1, Origin  1, Severity  1, Number  60
ct_cmd_drop(): user api layer: external error: There is a usage error.  This routine has been called at an illegal time.
Failure has occurred in CT-Library call. Connection is no longer usable and will be automatically dropped.
作者: lxh3603    时间: 2011-11-25 17:46
如果有最近的DUMP备份的话,建议还是重建库吧。
如果没有DUMP备份,可用BCP_OUT备份该库所有表数据;若能成功,则清空有问题的表,再BCP_IN该表。




欢迎光临 Chinaunix (http://bbs.chinaunix.net/) Powered by Discuz! X3.2