I am having an issue with a basically a snap restore process initiated by SMO. Here are is the error message:
0001-199 Command error: Snapdrive could not import /dev/vgoerspdata1: Unable to create volume group directory
--[ERROR] SMO-13032: Cannot perform operation: Backup Restore. Root cause: SMO-11005: Error restoring snapshot: FLOW-11019: Failure in ExecuteRestoreSteps: SD-00070: Error with volume groups(s) restore: SD-10016: Error executing snapdrive command "/usr/sbin/snapdrive snap restore -vg vg1 -vg vg2 -snapname smo_1_1_f_h_1_0f0679542d56e779012d56e781ad0001_0 -force -noprompt": Starting to restore /dev/vg1, /dev/vg2 WARNING: This can take several minutes. DO NOT CONTROL-C! If snap restore is interrupted, the filespecs being restored may have inconsistent or corrupted data. For detailed progress information, see the log file /var/snapdrive/sd-recovery.log Importing vg1, vg2 Importing vg1, vg2 0001-199 Command error: Snapdrive could not import /dev/vg1: Unable to create volume group directory
After talking this out, it seems that snapdrive is doing an extra step in the restore procedure that would normally have to execute if the volume group was not under Service Guard. We think that this extra step .... which is:
A # vgchange -a -y --- is not needed and thus fails during the restore process. This failure in the restore process kills the restore on the servers side. This is a snapdrive/Service Guard scripting issue. I need help!!
I would like to find out where on the system snapdrive builds its scripts from. If the script is a text file I should be able to edit the procedure, if its an executable I'm HOSED TOMMY !!!
Note: If you have any Service Guard Clustering there are some manual things that you have to do to enable SMO to do its magic. I will not go into that unless you have a ServiceGuard Cluster environment.
If SG clustering is not your situation things should be easier -- ( I say won't straight forward)
A new database install is the best situation, so I'll start there.
1) Make sure your volumes are sized properly.
2) Make sure to brake your data base up into parts:
Lun for CTRL files
Lun for data files
Lun for archive files
Lun for temp files
Depending on what you choose for your space management software on your server:
2) A disk files system setup
These choices will determine what SMO has to do to take snapshots and restore the the database.
SMO can do either one its just in my experience, I have had to deal with ServiceGaurd Clustering which makes things a bit more complicated in terms of restoring luns to a previous backup in an LVM configuration. There are specific commands used for clustered filesystems when using HP LVM. This is my current issue I need to find out where SMO create the scripts to export and import VG's. Its seems now that SMO is building a script but to handle serviceGuard is missing an option in the command.
However if you do not have SG to deal with you should be fine. SMO works great! But you have to be sure you include the DBA in all discussions as they will be the ones using and having to really understand whats going on behind the scenes.
I had to have multiple meetings to explain the snapshot technology with the database team. We also created a test database to allow the Database folks an opportunity to get used to the technology and eventually come to like it.
Thats all I got ...
Ask questions as you get them --- and hopefully I can help further.