Joined: 19 Oct 2004 Posts: 13 Topics: 4 Location: Atlanta
Posted: Thu Apr 10, 2008 2:34 pm Post subject: Platinum Performance issue for unloading
When I use platinum unload batch utility to unload a single DB2 table, it works great. But when I use this unload by joining two (2) DB2 tables, it runs for a long time and eventually I have to kill the job. Only change I have to make is from "SQL ACCESS NONE" to "SQL ACCESS ONLY". Is there anyway to unload effeciently by joing two tables? Do I have to make any changes to these parameters?
These two tables have 4-6 millions records each.
Here is the platinum unload card I am using:
Code:
FASTUNLOAD
DISCARDS 100
DISPLAY-STATUS 1000000
INPUT-FORMAT TABLE
IO-BUFFERS 50
LIMIT 0
OUTPUT-FORMAT DSNTIAUL
SHRLEVEL CHANGE
SORTFLAG ALL
SORTSIZE 4M
SORTNUM 3
ESTIMATED-ROWS 40000000
SQL-ACCESS ONLY <-----SQL -ACCESS NONE for single table unload
SELECT
A.DIVN_NBR,
A.PROD_DIM_ID,
A.BASIC_STOCK_FLG,
B.OWNED_RETAIL
INTO
DIVN_NBR
INTEGER ,
PROD_DIM_ID
DECIMAL ,
BASIC_STOCK_FLG
CHAR( 01),
OWNED_RETAIL
DECIMAL( 11,2)
FROM
PRD.TABLE1 A
INNER JOIN
PRD.TABLE2 B
ON A.PROD_DIM_ID = B.PROD_DIM_ID
AND A.DIVN_NBR = B.PRICE_LOC_NBR
WHERE A.DIVN_NBR = 25
AND A.SKU_UPC_NBR = 0
AND A.PROD_END_TS = '3000-01-01-00.00.00.000000'
AND A.ZL_STAT_NBR NOT IN (0,5)
AND B.ZL_STAT_NBR NOT IN (0,5)
AND A.PROD_LEVEL_CD =
(CASE WHEN A.BASIC_STOCK_FLG = 'Y' THEN 'C' ELSE 'S' END )
;
Joined: 14 Nov 2003 Posts: 66 Topics: 0 Location: St Cloud, Minnesota USA
Posted: Thu Apr 10, 2008 6:12 pm Post subject:
Subho,
I would suggest that you unload each of the DB2 tables separately using SQL ACCESS NONE. then write a COBOL program to do the join by using file match logic. We do this quite regularly and it works very well. With 4 to 6 million rows I would guess that the unloads would finish in a couple of minutes each. The COBOL match program will probably run in about the same amount of time. The total time for the process should be 10 to 15 minutes depending on the availability of cpu resources.
to reduce the total elapsed time, the two tables could be unloaded in separate jobs which run in parallel. However, since the tables are quite small, its probably better to leave them in the same job.
good luck, _________________ Chuck Haatvedt
email --> clastnameatcharterdotnet
(replace lastname, at, dot with appropriate
characters)
Joined: 19 Oct 2004 Posts: 13 Topics: 4 Location: Atlanta
Posted: Fri Apr 11, 2008 2:38 pm Post subject:
Chuck,
Thanks for your suggestion. I have already thought (matter of fact, wrote the high level spec) in the same route if platinum join of two tables don't work efficiently. But I was wondering if there is a way to make this more efficient using Platinum, IBM or any other utilities. COBOL program will have very convoluted complex logic for match merge since it will have other WHERE clause criteria in this SQL which I have not mentioned for simplicity. It will definitely be less maintenance work if I use utility. In future, we may have to change the where clause depending on the business need. Then changing the COBOL program will be a nightmare!!
Joined: 14 Nov 2003 Posts: 66 Topics: 0 Location: St Cloud, Minnesota USA
Posted: Sun Apr 13, 2008 11:00 pm Post subject:
Subho,
each of the unloads could still specify the predicate restrictions as follows. Then after that the COBOL program will just be a simple match program.
This will be much faster than the DB2 join process. just test the two unload steps without the COBOL match program and see how fast the unloads are.
If Platinum complains about the use of the IN clause, just convert it into two NOT EQUAL clauses.
I'm between jobs right now so I can't run a check on the IN clause. And even if it doesn't like it, the IN clause will be easy to eliminate.
Code:
==== unload # 1
FASTUNLOAD
DISCARDS 100
DISPLAY-STATUS 1000000
INPUT-FORMAT TABLE
IO-BUFFERS 50
VSAM-BUFFERS 300
LIMIT 0
OUTPUT-FORMAT DSNTIAUL
SHRLEVEL CHANGE
SORTFLAG ALL
SORTSIZE 4M
SORTNUM 3
ESTIMATED-ROWS 40000000
SQL-ACCESS NONE <-----SQL -ACCESS NONE for single table unload
SELECT
A.PROD_DIM_ID,
A.DIVN_NBR,
A.PROD_DIM_ID,
A.BASIC_STOCK_FLG
FROM
PRD.TABLE1 A
WHERE A.DIVN_NBR = 25
AND A.SKU_UPC_NBR = 0
AND A.PROD_END_TS = '3000-01-01-00.00.00.000000'
AND A.ZL_STAT_NBR NOT IN (0,5)
AND (( A.PROD_LEVEL_CD = "C"
AND
A.BASIC_STOCK_FLG = 'Y' )
OR ( A.PROD_LEVEL_CD = "S"
AND
A.BASIC_STOCK_FLG <> 'Y' ) )
ORDER BY A.PROD_DIM_ID,
A.DIVN_NBR
;
==== unload # 2
FASTUNLOAD
DISCARDS 100
DISPLAY-STATUS 1000000
INPUT-FORMAT TABLE
IO-BUFFERS 50
VSAM-BUFFERS 300
LIMIT 0
OUTPUT-FORMAT DSNTIAUL
SHRLEVEL CHANGE
SORTFLAG ALL
SORTSIZE 4M
SORTNUM 3
ESTIMATED-ROWS 40000000
SQL-ACCESS NONE <-----SQL -ACCESS NONE for single table unload
SELECT
B.PROD_DIM_ID,
B.PRICE_LOC_NBR,
B.OWNED_RETAIL
FROM
PRD.TABLE2 B
WHERE B.PRICE_LOC_NBR = 25
AND B.ZL_STAT_NBR NOT IN (0,5)
ORDER BY B.PROD_DIM_ID,
B.PRICE_LOC_NBR
;
good luck....
ps.. Subho, would you please post the results when you have tested this.
thanks, _________________ Chuck Haatvedt
email --> clastnameatcharterdotnet
(replace lastname, at, dot with appropriate
characters)
Joined: 19 Oct 2004 Posts: 13 Topics: 4 Location: Atlanta
Posted: Mon Apr 14, 2008 10:52 am Post subject:
Chuck,
Thanks for your reply. Yes, I will go in this route if i don't find any alternative to get the result using platinum or any utility directly. Again, I have two main concerns here.
1. Performance (Looking for the utility, not the COBOL program way)
2. Maintenance (This is an extremely critical SQL for financial performance process, it changes very frequently and support staff may change over the time. All these things together, it would be better to make the entire process in a single utility job).
In your approach, we have solved the issue number 1 , but not the number 2. A fine tuned utility will solve both issues.
Is there any thought from anybody else. Kolusu, do you have any suggestion?
Joined: 14 Nov 2003 Posts: 66 Topics: 0 Location: St Cloud, Minnesota USA
Posted: Mon Apr 14, 2008 3:30 pm Post subject:
Subho,
the issue is that the utility will basically just execute the query as dynamic sql. If you do an explain on the query I suspect that it is doing a nested loop join. I'm not sure about that but the DB2 join is much more costly than a sequential file matching process.
good luck.
I would suggest that you do an explain on the SQL query. _________________ Chuck Haatvedt
email --> clastnameatcharterdotnet
(replace lastname, at, dot with appropriate
characters)
Joined: 19 Oct 2004 Posts: 13 Topics: 4 Location: Atlanta
Posted: Mon Apr 14, 2008 4:35 pm Post subject:
Chuck,
Unloading multiple tables and match merging in COBOL program is a standard practise which we do a lot in our shop. My point is to avoid this process and get the platinum working.
Any help will be appreciated if anybody knows a way to do this effectively using Platinum or IBM utility.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum