Table suspect status

[Former Member]

Hi guys,

We have a problem with our ERP 6.0 ehp7 running in ASE 15.7 pl130, we can´t read the information  from table "FUPARAREF".

In the short dump is specify to run the command DBCC REPAIRDB, bur when we try to do so after logon in isql with the user sapsa, we got a permission error.

Can you help us to resolve and run those dbcc commands.

Thank you,

Alcino

this is dump

[Former Member]

Hi,

The Support suggestion for our problem, was to rebuild the table that is in suspect mode!

I've run the command Reorg rebuild, but it wasn't work

1> reorg rebuild DE1.SAPSR3.FUPARAREF

2> go

Beginning REORG REBUILD of table 'FUPARAREF'.

Msg 692, Level 20, State 1:

Server 'DE1', Line 1:

Uninitialized logical page '8878848' was read while accessing database 'DE1'

(4), object '' (99), index '<Unknown>' (0), partition '<Unknown>' (99). Please

contact Sybase Technical Support.

Msg 11050, Level 16, State 1:

Server 'DE1', Line 1:

Adaptive Server cannot process this ALTER TABLE statement due to one or more

preceding errors. If there are no preceding errors, please contact Sybase

Technical Support.

Msg 11934, Level 16, State 1:

Server 'DE1', Line 1:

REORG REBUILD of table 'FUPARAREF' failed due to an internal error. Please

contact SYBASE Technical Support.

1>

Any ideas?

Thank you

Alcino

[Former Member]

Stefan,

As you suggested I run the command DBCC DBREPAIR(DB, redo_shrink) bat the ASE stop with the message "ASE is terminating this process"

00:0003:00000:00031:2015/01/07 17:24:10.27 kernel  SQL causing error : dbcc dbrepair(DE1, redo_shrink)

00:0003:00000:00031:2015/01/07 17:24:10.27 kernel  ************************************

00:0003:00000:00031:2015/01/07 17:24:10.27 server  SQL Text: dbcc dbrepair(DE1, redo_shrink)

00:0003:00000:00031:2015/01/07 17:24:10.27 kernel  curdb = 4 tempdb = 2 pstat = 0x10000 p2stat = 0x101000

00:0003:00000:00031:2015/01/07 17:24:10.27 kernel  p3stat = 0x800 p4stat = 0x0 p5stat = 0x8 p6stat = 0x10 p7stat = 0x10000

00:0003:00000:00031:2015/01/07 17:24:10.27 kernel  lasterror = 0 preverror = 208 transtate = 1

00:0003:00000:00031:2015/01/07 17:24:10.27 kernel  curcmd = 317 program = isql                         

00:0003:00000:00031:2015/01/07 17:24:10.27 kernel  extended error information: hostname: SRV-DEV login: sapsa

00:0003:00000:00031:2015/01/07 17:24:10.27 kernel  pc: 0x0000000001403C58 os_get_cur_stk_desc+ 0xf8 (0x0000000007F59180, 0x0000000007F59180, 0x0000000007F5B110, 0x0000000000000000)

00:0003:00000:00031:2015/01/07 17:24:10.29 kernel  pc: 0x0000000001382872 pcstkwalk+ 0x3e2 (0x0000000000000001, 0x000000000053002A, 0x000000000000270F, 0x00000000A6FBF430)

00:0003:00000:00031:2015/01/07 17:24:10.29 kernel  pc: 0x0000000001383089 ucstkgentrace+ 0x339 (0x0000000000FAFEF1, 0x0000000000000001, 0x0000000000000000, 0x0000000000FAFEF1)

00:0003:00000:00031:2015/01/07 17:24:10.29 kernel  pc: 0x000000000138135F ucbacktrace+ 0xbf (0x00000000C0000005, 0x0000000007F5C400, 0x0000000007F5C400, 0x0000000029831930)

00:0003:00000:00031:2015/01/07 17:24:10.30 kernel  pc: 0x0000000000409C4B terminate_process+ 0x1b3b (0x000000000053002A, 0x00000000FFFFFFFF, 0x0000000029831930, 0x00000000743B0000)

00:0003:00000:00031:2015/01/07 17:24:10.33 kernel  pc: 0x00000000013CEEFF kiexception+ 0x50f (0x00000000013AFEF1, 0x0000000077034DC1, 0x0000000007F5C500, 0x0000000000000000)

