7.5.0.38 autolog not working as expected

[Former Member]

Hello,

in the last 4 days we have the strange situation that the autolog functionality is not working and the log devspace gets filled up.

"Normal" behaviour is, that every 10min a log backup is being created and copied to a second server. But in the last 4 days we have the situation (once a day) that this doesn't work and the log-devspace gets filled up.

Even a log backup doesn't solve the situation.

The only "solution" is restarting the database, which isn't a nice "solution" for a productive system.....

Today we restarted the database at 02:13pm. In the dbm.-files there are no error messages regarding the 10min-interval-creation of autologs, but we had to restart the db since the log devspace got filled up to 80% ?!?!

The dbm.utl/dbm.prt files show entries every 10min. for creating the autolog file, but in reality it didn't have been written..

What else can we check to get closer to the source of this problem ?

I can only think of a long running transaction which can cause such a situation, but we have no long running....?!?!

What exactly can we check if we're running in such a situation again ?

many thanks in advance...GERD...

2009-11-23 13:56:51 0x00002d59              0 DBM      command autolog_on
2009-11-23 14:06:56 0x00007bff              0 DBM      command autolog_off
2009-11-23 14:07:01 0x000001d7              0 DBM      command backup_start auto
2009-11-23 14:07:02 0x00000260              0 DBM      command autolog_on
2009-11-23 14:08:03 0x00007a82              0 DBM      command db_offline
2009-11-23 14:13:07 0x00007a82              0 DBM      command db_online
2009-11-23 14:17:59 0x00001f20              0 DBM      command autolog_off
2009-11-23 14:18:04 0x0000243a              0 DBM      command backup_start auto
2009-11-23 14:18:05 0x00002521              0 DBM      command autolog_on
2009-11-23 14:28:10 0x00004593              0 DBM      command autolog_off
2009-11-23 14:28:15 0x0000498b              0 DBM      command backup_start auto
2009-11-23 14:28:16 0x00004a21              0 DBM      command autolog_on
2009-11-23 14:38:27 0x000074a5              0 DBM      command autolog_off
2009-11-23 14:38:32 0x00007801              0 DBM      command backup_start auto
2009-11-23 14:38:33 0x0000788a              0 DBM      command autolog_on

[lbreddemann]

Hmm... there is no time based log backup in 7.5. Build 38 - it had been introduced with 7.5. Build 40 ...

So basically you're database is configured to write out log segments whenever they are filled up.

Besides this there must have been a savepoint written after a logsegment had been filled to make it possible that the logsegment can be marked as overwriteable.

In general I'd propose to check the KNLDIAG file that was active when the problem occured and (if available) the detail logs of the dbanalyzer.

And (of course) you should really install a more current patch of MaxDB!

regards,

Lars

[Former Member]

Hello Lars,

we're using an external tool to create the autologs (called DBShadow). We configured it to run every 10min.

In the knldiag files there's no entry with exception or failure of writing logs.

The entries in the backup history look "normal", looks like the autolog has been written..?!?!

4B0A782102A2|LOG_000132803|SAVE WARM|2009-11-23 12:44:57|2009-11-23 12:55:13|2009-11-23 12:55:13|2009-11-23 12:55:13|2363383738|2363457829|
   |auto                                                            |      4240|         1|         0|
   |
4B0A7A8902A5|LOG_000132804|SAVE WARM|2009-11-23 12:55:13|2009-11-23 13:05:29|2009-11-23 13:05:29|2009-11-23 13:05:29|2363457830|2363542607|
   |auto                                                            |      5000|         1|         0|
   |
4B0A7CF202A8|LOG_000132805|SAVE WARM|2009-11-23 13:05:29|2009-11-23 13:15:46|2009-11-23 13:15:46|2009-11-23 13:15:47|2363542608|2363632884|
   |auto                                                            |      5320|         1|         0|
   |
4B0A7F5C02AB|LOG_000132806|SAVE WARM|2009-11-23 13:15:47|2009-11-23 13:26:04|2009-11-23 13:26:04|2009-11-23 13:26:04|2363632885|2363722311|
   |auto                                                            |      5392|         1|         0|
   |
4B0A81C602AE|LOG_000132807|SAVE WARM|2009-11-23 13:26:04|2009-11-23 13:36:22|2009-11-23 13:36:22|2009-11-23 13:36:22|2363722312|2363805509|
   |auto                                                            |      4936|         1|         0|

Regarding your hint with installing the latest patches I wanted to ask what is the latest 7.5 version and where to get it ?

In the sdn download area there's only MaxDB starting with 7.6 and download sites from mysql offers only 7.5.0.38 as 64bit-rpm packages...

regards...GERD...

BTW: our .knl-file has a size of > 35MB and the DBM-Gui cannot display it Is it possible to modifiy this file in an editor (remove entries), since it's only plain ascii...?

[lbreddemann]

we're using an external tool to create the autologs (called DBShadow). We configured it to run every 10min.

> In the knldiag files there's no entry with exception or failure of writing logs.

> The entries in the backup history look "normal", looks like the autolog has been written..?!?!

Indeed - looks like the saving of the log data worked as expected.

This leads me to the assumption that something went wrong with marking the backed up log segments as overwriteable.

That's why I pointed you to the KNLDIAG file.

> Regarding your hint with installing the latest patches I wanted to ask what is the latest 7.5 version and where to get it ?

The most current patches are only available to SAP customers.

So you may think about moving to a more current release (7.6/7.7) soon.

> In the sdn download area there's only MaxDB starting with 7.6 and download sites from mysql offers only 7.5.0.38 as 64bit-rpm packages...

> BTW: our .knl-file has a size of > 35MB and the DBM-Gui cannot display it Is it possible to modifiy this file in an editor (remove entries), since it's only plain ascii...?

Sure you can edit it.

I've written a SAP note on that... #1089402

Since this d**n forum software is still not able to handle some more lines properliy, I copied the note contents to a WIKI article: http://wiki.sdn.sap.com/wiki/display/MaxDB/HowTo-ShortenthebackuphistoryforMaxDB+instances

With that you should be able to shorten the backup history properly.

regards,

Lars

[Former Member]

Hi Lars,

thanks for your support.

Currently I see now strategy to check for the source of this problem, since there are no entries in the log files and the misbehaviour isn't reproducable.

Probably the next step will be upgrading to 7.6

regards...GERD...