Check data finished unsuccessfully in Admin mode

[Former Member]

Every day, we check replicate DB in admin mode (maxdb 7.6.0.5.10)

dbmcli> db_execute check data with update

But sometimes the check was unsucessfully with error messages (knldiag.err) for instance

2009-02-08 17:50:56 22301 ERR 53019 CHECK Base error: index_not_accessib

2009-02-08 17:50:56 22301 ERR 53019 CHECK Root pageNo: 19825502

2009-02-08 17:50:56 22301 ERR 53019 CHECK Base error: index_not_accessib

2009-02-08 17:50:56 22301 ERR 53019 CHECK Root pageNo: 26040425

2009-02-08 17:50:56 22301 ERR 53019 CHECK Base error: index_not_accessib

2009-02-08 17:50:56 22301 ERR 53019 CHECK Root pageNo: 26055212

2009-02-08 17:50:56 22301 ERR 53019 CHECK Base error: index_not_accessib

2009-02-08 17:50:56 22301 ERR 53019 CHECK Root pageNo: 25141658

2009-02-08 17:50:56 22301 ERR 53019 CHECK Base error: index_not_accessib

2009-02-08 17:50:56 22301 ERR 53019 CHECK Root pageNo: 24711511

2009-02-08 17:50:56 22301 ERR 53019 CHECK Base error: index_not_accessib

2009-02-08 17:50:56 22301 ERR 53019 CHECK Root pageNo: 23782638

2009-02-09 01:25:58 22301 ERR 53000 CHECK Check data finished unsuccessfully

2009-02-09 01:25:59 22301 ERR 51080 SYSERROR -9041 BD Index not accessible

So i have done some controls to see what object was erroneous

sqlcli GLP=> SELECT * FROM ROOTS WHERE ROOT = 19825502

• 0: SQLSTATE:

sqlcli GLP=>

sqlcli GLP=> SELECT * FROM ROOTS WHERE ROOT = 26040425

• 0: SQLSTATE:

sqlcli GLP=>

Unfortunately there was no object related to pageNo.

What can i do to find eroneous objects?

[Former Member]

I thought the problem was resolved but check db does not work in my replicated DB after restore from offline backup.

[Former Member]

Thanks a lot, it is very helpful

[Former Member]

Thanks a lot, it is very helpful

but I have no error with the two requests (after i put replicated DB in online mode for these tests)

dbmcli on salvator : GLP>info BADIDX

OK

---

dbmcli on salvator : GLP>

and

salvator:glpadm 58> sqlcli -U w

Welcome to the MaxDB interactive terminal.

Type: \h for help with commands

\q to quit

sqlcli=> select t.owner, t.tablename, f.root from files f join tables t on f.fileid = t.tableid where f.root in (19825502,26040425,26055212,25141658,24711511,23782638)

• 0: SQLSTATE:

sqlcli GLP=>

I don't know which object was related to these page numbers in my replicated database which iwas in admin mode.

[lbreddemann]

> but I have no error with the two requests (after i put replicated DB in online mode for these tests)

What do you mean by "replicated DB" ?

Do you have a 1:1 copy of the database with the error messages here or do you use replication?

> I don't know which object was related to these page numbers in my replicated database which iwas in admin mode.

And again: how did you create the "replicated" version of your database?

Why do you assume that you'll find the same errors in a different db instance?

regards,

Lars

[Former Member]

I restore DB on another server with

db_activate recover and

recover_start, recover_replace for logs

and every day we replicated logs by

recover_start and recover_replace

Check db is start every day on this database not on production database.

[lbreddemann]

Hi Alain,

I'm not sure if I get you right.

You created a copy of your productive instance as a standby db.

You ran "CHECK DATA" on this copy, which produced the error messages.

Now you set the standby instance online, but you didn't find the roots mentioned by the error messages.

Is that correct?

regards,

Lars

[Former Member]

Yes, That's right.

But now i am obliged to restart replicated DB from backup.

[lbreddemann]

> But now i am obliged to restart replicated DB from backup.

Well, then there's nothing to check anymore.

Anyhow, you should run a CHECK DATA on your production instance as well to make sure that everything is OK there.

regards,

Lars

[Former Member]

Hello,

I restore my replicated DB from a backup of production DB and recover logs

I do check data with update on replicate DB without problem as you can see on following logs

dbmcli on salvator : GLP>OK

---

dbmcli on salvator : GLP>OK

PAGES_USED = 0031853677

BLOCKS_RELEASED = 0000052356

---

dbmcli on salvator : GLP>

Check GLP le Thu Feb 12 04:02:26 CET 2009 fin

dbmcli on salvator : GLP>OK

---

dbmcli on salvator : GLP>OK

State

OFFLINE

---

dbmcli on salvator : GLP>

Remarks: Unused pages are deleted by check DB, may is there the problem (notes 852168) ?

we used MaxDB 7.6.05.10.

[lbreddemann]

Hi Alain,

I know that the note is a bit difficult to comprehend, but the mentioned problems are already solved with the version you use (maxdb 7.6.0.5.10).

Concerning the freed pages, check my blog [MaxDB: Space oddities|https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/12959] [original link is broken] [original link is broken] [original link is broken];.

As a SAP customer you may as well open a support message for such issues.

We can then logon to the system and check whether there still corruptions in the database.

By the way: if the BAD indexes had been rebuild meanwhile (e.g. via the automatic rebuild during instance startup), then the root numbers for the indexes have changed, and the old ones aren't there any more.

regards,

Lars

[lbreddemann]

Hi Alain,

are there any indexes marked as BAD? (run 'info badidx' in dbmcli)

With which user did you logon to sqlcli to run the statement against table ROOTS?

regards,

Lars

[Former Member]

I connect with user superdba

[lbreddemann]

> I connect with user superdba

ROOTS will always restrict to OWNER = USER, therefore you likely will find the damaged indexes in a different schema.

Try this statement instead:

select t.owner, t.tablename, f.root 
from files f  join tables t on 
     f.fileid = t.tableid 
where 
   f.root in (<put your root#s here>)

Still easier would be the "info BADIDX" method - but you don't seem to like this one...

regards,

Lars