00:0003:00000:00031:2015/01/07 17:24:10.33 kernel  pc: 0x0000000001CEC2F3 kpntwrapper$filt$0+ 0x13 (0x0000000000000001, 0x0000000000000001, 0x0000000000000000, 0x0000000000000000)

00:0003:00000:00031:2015/01/07 17:24:10.33 kernel  pc: 0x00000000744212E3 _C_specific_handler+ 0x97 (0x0000000007F60000, 0x0000000007F5FF80, 0x0000000007F5FF80, 0x0000000002E11F5C)

00:0003:00000:00031:2015/01/07 17:24:10.33 kernel  pc: 0x0000000077034F4D RtlCompareUnicodeString+ 0x7d (0x0000000007F60000, 0x0000000002D87194, 0x00000000000CB3AC, 0x000000000024BAD0)

00:0003:00000:00031:2015/01/07 17:24:10.33 kernel  pc: 0x0000000077015B3C RtlTimeToSecondsSince1970+ 0x63c (0x0000000007F5D040, 0x0000000007F5CB50, 0x0000000000000000, 0x0000000000000000)

00:0003:00000:00031:2015/01/07 17:24:10.33 kernel  pc: 0x000000007704F638 KiUserExceptionDispatcher+ 0x2e (0x0000000007F5D490, 0x000000000084811F, 0x0000000007F5D6B8, 0x0000000000000000)

00:0003:00000:00031:2015/01/07 17:24:10.33 kernel  pc: 0x0000000000BB3092 bufunkeep+ 0x22 (0x0000000243797E9E, 0x00000000A6FC0C20, 0x0000000243797E9E, 0x00E1E8D4D9EF28C6)

00:0003:00000:00031:2015/01/07 17:24:10.33 kernel  pc: 0x00000000010ED05D altdb__propagate_rid_dol+ 0x6bd (0x01D02A9E00000001, 0x00000000A6FC0C20, 0x0000000007F5D490, 0x00000002882D4998)

00:0003:00000:00031:2015/01/07 17:24:10.33 kernel  pc: 0x00000000010F0F49 altdb__propagate_dupkey_group_dol+ 0x189 (0x0000000007F5D740, 0x0000000007F5D788, 0x0000000286CDA5F8, 0x0000000007F5D490)

00:0003:00000:00031:2015/01/07 17:24:10.33 kernel  pc: 0x00000000010F96B0 altdb__repair_idx_grp_dol+ 0x13e0 (0x01D02A9E9248803E, 0x01D02A9E9248803E, 0x0000000007F5D740, 0x0000000285BCC000)

00:0003:00000:00031:2015/01/07 17:24:10.33 kernel  pc: 0x00000000010F9D88 altdb__finish_obj_au_move+ 0x548 (0x00000000A6FC0C20, 0x00000000A6FC0C20, 0x000000007CEF6920, 0x00000000A6FBF430)

00:0003:00000:00031:2015/01/07 17:24:10.33 kernel  pc: 0x00000000010FC14D altdb_redo_xpgxfer+ 0x6ad (0x0000000000000004, 0x000000000099F64E, 0x00000000740D6C80, 0xA148000000020000)

00:0003:00000:00031:2015/01/07 17:24:10.33 kernel  pc: 0x00000000009EAFA3 dbr_redo_shrink+ 0x43 (0x0000000000000000, 0x0000000007F5E980, 0x0000000000000003, 0x0000000000000013)

00:0003:00000:00031:2015/01/07 17:24:10.33 kernel  pc: 0x00000000009EC44F dbrepair+ 0x68f (0x0000000000000000, 0x00000000AF19F680, 0x0000000007F5EA40, 0x0000000000000000)

00:0003:00000:00031:2015/01/07 17:24:10.33 kernel  pc: 0x00000000009A2152 exec_dbcc+ 0xcd2 (0x000000000000013D, 0x00000000AF19F150, 0x00000000AF19F158, 0x0000000000000001)

00:0003:00000:00031:2015/01/07 17:24:10.35 kernel  pc: 0x0000000000EE6C93 s_execute+ 0x6623 (0x00000000A6FBF430, 0x00000000A6FBF430, 0x00000000AF19F000, 0x0000000000000001)

