Problems with index in 7.8

[Former Member]

Hi

Maybe one of you can help me with a strange index problem in MaxDB 7.8.

We use a table for gathering some statistic data. This table has an index on one of its columns.

We have a job, deleting older data one by one. This jobs deletes aprox. 600 rows per second.

After few minutes of deletion the index becomes bad

In the error file we can see:

ERR B*TREE 53000: 0701000000000001B044000000000000

ERR B*TREE 53000: Index Root 1652047

ERR B*TREE 53367: bd400_DeleteSubTrees: 574188

ERR SYSERROR 51080: -9049 BD Primkey from inv in primtree no

ERR SYSERROR 51080: -9049 BD Primkey from inv in primtree no

ERR SYSERROR 51080: -9049 BD Primkey from inv in primtree no

ERR MOVECODE 20011: Bad parameter: source size [8181] dest size [8181], source addr [0x2b7d9770c000]7789, dest addr [0x2b7d9770c000]7799, -1116 bytes to copy; module vbd600noPIC.cpp, pos 200,_FILE=vbd600noPIC.cpp,_LINE=200

ERR B*TREE 53000: 0701000000000001C962000000000000

ERR B*TREE 53000: Index Root 5100308

ERR B*TREE 53333: Data page corrupted: 10191006

ERR Index 5: Mark index as not accessible,PERSISTENT_TYPE=perm,INTERNAL_FILENAME=0701000000000001C962000,KNL_BASE_ERROR=data_page_corrupted,ROOT=5100308,FILENO=000000000001C962,_FILE=vbd300+noPIC.cpp,_LINE=717

DESCRIPTION:

While accesing the index with FileID '000000000001C962' respectively with root '5100308' a severe error occured, so that it was deactivated.

For further processing please take notice of the attached note.

ACTION:

Find the reason for the deactivation of the index. Probably there is an hardware failure which damaged other database objects as well.Perform a check database in the near future.

After clarifying the reason drop and recreate the index.

ERR MOVECODE 20011: Bad parameter: source size [8181] dest size [8181], source addr [0x2b7d9770c000]7789, dest addr [0x2b7d9770c000]7799, -1116 bytes to copy; module vbd600noPIC.cpp, pos 200,_FILE=vbd600noPIC.cpp,_LINE=200

ERR MOVECODE 20013: Module vbd600noPIC.cpp, pos 200,_FILE=SAPDB_RangeCodenoPIC.cpp,_LINE=86

ERR SYSERROR 51080: -9049 BD Primkey from inv in primtree no

We can drop and rebuild the index but the error will occur again.

If the parameter "automatic Recreation of Bad indexes" is set to yes the database crashes and trying to restart it results in

-9407,System error: unexpected error

3,Database state: OFFLINE

Internal errorcode, Error code 6433 "system_error"

9,File directory restart failed; error '3'

29,Add of entry to file directory failed; file no '000000000001C968', file type 'IndexFile', error 'rcFileNoExists'

Does anyone of you know this problem and has an idea how to solve it?

CU,

Matthias

[former_member188883]

Hi,

There should be some bug fix available for MaxDB 7.8. May be database patch should resolve the issue.

Refer thread for similar issue.

Regards,

Deepak Kori

[Former Member]

Hi

Sorry for the delay

I couldn't test the patch by now, but can you ore anybody else anybody tell me what "-9049 BD Primkey from inv in primtree no" exactly means?

For me it looks like the index tries to delete an entry for non existing data?

CU,

Matthias

[thorsten_zielke]

Yes, your assumption is correct. A MaxDB index contains the index-fields (kept in a B*tree structure sorted in ascending order) *plus* a list of links to the related primary keys in the base table. MaxDB always keeps the primary keys in the index tree. So what happened is that for a certain index (= "Invertierung") entry the given primary key did not exist in the base table. Therfore the error message 'Primkey from inv (=index) in primtree not found'.

As you have rebuild that index and the same error occured again, I would recommend to install the latest MaxDB patch and retry. I do not know the MaxDB version you are using, but there is a known problem that was fixed with 7.7.07.20 and 7.8.02.08.

Other than that, you might try to delete every index on that table and rebuild them afterwards, but if this was caused by a MaxDB bug, it probably will not help.

Thorsten

[Former Member]

Hi

Thanks for the quick answer.

We use Version 7.8.02.21, so the bug you mentioned should not be a problem anymore.

I think we have to try the latest patch and see what happens.

CU,

Matthias

[thorsten_zielke]

Hi,

then it seems that this is a certain bug we are aware about since 7.8.02, but were unable to recreate at all on our test systems. If you have a test case we could use (by either remote logon or sending us the involved data and the delete job), please let me know, this would really help us.

Thorsten

[Former Member]

Hi Thorsten

We can send you the table definition, data and indexes. The delete job is done by a piece of software, I will have to ask our software developers for the sql statements behind this.

What data do you need exactly?

CU,

Matthias

[thorsten_zielke]

Hi Matthias,

that is the tricky part - I would prefer a small data set, but most important is that this data will lead us to the corrupt index. If you could isolate this into a small test case, it would be a great help. And, yes, I would also need the SQL statements behind.

Most important really is that we can recreate this inhouse here at SAP.

Thorsten

[Former Member]

Hi Thorsten

Sorry for the late answer, I was in vacation.

We discussed it here and found that we will try to reproduce the problem on a test DB.

If we succeed, we can reduce the data and hopefully provide you with a test case.

Maybe you can send me a PM, so I can come back to you with our results later.

CU,

Matthias