View previous topic :: View next topic |
Author |
Message |
Sarangadhar Beginner
Joined: 14 Oct 2004 Posts: 130 Topics: 43 Location: virtual village
|
Posted: Mon Nov 19, 2007 4:50 pm Post subject: INTERMEDIATE COMMIT in spufi for a query |
|
|
hi,
I am trying to execute some INSERTS/UPDATES on a table from a spufi. Since there are nearly million rows, and there is not COMMIT in between, the query fails saying "Unsuccessful execution caused by an unavailable resource". I guess this is because of no COMMIT in between.
Any way to commit in Spufi or QMF in a query, after some number of rows specified? _________________ Thanks |
|
Back to top |
|
 |
CZerfas Intermediate
Joined: 31 Jan 2003 Posts: 211 Topics: 8
|
Posted: Tue Nov 20, 2007 3:56 am Post subject: |
|
|
Your guess might not be true!! Why don't you post us the error message including the name and type of the unavailable ressoure?
A missing commit could harm all other processes in DB2, but not yours.
regards
Christian |
|
Back to top |
|
 |
Sarangadhar Beginner
Joined: 14 Oct 2004 Posts: 130 Topics: 43 Location: virtual village
|
Posted: Tue Nov 20, 2007 1:08 pm Post subject: |
|
|
I feel it right because when I tried to do for whole table, it failed. Then I did for first couple of members by giving a range in where caluse and it worked. Hence I thought of doing it by range. However, I have a member where mroe than 10K are present. This time it is failing again with same message. Hence, this should be because of intermediate commit.
here is the entire error message:
Code: | DSNT408I SQLCODE = -904, ERROR: UNSUCCESSFUL EXECUTION CAUSED BY AN
UNAVAILABLE RESOURCE. REASON 00C90096, TYPE OF RESOURCE 00000302, AND
RESOURCE NAME D6744DBT.TS674401.X'00000002'
DSNT418I SQLSTATE = 57011 SQLSTATE RETURN CODE
DSNT415I SQLERRP = DSNXRRC SQL PROCEDURE DETECTING ERROR
DSNT416I SQLERRD = 102 13172746 0 13813475 -1010298874 1073741824 SQL
DIAGNOSTIC INFORMATION
DSNT416I SQLERRD = X'00000066' X'00C9000A' X'00000000' X'00D2C6E3'
X'C3C81006' X'40000000' SQL DIAGNOSTIC INFORMATION |
_________________ Thanks |
|
Back to top |
|
 |
jsharon1248 Intermediate
Joined: 08 Aug 2007 Posts: 291 Topics: 2 Location: Chicago
|
Posted: Tue Nov 20, 2007 4:26 pm Post subject: |
|
|
You're exceeding the max number of locks allowed at your installation. Your first option is to split the SQL further. I hesitate to suggest the next option, but you could LOCK the table. Probably not that great of an idea, but it is an option. I'd work with the first option if at all possible.
One more thought. I assume you're using an INSERT with a SELECT. If you're not already doing it, try changing the isolation level on the SELECT. The default is RR which will hold locks on the SELECT table name much longer than RS and CS.
Code: |
INSERT INTO insert_tbl_nm
(<column list>)
SELECT <column list>
FROM select_tbl_nm
WHERE <predicates>
WITH CS
|
|
|
Back to top |
|
 |
Sarangadhar Beginner
Joined: 14 Oct 2004 Posts: 130 Topics: 43 Location: virtual village
|
|
Back to top |
|
 |
Sarangadhar Beginner
Joined: 14 Oct 2004 Posts: 130 Topics: 43 Location: virtual village
|
Posted: Tue Nov 20, 2007 6:13 pm Post subject: |
|
|
This si the query: Please ignore the previous post. i think it is unnecessary to look at the other post..
UPDATE TAB2 B
SET IND = (
SELECT A.IND FROM TAB1 A
WHERE A.SNUM = B.SNUM
) _________________ Thanks |
|
Back to top |
|
 |
jsharon1248 Intermediate
Joined: 08 Aug 2007 Posts: 291 Topics: 2 Location: Chicago
|
Posted: Wed Nov 21, 2007 9:08 am Post subject: |
|
|
If you haven't changed the default isolation level for SPUFI, you should try that. Use option 5, Change Defaults, and then change the Isolation Level to CS. The default is RR which holds more locks longer than CS.
If that doesn't resolve the problem, add a WHERE clause for TAB2.
One quick question. Is the D6744DBT.TS674401 tablespace the source or the target? |
|
Back to top |
|
 |
Sarangadhar Beginner
Joined: 14 Oct 2004 Posts: 130 Topics: 43 Location: virtual village
|
Posted: Fri Nov 30, 2007 5:39 pm Post subject: |
|
|
Jsharon,
its already CS, not RR.
I tried using predicates in TAB2 to the lowest level possible; still there are more rows for a lowest level predicate. Hence getting the same problem. (the lowest predicate results 10K rows)
and D6744DBT.TS674401 is the source table's tablespace. Now I wonder why should I get the problem with source table. Any idea? I am just reading that table. _________________ Thanks |
|
Back to top |
|
 |
jsharon1248 Intermediate
Joined: 08 Aug 2007 Posts: 291 Topics: 2 Location: Chicago
|
Posted: Mon Dec 03, 2007 4:20 pm Post subject: |
|
|
I wouldn't expect that updating 10K rows would trigger this error. You're more likely to get the 00C90096 error on the source table when using isolation RS and RR because the locks are held for the duration of the UPDATE. I'd check one more time that you're using CS.
If you can utilize the LOCK TABLE on the target, that will reduce the total number of locks and might get you through this.
Just a thought at large. I don't think I would recommend using SPUFI to update over 1 million rows. The time you're spending trying to get SPUFI to complete this task is probably more than just coding this in a procedural language using a cursor. If it's an existing process, it has grown large enough that the design should be re-evaluated. |
|
Back to top |
|
 |
|
|