## 9.1.2  Savepoint Performance
To perform a savepoint write operation, SAP HANA needs to take a global database lock. This period is called the 'critical phase' of a savepoint. While SAP HANA was designed to keep this time period as short as possible, poor I/O performance can extend it to a length that causes a considerable performance impact.
Savepoints are used to implement backup and disaster recovery in SAP HANA. If the state of SAP HANA has to be recovered, the database log from the last savepoint will be replayed.
You can analyze the savepoint performance with this SQL statement:
```
select start_time, volume_id, round(duration / 1000000) as "Duration in Seconds", round(critical_phase_duration / 1000000) as "Critical Phase Duration in Seconds", round(total_size / 1024 / 1024) as "Size in MB", round(total_size / duration) as "Appro. MB/sec", round (flushed_rowstore_size / 1024 / 1024) as "Row Store Part MB" from m_savepoints where volume_id in ( select volume_id from m_volumes where service_name = 'indexserver') ;
```
This statement shows how long the last and the current savepoint writes took/are taking. Especially the critical phase duration, in which savepoints need to take a global database lock, must be observed carefully.
The critical phase duration should not be longer than a second. In the example below the times are significantly higher due to I/O problems.
<!-- image -->
Savepoints
|    | START_TIME                     | VOLUME_ID   | Duration in Seconds   | Critical Phase Duration in Seconds   | Size in MB   |   Appro. MB{sec | Row Store Part MB   |
|----|--------------------------------|-------------|-----------------------|--------------------------------------|--------------|-----------------|---------------------|
|    | Dec 16, 2013 9.28.38,469738 AM |             | 23                    |                                      | 3,822        |             177 | 874                 |
|    |                                |             | 20                    |                                      | 3,845        |             197 | 796                 |
|    | Dec 16, 2013 9.17,49.383506 AM |             | 29                    |                                      | 3,910        |             143 | 1,065               |
|    | Dec 16, 2013 9.11.33.777138 AM |             | 76                    |                                      | 10,072       |             140 | 1,957               |
|    | Dec 16, 2013 9,05.57,694349 AM |             |                       |                                      | 3,879        |             113 | 1,362               |
|    | Dec 16, 2013 9,00.38.347428 AM |             |                       |                                      | 3,321        |             180 | 1,026               |
|    | Dec 16,2013 8.56.23.056008 AM  |             | 2                     |                                      | 4,226        |              64 | 1,324               |
|    | Dec 16, 2013 8,48,07.902735 AM |             | 154                   |                                      | 11,558       |              79 | 4,650               |
|    | Dec 16, 2013 8,09.16.575288 AM |             | 167                   |                                      | 20,150       |             127 | 5,032               |
| 10 | Dec 16, 2013 8,05.58.861928 AM |             | 49                    |                                      | 2,762        |              59 | 809                 |
| 11 | Dec 16. 2013 8.01.32.889947 AM |             |                       |                                      | 1253         |             201 | 161                 |
The following SQL shows a histogram on the critical phase duration:
```
select
```
```
to_char(SERVER_TIMESTAMP,'yyyy.mm.dd') as "time", sum(case when (critical_phase_duration <= 1000000) then 1 else 0 end) as "<= 1 s", sum(case when (critical_phase_duration > 1000000 and critical_phase_duration <=2000000) then 1 else 0 end) as "<= 2 s", sum(case when (critical_phase_duration > 2000000 and critical_phase_duration <=3000000) then 1 else 0 end) as "<= 3 s", sum(case when (critical_phase_duration > 3000000 and critical_phase_duration <=4000000) then 1 else 0 end) as "<= 4 s", sum(case when (critical_phase_duration > 4000000 and critical_phase_duration <=5000000) then 1 else 0 end) as "<= 5 s", sum(case when (critical_phase_duration > 5000000 and critical_phase_duration <=10000000) then 1 else 0 end) as "<= 10 s", sum(case when (critical_phase_duration > 10000000 and critical_phase_duration <=20000000) then 1 else 0 end) as "<= 20 s", sum(case when (critical_phase_duration > 20000000 and critical_phase_duration <=40000000) then 1 else 0 end) as "<= 40 s", sum(case when (critical_phase_duration > 40000000 and critical_phase_duration <=60000000) then 1 else 0 end) as "<= 60 s", sum(case when (critical_phase_duration > 60000000 ) then 1 else 0 end) as "> 60 s", count(critical_phase_duration) as "ALL" from "_SYS_STATISTICS"."HOST_SAVEPOINTS" where volume_id in (select volume_id from m_volumes where service_name = 'indexserver') and weekday (server_timestamp) not in (5, 6) group by to_char(SERVER_TIMESTAMP,'yyyy.mm.dd') order by to_char(SERVER_TIMESTAMP,'yyyy.mm.dd') desc;
```
<!-- image -->
## Savepoint Histogram
The performance of the backup can be analyzed with this statement:
```
select mbc.backup_id, SECONDS_BETWEEN (mbc.sys_start_time, mbc.sys_end_time) seconds, round(sum(backup_size) / 1024 / 1024 / 1024,2) size_gb, round(sum(backup_size) / SECONDS_BETWEEN (mbc.sys_start_time, mbc.sys_end_time) / 1024 / 1024, 2) speed_mbs from m_backup_catalog_files mbcf , m_backup_catalog mbc where mbc.entry_type_name = 'complete data backup' and mbc.state_name = 'successful' and mbcf.backup_id = mbc.backup_id group by mbc.backup_id, mbc.sys_end_time, mbc.sys_start_time order by mbc.sys_start_time
```