> For how a rollback works, the difference between pages on disk and in memory is irrelevant.
True from a logical standpoint, but not quite true when it comes to the question of time taken to rollback. If data or log pages have been flushed from cache to make room for more recently used pages and so have to be read back into cache to perform the rollback, the rollback will take longer because physical io is comparatively slow.
Another factor will be the duration of the transaction and the amount of other concurrent logged activity. To perform the rollback, ASE has to scan the log from the current end to the page containing the BEGINXACT record and generate CLR (rollback) records. The more log records it has to scan through, the longer it will take (and the greater the chance that the pages containing the earlier changes will have aged out of cache).
Minimally logged transactions ("fast" bcp, select into, create index) only generate allocation log records, so there is much less work for rollback to do compared to regular inserts; it can simply deallocate the newly allocated extents as opposed to undoing the insert of each row.
>so a rollback on a delete tran will reinsert the old data back in the pages (in memory and disk). likewise with an update where it will put back the old values.
The rollback on delete will reinsert the old data (on DOL pages it just clears the "deleted row" bit in the row) on the page in cache (if the page wasn't in cache, it will first be read into cache) and insert a new CLR log record in syslogs. When the rollback completes, all the syslogs pages associated with the rolled back transaction will be flushed to disk before control passes back to the client. The data pages in cache are not flushed to disk at this point, but will be flushed by the next checkpoint, or by aging out of cache.
>but let us suppose there is an insert of a million rows. so new pages will be
>allocated? so during transaction, bunch of it will be in memory and disk. so on a
>rollback, will newly allocated pages be simply discarded (on memory and disk)
>without being specifically deleted?
Only if large-scale allocation (LSA) was used, meaning "fast" bcp or SELECT INTO.
These operations start by allocating new extents and insert all their data onto the
new extents. But in the general case, for APL and DOL tables with a clustered index,
ASE will be inserting these rows onto pages that contain already existing data with similar keys.
For datarows tables, concurrent activity may be inserting rows on the same pages.
And if there are any indexes on the table, the index entries for the new rows will be mixed in
with entries for existing data as they are sorted by key. So in general, no, rollback of massive inserts (except by fast bcp and select into) will not be faster due to new extents being allocated.
-bret