Hello,


During the execution of a load test for a WPS based application a lot of archive logs are created on DB2 server. I have several instances of DB2 set on userexit - logs are moved into another partition that becomes full 100% and then I got archiving logs error.
Soon after this it happened that the load test failed. WAS behind WPS (located on some other app server) reported the cause is due to a time out connection and a WAS transaction has to be rolled-back - the WAS logs are not relevant if indeed this is DB2 fault.
This is the error in my USEREXIT.ERR:

Audit Log File ARCHIVE.LOG reports:

However I have 2 questions to be clarified:

1. What can I do to see what is happening during the load test?
What do you suggest is better for me to monitor - to take db2 get snapshot from time to time or do you have a better idea - to see if indeed this is cause by archive log failure and what DB2 is doing during the test.
Anyway I need to establish a kind of monitoring and it would be helpfully for me.

2. I inherited this systems without any knowledge transition.
I have several DB2 servers each with about 3 to 10 instances each with one DB SMS, LOGARCHMETH1 is userexit and no partioned is used since db are small sized.
I found the path where db2uext2.c is located and I understand when some conditions are fullfilled the logs are moved from logfile path to another location/AIX partition - and there they are purged by a crontab script if they become old enough.
My problem is to understand in what conditions / when the logs are moved - if someone can help I will attach the db2uext2.c file here - I am not an expert in C.


Thank you,

1. DB2 does not crash, stop, or timeout if it fails to archive a log file. An error will be recorded in db2diag.log, and DB2 will periodically retry archiving while it continues operating. The reason for your application errors is elsewhere.

2. The userexit program is called by the database manager when one of the log files becomes inactive and therefore can be archived. In other words, the conditions for log archiving are external to the userexit routine.

This is what I have seen regarding archive logs in db2diag.log
Anyway how do you suggest to monitor the load tets from the DB2 perspective?


So these means that if you have configured 100 primary logs and 20 secondary logs the condition for log archiving is fullfilled when already you have 121 logs (120 active and 1 archival) in log path files and next logs are moved by userexit program.
It means that if DB2 is running for a while in the log file path you should have all the time 120 archive logs right?

Thanks a lot for your help,

I would start with periodic snapshots.


A log file can be archived when it does not contain data for any active transaction. The fact that you have configured 100 primary logs does not mean that all of them are active. However, if you reach the point where secondary logs are allocated that probably means that an active transaction spans all log files. All of them will be archived after the transaction completes. However, if a transaction requires more logs than you have configured (121 in your example) you will get a log full error, because none of the logs can be archived while they are active. Archived log files will be reused by DB2 for new transactions.

This is what I have done - get snapshots on dynamic sql and locks for time-outs.




So at any time you can have in the log path file (depending on how many active logs are needed) at most the maximum number of configured value but also you can have less and all the logs present are active logs.
As soon as a log become inactive immediately userexit program acts and archive the log according to that routine - in this case it moves the archived log from log file path into another directory/partition.
That directory/partition is specified in the routine db2uext2 right.
I just overview all this in order to have a clear picture of how userexit acts.

Thank you very much for your help,