 |
 |
Archives of the TeradataForum
Message Posted: Thu, 01 Aug 2002 @ 09:12:35 GMT
| Subj: | | Re: Rollback on long-running update |
| |
| From: | | Dieter Nöth |
Hi Frank,
| | We have experienced a rollback problem when a user aborted a long running update. This update was running for several hours
when they terminated their Queryman session. | |
Uh oh, you shouldn't do large updates with plain SQL. A rollback usually runs about 1 1/2 to 2 times longer than the original
transaction.
| | Then the rollback commenced and ran for several hours. During this time, the rollback process took nearly all the CPU
time and the box was barely usable. For example, users were getting logon timeouts, simple queries that normally take 2 minutes were
taking 30 minutes etc. | |
| | Once the rollback completed, the system recovered to its normal performance level. | |
| | Does any one have any experience on how to handle this? Are there any options available where one can reduce the loss of
service during a rollback? | |
Start dbscontrol and look at general field 10, RollbackPriority. The default is false, i.e. all rollbacks run at at highest
priority ($R = RUSH). When set to true, the rollback is assigned the user's priority (typically $M).
You can read more about that in the manuals: "Performance Optimization" and "Utilities Vol. 1" (R4.1 manuals, don't know about R3,
but you could download the new versions)
Dieter
| |
