The following steps reproduce the problem (must be done on a
non-catalog node):
CONNECT TO TEST
CREATE USER TEMPORARY TABLESPACE SYSTOOLSTMPSPACE IN IBMCATGROUP
MANAGED BY AUTOMATIC STORAGE EXTENTSIZE 4
DECLARE GLOBAL TEMPORARY TABLE SESSION.TEMP_EMP (EMPNO CHAR(6)
NOT NULL, SALARY DECIMAL(9, 2), BONUS DECIMAL(9, 2), COMM
DECIMAL(9, 2)) WITH REPLACE ON COMMIT PRESERVE ROWS
INSERT INTO SESSION.TEMP_EMP VALUES ('123456', 20.00, 10.00,
5.00)
DROP TABLE SESSION.TEMP_EMP
==> produces SQL0964C The transaction log for the database is
full. SQLSTATE=57011
DROP TABLE SESSION.TEMP_EMP
DECLARE GLOBAL TEMPORARY TABLE SESSION.TEMP_EMP (EMPNO CHAR(6)
NOT NULL, SALARY DECIMAL(9, 2), BONUS DECIMAL(9, 2), COMM
DECIMAL(9, 2)) WITH REPLACE ON COMMIT PRESERVE ROWS
INSERT INTO SESSION.TEMP_EMP VALUES ('123456', 20.00, 10.00,
5.00)
==> produces SQL0901N The SQL statement failed because of a
non-severe system error. Subsequent SQL statements can be
processed. (Reason "sqlrl_userTempIUD: tid/fid not found".)
SQLSTATE=58004
CONNECT RESET
On a non-catalog node, when the logs are full db2 responds with
SQL0964C on the first DROP TABLE. Even though the DROP TABLE
failed, the first INSERT still remains in the APM cache as
valid. On the
second INSERT, db2 tries to use the first INSERT's tid/fid, thus
resulting in the -901.
On the catalog node, both DROP TABLE statements fail with
SQL0964C. |
