New instance on 7.7.06.09 crashes with SIGNAL 11 (SIGSEGV)

[simon_matter]

After having lots of trouble to migrate our 7.6 instance to 7.7, we have decided to create a new instance on 7.7 and migrating all tables with our own dbcopy tool.

The new instance is configured the same way like our old 7.6 instance. We have started the instance and copied all data to it. After that we have started our Java based appserver with the new instance but the instance crashes quite soon. We have now switched back to the 7.6 instance which is one the same server and works fine.

I have put the tarball of the DIAGHISTORY directory here:

[DIAGHISTORY|http://www.invoca.ch/pub/maxdb/DIAGHISTORY.tar.bz2]

Any ideas how to find out what's wrong?

Regards,

Simon

[Former Member · Accepted solution]

Hello Simon,

can you tell us linux version you are using with:

uname -a

rpm -q -a grep glibc-2

Regards

Ivan

[simon_matter · Accepted solution]

Sorry, forgot to mention that. It's RHEL5.3

Linux omega.corp.invoca.ch 2.6.18-128.1.10.el5 #1 SMP Thu May 7 10:35:59 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux

glibc-2.5-34

Hardware is HP DL385 G5

Regards,

Simon

[former_member229109 · Accepted solution]

Hello Simon,

You are running the database version 7.7.06.09

I think the problem occurred due the QueryRewrite rules AddLocalPredicates or NormalizePrediactes are activated,

Case reported in PTS :

http://www.sapdb.org/webpts?wptsdetail=yes&ErrorType=0&ErrorID=1175192

The problem is planned to be solved with MaxDB 7.7.06.16 or higher.

Could you please use the workaround in your version of the datababase to avoid the reported crash,

Workaround:

Disable QueryRewriterules by updating QUERYREWRITERULES table

Please let us know, if the database will be crashed after that.

***

Could you please set the MaxDB parameter EnableQueryRewrite to NO to ensure optimal database stability and performance. And as of MaxDB-Version 7.7.05 you could activate SharedSQL. I recommend to set the database parameter UseSharedSQL= YES.

The general parameter UseVectorIOSimulation recommendation for MaxDB is NEVER.

Thank you and best regards, Natalia Khlopina

Edited by: Natalia Khlopina on Jun 4, 2009 2:22 PM

[simon_matter · Accepted solution]

Hello Natalia,

Wow, that looks much better now!

I ran two of our tests and they both finished without a crash. So it looks like that may exactly be our problem.

For my understanding:

I have fist set EnableQueryRewrite=NO (beside the other parameters you suggested). Then ran the tests and it was successful. But, I guess completely disabling query rewrites may harm performance (and the parameter seem not to exist in 7.6) I decided to enable it again and then updated the table QUERYREWRITERULES as shown in the PTS. The same tests also finished without crash.

Am I right that doing the latter is a bit better for performance?

Hm, I'm quite sure this bug has hit us for quite some time. We saw crashed from time to time and just didn't realize it could be something like that. We have recently reported a bug which led to a crash and was verified but that was a different bug. Now I feel we are close to a solution.

We really wanted to upgrade because of those crashes and didn't know the problem exists on both versions.

I'll report back how it goes.

Regards,

Simon

Edited by: Simon Matter on Jun 4, 2009 11:05 PM

[former_member229109 · Accepted solution]

Hello Simon,

1.

Please check the PTS :

http://www.sapdb.org/webpts?wptsdetail=yes&ErrorType=0&ErrorID=1175192

The database fixed patch is not delivered yet.

Please update the thread if the database crash/problems occurred when you are using the recommended workaround.

2.

"u2026 and the parameter seem not to exist in 7.6 u2026 "

In the database version 7.6 the name of the database parameter is OPTIMIZE_QUERYREWRITE.

param_getexplain OPTIMIZE_QUERYREWRITE

OK

OPTIMIZE_QUERYREWRITE 'NO' or 'STATEMENT' or 'OPERATOR'

'NO': No query rewrite will be done.

'STATEMENT' : Query rewrite on sqlstatement level.

'OPERATOR' : Query rewrite on operator level.

Thank you & Best Regards, N. Khlopina

[simon_matter · Accepted solution]

Hi Natalia,

Thanks for all your help and the link to PTS which fixed our segfaults.

We have finally migrated the production instance using our Java db migrator to version 7.7 and all seems to work well.

Regards,

Simon

[Former Member]

Hello Simon,

1)

first of all the atached files you have posted are very difficult to read , try it yourself. So I would suggest to convert them to ASCII files (from xml) with protconv tool (sapdb/programs/bin)

-> reproduce the crash , so fresh new crash is in the knlmsg (/sapdb/data/wrk/<SID>)

->switch to this directory

-> run

protconv -o knldiag.txt

2)

try to set shared UseSharedSQL to NO and reproduce the try if it is still crashing

Regards

Ivan

Edited by: Ivan Levrinc on Jun 4, 2009 1:31 PM

[simon_matter]

Hello Ivan,

Thanks for your suggestions.

1)

I have added KnlMsg of two crashed here:

[Crash 1|http://www.invoca.ch/pub/maxdb/KnlMsg.log]

[Crash 2|http://www.invoca.ch/pub/maxdb/KnlMsg2.log]

2)

We will try running our appserver ASAP with UseSharedSQL=NO.

Regards,

Simon

[simon_matter]

Here is the new Log with UseSharedSQL=NO:

[Crash 3|http://www.invoca.ch/pub/maxdb/KnlMsg3.log]

Regards,

Simon