Solved: MaxDB - Check Database Structure error

Hello community,

on a MAXDB Version 7.7.04.25 on AIX operating systemthe check database structure terminates with the following error:

-24988,ERR_SQL: SQL error

-9407,00000000000000000001

100,Check database finished unsuccessfully

2,Check OMS container failed

Servertask Info: because bd01CheckFile failed

Job 0 (Check Data) [executing] WaitingT254 Result=OK

bd01CheckFile failed, Error code -28826 "wrong_all_page_count"

Could anyone give me some hint regarding this error?

Regards, Valerio

SAP Managed Tags:
SAP MaxDB

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Accepted Solutions (1)

> -24988,ERR_SQL: SQL error

> -9407,00000000000000000001

> 100,Check database finished unsuccessfully

> 2,Check OMS container failed

> Servertask Info: because bd01CheckFile failed

> Job 0 (Check Data) [executing] WaitingT254 Result=OK

> bd01CheckFile failed, Error code -28826 "wrong_all_page_count"

Is this a Livecache? What's the output in KnlMsg (step to /sapdb/data/wrk/<DB> and excute "protconv > knldiag.txt", then check the last lines.

Markus

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Hi Mark,

this is a Livecache, I don't have access to the database server, I can only execute commands in the DBMGUI.

This is the details of the error as I see them in Check, Diagnostic Files, Database Messages.

I am sorry but I can't paste the log in a readable form, I paste only the relevant entry

Check data on database object failed,KNL_BASE_ERROR=wrong_all_page_count,ROOT=29777,_FILE=vbd38.cpp,_LINE=353

An error occurred while checking the structure of the database object with Root '29777'.

Determine the name of the affected database object by querying the system tables FILES respectively ROOTS using the reported FileID respectively Root.

Check OMS container failed,KNL_BASE_ERROR=wrong_all_page_count,INTERNAL_FILENAME=16000000000000000533000, ROOT=29777,FILENO=0000000000000533,_FILE=vbd92.cpp,_LINE=503

In the System Table FILES I can't find an entry with ROOT=29777

Regards,

Valerio

Hi Valerio,

it's of no use to figure out the root for the corrupted OMS object because there is no way to "repair" it.

To fix this issue you need to perform a full restore/recovery of the liveaCache.

You may well open a support message for this to have this double checked - but I'm pretty sure that a recovery will be the outcome.

regards,

Lars

This message was moderated.

Thanks for your support.

We prefer not to restore the database, if it is possibile.

The instance on which we have this error is a quality system, can we export the same object from the production and import it on the quality system using the MaxDB loader or by other means?

Thanks, Valerio

> We prefer not to restore the database, if it is possibile.

Sure you prefer not to do it.

But it's the only correct solution.

> The instance on which we have this error is a quality system, can we export the same object from the production and import it on the quality system using the MaxDB loader or by other means?

No, MaxDB loader is not able to handle OMS objects.

If this is just a Q/A instance - fine. Rebuild it from the production and you're done.

Really - corruptions are THE use case for recoveries. That's what you have backups for.

You do have a backup, don't you?

So what's the point in not recovering it, when this guaratees to solve the issue for you?

regards,

Lars

Marketing: if you're not already booked for October 27-29 this

year and you happen to stay in vienna and you keep asking yourself

