重建表索引失败(已解决)

donniejeck 发表于 2009-06-15 10:23

OS:2003 64位
数据库版本:ASE 12.53

礼拜五服务器不幸断电,重新启动后,应用库状态可疑.通过dbcc rebuild_log将状态改为0后,应用库恢复正常.做DBCC checkdb日志提示,索引失效.故重建索引.但出错退出.........

日志如下:

03:00000:00044:2009/06/15 09:37:23.73 serverError: 2628, Severity: 21, State: 2
03:00000:00044:2009/06/15 09:37:23.73 serverIn database 'WDZX', page 15953689 is linked forward to page 15969149, but that page is linked backward to page 15969147. Please report this internal error to Sybase Technical Support.
03:00000:00044:2009/06/15 09:37:23.73 kernel************************************
03:00000:00044:2009/06/15 09:37:23.73 kernelSQL causing error : update statistics WDZX.G_UFILES using 100 values

03:00000:00044:2009/06/15 09:37:23.73 kernel************************************
03:00000:00044:2009/06/15 09:37:23.73 serverSQL Text: update statistics WDZX.G_UFILES using 100 values
03:00000:00044:2009/06/15 09:37:23.73 kernelcurdb = 4 tempdb = 2 pstat = 0x10000
03:00000:00044:2009/06/15 09:37:23.73 kernellasterror = 2628 preverror = 0 transtate = 1
03:00000:00044:2009/06/15 09:37:23.73 kernelcurcmd = 326 program = isql
03:00000:00044:2009/06/15 09:37:24.53 kernelSymbolic stack trace information is successfully loaded
03:00000:00044:2009/06/15 09:37:24.54 kernelpc: 0x00C57F38 os_get_cur_stk_desc+ 0x170 (0x01FADC90, 0x7D5089C4, 0x7D508F28, 0xFFFFFFFF)
03:00000:00044:2009/06/15 09:37:24.54 kernelpc: 0x00C57F38 os_get_cur_stk_desc+ 0x170 (0x01FADC90, 0x01FADA48, 0x0000270F, 0x00000002)
03:00000:00044:2009/06/15 09:37:24.54 kernelpc: 0x00C2D4D5 pcstkwalk+ 0x204 (0x005C005C, 0x00000002, 0x0000270F, 0x00000000)
03:00000:00044:2009/06/15 09:37:24.54 kernelpc: 0x00C2D15F ucstkgentrace+ 0x25f (0x005C005C, 0x00000001, 0x01FAE890, 0x0144B184)
03:00000:00044:2009/06/15 09:37:24.54 kernelpc: 0x00BD7A0B ucbacktrace+ 0xab (0x00000000, 0xFFFFFFFF, 0x01FAE228, 0x0047E452)
03:00000:00044:2009/06/15 09:37:24.54 kernelpc: 0x0040760C terminate_process+ 0xccd (0x01FAE248, 0x00708FA6, 0x0000001A, 0x0000001C)
03:00000:00044:2009/06/15 09:37:24.54 kernelpc: 0x0047E46F close_network+ 0xc (0x0000001A, 0x0000001C, 0x00000015, 0x00000002)
03:00000:00044:2009/06/15 09:37:24.54 kernelpc: 0x0047E452 hdl_default+ 0x38 (0x0000001A, 0x0000001C, 0x00000015, 0x00000002)
03:00000:00044:2009/06/15 09:37:24.54 kernelpc: 0x00708FA6 ut_handle+ 0xd6 (0x0000001A, 0x0000001C, 0x00000015, 0x00000002)
03:00000:00044:2009/06/15 09:37:24.54 kernelpc: 0x0047E0A8 ex_raise+ 0x2b3 (0x06282174, 0x01FAE41C, 0x40F33ABC, 0x00000020)
03:00000:00044:2009/06/15 09:37:24.54 kernelpc: 0x00AEBA2F bt__getnextscanpg+ 0x49b (0x06282174, 0x01FAE41C, 0x01FAE404, 0x0144B184)
03:00000:00044:2009/06/15 09:37:24.54 kernelpc: 0x00AEB446 bt__handle_pagedone+ 0x2ad (0x06282174, 0x00000000, 0x00000001, 0x01FAE5B4)
03:00000:00044:2009/06/15 09:37:24.54 kernelpc: 0x00AE99BC bt_getnext+ 0xe5c (0x06282174, 0x0AA74820, 0x00000010, 0x00F36C50)
03:00000:00044:2009/06/15 09:37:24.54 kernelpc: 0x006611D1 dol_bt_getnext+ 0x7b6 (0x06282174, 0x0627A348, 0x00F36F19, 0x01FAE8B4)
03:00000:00044:2009/06/15 09:37:24.54 kernelpc: 0x0060BF02 getnext+ 0x1a2 (0x06282174, 0x01FAF2E4, 0x0144B184, 0x00000001)
03:00000:00044:2009/06/15 09:37:24.54 kernelpc: 0x00F248AA ups_deadlock_getnext+ 0x17 (0x01FAE8F8, 0x06282174, 0x01FAEE14, 0x00000064)
03:00000:00044:2009/06/15 09:37:24.54 kernel
03:00000:00044:2009/06/15 09:37:24.54 kernelpc: 0x00F24484 ups_build+ 0x874 (0x06282174, 0x00800000, 0x119BDE78, 0x0000000D)
03:00000:00044:2009/06/15 09:37:24.54 kernelpc: 0x00F22B1E update_statistics+ 0x128 (0x119BDDB8, 0x00000146, 0x01FAFF4C, 0x0144B184)
03:00000:00044:2009/06/15 09:37:24.54 kernel
03:00000:00044:2009/06/15 09:37:24.54 kernelpc: 0x00F21DAA ups_main+ 0x2fa (0x7D60C888, 0x7D53AFF3, 0x000003D4, 0x00000000)
03:00000:00044:2009/06/15 09:37:24.54 kernelpc: 0x007B0736 s_execute+ 0x48b6 (0x119C8000, 0x01FAFF4C, 0x0144B184, 0x0000005C)
03:00000:00044:2009/06/15 09:37:24.54 kernel
03:00000:00044:2009/06/15 09:37:24.54 kernelpc: 0x007EB603 sequencer+ 0x1893 (0x0627A300, 0x00000000, 0x00000000, 0x00000000)
03:00000:00044:2009/06/15 09:37:24.54 kernelpc: 0x0045DB68 tdsrecv_language+ 0x552 (0x000000A4, 0x00000000, 0x00000000, 0x0999AE10)
03:00000:00044:2009/06/15 09:37:24.56 kernel
03:00000:00044:2009/06/15 09:37:24.56 kernel
03:00000:00044:2009/06/15 09:37:24.56 kernel
03:00000:00044:2009/06/15 09:37:24.56 kernelpc: 0x004235D6 conn_hdlr+ 0x37a2 (0x0999AE10, 0x00000000, 0x00000000, 0x0999AE10)
03:00000:00044:2009/06/15 09:37:24.56 kernelpc: 0x00BCCAD7 kpntwrapper+ 0x84 (0x00BCCA53, 0x0999AE10, 0x000000C8, 0x00000191)
03:00000:00044:2009/06/15 09:37:24.59 kernelpc: 0x7D50FE21 FlsSetValue+ 0x136 (0x00000000, 0x00000000, 0x00000000, 0x00000000)
03:00000:00044:2009/06/15 09:37:24.59 kernelend of stack trace, spid 44, kpid 6029404, suid 1