00:0003:00000:00031:2015/01/07 17:24:10.35 kernel  pc: 0x0000000000EF7476 sequencer+ 0x1f86 (0x00000000A6FBF430, 0x00000000A6FBF430, 0x0000000000000021, 0x0000000000000001)

00:0003:00000:00031:2015/01/07 17:24:10.35 kernel  pc: 0x0000000000467406 tdsrecv_language+ 0x706 (0x0000000000000021, 0x0000000000400000, 0x0000000000000000, 0x0000000000000021)

00:0003:00000:00031:2015/01/07 17:24:10.35 kernel  pc: 0x000000000042BF87 conn_hdlr+ 0x2307 (0x0000000029831930, 0x0000000029831930, 0x0000000000000000, 0x0000000000000000)

00:0003:00000:00031:2015/01/07 17:24:10.35 kernel  pc: 0x00000000013AFEF1 kpntwrapper+ 0x51 (0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000)

00:0003:00000:00031:2015/01/07 17:24:10.35 kernel  pc: 0x0000000076EEA34D CreateFiberEx+ 0x27d (0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000)

00:0003:00000:00031:2015/01/07 17:24:10.35 kernel  end of stack trace, spid 31, kpid 5439530, suid 4

Do you think that i have to restore a backup?

Regards,

Alcino

[former_member3043]

Hello,

only this table is in suspect mode, I won't suggest to do a restore from backup right now, but it might be necessary.

My suggestion would be that you will open an incident with Product Support and send them the errorlog, where the alter database failed and where the dbcc dbrepair failed. They should take a closer look where in the code this happens, the ASE version you use is pretty new and stacktraces shouldn't happen.

So your problem is indeed that a shrink database failed and one table cannot be accessed, it could be possible that we just rebuild this single table, but as suggested engineering should take a look into this. To save time you might decide to load a backup, not sure what system this is and how important you need to get this online.

Sorry.

With kind regards

Stefan

[Former Member]

Hi Stefan,

Thank you for your suggestion! we have opened a message in the SAP support.

I'll report here their answer.

We have that problem in the DEV system! but our backup is 2 weeks old

Regards,

Alcino

[former_member3043]

Hello Alcino,

I'm following you so you can send me a direct message with the incident number.

Just go to your profile -> connections -> Followers and then you should see me and should be able to select 'send a message'.

With kind regards

Stefan

[Former Member]

Hi Stefan,

I've check the log, and effectively there an error concerning the shrink!

But this isn't very clear.

I'll past the error part!

00:0006:00000:00228:2014/12/27 22:23:39.16 kernel  winrnr.dll loaded at 000007FEFA500000 [C:\Windows\System32\winrnr.dll]

00:0006:00000:00228:2014/12/27 22:23:39.16 kernel  napinsp.dll loaded at 000007FEFA4E0000 [C:\Windows\system32\napinsp.dll]

00:0006:00000:00228:2014/12/27 22:23:39.16 kernel  ************************************

00:0006:00000:00228:2014/12/27 22:23:39.16 kernel  SQL causing error :

alter database DE1 off DE1_data_002='30000'

00:0006:00000:00228:2014/12/27 22:23:39.16 kernel  ************************************

00:0006:00000:00228:2014/12/27 22:23:39.16 server  SQL Text:

alter database DE1 off DE1_data_002='30000'

00:0006:00000:00228:2014/12/27 22:23:39.16 kernel  curdb = 4 tempdb = 2 pstat = 0x10000 p2stat = 0x101100

00:0006:00000:00228:2014/12/27 22:23:39.16 kernel  p3stat = 0x800 p4stat = 0x0 p5stat = 0x8 p6stat = 0x10 p7stat = 0x10000

00:0006:00000:00228:2014/12/27 22:23:39.18 kernel  lasterror = 0 preverror = 10520 transtate = 0

00:0006:00000:00228:2014/12/27 22:23:39.18 kernel  curcmd = 305 program = isql                         

00:0006:00000:00228:2014/12/27 22:23:39.18 kernel  extended error information: hostname: SRV-DEV login: sapsa

00:0006:00000:00228:2014/12/27 22:23:39.18 kernel  pc: 0x0000000001403C58 os_get_cur_stk_desc+ 0xf8 (0x000000000C7A82B0, 0x000000000C7A82B0, 0x000000000C7AA240, 0x0000000000000000)

