How Slow Is Your Upgrade?
October 16, 2007
Posted by on
It’s a complaint I hear often, although not as often as I used to hear it. The upgrade programs/process was re-worked to take advantage of sqldbcopy, which solves some of the speed issues for copy jobs (i.e. tables which don’t require conversion). For those, the copying is done directly on the database server. However, some of the pre-jobs, loads, and post-jobs continue to be a bottleneck. The way I approach an upgrade is to work with the client to develop a baseline—using the Lawson-delivered programs, and then target the jobs which require tuning. For instance, a recent upgrade project looked like this:
- Run 1st time, hundreds of hours.
- Changed ‘drop index’ parameter, reduced to 213 hours.
- Re-wrote UG121 setup job, dropping that job ‘s run-time from 54 hours to 31 minutes
- Re-wrote AR800 post job; went from 91 hours to 12 hours
- Further address AR800 by replacing with SQL; down to 2 hours.
The final result is an upgrade process that runs in about 30 hours—compared to hundreds of hours—for a 210GB database.
Can your upgrade process be improved?