Archives of the TeradataForum
Message Posted: Fri, 09 Mar 2001 @ 09:22:31 GMT
The more complex the Select portion then the lower the ratio should be - a 3 hour 'insert' that actually comprises of 1 hour of select processing only has to rollback the 2 hours of insert processing, not the 1 hour select.
I'm not aware of any utility that will tell you how much rollback has been done. You basically need knowledge of what the transaction was doing, the state of the table before the transaction etc and then start querying the target table using an ACCESS lock.
Take a simple case: if the table started with 100 rows and your transaction is only doing inserts then issuing a "locking table xxx for access Select count(*) from xxx" will tell you how many rows are still on the table. You can then tell how many are left to rollback.
More complicated cases typically just add to the WHERE clause on a query, but the principal is the same.
If you can do this, then you also get an idea of how long the rollback will take.
A thought just occurred (and this may be a bit 'extreme') if you restart the DBMS whilst the rollback is flight, then you could use Recovery Manager to monitor it. However, if the transaction's already been rolling back for 60 hours then this probably isn't a good idea in this case. No, it's definitely not a good idea for this one !
Hope that helps.
|Copyright 2016 - All Rights Reserved|
|Last Modified: 27 Dec 2016|