what to do ... then get your ticket for *[SAP TechED 2009|http://www.sapteched.com/emea/

]* and make sure to attend my *[MaxDB session|http://www.sapteched.com/emea/edu_sessions/session.htm?id=237

Hi,

we do regular backups, but they asked me to search for a quicker and simpler solution than a restore if possibile, also because our team found out this problem independently, from the application point of view there are no evident errors or issues.

So, it's a bit difficult to justify the restore to our customer without an issue coming from the final users of the system.

You know, these are hard times...

Thanks everybody for your support, we will follow your hint.

This thread is closed

Valerio

> Hi,

> we do regular backups, but they asked me to search for a quicker and simpler solution than a restore if possibile, also because our team found out this problem independently, from the application point of view there are no evident errors or issues.

So what? The users did not hit the corrupt object yet.

That's what you do consistency checks for. So that you know about the issue in advance of the users.

Now you've the chance to plan your downtime, to test the recovery and make sure everything will be ok.

Much better than facing a production down and feeling the pressure of the application users in your neck..

> So, it's a bit difficult to justify the restore to our customer without an issue coming from the final users of the system.

> You know, these are hard times...

Sorry, but I fail to see what these hard times have anything to do with these clear technical facts.

There is a damage of your database that cannot be repaired.

You have a backup that can be used to avoid loosing the data.

You make use of the backup.

That's simply the correct way to handle the issue - interesting to learn that doing your work the right way actually required justification from the end users...

best regards,

Lars

Marketing: if you're not already booked for October 27-29 this year and you happen to stay in vienna and you keep asking yourself what to do ... then get your ticket for [SAP TechED 2009|http://www.sapteched.com/emea/] and make sure to attend my [MaxDB Session|http://www.sapteched.com/emea/edu_sessions/session.htm?id=237]

Hi community,

this problem was related to a bug in the MaxDB kernel reported in the Problem Tracking System:

[PTS 1159452|http://maxdb.sap.com/webpts?wptsdetail=yes&ErrorType=0&ErrorID=1159452]

We solved the problem upgrading from version 7.7.04.25 to 7.7.04.32

Thanks,

Valerio

hmmm... the PTS describes an error in the "FreePageCount" information, while you hit a problem with the "AllPageCount"...

Had you opened a support message to verify this?

regards,

Lars

You are right Lars

I didn't copy all the kernel messages here in the forum because I couldn't keep a readable format of my post, I did copy only the relevant errors here

In the whole kernel log there are both the entries, but I can't add an attachment here

And yes, I opened a customer message to SAP to solve the problem, and they told me to do so, and It worked

Regards, Valerio

Thread 0x434 Task 220 2009-08-07 12:08:01 Data 82: Start check database

Thread 0x1C1 Task 114 2009-08-07 12:08:04 Data 108: Check database progress report: 41133 of about 411332 pages checked

Thread 0x1C1 Task 118 2009-08-07 12:08:07 Data 108: Check database progress report: 82266 of about 411332 pages checked

Thread 0x1C1 Task 116 2009-08-07 12:08:22 Data 108: Check database progress report: 123399 of about 411332 pages checked

Thread 0x1C1 Task 118 2009-08-07 12:08:26 ERR OBJECT 53000: vbd92.cpp:2074 bd92_VerifyObjSubRootPage

Thread 0x1C1 Task 118 2009-08-07 12:08:26 ERR OBJECT 53000: - subroot:0 wrong FreePageCount SubRoot

Thread 0x1C1 Task 118 2009-08-07 12:08:26 ERR OBJECT 53000: Info:21

Thread 0x1C1 Task 118 2009-08-07 12:08:26 ERR OBJECT 53000: vbd92.cpp:2074 bd92_VerifyObjSubRootPage

Thread 0x1C1 Task 118 2009-08-07 12:08:26 ERR OBJECT 53000: - subroot:14889 wrong FreePageCount Sub

Thread 0x1C1 Task 118 2009-08-07 12:08:26 ERR OBJECT 53000: RootInfo:21

Thread 0x434 Task 220 2009-08-07 12:08:26 ERR Data 47: Check data on database object failed,KNL_BASE_ERROR=wrong_all_page_count,ROOT=0,_FILE=vbd38.cpp,_LINE=353

DESCRIPTION:

An error occurred while checking the structure of the database object with Root '0'.

Thread 0x1C1 Task 118 2009-08-07 12:08:34 Data 108: Check database progress report: 164532 of about 411332 pages checked

Thread 0x1C1 Task 112 2009-08-07 12:08:47 Data 108: Check database progress report: 205665 of about 411332 pages checked

Thread 0x1C1 Task 118 2009-08-07 12:09:34 Data 108: Check database progress report: 246798 of about 411332 pages checked