Hi,

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?

Thanks,

Cancel the current rollforward operation, then roll forward to a point in time _before_ the missing log.

Not that I can think of.

Andy

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.

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-00.05.31.886672-300 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-00.14.01.138575-300 I624802778G395 LEVEL: Error
PID : 748 TID : 3086431936 PROC : db2loggw (RESEARCH)
INSTANCE: db2inst NODE : 000 DB : RESEARCH
FUNCTION: DB2 UDB, data protection, sqlpgasn2, probe:2950
RETCODE : ZRC=0x871000E8=-2028994328=SQLPG_LOGR_RECREATE_LOGFILE
"Loggw cannot find log file, need loggr to recreate it"

2009-01-01-00.59.03.208346-300 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
MESSAGE : ZRC=0xFFFFFC3C=-964
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?

Thanks,

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)
Component:
SQLP ; data protection services (Component Index: 16)
Reason Code:
9 (0x0009)

Identifer:
SQLP_NOSPACE
Identifer (without component):
SQLZ_RC_NOSPAC

Description:
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.

Explanation:

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
transaction.

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 ?
nope..
any idea of other possible solutions?
I would advise you to try contacting db2support and check with them.