Why are rollbacks MUCH slower than committed changes?

----LNX_Mon_Mar_08_2004_12:10:03_V3.33-- Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello everybody, = can anybody tell me why rollbacks on large transactions (table reorgs/loa= ds) need MUCH more time than they needed until the rollback started ? = For example a table load run for 25 minutes (not exclusive). Checkpoints = occur (pages are written to disk). Then the table load gets an error (long transaction= ). The following rollback needed more than a 4 1/2 hours! In the beginning the rollback would even have needed more time, but than = the database was restarted and the fast recovery was slightly faster (sure: it runexcl= usive), but it was still much slower than the load. = The data store is an HP/Hitachi XP1024 disk storage system with plenty of= cache (read and write) - therefore reading old log records and writing new ones (disk= positioning) shouldn't be too expensive - or is it? = I know the database is optimized for committed changes and not for rollba= cks. Therefore I wouldn't mind if the rollback takes two or three times as long - but it= 's much more. = Regards, Andreas Kutsche ------------------------------------------------ SPAR Oesterreichische Warenhandels-AG Hauptzentrale Europastra=DFe 3 A-5015 Salzburg = Telefon : +43 662 4470 24423 E-Mail : Andreas.KUTSCHE@spar.at Internet: http://www.spar.at ------------------------------------------------ = ----LNX_Mon_Mar_08_2004_12:10:03_V3.33----