 |
 |
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
| |
