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:stapleto AT BERBEE DOT COM]
Sent: Thursday, March 13, 2003 11:04 AM
To: ADSM-L AT VM.MARIST DOT EDU
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:stixpjr AT BIGPOND.NET DOT AU]
>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 (mark.stapleton AT berbee DOT com)