Please undo my confusion

[GrahamNewport]

I just need something cleared up about savepoint data/Undo persistence

After 4 minutes of heavy updates in memory a savepoint occurs while a small financial update for 10 million has not yet committed.

The log buffers are persisted synchronously to log segments with both committed and uncommitted records quite fast due to log disk requirement and the savepoint waits for its completion.

A lot of data has been changed and has to be persisted with all of its undo to the data volume which is typically slower and has to write many times  more data due to the heavy changes over the last 4 minutes. From my understanding this is done at the start of the savepoint before the critical phase

It makes sense the savepoint would need all undo blocks and dirty blocks persisted in the data file but this could take many minutes, more than 30 I imagine.

Alert 28 (Most recent savepoint) by default has  low alert at 1 hour, medium alert at 2 hours and a high alert at 5 hours according to note 1977291

Alert 54 (savepoint duration) alerts with low 5 minutes, medium 10 minutes and high 15 minutes but states the critical phase should not be higher than 2 seconds according to note 1977220

This above alerts indicate that a savepoint duration saving dirty blocks to the data volume may take more than 5 minutes

Are people infrequently getting this alert but it goes away or does someone know how Hana avoids saving masses of dirty data blocks during the savepoint?

All help appreciated, aplogies I am still a Hana innocent

[lbreddemann · Accepted solution]

Few comments here:

For column store tables, there are no specific "undo" blocks that get saved. Changed data simply gets added to the delta store of the tables and as long as the transaction is not committed, other transactions simply keep seeing the old entry.

If a rollback (undo) happens, the new records just never become the 'active' version.

Saving the changed data is exactly the point of the savepoint. If you get a warning that it's too slow, than maybe the storage system is not sized correctly.

A too long critical phase might be the result of other processes exclusively blocking resources.

So I recommend to check for storage system performance and for locking activity around the savepoints. SAP note 1969700 from contains scripts to help you do exactly that.

[GrahamNewport · Accepted solution]

Perfect Lars!,

Sometimes we miss the obvious staring at us in the face.

Excellent and very much appreciated

It does not really clear up my concern over masses of delta records being created in memory and having to be persisted as writing in memory is much faster than persisting to disk but I am so happy about having no confusion and no-one else has said they got long checkpoints.

MfG

Graham