00:0006:00000:00228:2014/12/27 22:23:39.18 kernel  pc: 0x0000000001382872 pcstkwalk+ 0x3e2 (0x0000000000000001, 0x0000000001270094, 0x000000000000270F, 0x00000000A86595E0)

00:0006:00000:00228:2014/12/27 22:23:39.18 kernel  pc: 0x0000000001383089 ucstkgentrace+ 0x339 (0x0000000000FAFEF1, 0x0000000000000001, 0x0000000000000000, 0x0000000000FAFEF1)

00:0006:00000:00228:2014/12/27 22:23:39.18 kernel  pc: 0x000000000138135F ucbacktrace+ 0xbf (0x00000000C0000005, 0x000000000C7AB530, 0x000000000C7AB530, 0x00000000298545B0)

00:0006:00000:00228:2014/12/27 22:23:39.18 kernel  pc: 0x0000000000409C4B terminate_process+ 0x1b3b (0x0000000001270094, 0x00000000FFFFFFFF, 0x00000000298545B0, 0x00000000743B0000)

00:0006:00000:00228:2014/12/27 22:23:39.18 kernel  pc: 0x00000000013CEEFF kiexception+ 0x50f (0x00000000013AFEF1, 0x0000000077034DC1, 0x000000000C7AB630, 0x0000000000000000)

00:0006:00000:00228:2014/12/27 22:23:39.18 kernel  pc: 0x0000000001CEC2F3 kpntwrapper$filt$0+ 0x13 (0x000000007D35A9D0, 0x0000000000000000, 0x0000000000000000, 0x0001FF0000000000)

00:0006:00000:00228:2014/12/27 22:23:39.18 kernel  pc: 0x00000000744212E3 _C_specific_handler+ 0x97 (0x000000000C7B0000, 0x000000000C7AFF80, 0x000000000C7AFF80, 0x0000000002E11F5C)

00:0006:00000:00228:2014/12/27 22:23:39.18 kernel  pc: 0x0000000077034F4D RtlCompareUnicodeString+ 0x7d (0x000000000C7B0000, 0x0000000002D87194, 0x00000000000CB3AC, 0x00000000002C63B0)

00:0006:00000:00228:2014/12/27 22:23:39.18 kernel  pc: 0x0000000077015B3C RtlTimeToSecondsSince1970+ 0x63c (0x000000000C7AC170, 0x000000000C7ABC80, 0x0000000000000000, 0x0000000000000000)

00:0006:00000:00228:2014/12/27 22:23:39.18 kernel  pc: 0x000000007704F638 KiUserExceptionDispatcher+ 0x2e (0x000000000C7AC5C0, 0x000000000084811F, 0x000000000C7AC7E8, 0x0000000000000000)

00:0006:00000:00228:2014/12/27 22:23:39.18 kernel  pc: 0x0000000000BB3092 bufunkeep+ 0x22 (0x000000023BF03E9E, 0x00000000A865A7E8, 0x000000023BF03E9E, 0x00E1E7FBC0D75789)

00:0006:00000:00228:2014/12/27 22:23:39.18 kernel  pc: 0x00000000010ED05D altdb__propagate_rid_dol+ 0x6bd (0x01D0222300000001, 0x00000000A865A7E8, 0x000000000C7AC5C0, 0x0000000287F33778)

00:0006:00000:00228:2014/12/27 22:23:39.18 kernel  pc: 0x00000000010F0F49 altdb__propagate_dupkey_group_dol+ 0x189 (0x000000000C7AC870, 0x000000000C7AC8B8, 0x00000002868399F0, 0x000000000C7AC5C0)

00:0006:00000:00228:2014/12/27 22:23:39.18 kernel  pc: 0x00000000010F96B0 altdb__repair_idx_grp_dol+ 0x13e0 (0x01D02223C1EE10E5, 0x01D02223C1EE10E5, 0x000000000C7AC870, 0x00000000A865A940)

00:0006:00000:00228:2014/12/27 22:23:39.18 kernel  pc: 0x00000000010F9D88 altdb__finish_obj_au_move+ 0x548 (0x00E1E7FBC0A097E3, 0x0000000000870000, 0x0000000119126000, 0x00000000A86595E0)

00:0006:00000:00228:2014/12/27 22:23:39.18 kernel  pc: 0x00000000010FD30C altdb__move_extents+ 0x63c (0x0000000000000000, 0x0000000000000001, 0x0000000000000020, 0x0000000000000020)

