Mark, I'm not a database guru, but I think I have to disagree. I think it goes something like this....
All logged to Recovery Log: 1 Start Txn 402165173 2 Server finishes copying 1GB file from one tape to another 3 Pointer to old copy gets updated STOP PROCESS (would have happened: 4 Pointer to new copy gets written 5 End Txn 402165173 ) After process interruption, you have a rollback, like you said. Or, if it's a crash, you have a Recovery Log Redo. It sees the start of the Txn, no end, so it doesn't commit that transaction and rolls it back, rolls those changes out. No integrity problem, it just "never happened" as far as the database is concerned. That's what the transaction log is for, so you can roll back interrupted processes. Can anybody familiar with db internals confirm/deny? Alex Paschal Freightliner, LLC (503) 745-6850 phone/vmail -----Original Message----- From: Stapleton, Mark [mailto:[EMAIL PROTECTED] Sent: Thursday, March 13, 2003 11:04 AM To: [EMAIL PROTECTED] Subject: Re: Canceling a Reclamation FAST >Steve Harris wrote: >>updating the drive mid transaction to online=no does it for me. From: Paul Ripke [mailto:[EMAIL PROTECTED] >Sneaky! Since TSM *has* to be able to cope with this scenario >gracefully, it does surprise me somewhat that there isn't a >"cleaner" way of doing this - something like "cancel process >123 immediate=y". As I've said before, there's a good reason why many processes can't stop on a dime. Example: You're running space reclamation. The server is finished copying a 1GB file from one tape volume to another. The pointer in the TSM database to the old copy gets updated, but you *stop* the process before the pointer for the new copy gets written. Oops. There's a reason for rollback, and for finishing a process. Sometimes you've got wait; that's the price you pay for db integrity. -- Mark Stapleton ([EMAIL PROTECTED])
