Several snapshot for one SMSAP backup [ Edited ]

[#1]

IHAC is using SMSAP, he found for one backup, there were several snapshots, he wants to know why?

21% (21%)    7% ( 7%)  Oct 20 20:13  smsap_naawcn101_cn1_p_h_3_8ac383e52bc985a8012bc985ad9b0001_0

21% ( 0%)    7% ( 0%)  Oct 20 20:12  smsap_naawcn101_cn1_p_h_2_8ac383e52bc985a8012bc985ad9b0001_0

21% ( 0%)    7% ( 0%)  Oct 20 20:04  smsap_naawcn101_cn1_p_h_1_8ac383e52bc985a8012bc985ad9b0001_0

21% ( 0%)    7% ( 0%)  Oct 20 20:02  smsap_naawcn101_cn1_f_h_2_8ac383e52bc98356012bc9835d610001_0 (snapvault)

21% ( 0%)    7% ( 0%)  Oct 20 20:01  smsap_naawcn101_cn1_f_h_1_8ac383e52bc98356012bc9835d610001_0

Anybody knows what are those p_h_* and f_h_* mean?

Thanks,

Jeff

[#2]

These snapshots belong to 1 full backup

21% ( 0%)    7% ( 0%)  Oct 20 20:02  smsap_naawcn101_cn1_f_h_2_8ac383e52bc98356012bc9835d610001_0 (snapvault)

21% ( 0%)    7% ( 0%)  Oct 20 20:01  smsap_naawcn101_cn1_f_h_1_8ac383e52bc98356012bc9835d610001_0

and the following belong to 1 partial backup

21% (21%)    7% ( 7%)  Oct 20 20:13  smsap_naawcn101_cn1_p_h_3_8ac383e52bc985a8012bc985ad9b0001_0

21% ( 0%)    7% ( 0%)  Oct 20 20:12  smsap_naawcn101_cn1_p_h_2_8ac383e52bc985a8012bc985ad9b0001_0

21% ( 0%)    7% ( 0%)  Oct 20 20:04  smsap_naawcn101_cn1_p_h_1_8ac383e52bc985a8012bc985ad9b0001_0

Snapshot is taken at volume level and hence number of snapshots will be same as number of volumes (number of volumes that constitutes the db)

f -> full backup

p -> partial backup

h -> hot or online backup

Thanks,

Nithyananthan S

[#3]

Jeff and Nithyanathan,

During the backup, SnapDrive will attempt to quiesce the file systems and LUNs to acheive a consistent state for the snapshot.  In the event that it is not able to do this within the timeout period, SnapDrive will then create individual snapshots on the volumes.  This is why you see three snapshots for the same volume.  The "p" refers to partial, as it is a partial backup of the database.  The "f" is for full.

This is quite possible a result of your storage layout, however, without the details regarding the layout and configuration of your system, it's impossible to tell.  It's important that the best practices are followed when laying out the storage for your SAP environments on NetApp.  Please review TR-3533 SAP with Oracle on UNIX and FCP and NetApp Storage. This document discusses how to properly configure storage to support SMSAP.  Another excellent resource is TR-3823 Best Practices for SnapManager 3.0 for SAP.

Regards,

Craig

[#4]

Craig,

After checking with the customer, those SnapShots would be generated within one SMSAP backup.

Why in one backup, some snapshots are marked as full and some are marked as partial?

I attach one of SMSAP backup log file.

Thanks,
Jeff

brbackup.txt.zip ‏6 KB

[#5]

I'm on leave from 30th Oct to 12th Nov. Please contact my manager

Senthil (senthilk@netapp.com) for anything urgent.

Thanks,

Vrishali

[#6]

This happens because you have invalid storage layout, (e.g.. LUNs with various Oracle files in the same volume) which is forcing SMSAP to create several snapshots for the same volume.

You can verify that by selecting the hot-backup in SMSAP GUI , selecting "override" mode (to force so called "fast restore via snapshots") and then doing restore. It is going to probably to fail rendering your SAP enviorniment useless, but you might have chance to do the default SMSAP restore, but then it is going to be long (AKA file-based copy restore).

-Jakub.

[#7]

I'm on leave from 30th Oct to 12th Nov. Please contact my manager

Senthil (senthilk@netapp.com) for anything urgent.

Thanks,

Vrishali

[#8]

Customer is using brbackup and brarchive to do the backup.

For the f_h_* related snapshots, in the TR3823, SnapManger for SAP 3.0 Best Practices, on page 25, there is the explanation about those two snapshots.

The following example shows two Snapshot copy names created for the datafiles volume and the control files volume. The second Snapshot copy listed has “_f_h_1_“ in the middle of its name. The "1" indicates that it is the first Snapshot copy created in the backup set. The first Snapshot copy listed is the most recent and has a "2," which means it is the second Snapshot copy created. The "1" Snapshot copy includes the datafiles; the "2" Snapshot copy includes the control files. Because the control file Snapshot copy must be created after the datafile Snapshot copy, two Snapshot copies are required.

Those three p_h_* snapshots should be generated by brarchive, but why there are 3 snapshots? Anybody knows that?

Thanks,

Jeff

[#9]

I'm on leave from 30th Oct to 12th Nov. Please contact my manager

Senthil (senthilk@netapp.com) for anything urgent.

Thanks,

Vrishali

[#10]

Jeff,

I can't say exactly why there were three snapshots created.  I think Jakub is correct that the storage layout may not be in line with best practices, which can make it difficult for SDU to quiesce the file systems within the window necessary to create a consistent backup.  As a result, it defaults to doing partial backups of the volume and quiescing only a portion of the file systems each time.

Please review the documents I mentioned in an earlier reply to see if your storage layout could be the culprit.

Craig