00:0006:00000:00228:2014/12/27 22:23:39.18 kernel  pc: 0x00000000010FE0CD altdb__clear_chunk+ 0x3dd (0x0000000029F022D0, 0x0000000119126000, 0x0000000000000000, 0x00000000A86595E0)

00:0006:00000:00228:2014/12/27 22:23:39.18 kernel  pc: 0x00000000010FE6B9 altdb__clear_lpages+ 0x279 (0x00000000A86595E0, 0x0000000119126000, 0x000000000C7AE7E0, 0x0000000001EEC5B0)

00:0006:00000:00228:2014/12/27 22:23:39.19 kernel  pc: 0x00000000010FEF89 altdb__do_shrinkdb+ 0x7f9 (0x0000000000000000, 0x00000000740D6C80, 0x0000000000000000, 0x00000000B9560800)

00:0006:00000:00228:2014/12/27 22:23:39.19 kernel  pc: 0x00000000010FFFC1 altdb_shrink+ 0x751 (0x000000000C7AEA20, 0x000000000C7AEC20, 0x0000000000000032, 0x0000000000000032)

00:0006:00000:00228:2014/12/27 22:23:39.19 kernel  pc: 0x0000000001100CDA alterdb+ 0x35a (0x0000000000000131, 0x00000000B2A05950, 0x00000000B2A05958, 0x0000000000000001)

00:0006:00000:00228:2014/12/27 22:23:39.19 kernel  pc: 0x0000000000EE68F8 s_execute+ 0x6288 (0x00000000A86595E0, 0x00000000A86595E0, 0x00000000B2A05800, 0x0000000000000001)

00:0006:00000:00228:2014/12/27 22:23:39.19 kernel  pc: 0x0000000000EF7476 sequencer+ 0x1f86 (0x00000000A86595E0, 0x00000000A86595E0, 0x0000000000000021, 0x0000000000000001)

00:0006:00000:00228:2014/12/27 22:23:39.19 kernel  pc: 0x0000000000467406 tdsrecv_language+ 0x706 (0x0000000000000021, 0x0000000000400000, 0x0000000000000000, 0x0000000000000000)

00:0006:00000:00228:2014/12/27 22:23:39.19 kernel  pc: 0x000000000042BF87 conn_hdlr+ 0x2307 (0x00000000298545B0, 0x00000000298545B0, 0x0000000000000000, 0x0000000000000000)

00:0006:00000:00228:2014/12/27 22:23:39.19 kernel  pc: 0x00000000013AFEF1 kpntwrapper+ 0x51 (0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000)

00:0006:00000:00228:2014/12/27 22:23:39.19 kernel  pc: 0x0000000076EEA34D CreateFiberEx+ 0x27d (0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000)

00:0006:00000:00228:2014/12/27 22:23:39.19 kernel  end of stack trace, spid 228, kpid 19333268, suid 4

00:0004:00000:00325:2014/12/28 02:00:02.89 server  DBCC TRACEON 11906, SPID 325

[Former Member]

Hi Kiran,

we have done the command like your suggestion, the output below

But we try to select from the table "FUPARAREF" we still have the same error

Do you have any other idea?

Thank you.

Regards,

Alcino

[Former Member]

Here is the error when we try to run DBCC DBrepair

[former_member187136]

this is correct syntax:

dbcc dbrepair(database_name, ltmignore)

[former_member3043]

Hello Alcino,

the error indicates that a shrink failed, could you check the ASE errorlog ($SYBASE\$SYBASE_ASE\install\<SID>.log) if problems were reported there ?

See also the dbcc dbrepair command details:

Restarting Partially Completed Shrink Operations

Hope this will help.

Regards

Stefan

[former_member3043]

Hello Kiran,

this command will just clear the secondary truncation point for an offline replicated database, it will do the same like settrunc ignore.

Regards

Stefan

[former_member3043]

Hello,

it looks like that a shrink database was interrupted before, can you confirm this ?

Also what dbcc dbrepair command in detail was executed ?

Regards

Stefan

[Former Member]

Hello Stefan,

We have done the shrink, but it wasn't  interrupted.

No we can´t execute the command  dbcc dbrepair, and unfortunately  we don´t have a big knowledge with sybase.

For now we have run the command dbcc checkdb, it is still running!

Regards,

Alcino