Results 1 to 5 of 5
  1. #1
    Join Date
    Feb 2009
    Posts
    24

    Unanswered: DB2 rc 28 failure during a load test

    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:

    HTML Code:
    ********************************************************************************
    Time of Error:     
    
    ...
    Logfile path:      ...
    Node number:       NODE0000
    Operating system:  AIX64BIT
    Release:           SQL08029
    Request:           ARCHIVE
    Audit Log File:    .../ARCHIVE.LOG
    System Call Parms: rm -f ..../NODE0000/S0000xxx.LOG
    Media Type:        disk
    User Exit RC:      28
    
    > Error isolation: Error archiving file.  Return code 256 received from the system call
    Audit Log File ARCHIVE.LOG reports:

    HTML Code:
    ********************************************************************************
    Time Started:      Wed Mar 11 ...
    
    Parameter Count:      8
    Parameters Passed:
    Database name:     ...
    Logfile name:      S0000xxx.LOG
    Logfile path:      .../NODE0000/SQL00001/SQLOGDIR/
    Node number:       NODE0000
    Operating system:  AIX64BIT
    Release:           SQL08029
    Request:           ARCHIVE
    System Action:     ARCHIVE from ..../NODE0000/SQL00001/SQLOGDIR/ file S0000xxx.LOG to ...
    Media Type:        disk
    User Exit RC:      28            |||> ERROR <|||
    Time Completed:    Wed Mar 11 ...
    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.

    HTML Code:
    $ db2level
    DB21085I  Instance "za7d1006" uses "64" bits and DB2 code release "SQL08029" with level identifier "030A0106".
    Informational tokens are "DB2 v8.1.1.144", "s080111", "U811269", and FixPak
    "16".

    Thank you,

  2. #2
    Join Date
    Jun 2003
    Location
    Toronto, Canada
    Posts
    5,516
    Provided Answers: 1
    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.
    ---
    "It does not work" is not a valid problem statement.

  3. #3
    Join Date
    Feb 2009
    Posts
    24
    Quote Originally Posted by n_i
    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.
    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?


    Quote Originally Posted by n_i
    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.
    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,
    Last edited by heartwork93; 03-12-09 at 13:08.

  4. #4
    Join Date
    Jun 2003
    Location
    Toronto, Canada
    Posts
    5,516
    Provided Answers: 1
    Quote Originally Posted by heartwork93
    Anyway how do you suggest to monitor the load tets from the DB2 perspective?
    I would start with periodic snapshots.


    Quote Originally Posted by heartwork93
    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?
    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.
    ---
    "It does not work" is not a valid problem statement.

  5. #5
    Join Date
    Feb 2009
    Posts
    24
    Quote Originally Posted by n_i
    I would start with periodic snapshots.
    This is what I have done - get snapshots on dynamic sql and locks for time-outs.



    Quote Originally Posted by n_i
    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.

    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,

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •