Speeding up Conversion (or slowing down time)

Hint: One of the questions that I tend to get asked a lot is... how do we speed up conversion?

I tend to focus on a number of factors in an attempt to speed things up, but my top 11 is:

  1. Are the Staging and Production schemas on the same database/tablespace?
  2. Are the disks experiencing hotspots as a result of this shared implementation?
  3. If the two schemas are not on the same database, what is the theoretical maximum capacity of the link between the two instances?
  4. Is the machine CPU or Memory constrained?
  5. Can multithreaded runs be threaded further?
  6. Can Indexes be dropped for specific conversion steps? In most instances it it cheaper to drop the indexes before any mass insert steps and rebuild them afterwards than wear the cost of multiple I/Os for each insert.
  7. In instances where the indexes cannot be dropped, have these been created on their own database tablespace, with a dedicated I/O channel?
  8. For multi-threaded jobs, are the thread ranges reasonable, or can better results be achieved by running a number of single threaded artificial high/low limit jobs (CC&B Threading does not dynamically assign High/Low limits, it basically takes the max key range and divides by the number of threads, which can result in all of the work falling to the first couple of threads).
  9. How regular are database statistics being gathered... massive numbers of inserts can skew the optimum access path, so regular stats collections are essential.
  10. Can complex data manipulation be better served with the creation of a temporary table on the Staging or Input schemas?
  11. Consider whether all documented Conversion steps are required. e.g. I tend to avoid running Tidy Balances and prefer to build all required components and associated values into my data extracts and mapping rules.

Comments

Popular posts from this blog

Database Upgrades and their impact on Conversion

Bundle Corrections.

Threading...