SAP ASE does a bare minimum of rotating its text log files.
In this post I describe the main SAP ASE log files, and my recommendation for a rotation configuration on Linux (yay!) and Windows (here be dragons!).
What Needs to Be Rotated?
ASE database instance log: /sybase/<SID>/ASE-16_0/install/<SID>.log ASE backup server log: /sybase/<SID>/ASE-16_0/install/<SID>_BS.log ASE Job Server log: /sybase/<SID>/ASE-16_0/install/<SID>_JSAGENT.log I do not include the dumphist file, which (if dumphistory is enabled) gets backed up daily from /sybase/<SID>/ASE-16_0/dumphist to /sybase/<SID>/ASE-16_0/dumphist.nnnnnnnnn.
NOTE: For ASE instances with HADR installed (a.k.a SAP Replication Server) there are also an additional 4 log files which should be rotated, that I won’t go into in this post. (Hire me, and I’ll tell you).
What Happens When ASE Rotates Those Logs?
When the ASE instance is restarted, some of the above standard logs are rotated and some are cleared down. For the ones that are rotated, there is no end to the rotation, they keep building up. They are never removed.
As part of your log rotation solution, you should also rotate the ASE rotated logs, making sure that they don’t build up over the years of ASE instance restarts (especially if starting/stopping systems frequently in The Cloud).
This is what happens to the auto-rotated logs:
<SID>.log is moved to <SID>.log.nnnnnnnn_nnnnnn <SID>_BS.log is cleared down. <SID>_JSAGENT.log is cleared down. We can see that for those log files that are cleared down, a daily rotation should capture them, but it will be hit and miss. If the ASE instance is restarted part way through the day, then the morning logs will not have been preserved (unless you remember to manually run your log rotation). There’s not much we can do about this.
For the log that is auto-rotated by ASE (on restart), then we also need to capture that in our rotation schedule. We have a choice to maybe just compress it and only retain a specific number.
What Log Retention Works Best?
For production systems, I usually say 30 rotations is ideal (1 month).
Rotation Schedule
With tools like logrotate, you can decide to rotate logs on a time basis, or even on a size basis.
Since SAP ASE automatically rotates the <SID>.log file on instance restart, it would get a bit messy if we also have a daily rotation on top of this.
We’ve already mentioned that the ASE backup server log is quite important for helping us to understand when backups were taken and any issues during that backup. This is the reason we rotate this file daily, no matter what size it is.
The ASE job server is a little less critical, so we really don’t need it rotated every day. However it can grow quite big if the job server experiences a database space issue. So instead we can choose to rotate on size.
With the above in mind, this is what I would recommend for the ASE log files:
<SID>.log rotated on size >5MB with 30 rotations. <SID>_BS.log rotated daily with 30 rotations. <SID>_JSAGENT.log rotated on size>5MB with 30 rotations. For ASE rotated copies of <SID>.log (called <SID>.log.nnnnnnnn_nnnnnn), it’s best to retain something like 10 rotations for production systems.
Log File Truncation
During the rotation process, you have an option to keep the existing log file or truncate it. My preference is to truncate the original log file, to prevent the log from growing.
The exception to this rule is obviously the ASE auto-rotated copies of the <SID>.log. We don’t want to be truncating that at all.
Log File Compression
After the copy of the logs has been taken, the copy can then be compressed. This makes complete sense, because text files (these are ASCII text logs) compress really, really well. You should expect ~90% compression ratios.
Just make sure that you chose a compression tool/utility that has an easy method to access the compressed contents.
For example, in Linux I can use gzip. Then if I need to scan the log for a particular error I can use zcat and pipe through grep to check the contents (like this: “zcat <theGZlog>|grep error”).
On Windows, I would need to use PowerShell to stream the zipped contents and pattern match. So a script or a separate utility would be needed to help with this.
Log Copy Naming
Once the log file has been copied to a new file and compressed, the name of the copied log file should be appended with the date time stamp.
The exception to this rule is the ASE auto-rotated copies of <SID>.log.
Sample Log Rotation Config
Here’s a sample logrotate configuration file that includes all that we have mentioned above.
The call to logrotate looks like this: logrotate –state <state-file> <config-file>
# logrotate configuration file.
# This file defines the config for which logrotate uses.
################################################
# The global defaults are established first.
# compress all files using default gzip -9.
compress
# Dont rotate it if its empty.
notifempty
# Ignore if missing.
missingok
# Add date as extension instead of just a number.
dateext
################################################
# Each section below is specific to a log file match.
# The contents of the section can override the global defaults.
#
# The ASE dataserver log.
/sybase/[A-Z][0-9][A-Z]/ASE-[0-9][0-9]*/install/[A-Z][0-9][A-Z].log {
# Truncate the original log once rotated.
copytruncate
# Permit 30 rotations.
rotate 30
# Rotate the file based on size.
size 5M
}
#
# The auto-rotated ASE dataserver log after a restart of ASE.
/sybase/[A-Z][0-9][A-Z]/ASE-[0-9][0-9]*/install/[A-Z][0-9][A-Z].log.[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]_[0-9][0-9][0-9][0-9][0-9][0-9] {
# We just zip this file.
# We dont truncate it.
nocopytruncate
# We dont copy it.
nocopy
# We dont add the date on the end, its already there.
nodateext
# Check daily for these files.
daily
# Permit 10 rotations = 10 restarts of ASE.
rotate 10
}
#
# The ASE backup server log.
/sybase/[A-Z][0-9][A-Z]/ASE-[0-9][0-9]*/install/*_BS.log {
# Truncate the original log once rotated.
copytruncate
# Permit 30 rotations.
rotate 30
# Rotate the file daily.
daily
}
#
# The ASE jsagent server log.
/sybase/[A-Z][0-9][A-Z]/ASE-[0-9][0-9]*/install/*_JSAGENT.log {
# Truncate the original log once rotated.
copytruncate
# Permit 30 rotations.
rotate 30
# Rotate the file based on size.
size 5M
}
The above is just the start.
Executing File Removal
In the logrotate configuration file, in every log rotation file block, it is possible to include a script block that gets executed every time a successful file rotation is performed.rm $1.[0-9][0-9][0-9] ” would actually remove the file passed in as “$1” (somefile.ext) plus anything that it finds that matches pattern “.[0-9][0-9][0-9]”. Quite problematic and dangerous.
Rotation Fun with Windows
Contrary to the header, it’s not fun to try and rotate logs on Windows.
Windows locks files and can cause issues with log file truncation unless you use a utility able to handle this (LogRotateWin can). There is no built-in log rotation utility on Windows. If you have a heterogeneous landscape you generally do not want to be maintaining too many different tools and configurations.
Not fun, but it works and it means I only have 1 configuration file I need to worry about.
Summary:
A good log rotation strategy for SAP ASE databases is important to maintain the ASE text log files effectively.
Maintaining a consistent approach across heterogeneous landscapes is not easy, and may require you to be creative in your method.
As part of the ASE log rotation configuration, you should also look to include the dumphist file and also the HADR log files (from SRS and RMA).
A final comment: In some cases, I’ve witnessed an ASE system error which has caused thousands of retries to execute “sp_configure” which caused thousands of versions of the <SID>.cfg file to be created. So many, that it took multiple executions of “rm” to remove them.
You may also be interested in:
