cancel
Showing results for 
Search instead for 
Did you mean: 

Reorg error in Linux Cache Server running on MaxDB 'Unknown result table'

jgleichmann
Active Contributor
0 Kudos

Hello everybody,

I´m facing a problem with my linux cache servers. I noticed that the DB is growing up and no old document, which is not longer needed and its use is a long time ago, will be deleted from the MaxDB by reorg. So I have decided to analyze this behavior.

I´ve enabled the debugging for the cache server in the csc.conf and enabled the trace on MaxDB .

Here some lines from the apache error.log:


[Wed Sep 09 11:36:34 2009] [debug] apatracer.cpp(54): 
ContentServerCache [4013] 49ac50d1c7074050e10080000a803 removed from repository
 <IP>_<port>_<repository> during reorganization

[Wed Sep 09 11:36:34 2009] [error] ContentServerCache [4013] SAPDB Cache: [SAP AG][LIBSQLOD SO][MaxDB]
General error;-4000 POS(1) Unknown result table

[Wed Sep 09 11:36:34 2009] [notice] ContentServerCache [4013] 
eorganization
summary for repository <IP>_<port>_<repository>
 Pre reorg available KB: 1002024,  
Pre used ratio: 94%
Post reorg available KB: 1002024,
Post used ratio: 94%
Threshold: 90%, Free'd KB: 0
Reorg passes: 250
Elapsed time 0h 0m 0s 197ms 806us

MaxDB trace:

all 250 ID´s get in state ' key_not_found' and at the end of every run there is the error 'Unknown result table':


>b07cget key(138):

         00000000 00000000 00B50053 0051004C 005F0043 00550052 0053004F

         0052005F 00300030 00300036 00200020 00200020 00200020 00200020

         00200020

         '...........S.Q.L._.C.U.R.S.O.R._.0.0.0.6. . . . . . . . . . '

 b07cget root                90808; *** key_not_found ***

RECEIVE: ascii, full_swap, 70600-ODB     (1 segment, len: 80)

(4.2002 ; page 5)

   *** -4000 / RETURN SEGMENT 1   (1 part, len: 80)

         close_fc, errpos: 7, sqlstate: '24000'

   errortext PART   (1 argument, size: 130856)

         buf(20): 'Unknown result table'

The reorg routine is taking every time the same 250 ID´s and will delete them from all repositories! But in reality it was nothing deleted from any repository, just looping. I noticed this only on Linux, the Windows servers reorg works fine.

The reorg is triggered by the csc.conf parameter 'CacheThreshold' its default value is 70.

Is anyone facing the same issue?

Thanks in advance!

Regards,

Jens

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

Hi,

did I miss the info about the used kernel and client-version and the used client?

The statement causing the problem will be helpful.

Does the statement itself causes the problem or is the statement only a victim of some problem having occured before?

I hope, you checked this.

Lars thinks, the b07cget is to deep (correct for him), but for me this trace starting from the connect to the kernel to this

-4000 would be of some use.

Can you provide it ?

Elke

lbreddemann
Active Contributor
0 Kudos

I´m facing a problem with my linux cache servers. I noticed that the DB is growing up and no old document, which is not longer needed and its use is a long time ago, will be deleted from the MaxDB by reorg. So I have decided to analyze this behavior.

There is no such thing as a 'reorg' for MaxDBs.

You want to delete documents from the content server not to reorg the database.

I´ve enabled the debugging for the cache server in the csc.conf and enabled the trace on MaxDB .

ContentServerCache SAPDB Cache: [LIBSQLOD SO][MaxDB]

General error;-4000 POS(1) Unknown result table

Ok, and do you now the SQL command that lead to this error?

MaxDB trace:

all 250 ID´s get in state ' key_not_found' and at the end of every run there is the error 'Unknown result table':

>b07cget key(138):

b07cget root 90808; *** key_not_found ***

RECEIVE: ascii, full_swap, 70600-ODB (1 segment, len: 80)

Sorry, but this is far too low level for this.

The "key not found" is likely just the "unknown result table" error in a different message.

All in all I'd guess that this is a client software issue...

Anyhow, since you're a SAP customer, please open a support message for this so that we have better options to analyze this.

regards,

Lars

jgleichmann
Active Contributor
0 Kudos

Hi Lars,

this is an automatism from the cache server which is triggered by the fill status of the DB. The oldest documents will be deleted, I don´t know the complete routine. This is the explanation by sap:


CacheThreshold
--------------
Type: INTEGER
Range: 0 - 100
Default: 70
Purpose: Maximum storage usage ratio in percent. Cache server starts cache
reorganisation if this threshold limit is exceeded or storage space is
insufficient for the next document.
Setting the ratio to 100% is not a good idea since this increases not
only the number of reorganization jobs but can also lead to a system lock
down in case the cache repository is located in a file system.

Anyhow, since you're a SAP customer, please open a support message for this so that we have better options to analyze this.

here is the problem

I opened a oss message 2 month ago and it´s still in the development of cache/content server and MaxDB team... There is no solution for this behavior till now.

MaxDB version is 7.6.06.06.

Regards,

Jens

lbreddemann
Active Contributor
0 Kudos

Anyhow, since you're a SAP customer, please open a support message for this so that we have better options to analyze this.

here is the problem

I opened a oss message 2 month ago and it´s still in the development of cache/content server and MaxDB team... There is no solution for this behavior till now.

MaxDB version is 7.6.06.06.

Hi Jens,

I reviewed the message (see, I'm working in SAP MaxDB Support as well...) and it looks like the analysis got stuck a bit by figuring out which statement causes the problem.

One additional approach to what the colleagues already are trying might be to enable the MaxDB vtrace and specify the stop on error option for the "unknown result table" error.

Anyhow, just like in the detective stories: never intervene with ongoing investigations

So it really might be best to stay in close touch with the message processors to have this analyzed properly.

regards,

Lars