I have a table that stores Order data (master) and its associated data is stored in various other DB2 tables. I have a need to download all this data -- from 15 different tables -- every morning through a COBOL program with a lot of cursors and SELECT statements of various types in flat files and FTP them to the another server so that it can be loaded into the SQL Server on a Windows machine.
To make the data processing faster, I am proposing 10 parallel jobs so that each one is pulling data for a range of orders. The data files are combined together and sent to the other server later through a JCL. The Order table is not partitioned as of now -- can be based on the need though -- but some of the associated tables are partitioned into 10 partitions.
The question raised by the architects on the customer side is that by running 10 parallel jobs on a non-partitioned table it may not be of any help because they all are hitting the same table/partition. My opinion on this is different. I feel that we can take advantage of parallel processing through multiple jobs with this approach.
I would like your opinion on this. Can we take advantage of parallel processing even if the DB2 table is not partitioned? Should I do something else to ensure this? The requirement is only to read the DB2 tables. No updates.
You should be able to reduce the overall elapsed time by running multiple jobs in parallel against the data even if the table spaces are not partitioned. You may get some minor read contention in the jobs when they need to access data on the same page, but I would guess that the impact should not be too major.
My advice to you is to mock up your job and test it out.
Editor's note: Do you agree with this expert's response? If you have more to share, post it in one of our
Dig Deeper on IBM DB2 management
To export data from a DB2 table to a flat file, you need to run an export specifying the proper file format. The export utility exports data from a ...
Craig Mullins recommends two specific resources for learning how to create and support Binary Large Objects (BLOB) in DB2.
Craig Mullins explains various definitions of a data mart and sheds some light on the complexity of its relation to a data warehouse.