[ 本帖最后由 donniejeck 于 2009-6-15 16:38 编辑 ]

donniejeck 发表于 2009-06-15 10:24

重建索引脚本日志输出部分内容

Server 'cq', Line 1:
In database 'WDZX', page 15953689 is linked forward to page 15969149, but that
page is linked backward to page 15969147. Please report this internal error to
Sybase Technical Support.
The SQL Server is terminating this process.
CT-LIBRARY error:
ct_send(): network packet layer: internal Client Library error: State error: trying to write when connection is expecting a read.
CT-LIBRARY error:
ct_cancel(): network packet layer: internal net library error: Net-Library operation terminated due to disconnect

donniejeck 发表于 2009-06-15 10:29

摘自SYBASE官方解释

Error 2628
Severity

21

Error message text
In database '%.*s', page %ld is linked forward to page %ld, but that page is linked backward to page %ld. Please report this internal error to Sybase Technical Support.

This error may be caused by a hardware problem.

Explanation
When updating a table or index, Adaptive Server may determine that there is not enough room on a page to insert additional data. A new page is then allocated for the object. Existing rows may be moved to this page and new rows inserted. Error 2628 is raised when Adaptive Server fetches a page by following the forward pointers, examines the existing page linkage, and finds that the backward pointer does not point to the previous page as expected. Since the linkage problem could be worsened by continuing the page split, the operation is aborted.

When dbcc detects this problem, it raises Error 2503 (Table Corrupt: Page linkage is not consistent; check the following pages: (current page#=%ld; page# pointing to this page=%ld; previous page# indicated in this page=%ld)).

Action
Error 2628 is due to corruption of page pointers for the object. Use the following steps to resolve the error:

Identify the object using one of the pages identified in the message. Refer to "How to Find an Object Name from a Page Number" in the Encyclopedia of Tasks chapter for information.

If the page is a data page (index ID = 0), drop and recreate th

donniejeck 发表于 2009-06-15 10:30

摘自SYBASE官方解释

donniejeck 发表于 2009-06-15 10:31

硬件故障?难道是

chuxu 发表于 2009-06-15 14:13

删了索引，再重新建立不行吗？

donniejeck 发表于 2009-06-15 14:20

03:00000:00044:2009/06/15 09:37:23.73 serverIn database 'WDZX', page 15953689 is linked forward to page 15969149, but that page is linked backward to page 15969147. Please report this internal error to Sybase Technical Support.
数据页链错误如何修复呢?

chuxu 发表于 2009-06-15 15:02

dbcc checktable

donniejeck 发表于 2009-06-15 15:35

1> dbcc tablealloc(1628532835)
2> go
The default report option of OPTIMIZED is used for this run.
The default fix option of FIX is used for this run.
***************************************************************
TABLE: LONGTEXT       OBJID = 1628532835
INDID=0FIRST=4561    ROOT=4561    SORT=0
The oam counts for objid 1628532835 indid 0 are corrected.
   Data level: 0.43069 Data pages allocated and 5716 Extents allocated.
INDID=2FIRST=3853705 ROOT=3853704 SORT=1
Msg 2503, Level 16, State 2:
Server 'cq', Line 1:
Table Corrupt: Page linkage is not consistent; check the following pages: (current page#=11928067;page# pointing to th
is page=11928066; previous page# indicated in this page=11928068)
INDID=3FIRST=9995961 ROOT=9995960 SORT=1
   Indid : 3.10193 Index pages allocated and 1276 Extents allocated.
TOTAL # of extents = 6992
1> dbcc tablealloc(876530156)
2> go
The default report option of OPTIMIZED is used for this run.
The default fix option of FIX is used for this run.
***************************************************************
TABLE: G_UFILES       OBJID = 876530156
INDID=0FIRST=3673    ROOT=3673    SORT=0
The oam counts for objid 876530156 indid 0 are corrected.
   Data level: 0.25215 Data pages allocated and 3222 Extents allocated.
INDID=2FIRST=1886417 ROOT=1886416 SORT=1
Msg 2503, Level 16, State 2:
Server 'cq', Line 1:
Table Corrupt: Page linkage is not consistent; check the following pages: (current page#=15969149;page# pointing to th
is page=15953689; previous page# indicated in this page=15969147)
INDID=3FIRST=9970361 ROOT=9970360 SORT=1
   Indid : 3.8267 Index pages allocated and 1035 Extents allocated.
INDID=4FIRST=9987121 ROOT=9987120 SORT=1
   Indid : 4.6286 Index pages allocated and 806 Extents allocated.
TOTAL # of extents = 5063
1>

donniejeck 发表于 2009-06-15 16:01

重建OBJID(1628532835,876530156)索引后,tablealloc正常.

页: [1] 2

Chinaunix's Archiver