Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
former_member184549
Participant

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.

1 Comment