MaxDB memory problem and other random behavior

[Former Member]

Hello, we have been using MaxDB 7.5.05 for a while and it has been working fine however it had come time to upgrade the server and decided to upgrade the database as well.

We were provided with a special MaxDB kernel for use with the upgrade so that triggers would continue to work correctly after the upgrade. After the upgrade was done, everything looked fine and started to work as usual. However not long after, we noticed that things stopped working as they should.

An example is, in SQL studio, if we execute a certain long statement, sometimes it will work and sometimes it will just come back with a memory error. All the parameters in the database are set to exactly what they were in the old system.

Another problem is that we have some ASP code that goes in and will update a field in the database. When this happens, a trigger should fire. Again, sometimes the trigger works, and sometimes it doesn't.

The version of MaxDB we are currently using is 7.6.02.10. I know that there is a newer version out but don't really want to upgrade unless it's going to solve our problem.

I did the upgrade on our old server, then ran a backup. Installed a fresh MaxDB 7.6.02.10 on the new server and then a restore of the backup file.

The CPU we use is a dual Intel(R) Xeon(TM) CPU 2.80GHz. OS is CentOS 5 32bit. We have 4gb of memory which is twice the amount in the old server.

Is this a known problem or has anyone come across this before? We get no errors at all in the system or MaxDB logs (knldiag/knldiag.err) about any memory errors or any other errors at all - everything looks fine. It's as if it's failing internally and MaxDB isn't recognizing it as an error.

We also came across a bug where table joins with views don't work as expected. For example, if we have a view that does a left join and then we do a SELECT from the view, we need to make sure that in the view, the WHERE clause will query based on the left table and not the right. This is a known bug though (don't have a reference for it with me at the moment) and we have worked around this problem.

Thanks for any help on this. This is our production system and we can't really go back to the old one so we are stuck with this for now and is causing a lot of problems for us. Appreciate any feedback.

[Melanie]

Hello Ben,

as this seems to be an SAP system you should open a customer message (or better: one for each problem) that we can analyse and solve your problems as fast as possible.

Best regards,

Melanie

[Former Member]

Hi, thanks a lot for the replies.

I didn't originally know what the error code was until just a few moments ago: -915 no more memory.

Now that I know the error, I went and researched this and found that our database is only using a cache size of 12000 pages, and a cat cache supply of 5184 pages. These pages were inherited from the old 7.5 instance.

As I understand, 1 page is equal to 8k of physical memory, that means we have MaxDB using around about 96mb of memory. I also understand that there is a limit of 2gb memory that we can use on a 32bit system. What should be a good value to set for the cache size and cat cache supply on our system?

Thanks again for the help.

[markus_doehr2]

That depends on a number of other parameters but you can try 100.000 pages (which is 800 MB) - if that leaves enough memory for your application. You didn't state how much memory you have in your box so that's just a suggestion.

--

Markus

[Former Member]

Hi Markus, we are using 4gb on the machine but I think we can only use 2gb of it as it is a 32bit arch. All we are running on that server is MaxDB so if we set it to around 200,000 then that should be fine (at least, better than what we have now).

[markus_doehr2]

200000 may be too much (as said, depending on other parameters) - but you can try.

--

Markus

[Former Member]

I've set it to 150,000. On top of that, we found some other things when monitoring the queries passing through it which have caused it to go slow (indexing on constantly-used tables for example) and now these queries operate much faster.

We'll see how it goes tomorrow, hopefully it will be OK and we'll test the trigger problem we were having as well and if problems persist, will create a separate customer message.

Thanks again for the help and quick response time.

[markus_doehr2]

[...]

> An example is, in SQL studio, if we execute a certain

> long statement, sometimes it will work and sometimes

> it will just come back with a memory error. All the

> parameters in the database are set to exactly what

> they were in the old system.

can you be tell us what you mean with "a memory error"? What error message do you get?

--

Markus