Results 1 to 6 of 6
  1. #1
    Join Date
    Sep 2004

    Unanswered: Help cant rollforward (missing log file)


    my db is in rollforward pending state and need a log file
    which we dont have, is there any way to force the db back up?


  2. #2
    Join Date
    Jun 2003
    Toronto, Canada
    Provided Answers: 1
    Cancel the current rollforward operation, then roll forward to a point in time _before_ the missing log.
    "It does not work" is not a valid problem statement.

  3. #3
    Join Date
    Jan 2003
    Provided Answers: 5
    Not that I can think of.


  4. #4
    Join Date
    May 2003
    Try using the NO RETRIEVE option on the rollforward and rollforward to the minimum time possible. To find the minimum time possible, rollforward to 1950-01-01... and DB2 will tell you the minimum time possible.

    The above suggestion assumes you have at least one log file available, but maybe not the one that DB2 is asking for.
    M. A. Feldman
    IBM Certified DBA on DB2 for Linux, UNIX, and Windows
    IBM Certified DBA on DB2 for z/OS and OS/390

  5. #5
    Join Date
    Sep 2004
    Thanks for the reply, ive tried your solutions and still was not able to restore the db, i'm trying to figure out why the log files are missing and found in the db2diag.log the following:

    2009-01-01- I624799665G476 LEVEL: Error
    PID : 30541 TID : 3086431936 PROC : db2agent (idle)
    INSTANCE: db2inst NODE : 000 DB : GLUE
    APPHDL : 0-390 APPID: *LOCAL.db2inst.090114011302
    FUNCTION: DB2 UDB, data protection, sqlpPreForceLogArchive, probe:430
    RETCODE : ZRC=0x85100009=-2062548983=SQLP_NOSPACE
    "Log File has reached its saturation point"
    DIA8309C Log file was full.

    2009-01-01- I624802778G395 LEVEL: Error
    PID : 748 TID : 3086431936 PROC : db2loggw (RESEARCH)
    INSTANCE: db2inst NODE : 000 DB : RESEARCH
    FUNCTION: DB2 UDB, data protection, sqlpgasn2, probe:2950
    "Loggw cannot find log file, need loggr to recreate it"

    2009-01-01- I624806574G459 LEVEL: Error
    PID : 22822 TID : 2865757088 PROC : db2hmon
    INSTANCE: db2inst NODE : 000
    APPID : *LOCAL.db2inst.090114023813
    FUNCTION: DB2 UDB, Automatic Table Maintenance, AtmTable::update_record, probe:230
    DATA #1 : <preformatted>
    AutoStats: [IBM][CLI Driver][DB2/LINUX] SQL0964C The transaction log for the database is full. SQLSTATE=57011[/COLOR]

    IS it possible that the log file was never generated ?
    any idea of other possible solutions?


  6. #6
    Join Date
    Oct 2008

    some guidence

    some points about your error messages...

    C:\Documents and Settings\Administrator>db2diag -rc -2062548983

    Input ZRC string '-2062548983' parsed as 0x85100009 (-2062548983).

    ZRC value to map: 0x85100009 (-2062548983)
    V7 Equivalent ZRC value: 0xFFFFD509 (-10999)

    ZRC class :
    Resource Capacity Error (Class Index: 5)
    SQLP ; data protection services (Component Index: 16)
    Reason Code:
    9 (0x0009)

    Identifer (without component):

    Log File has reached its saturation point

    Associated information:
    Sqlcode -964
    SQL0964C The transaction log for the database is full.

    Number of sqlca tokens : 0
    Diaglog message number: 8309

    C:\Documents and Settings\Administrator>db2 ? SQL0964C

    SQL0964C The transaction log for the database is full.


    All space in the transaction log is being used.

    If a circular log with secondary log files is being used, an attempt has
    been made to allocate and use them. When the file system has no more
    space, secondary logs cannot be used.

    If an archive log is used, then the file system has not provided space
    to contain a new log file.

    The statement cannot be processed.

    User response:

    Execute a COMMIT or ROLLBACK on receipt of this message (SQLCODE) or
    retry the operation.

    If the database is being updated by concurrent applications, retry the
    operation. Log space may be freed up when another application finishes a

    Issue more frequent commit operations. If your transactions are not
    committed, log space may be freed up when the transactions are
    committed. When designing an application, consider when to commit the
    update transactions to prevent a log full condition.

    If deadlocks are occurring, check for them more frequently. This can be
    done by decreasing the database configuration parameter DLCHKTIME. This
    will cause deadlocks to be detected and resolved sooner (by ROLLBACK)
    which will then free log space.

    If the condition occurs often, increase the database configuration
    parameter to allow a larger log file. A larger log file requires more
    space but reduces the need for applications to retry the operation.
    Transaction configuration parameters which may need to be adjusted are
    LOGFILSIZ, LOGPRIMARY, LOGSECOND. For more information about the
    transaction log search the DB2 Information Center using phrases such as
    "transaction log".

    If installing the sample database, drop it and install the sample
    database again.

    sqlcode: -964

    sqlstate: 57011


    IS it possible that the log file was never generated ?
    any idea of other possible solutions?
    I would advise you to try contacting db2support and check with them.
    Last edited by eldho_mathewk; 01-07-09 at 12:27.

Posting Permissions

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