Skip to Content
Based on revision 45 (SPS 5) of SAP HANA Studio and Database

As projects with HANA (just like with any other technology) move on, at some point in time the requirement to perform tests and trainings comes up.

If this is not the case in your project, please go and talk to your project responsible right away! ๐Ÿ˜‰

Stil here? Ok, so you’re actually want to perform some testing?

One important thing when performing tests is that you repeat them in the same environment (and maybe alter one thing at a time).

So, how do you achieve this with a database?

You restore a backup taken earlier, right?

Yeah, right!

That’s one way to do it.

A disadvantage of this approach is that it takes a lot of time as the whole database backup needs to be read from the backup medium and be written to the database storage.

Another way to deal with this requirement is to take snapshots of the database and set it back to a snapshot once required.

If you’ve worked with a virtual machine (e.g. VMWare, VirtualBox or Parallels) you know how snapshots work:

the system is ‘frozen’ for a moment, a snapshot is taken and afterwards you can continue to work with the system.

From that moment on you always have the option to ‘flash back‘ to the system state when you took the snapshot.

SAP HANA is offering a pretty similar functionality.

Those of you that know SAP MaxDB snapshots will clearly recognize the concepts.

The HANA implementation is quite close to the MaxDB feature.

SNAPSHOTS in HANA

So, I can take snapshots of my HANA instance?

Great, show me the button for that in HANA studio!

Unfortunately there is no frontend UI support for HANA snapshots (yet – no idea whether this is on the backlog for development).

Therefore, this little walktrough involves a bit of typing and reading…

But, wait a minute: where is all the old data stored then?

Ok, let’s answer this obvious question first. Similar to many filesystems and in fact very similar to MaxDB HANA’s persistency employs the shadow paging concept (http://en.wikipedia.org/wiki/Shadow_paging). That means that whenever a changed data page is written from memory to the disks (this is called a savepoint in HANA) the changed page is stored at a different physical position. The old page is not immediately overwritten. Instead the old version of the page remains in the storage until one of the subsequent savepoints overwrites it with newly changed data.

To keep track of which pages are current and which ones can be overwritten, HANA uses a mapping structure called the converter (hello MaxDB again).

Having these two concepts savepoint+converter in place, a snapshot is now easy to create.

All you’ve to do is to keep a specific state of the Converter and keep all pages referenced by this converter version from being overwritten.

And that’s exactly what happens within HANA when you take a snapshot.

Since savepoints can be recovered transactionally consistent by their design, HANA can simply switch back to a saved Converter version and resume working from there.

By knowing this, the answer to the question is easy to give: the data is still in the data area and won’t be overwritten.

Obviously, if you do change a lot of the data that is part of the snapshot, the data area usage will grow quite a bit, even if you’re only doing UPDATEs or DELETEs (funny effect, isn’t it? ๐Ÿ™‚ ).

Well, then let’s see what the snapshot is like with HANA.

And off we go – my annotated HANA snapshot walkthrough:

The commands I use I found in our documentation:

   System Administration and Maintenance Information

    SAP HANA Administration Guide

    13.14 SQL Syntax for Backup and Recovery.

    13.14.4 SQL Statements for Data Snapshot……………………………………188

    Syntax

    <execute_create_snapshot>::= BACKUP DATA CREATE SNAPSHOT

  <execute_drop_snapshot>::= BACKUP DATA DROP SNAPSHOT

Just there I also found this interesting remark that I will check out later in more detail:

   “Examples of SQL Statements for Data Snapshot

    BACKUP DATA CREATE SNAPSHOT

    Create a database-wide snapshot based on a transactional consistent savepoint similar to the data backup.

    If a snapshot exists, no complete data backup is possible.

    Every request of this kind is rejected with a notification that a data backup is still in process.

    BACKUP DATA DROP SNAPSHOT

    Drop a database-wide snapshot. From this point in time on, complete data backups are possible.”

To start I setup a test table and fill it with some data.

I also make sure that the table is not fully merged, since I want to know whether the snapshot works with the change log of column tables as well

    (no commits here as AUTOCOMMIT = ON)
    drop table lars.snappy;
    create column table lars.snappy (col1 varchar(20));
    insert into lars.snappy values ('LARS');
    merge delta of lars.snappy;
    -- table created, one record in and merged to the main store
    -- now another record for the delta store:
    insert into lars.snappy values ('NORA');
    -- let's check what we've got:
    -- (I cut away the columns that I'm not interested in for readabilty)
    select * from m_cs_tables where table_name='SNAPPY';
    SCHEMA_NAME TABLE_NAME  RECORD_COUNT    RAW_RECORD_COUNT_IN_MAIN    RAW_RECORD_COUNT_IN_DELTA
    LARS        SNAPPY      2               1                           1

Now, I take a snapshot of this database.

    backup data create snapshot;
    Statement 'backup data create snapshot' successfully executed in 33.449 seconds
    Started: 2012-12-06 21:43:58 (server processing time: 33.428 seconds)
    - Rows Affected: 0

That was easy.

Noteworthy is that the time to take a snapshot is *not* related to the size of the database.

Instead it’s bound to how many changed pages have to be written out for the savepoint that is triggered.

Remember? A HANA snapshot is a ‘frozen’ savepoint.

Well, while we’re at it, we could also just check on this, shall we?

    select * from m_savepoints;
    HOST             PORT           VOLUME_ID          START_TIME                       STATE          VERSION          REQUESTED_FREQUENCY          TIME_SINCE_PREVIOUS          DURATION          CRITICAL_PHASE_DURATION          TOTAL_SIZE          FLUSHED_PAGES          FLUSHED_PAGES_IN_CRITICAL_PHASE          FLUSHED_ROWSTORE_PAGES          FLUSHED_ROWSTORE_PAGES_IN_CRITICAL_PHASE          FLUSHED_SIZE          FLUSHED_SIZE_IN_CRITICAL_PHASE          FLUSHED_ROWSTORE_SIZE          FLUSHED_ROWSTORE_SIZE_IN_CRITICAL_PHASE          RTT_SIZE
    vml3012          30003          2                  2012-12-06 21:43:59.017          DONE           85775            300                          171                          5592076           15801                            973209600           14637                  9                                        0                               0                                                 972029952             1179648                                 0                              0                                                0
    vml3012          30003          2                  2012-12-06 21:41:07.241          DONE           85774            300                          114                          22376             111                              2048000             8                      0                                        3                               0                                                 1507328               0                                       540672                         0                                                0
    [...]
    (RTT =  rollback transaction table - see RTT_SIZE column description for m_savepoints view)

The first line shows our snapshot savepoint.

Don’t ask me about the mismatch of DURATION (5592076 ms) and the reported 33.449 seconds, no clue on that.

Another system view to check out is – wait for it – m_snapshots:

    select * from m_snapshots;
    HOST             PORT           VOLUME_ID          ID             TIMESTAMP                        FOR_BACKUP          ANCHOR
    vml3012          30003          2                  85775          2012-12-06 21:43:59.017          TRUE                105553116266525
    vml3012          30005          3                  24610          2012-12-06 21:43:58.106          TRUE                105553116266559
    vml3012          30007          4                  69057          2012-12-06 21:43:58.194          TRUE                105553116266504

The avid reader will have noticed, that we took ONE snapshot and now we see THREE entried in our system view.

Upton closer look we find that these snapshots belong to different volumes of different services (notice the PORT cokumn).

This is already a hint to how snapshots are handled in our distributed system (distributed over separate services with separate persistencies eventually distributed over several nodes).

Being the old support guy I am, I also peek into the current indexserver trace file and find one line:

    [...]
    [8319]{0}[0] 2012-12-06 21:44:04.608995 i Logger       SavepointImpl.cpp(02077) : Snapshot 85775->85776, snapsp=85775, RTT size=0P+0O+0D
    [...]

Noticable here is apart from the savepoint number (85775->85776) the information that there is currently a snapshot currently present (snapsp=85775).

If no snapshot would be present we would find snapsp=0 there.

Finally, the backup.log file provides more information:

    [...]
    2012-12-06T21:43:58+01:00  P07589      13b71f5e371 INFO    BACKUP   SNAPSHOT started
    2012-12-06T21:43:58+01:00  P07589      13b71f5e371 INFO    BACKUP   state of service: nameserver, vml3012:30001, volume: 1, BackupPrepareSavepointInProgress
    2012-12-06T21:43:58+01:00  P07589      13b71f5e371 INFO    BACKUP   state of service: statisticsserver, vml3012:30005, volume: 3, BackupPrepareSavepointInProgress
    2012-12-06T21:43:58+01:00  P07589      13b71f5e371 INFO    BACKUP   state of service: xsengine, vml3012:30007, volume: 4, BackupPrepareSavepointInProgress
    2012-12-06T21:43:58+01:00  P07589      13b71f5e371 INFO    BACKUP   state of service: indexserver, vml3012:30003, volume: 2, BackupPrepareSavepointInProgress
    2012-12-06T21:43:58+01:00  P07589      13b71f5e371 INFO    BACKUP   state of service: xsengine, vml3012:30007, volume: 4, BackupPrepareSavepointFinished
    2012-12-06T21:43:58+01:00  P07589      13b71f5e371 INFO    BACKUP   state of service: nameserver, vml3012:30001, volume: 1, BackupPrepareSavepointFinished
    2012-12-06T21:43:58+01:00  P07589      13b71f5e371 INFO    BACKUP   state of service: statisticsserver, vml3012:30005, volume: 3, BackupPrepareSavepointFinished
    2012-12-06T21:44:03+01:00  P07589      13b71f5e371 INFO    BACKUP   state of service: indexserver, vml3012:30003, volume: 2, BackupPrepareSavepointFinished
    2012-12-06T21:44:03+01:00  P07589      13b71f5e371 INFO    BACKUP   state of service: nameserver, vml3012:30001, volume: 1, BackupSynchronizeSavepointInProgress
    2012-12-06T21:44:03+01:00  P07589      13b71f5e371 INFO    BACKUP   state of service: statisticsserver, vml3012:30005, volume: 3, BackupSynchronizeSavepointInProgress
    2012-12-06T21:44:03+01:00  P07589      13b71f5e371 INFO    BACKUP   state of service: xsengine, vml3012:30007, volume: 4, BackupSynchronizeSavepointInProgress
    2012-12-06T21:44:03+01:00  P07589      13b71f5e371 INFO    BACKUP   state of service: indexserver, vml3012:30003, volume: 2, BackupSynchronizeSavepointInProgress
    2012-12-06T21:44:03+01:00  P07589      13b71f5e371 INFO    BACKUP   state of service: nameserver, vml3012:30001, volume: 1, BackupSynchronizeSavepointFinished
    2012-12-06T21:44:03+01:00  P07589      13b71f5e371 INFO    BACKUP   state of service: statisticsserver, vml3012:30005, volume: 3, BackupSynchronizeSavepointFinished
    2012-12-06T21:44:03+01:00  P07589      13b71f5e371 INFO    BACKUP   state of service: xsengine, vml3012:30007, volume: 4, BackupSynchronizeSavepointFinished
    2012-12-06T21:44:03+01:00  P07589      13b71f5e371 INFO    BACKUP   state of service: indexserver, vml3012:30003, volume: 2, BackupSynchronizeSavepointFinished
    2012-12-06T21:44:03+01:00  P07589      13b71f5e371 INFO    BACKUP   state of service: nameserver, vml3012:30001, volume: 1, BackupFinishSavepointInProgress
    2012-12-06T21:44:03+01:00  P07589      13b71f5e371 INFO    BACKUP   state of service: indexserver, vml3012:30003, volume: 2, BackupFinishSavepointInProgress
    2012-12-06T21:44:03+01:00  P07589      13b71f5e371 INFO    BACKUP   state of service: statisticsserver, vml3012:30005, volume: 3, BackupFinishSavepointInProgress
    2012-12-06T21:44:03+01:00  P07589      13b71f5e371 INFO    BACKUP   state of service: xsengine, vml3012:30007, volume: 4, BackupFinishSavepointInProgress
    2012-12-06T21:44:03+01:00  P07589      13b71f5e371 INFO    BACKUP   state of service: nameserver, vml3012:30001, volume: 1, BackupFinishSavepointFinished
    2012-12-06T21:44:03+01:00  P07589      13b71f5e371 INFO    BACKUP   state of service: statisticsserver, vml3012:30005, volume: 3, BackupFinishSavepointFinished
    2012-12-06T21:44:03+01:00  P07589      13b71f5e371 INFO    BACKUP   state of service: xsengine, vml3012:30007, volume: 4, BackupFinishSavepointFinished
    2012-12-06T21:44:04+01:00  P07589      13b71f5e371 INFO    BACKUP   state of service: indexserver, vml3012:30003, volume: 2, BackupFinishSavepointFinished
    2012-12-06T21:44:04+01:00  P07589      13b71f5e371 INFO    BACKUP   SNAPSHOT finished successfully
    [...]

And since the snapshot command was bundled into the BACKUP DATA command, finding this information here kind of makes sense.

Maybe we even find something in m_backup_catalog (the system view used to track data backups) for our snapshot?

NOPE. NADA. RIEN.

If you ask me this is just consequent because a snapshot is all but a backup.

It doesn’t prevent you from loss of data by media failure.

You can’t store the backed up data somewhere else, somewhere safe.

A snapshot is not a backup.

The mixing up of these technically extremely close concepts on a semantic level (by using the same command to trigger both) is not the wisest design decision, if you ask me.

Even worse, due to the overlapping of both functions, there is also a severe limitation that comes into play, when you create a snapshot.

I mentioned it already above: once there is a snapshot, it’s not possible to take new data backups anymore!

WOW – this is not nice.

And this wasn’t the case with MaxDB.

To bad it really isn’t possible to run a data backup on top of a snapshot. If you use the backup wizard to start a new data backup, the wizard will present the following message:

    Backup of system HAN failed
    Could not start backup of system 'HAN'. '
    The state 'ManagerSnapshotExists' of the BackupManager does not allow the requested operation'

The same thing happens when you try to add another snapshot (multiple snapshots are supported by MaxDB, so why not try this?):

    Could not execute 'backup data create snapshot' in 26 ms 719 µs Started: 2012-12-06 21:59:11.
    SAP DBTech JDBC: [2]: general error:
    Backup error: The state 'ManagerSnapshotExists' of the BackupManager does not allow the requested operation

To be honest, no idea why multiple snapshots and backups are not possible.

What is easy to see however, is that the converter structure is more complex than in MaxDB:

    select * from m_converter_statistics;
    HOST             PORT           VOLUME_ID          TYPE                        MAX_LEVEL          MAX_PAGENUMBER          ALLOCATED_PAGE_COUNT          ALLOCATED_PAGE_SIZE CREATE_SNAPSHOT_COUNT          DROP_SNAPSHOT_COUNT
    vml3012          30003          2                  StaticConverter             0                  16382                   4                             1048576             10                             9
    vml3012          30003          2                  TemporaryConverter          0                  0                       0                             0                   0                              0
    vml3012          30003          2                  RowStoreConverter           1                  688127                  94208                         1543503872          10                             9
    vml3012          30003          2                  DynamicConverter            1                  212990                  28270                         1818025984          10                             9
    vml3012          30005          3                  StaticConverter             0                  0                       0                             0                   10                             9
    vml3012          30005          3                  TemporaryConverter          0                  0                       0                             0                   0                              0
    vml3012          30005          3                  RowStoreConverter           0                  8191                    4096                          67108864            10                             9
    vml3012          30005          3                  DynamicConverter            0                  16382                   10113                         675201024           10                             9
    vml3012          30007          4                  StaticConverter             0                  0                       0                             0                   10                             9
    vml3012          30007          4                  TemporaryConverter          0                  0                       0                             0                   0                              0
    vml3012          30007          4                  RowStoreConverter           0                  8191                    4096                          67108864            10                             9
    vml3012          30007          4                  DynamicConverter            0                  16382                   23                            1863680             10                             9

In order to be able to backup data again, the existing snapshot (frozen savepoint) needs to be dropped/unfrozen:

    backup data drop snapshot;

After this command, you can take new backups and snapshots again.

Sadly, the error message when you try to drop a snapshot when there is no snapshot is cryptic, to say the least:

    Could not execute 'backup data drop snapshot' in 54 ms 338 µs Started: 2012-12-11 13:42:44.
    SAP DBTech JDBC: [2]: general error:
    Backup error: The state 'ManagerIdle' of the BackupManager does not allow the requested operation 

Seriously, why not something more appealing like, I don’t know, “no snapshot present to drop“?

BACK TO THE PAST!

Okay, okay, enough looking around in the system.

Let’s change some data and return to the snapshot afterwards (I didn’t drop the snapshot during but after my tryout ๐Ÿ˜‰ )

    insert into lars.snappy (select * from lars.snappy);
    Statement 'insert into lars.snappy (select * from lars.snappy)' successfully executed in 44 ms 380 µs Started: 2012-12-06 22:17:03 (server processing time: 19 ms 481 µs) - Rows Affected: 2
    Statement 'insert into lars.snappy (select * from lars.snappy)' successfully executed in 22 ms 763 µs Started: 2012-12-06 22:17:06 (server processing time: 4 ms 60 µs) - Rows Affected: 4
    Statement 'insert into lars.snappy (select * from lars.snappy)' successfully executed in 21 ms 419 µs Started: 2012-12-06 22:17:07 (server processing time: 2 ms 507 µs) - Rows Affected: 8
    Statement 'insert into lars.snappy (select * from lars.snappy)' successfully executed in 21 ms 435 µs Started: 2012-12-06 22:17:07 (server processing time: 2 ms 658 µs) - Rows Affected: 16

Now there’s some more data in our table.

    select * from lars.snappy;
    COL1
    ----
    LARS
    NORA
    LARS
    NORA
    LARS
    NORA
    LARS
    NORA
    LARS
    NORA
    LARS
    NORA
    LARS
    NORA
    LARS
    NORA
    LARS
    NORA
    LARS
    NORA
    LARS
    NORA
    LARS
    NORA
    LARS
    NORA
    LARS
    NORA
    LARS
    NORA
    LARS
    NORA

And of course:

    merge delta of lars.snappy;
    select * from m_cs_tables where table_name='SNAPPY';
    SCHEMA_NAME TABLE_NAME  RECORD_COUNT    RAW_RECORD_COUNT_IN_MAIN    RAW_RECORD_COUNT_IN_DELTA
    LARS        SNAPPY      32              32                          0

To get the old version of the database content back, I first have to shutdown the instance and then use a command line tool:

    -- shutdown via HANA studio
    -- logon to HANA server via SSH:

Tell the database to use the snapshot:

    hanadm@lxxxx:/usr/sap/HAN/HDB00> hdbnsutil -useSnapshot
    nameserver lxxxx:30001 not responding.
    opening persistence ...
    run as transaction master
    done.

For some reason the database is not online now, but has to be started manually…

    hanadm@lxxxx:/usr/sap/HAN/HDB00> HDB start
    StartService
    OK
    OK
    Starting instance using: /usr/sap/HAN/SYS/exe/hdb/sapcontrol -prot NI_HTTP -nr 00 -function StartWait 2700 2
    06.12.2012 22:20:49
    Start
    OK
    06.12.2012 22:23:13
    StartWait
    OK

Finally the instance is up and running again and I can look for my old data.

    select * from lars.snappy
    COL1
    ----
    LARS
    NORA
    select * from m_cs_tables where table_name='SNAPPY';
    SCHEMA_NAME TABLE_NAME  RECORD_COUNT    RAW_RECORD_COUNT_IN_MAIN    RAW_RECORD_COUNT_IN_DELTA
    LARS        SNAPPY      2               1                           1                        

In fact, this is how my data (and the whole database) looked like when I created the snapshot.

Welly, welly, welly, well – not too bad.

Is the snapshot still there now?

What would be your guess?

Mine, based on past experiences with VM-machines and MaxDB, was that the snapshot stays there until I drop it explicitely.

Is it the same with HANA?

Nope.

    select * from m_snapshots;
    ==> EMPTY <==
   

This is not too problematic.

You could still use the snapshots to re-generate the same database state over and over, for testing or training system purposes.

All you have to keep in mind is to take a snapshot again, immediately after you restarted the instance when you re-activated the former snapshot.

If you do use the return to snapshot functionality and continue working from there, make sure to create a data backup immediately as well, because the indexserver trace file warns us:

    [...]
    [19308]{0}[0] 2012-12-06 22:31:54.782171 w Logger       SavepointImpl.cpp(02091) : NOTE: BACKUP DATA needed to ensure recoverability of the database
    [...]

And that’s it once again folks.

Hope there was something in here for you.

Cheers,

Lars

Here are some links to documentation, references etc. that I used…

System view references:

To report this post you need to login first.

27 Comments

You must be Logged on to comment or reply to a post.

  1. Andy Silvey

    Hi Lars,

    contrary to the blog title, this is certainly _not_ a cheesy blog ๐Ÿ˜‰

    This is an excellent blog, thank you.

    All the best,

    Andy.

    (0) 
    1. Lars Breddemann Post author

      Thanks Lakshmi!

      What exactly do you refer to with your later comment?

      In order to perform backup we actually take a snapshot and copy all data belonging to the snapshot into the backup files/pipes. For that there is also no downtime required.

      It never was for HANA.

      What’s true however is, that you can create a snapshot and then use storage tools to copy the data and log files to another instance. There you can recover the instance based on the snapshot. This method doesn’t safe you any downtime (as there was no downtime required in the first place) but it may safe time to get the copy system up, since you don’t have to restore the data from the backup.

      cheers, Lars

      (0) 
  2. Former Member

    Hi Lars

    Thanks for an excellent blog on snapshot on HANA…

    In the above reply you did mention that savepoints of one server(for say Prod) can be copied over from one server and used to restore another server (for say Test). Can you thrown some light..

    1) Where are the snapshot files stored on OS level that need to be copied on to test server?

    2) On the test server can you through some light on the commands and sequence in which we need to perform restore.

    Thanks

    Naresh P.

    (0) 
    1. Lars Breddemann Post author

      Hi Naresh,

      there are no specific snapshot files, but instead the data is held in the main data area persistence of the HANA instance.

      If you want to use backups of snapshots to copy systems you take the backup files to the target server and recover them there.

      The sequence of commands for this can found in SAP note 1703435.

      – Lars

      (0) 
    2. Lars Breddemann Post author

      Hi Naresh,

      there are no specific snapshot files, but instead the data is held in the main data area persistence of the HANA instance.

      If you want to use backups of snapshots to copy systems you take the backup files to the target server and recover them there.

      The sequence of commands for this can found in SAP note 1703435.

      – Lars

      (0) 
  3. Former Member

    Hi Lars,

    I’d like to make an addition, because it wasn’t really clear to me after reading your blog:

    Snapshots disappear with EVERY system restart, not only if you set the system back. And we have one more problem. In our productive system we encountered a lot of indexserver process crashes, because of several program bugs (may be solved with the current release, but I wouln’t bet they can’t occure anymore). In such case the entry for the restarted process disappears in m_snapshots, whilst the other entries remain. Or in other words you’ll end up with only two lines in this view. No idea what happens, if you now try to set the system back …

    So I’d say we should still be quite careful with this function currently. (But good to know we have it ๐Ÿ˜‰ .)

    Regards,

    Dirk

    (0) 
    1. Lars Breddemann Post author

      Hi Dirk,

      thanks for the comment – actually, I wasn’t aware that the restart will drop snapshots and I’ll need to check this.

      The other thing you mentioned is rather not so nice as it means, that the system wide snapshot information are not consistent anymore.

      Are you able to clean this situation up via DROP SNAPSHOT?

      – Lars

      (0) 
      1. Former Member

        Hi Lars,

        DROP SNAPSHOT throws no errors and M_SNAPSHOTS is empty afterwards, so I’d say yes. By the way: I tested with revision 45, so maybe the most current version may behave different.

        Regards,

        Dirk

        (0) 
  4. Stefan Koehler

    Hmm … i must have missed this blog last year (ok i was very busy in December, but this is no excuse). Great work (as usual) Lars.

    However this sounds like some kind of poor man flashback technology ๐Ÿ˜› No backup possible, just because of a “snapshot” (something like a (Guaranteed) restore point in my language)? That is ridiculous.

    Thank god … HANA has a looooong way to go for playing with the big boys in big environments ๐Ÿ˜ˆ

    Sometimes i really wonder about such implementations and what the developers were thinking about while implementing such stuff.

    Regards

    Stefan

    (0) 
    1. Lars Breddemann Post author

      Stefan, the day you stop mocking about HANA, I’ll know we’re super-settled and mature ๐Ÿ˜† .

      Thanks and hope to read more from you soon as well!

      Lars

      (0) 
      1. Stefan Koehler

        Hehe .. be prepared and do not fall off your chair now .. this day is today ๐Ÿ˜›

        I read this blog (http://scn.sap.com/community/hana-in-memory/blog/2013/02/21/blocked-and-lovin-it-looking-for-clues-on-the-technology-behind-the-new-hana-enhanced-nba-stats-site) and tried out that NBA statistic website. I am not very familiar with basketball statistics and this was my first “hands-on” experience with SAP HANA.

        *drum roll* Damn man .. even custom statistic queries are fast like hell .. i am totally thrilled .. no kidding *drum roll*

        However i am more concerned about myself as i am reading more HANA related stuff than Oracle stuff in the past days ๐Ÿ˜‰

        I hope you don’t stop developing SAP HANA now, just because of my positive experience / feedback ๐Ÿ˜† ๐Ÿ˜›

        (0) 
  5. Former Member

    Hey Lars….Great blog,I was actually looking for some more internal technical information on how  HANA asyn system replication (DR ) works -we know snapshots are created and then sent across to the other site but there is no real documentation on  this…isnt it interesting to note how much of MaxDB has been ported over to HANA…

    actually I found a great link

    https://wiki.wdf.sap.corp/wiki/display/ngdb/High+Availability+and+Disaster+Tolerance

    ..Felix

    (0) 
  6. Former Member

    Hi Lars,

    Maybe I could provide some additional information regarding HANA Storage Snapshots. With latest revision of HANA, functionality to use Snapshot has changed a little bit. This has been updated in the Administration guide also.

    To create a Snapshot command is still same:-

    BACKUP DATA CREATE SNAPSHOT COMMENT ‘<comment string>’

    However, to drop/delete a Snapshot, DROP statement is not used anymore but is still supported for lower releases. Therefore, the general error mentioned by you in blog will not be a problem anymore. ๐Ÿ˜‰

    To drop/close a Snapshot, we have to use following statement:-

    BACKUP DATA CLOSE SNAPSHOT BACKUP_ID <backup_id> SUCCESSFUL <external_id> | UNSUCCESSFUL [<string>]

    Here, backup_id could be searched from backup catalog (from HANA Studio) or from M_BACKUP_CATALOG table. External ID could be anything (or the ID used by external disk).

    However, previously created closed Snapshots can be used to recover if the files related to Snapshot are backed up at some other location after taking Snapshot {I hadn’t exclusively test this feature but in my knowledge it is possible}

    But, still no other snapshot can be created if the previously created Snapshot is not closed.

    Rest of the topic is explained very awesomely by you and this blog is very interesting to read. Kudos!!

    Thanks,

    Apoorv

    (0) 
    1. Former Member

      Hi Apoorv,

      the documentation of SP7 tells us that a backup is NOT possible, as long as a DB snapshot exists. You have to close it first.

      Regards,

      Dirk

      (0) 
    2. Lars Breddemann Post author

      Hi Apoorv

      Thanks for the feedback on this (pretty old and outdated) blog post of mine.

      Nice to learn that it still is somewhat relevant… ๐Ÿ™‚

      (BTW: we really should have a filter in the product related communities that allow to filter on specific releases…)

      Upon my test on Rev 72 I got a

      Could not start backup of system ‘XYZ’. ‘ The state ‘ManagerSnapshotExists’ of the BackupManager does not allow the requested operation‘”

      As I understand it, this BACKUP CLOSE SNAPSHOT feature is there simply to indicate that your external backup program is done with copying the files away.

      It is not a snapshot kept with the database for later reuse.

      To be able to take new backups, you need to close/drop the snapshot and to return to the snapshot state you need to get the data back from the external backup tool.

      – Lars

      (0) 
      1. Former Member

        Hi Dirk & Lars,

        Thanks for the reply and correcting me. I have changed my comment (in case someone read upto that comment only). ๐Ÿ™‚ ๐Ÿ™‚

        Thanks,

        Apoorv

        (0) 
        1. Dmitry Ponomarev

          Hi Apoorv,

          I assume you will have just one datavolume_xxx file for data area, or at least you cannot identify in which data area file your snapshot sits. Therefore you are forced to copy entire data area, all its files, into backup folder to be able to restore DB using snapshot later after disaster (hardware failure of db storage).

          I could be wrong, but it makes snapshot meaningless for disaster recovery.

          You have to copy data area with snapshot in it anyway, would it be easier to copy complete data and log areas together without struggling with any snapshots (log doesn’t look like a big addition to the amount of data one will copy… about 1/3 of data at worst methinks).

          PS. I do understand benefit of snapshot for example in QA where you need to test & retest again and again some irreversible scenario like period close in MM / FI. Snapshot will allow to reverse it.

          Thanks.

          (0) 
      2. Dmitry Ponomarev

        Hi Lars,

        I assume you will have just one datavolume_xxx file for data area, or at least you cannot identify in which data area file your snapshot sits. Therefore you are forced to copy entire data area, all its files, into backup folder to be able to restore DB using snapshot later after disaster (hardware failure of db storage).

        I could be wrong, but it makes snapshot meaningless for disaster recovery.

        You have to copy data area with snapshot in it anyway, would it be easier to copy complete data and log areas together without struggling with any snapshots

        (log doesn’t look like a big addition to the amount of data one will copy… about 1/3 of data at worst methinks).

        PS. I do understand benefit of snapshot for example in QA where you need to test & retest again and again some irreversible scenario like period close in MM / FI. Snapshot will allow to reverse it.

        Thanks.

        (0) 
          1. Dmitry Ponomarev

            Hi Lars,

            I’ve read the notes, thank you. They are very helpful but still there is no answer in them  to the main question (this is where I was a bit wrong perhaps):

            why do I need to prepare data area for copying by using SQL statement ‘backup data create snapshot’.

            Because I was thinking If I just copy data area blindly – it will have some previous savepoint in it anyway – and log area is already synchronous and consistent (i.e. it can be copied at any moment without any special preparation I believe). Thus why copies of both areas will not work as a backup  without the preliminary preparation snapshot step ?!

            * * *

            Another minor puzzle is a statement from the FAQ note that the snapshot can be performed only from vendor’s admin console. Does it mean there is a hardware option to separate internal snapshot from other data area files? Could it be the reason why the preparation step is required.

            PS. Thank you for your time.

            (0) 
            1. Lars Breddemann Post author

              Ok, so you want to copy several open files while concurrent IO is happening?

              And after that, without the backup history you somehow will re-assemble the file set and cross fingers for a consistent overall state?

              How are you going to do that?

              The backup is also a method to sync up the different persistence containers for a SAP HANA installation. The storage snapshot provides all this.

              Just copying files doesn’t.

              And the FAQ was talking about the storage system vendor’s tools to trigger a file system snapshot. That has less to do with hardware but more with the tooling provided for the filer.

              But to the bottom line of your question: are there any chances that a SAP HANA could be restarted by using data/log volume files that had simply be copied while the system was up and running? The answer is: yes, that could work.

              Does anyone guarantee it would? Nope?

              Do you want to have that guarantee? I guess so.

              Would you be able to know upfront to what state the database returns after this “restore”? Nope.

              (0) 
              1. Dmitry Ponomarev

                Thanks again! Thus the main argument is “does anyone guarantee it would work”.

                I was not thinking from that angle, which is more important vs. technical reasons. You are right.

                Regarding other points (just to give my technical reasons):

                1. how to copy open files etc. – the note 1703435 says simply just copy. I think it doesn’t matter for copy routine what is inside files, if we can copy files with a snapshot (as the note says), then we can copy similar files without snapshot in the same way.

                2. how to assemble etc. – the FAQ note says that on restart DB will start automatically from last savepoint in it. And we also have log records (from that old time) which are consistent. And (again as per notes) backup catalogue can be re-created from files.

                But I’ve got your point – there is no guarantee, thus admins must not do that (if any other options available).

                (0) 
                1. Lars Breddemann Post author

                  Well, you’re not getting the full point here.

                  1. There are multiple data volume files (from the different services) involved and for a successful recovery those need to be recovered from to the same coordinated savepoint.

                  2. Copying open files without a snapshot could potentially end up in unreadable snapshots – depending on how long the file copy takes and whether pages belonging to savepoints get overwritten meanwhile.

                  E.g. when a delta merge is done, the result is persisted outside of the savepoint schedule and might overwrite the data belonging to the savepoint before the most current one.

                  As written above: it’s not like the method without the snapshot will always fail. But it could – and there’s no way to know whether it did until you try to recover.

                  And all you’ve to do to avoid this is running two additional commands. Seems like a small price to me.

                  (0) 

Leave a Reply