I would recommend using SNAP_TIMESTAMP_ONLY=Y since with _recent we need to rename snapshots, this can slow down process and cause you to reach cg timeout, medium is 7 seconds so not doing rename is prefered.
Consistency Groups are done on a per storage controller basis, since that is what ontap supports. There is no such thing as a consistency group that spans controller, the main thing however is doing cg-start on all controllers before doing commits so that you have a consistency point.
Since oracle will not send a write without previous write being complete you just need to cg-start on all controllers which SC does.
SC does the following process for your config
This is pretty much the best you can do. One small improvement would be to send the start and commit calls in parallel, SC does it in serial since this would increase speed. We are planning that for a future release.
Also in SC 3.4.0 (will release end of June) we added a wafl-sync before cg-start as option which also can increase speed and prevent timeouts
We recommend combining this with our Oracle plugin, it certainly doesn't hurt putting Oracle in backup mode
If you are on AIX you can freezee any actvitiy on VG by using chvg -S/-R... that's actually what snapdrive does. Your single VG can span across multiple LUNs on multiple controllers. I'm not so sure what to do with NFS across controllers on on other OS'es.
If volumes are spread accross storage controllers it depends on application. CG snapshots are within a storage controller so SC will end up creating a CG per controller meaning CGs are not 100% consistent with one another.
However if application issues write dependent writes (meaning first write must be successfull before it sends another write) then they will be consistent since as long as one CG has it's bubble up the application will hold writes and wait which we want it to do.
You can control the wait time in SC since CG has a timeout
For ASM and oracle snapdrive puts DB in backup mode and does a CG snapshot. It does nothing to file system, so this would apply for NFS. In ASM volumes are spread all over file systems.
In summary it is a combination of CG and Application that make things work (write dependent writes)
Well you your thinking about applicannot is correct when you are thinking from storage point of view... however if you are using LVMs then you must take into consideration that something folloowing like this might be happening:
a) /bin/HelloWorld wries 1MB to /test/file1
b) AIX recieved the write() syscall and passes it to VMM/FS layer
c) FS layer identifies that /test fs is on testLV which is on testVG
d) testVG is e.g. stripped across >= 2 physcial volumes
e) you write 1MB to one of the physcial volumes (PV) becasue the (in e.g. AIX) Physcial Partition (PP) size is let's say 32MB.
Now taking into consideration that HelloWorld can be run in paralell (or anything else writes to /test/) even if you freeze FlexVol on controller1 (handling 1st PV/LUN) there is absolutley no guarantee that the 2nd controller is not going to be used.
Enter Oracle: Yes it appears that DBWR can issue ordered application writes, but how do you know that? Do you have access to source code for every Oracle C source code file ? And what is happening if direct write path was used e.g. during loading from SQLLoader or during INSERT /*+ APPEND */ .. ?
That's why i'm thinking that suspending VG (especially writes) is very good idea. You have frozen writes at VG at some identical point to all VGs.
Now when it is mixed hot-backups it can give yet another layer of protection in my oppinion. Your oppinion and testing can vary. Even thinking about it is is pretty interesting
Like I said CG is only IO consistent inside a CG and a CG doesn't span controllers 1) so with one controller and many volumes, no problem under any condition using CG 2) many volumes many controllers, you need write dependent writes or write ordering as you refer to it from Application.
If we have write ordering, you can spread volumes across controllers and use CG, if not then you need to look at freezing LVM as you mentioned or something else. All of which can be done through Snap Creator since it is a framework by providing simple commands or scripts to handle LVM layer.
You are correct all three methods are valid. Method 1 and 2 rely on you creating oracle script or sql commands and using APP_QUIESCE_CMDs, APP_UNQUIESC_CMDs, as well as PRE_EXIT_CMDs.
Option three uses SC built-in oracle plugin APP_NAME=oracle
The SC oracle plugin will do following:
quiesce - begin backup mode
unquiesce - end backup mode, switch logs
Archive log only
Optionally with ARCHIVE_LOG_ONLY=Y SC will do following:
quiesce - switch logs
unquiesc - nothing
This allows you to separate data from archive log backups if desired. Best practice is to create 2 configs 1) for data files 2) for archive logs. If customer wants to backup everything you would run archive log config from within data config as a POST_APP_UNQUIESCE_CMD01 or NTAP_POST_CMD01.
The adv of using oracle plugin is it is supported. SC is supported but if issue occurs with cmds or scripts you are running those wouldnt be supported, of course we would still try to help. Another adv is discovery VALIDATE_VOLUMES=data. SC determines if we are backing up correct data files, this is optional but does require snapdrive for non NFS.
In the end it is your decision, that is what is nice about SC, you have lots of choices and flexibility.
There is also an unsupported oracle backup script on communities we have used for 8 and 9 which arent supported by SC buikt-in plugin, that may be interesting, it isnt well documented though but if interested I can try and help you out.