1. MaxDB is still available as community plugin. All plugins are available through community just if you use them you dont get NGS support. Only plugins that ship and are included with SC are supported by NGS. As of SC 3.5 MaxDB plugin is supported and ships with SC.
3. There is no special file system layout however it is strongly recommended to separate logs and db files on separate netapp volumes. In addition NFS makes things quite a bit simpler from a recovery / restore perspective.
Solutions builder which is a tool partners and netapp have access to has the detailed documentation and procedures. Since not sure if you have access I have attached DOC for MaxDB and SC.
Snap Creator will restore the data but not perform recovery. You need to preform recovery of MaxDB manually after doing restore in SC. If you want you can automate this through SC using RESTORE_POST_CMDs. Again recovery procedure is attached in document form solutions builder.
I've tested now a little bit with the restore of the database. Unfortunately I've some problems... maybe you have an idea.
Restore Data Volume --> db_restartinfo --> Needed Pages are still in the LOG Area --> db_restart ---> DB online with latest state
Restore Data Volume and LOG Volume --> Needed Pages are not completly in the LOG area --> so I have to restore archive logs
--> recover_start <medium_name> log 005 --> after that the database goes online! But we don't have the latest state.
Is there a way to prevent the online state and continue with next logs with recover_replace log 6 ?
I wonder why the database goes online... if I restore the log area from the backup, it can not contain the latest log information. So if the db goes online the page is not the one which is contained
in the latest log file.
Do you have any idea?
When you do a traditional maxdb restore via Backup Images, you would normally reinitalize the database and log area.... but when I restore the data and log vol from the snapshot it's the same I guess...
I'm a bit confused about this fact at the moment....
Nachricht wurde geändert durch: Andreas Jankowiak
Seems I have to clear the log area first with db_execute clear log.
After that I can recover sucessully.
Bad thing is, that the history log gets status histlost.
SnapCreator for MaxDB has a Y/N switch for that, you can choose.
Based on my research until now this would not be necessary for Netapp/NFS and if all data files are on the same volume. For NFS with data files spread over multiple volumes there would be volume-groups. I think the suspending of the MaxDB logwriter would be used in cases like a SAN where the storage controller has no visibility of the file system which in that case is owned by the host OS.
> Automatic Savepoint Not sure, but I think there is a feature in MaxDB to trigger an automatic Savepoint in less busy databases every <x> minutes. You could always use a SnapCreator Pre-command for that or just test it: there must be a DB table like V$Savepoints which stores this information.
> MaxDB Versions
I'm not involved is the development of the plug-in but I would expect it to work with all current versions like 7.6, 7.7 and 7.8.
> Case 2 - Point in time recovery
You executed a "recover log #" so I think it will at the end of that log, start the DB and this is what you requested.
If you need a point in time recovery which does not go to the very latest Savepoint (that's case 1) the syntax
would be something like "db_restart -until <date> <time>".