As you probably know, APM v8.1.x uses DB2 as database server for WAREHOUS, SCR and DATAMART databases.
In a production environment, performing backups for those database is a mandatory task if you want to effectively recover after a serious problem or a DB corruption.
APM provides a script, backup.sh, that can be executed to perform an online or an offline backup.
It tries to perform an online backup first, but if DB2 is not configured for it, then it performs an offline backup.
By default, the APM DB2 databases are not configured for online backup.
You can find more information in the APM manual:
What is the difference between online and offline backup ?
Basically, with offline backup, all the applications accessing the database must be stopped, otherwise the backup cannot take place.
Using online backup instead, you don't need to stop the applications. So in our case, if you enable DB2 for online backup, you can perform a backup
without stopping APM.
This can be done because during an online backup, all activities against the database are logged.
After an online backup is complete, the database manager forces the currently active log to close, and as a result, the log is archived.
In this way, we can be sure that the online backup has a complete set of archived logs available for recovery.
In order to activate online backup you basically needs to enable DB2 archive logging.
APM manual explains how this can be done:
This is instead a link from DB2 documentation where you can find additional information about archive logging
At least looking the above information, online backup seems to be a very good feature and it should be seriously considered.
There is anyway something you need to know about archive logging.
The path specified with keyword LOGARCHMETH1 is the location where the archive log file will be stored.
When archive logging is active, all transaction are logged; when you run online backup it will generate new logs, older logs are archived and new active logs are created.
So the space allocated in this file system will quickly grow.
For this reason, if you decide to activate archive logging you must carefully plan how much space you need for it, depending on the growth rate observed for a specified interval.
Possibly you should use a file system with plenty of space and avoid to use the same file system used by APM itself.
In order to know how to better manage this feature, I contacted a DB2 colleague and made two questions on this matter.
Question 1: We noticed that the space allocated for archive logging quickly grows. Considering that I do not expect the space to grow indefinitely, when are the older data pruned ?
Is the pruning associated with parameter REC_HIS_RETENTN and AUTO_DEL_REC_OBJ ?
Answer 1: yes, it depends ALSO on AUTO_DEL_REC_OBJ.
There are a couple of scenarios to be considered:
1) set "db2 update db cfg using AUTO_DEL_REC_OBJ ON" for the database you are connected to.
This will allow you to use the history file to prune unneeded backups and archive logs.
You can use "db2 prune history <timestamp> [with force option]" to delete to remove unneeded backups.
Running the command:
db2 prune logfile prior to <log file name>
will instead delete unneeded archived logs.
2) set "db2 update db cfg using AUTO_DEL_REC_OBJ ON" for the database in question.
Then you can set "db2 update db cfg using NUM_DB_BACKUPS <number>".
This set the maximum number of backups you wish to retain for the period of REC_HIS_RETENTN days.
Now set "db2 update db cfg REC_HIS_RETENTN <number>" to the number of days.
If you set NUM_DB_BACKUPS to 3 and REC_HIS_RETENTN to 2, it will keep 3 backups for 2 days.
It means that a backup needs to be at least two days old before it will be consider for removal.
Once a backup is older than 2 days, it will check to see if there are more than 3 backups. If this is true, then it will remove the older backups.
If I decide to turn archive logging (and so online backup) off, in order to free the space used by log files, can I just delete manually the folders from ../logs
or do I need to run a specific command to remove the archive files and recover space for the file system ?
Answer 2: It is important to determine the current first active log file required for database crash recovery. In this example, log file 20 is the first active log.
$ db2 get db config for logarch | grep "First active log file"
First active log file = S0000020.LOG
But if you are not using archived logging, the logs can be removed after a backup offline
So if you have executed an offline backup successfully, the answer is yes, you can just delete them.
Hope this cam be helpful for you if you decide to turn online backup on for APM v8.1.x servers.
Subscribe and follow us for all the latest information directly on your social feeds: