Skip to Content
Author's profile photo Jonathan Groll

Max DB log is full – SAP NW 2004S TestDrive for Linux

A short while back I downloaded and installed the SAP NetWeaver 2004S TestDrive SAP system (running on my Atom! machine at home). This provided me with my own (90-day licensed) basic SAP R/3 system which, according to the documentation, includes both ABAP and Java stacks running on SAP’s own database Max DB.

One of the issues that this system is prone to is that the Max DB log gets full (there is no default log cycling). It is quite a well known issue and is even described on the SAP on Linux: Test Drives – Tips and Tricks FAQ . In my case, I encountered this issue after running an SGEN job to generate all the basis components on the system. I could log into the SAP system, but the GUI froze before anything useful came up. Trying to run stopsap, it hung forever at the checking database step (where it runs R3trans -d).

Looking in knldiag, I knew I had a full log problem because of this message:

2009-07-17 10:38:54    21 WNG 20001 KernelDB  99 percent of log area occupied, 126717 pages used

What one should do in this case is use one of the database management tools (either dbmgui or dbmcli) to clear the log area. However, no matter which “database owner” username and password I tried, I could not gain access to administer the database, and others LOG FULL and dbmcli userid/password . In other words, I was trying something like this:

dbmcli -u some_username,some_password -d N4S util_execute set log auto overwrite on

but was receiving this error message:

Error! Connection failed to node (local) for database N4S: ERR_USRFAIL: User authorization failed

Luckily that LOG FULL and dbmcli userid/password described another means by which I could authenticate in order to perform database management.  Philip Kisloff mentioned that it is possible to connect using

dbmcli -U c

instead of

dbmcli -u some_username,some_password

(For the record, his method works for me when logged on as the n4sadm user, which did have a .XUSER.62 file in ~/
This .XUSER62 file was created by the TestDrive install script).

The log was cleared by issuing the following as n4sadm (originally obtained from this Re: MaxDB dbmcli db_online InconsistentLogInfoPage ):

dbmcli -U c -d N4S db_admin
dbmcli -U c -d N4S util_connect
dbmcli -U c -d N4S util_execute clear log
dbmcli -U c -d N4S db_online

These steps should be performed on a stopped SAP system. If you can’t stop the SAP system since stopsap will stall with a full log – then the first step of the above will take the database offline and will allow you to run stopsap to completion. BE AWARE that you’re deleting all log information – in my case I wasn’t too worried as I could just reinstall the testdrive system, but you must be warned that this could be risky.

To prevent future overflow of the log the following can be used:

dbmcli -U c -d N4S util_execute set log auto overwrite on

This is also not without risk. As SAP put it on this page

Please note: With this setting, the database will overwrite its logs circularly, so the database will be unable to recover, if the DATA volume crashed. When developing a lot with the TestDrive, doing a backup or increasing the LOG volume would be a better solution.

Assigned tags

      1 Comment
      You must be Logged on to comment or reply to a post.
      Author's profile photo Melanie Handreck
      Melanie Handreck
      Hello Jonathan,

      I'd like to propose the usage of the autosave log feature. In that case log backups are generated automatically and the log volume won't run full.
      In case of a test server you could also activate the autooverwrite feature, as you probably don't need to be able to restore the database to the latest point in time.
      You could also just set it temporarily to autooverwrite while you are running such load/generating jobs...

      Running into a log full situation (which - by the way - normally is solved by creating a log backup!) and clearing the log is definetly not the only option you have. This should be a very rare exception!

      Best regards, Melanie