We are on DB2 8.1 FixPack 3 and getting "DIA8309C Log file was full"
during testing. I understand long running updates/inserts without
commit or rollback can cause this issue. But ..

1)Can a long running transaction with only SELECT statements cause the
Log to become full? Do we need to commit SELECT statements? The
transaction has many SELECT statements and can last for days without
doing a commit. All SELECTs have 'for read only' clause except one.

2)Can a transaction that calls Stored Procedures with "CURSOR WITH
RETURN TO CLIENT" cause Log to become full? The procedure returns the
results of SELECT statement done with 'for read only' clause.

Thanks for the help.
-Jane

Jane wrote:
[color=blue]
>We are on DB2 8.1 FixPack 3 and getting "DIA8309C Log file was full"
>during testing. I understand long running updates/inserts without
>commit or rollback can cause this issue. But ..
>
>1)Can a long running transaction with only SELECT statements cause the
>Log to become full? Do we need to commit SELECT statements? The
>transaction has many SELECT statements and can last for days without
>doing a commit. All SELECTs have 'for read only' clause except one.
>[/color]

Yes, select statements can issue row locks.
Try to use the UR (dirty read) isolation level.
[color=blue]
>
>2)Can a transaction that calls Stored Procedures with "CURSOR WITH
>RETURN TO CLIENT" cause Log to become full? The procedure returns the
>results of SELECT statement done with 'for read only' clause.
>[/color]

Same as 1.
[color=blue]
>
>Thanks for the help.
>-Jane
>
>[/color]

--
Anton Versteeg
IBM Certified DB2 Specialist
IBM Netherlands