Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12

Extract Speed from DB2 Expand / Collapse
Author
Message
Posted Wednesday, May 1, 2013 8:27 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Wednesday, November 19, 2014 9:27 AM
Points: 356, Visits: 1,981
Jeff Moden (4/29/2013)
I guess I'll ask a similar question on these thread. Is there any way to bulk export data from DB2 to a Tab delimited file? One of the "fixes" we made for previous large data/long haul problems (between like servers, though) was to do such an export and Fedex the table backup of the export. Compared to an 'over the line' transfer for the same amout of data, it was a lot faster.

I'd like to do the same thing locally but no one here (not even the AS400 guys) know how to export DB2 files (tables) to delimited files.


For an AS400, take a look at the CPYTOIMPF and CPYTOSTMF commands. They can copy to the integrated file system that's accessible from a PC. It's been a while since I used an AS400, but I was copying data to text and dbase files in 1996, and it was very fast. If the DB2 is the mainframe version, I have no clue as to how to export data.
Post #1448438
Posted Wednesday, May 1, 2013 10:56 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Monday, September 29, 2014 10:25 PM
Points: 254, Visits: 755
Another thing to consider, too, is do you have any sort of identifier or key in the DB2 source that could allow you to effectively break your source data into multiple sets/processes in your SSIS export package? If so, you could design your SSIS package(s) so that you can have multiple data flow tasks running concurrently, each with its own specific range of data to extract from the source, likely reducing the overall export time to your stage table.
Post #1448526
Posted Wednesday, May 1, 2013 11:06 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Yesterday @ 6:47 AM
Points: 25, Visits: 466
Thanks dg.
Actually, this is connected to a large warehouse staging SSIS process, we are pulling roughly 50 tables from the db2 source, and it already uses concurrency. We still need to find a way to reduce the extract times beyond this.
Post #1448529
Posted Wednesday, May 1, 2013 3:54 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 7:54 AM
Points: 35,587, Visits: 32,175
Ross McMicken (5/1/2013)
Jeff Moden (4/29/2013)
I guess I'll ask a similar question on these thread. Is there any way to bulk export data from DB2 to a Tab delimited file? One of the "fixes" we made for previous large data/long haul problems (between like servers, though) was to do such an export and Fedex the table backup of the export. Compared to an 'over the line' transfer for the same amout of data, it was a lot faster.

I'd like to do the same thing locally but no one here (not even the AS400 guys) know how to export DB2 files (tables) to delimited files.


For an AS400, take a look at the CPYTOIMPF and CPYTOSTMF commands. They can copy to the integrated file system that's accessible from a PC. It's been a while since I used an AS400, but I was copying data to text and dbase files in 1996, and it was very fast. If the DB2 is the mainframe version, I have no clue as to how to export data.


Thanks, Ross. I'll check it out.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1448637
Posted Wednesday, May 1, 2013 4:11 PM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Wednesday, November 19, 2014 9:27 AM
Points: 356, Visits: 1,981
Jeff, you should also check to see if the AS400 you need to extract from has any third party query tools on it, or Query/400. Those generally have th eability to save data to the area that's accessible from other computers.
Post #1448643
Posted Wednesday, May 1, 2013 5:24 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 7:54 AM
Points: 35,587, Visits: 32,175
Ross McMicken (5/1/2013)
Jeff, you should also check to see if the AS400 you need to extract from has any third party query tools on it, or Query/400. Those generally have th eability to save data to the area that's accessible from other computers.


Thanks, Ross. I already checked with the AS400 guys and they said they used to have one but didn't see the utility in it so they got rid of it and never renewed the license. Guess I'll have to hit Google a little harder and see if I can come up with a free tool because they don't want to spend any money on it even if it were to turn a memory sucking, CPU burning, network churning 4+ job into a 10 or 15 minute breath of fresh air.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1448649
Posted Wednesday, May 1, 2013 11:08 PM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: 2 days ago @ 5:45 PM
Points: 179, Visits: 589
In my past experience (admittedly with an old AS/400 version and a dysfunctional IT team), the only reliable way to get data out of an AS400 was to use one of the supplied AS/400 windows client tools to dump it down to a text file and then load the text file into SQL Server. This was quite some time ago - some technical aspects may have changed since then.
Post #1448688
Posted Thursday, May 2, 2013 8:58 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Wednesday, November 19, 2014 9:27 AM
Points: 356, Visits: 1,981
Jeff, the IBM documentation is very good. You can find it at http://publib.boulder.ibm.com/iseries/

The copy commands I mentioned earlier are built in to the AS400, and cna be scheduled if your AS400 guys write a short CL program to extract the data you want. CL is just a batch file with commands in it.

You can also ftp data, but there's no translation of the IBM packed decimal format of numbers into something that is usable in SQL server. It's not hard to write a translator for that, and ftp is very fast.

I feel your pain on losing tools. I had a senior IT manager ask me why anyone would want to get data out of the system. "If they need data, they should have a report written". He had no clue as to how the system was used, he jsut wanted to cut costs, no matter the impact.
Post #1448843
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse