T
temays
Guest
Valeri, We seem to have multiple topics going on within this thread and it doesn't appear ALL are related to bulk copy. If this doesn't answer your question, then you might want to start a new thread. First...Bulk loading a table potentially can be split across "threads." I say potentially as really the index structure of the source table is the primary factor when determining if this is possible ,and really the piece to check is whether an index is already defined to logically break up the source side data. For example, is there a good date index that would allow multiple threads to properly bracket the reading of source data? Is the data separated by warehouse? Then threading makes sense, one thread per warehouse. This analysis really is the key to success when multi-threading the bulk load. Pending that analysis is good and you have properly identified a good method of separation, then you simply pull up the generated bulk load procedure for the table(s) in question (normally to bprepl/repl_mproc), find how the generated procedure is navigating the source records (using standard templates this would be FOR EACH bfrSrcTABLENAME NO-LOCK
and add a WHERE clause that makes sense based on the index evaluation done earlier. Save that modified version of the bulk load procedure to something like originalname1.p. Change the where clause again and again save it as originalname2.p sort of scheme. Then simply open a Pro2 editor session for each of the saved "threaded" procedures and run them individually. Note** If you wish to load other tables using the normal bulk load interface, then you should add the table being manually loaded to the bulk load "exclusion" list. This should make sense as you wouldn't want that process to also attempt to load the same table. Be aware that "threading" a bulk load does NOT affect how replication handles the copy of data. Bulk Load threads and Replication threads are not the same thing. Also you should know that splitting tables at the replication level requires a fully custom effort, as you have to change standard Pro2 code to traverse the ReplQueue table differently than normal. To split tables at replication also requires certain trigger dependencies, etc. so this really should be done by someone with experience in Pro2 implementations. Hope this helps, Terry
Continue reading...
and add a WHERE clause that makes sense based on the index evaluation done earlier. Save that modified version of the bulk load procedure to something like originalname1.p. Change the where clause again and again save it as originalname2.p sort of scheme. Then simply open a Pro2 editor session for each of the saved "threaded" procedures and run them individually. Note** If you wish to load other tables using the normal bulk load interface, then you should add the table being manually loaded to the bulk load "exclusion" list. This should make sense as you wouldn't want that process to also attempt to load the same table. Be aware that "threading" a bulk load does NOT affect how replication handles the copy of data. Bulk Load threads and Replication threads are not the same thing. Also you should know that splitting tables at the replication level requires a fully custom effort, as you have to change standard Pro2 code to traverse the ReplQueue table differently than normal. To split tables at replication also requires certain trigger dependencies, etc. so this really should be done by someone with experience in Pro2 implementations. Hope this helps, TerryContinue reading...