Yes John, what are the commands that we execute today to our database with backup stopped.
We have old scripts CMD (which will migrate MAXL to late)
disablelogin "$ _App"
unloadapp "$ _App"
The problem is that we talk to the backup Essbase Runtime?
Or if you disconnected the users or if you kill the calculation ? measure the impact that can doing if calculation was not terminated ?
What is the value added from this method? and the stopping database ?
We should find a good process to switch on read only mode to integrate the back up in runtime withiout disturb the users.
indeed, a good process should not disturb the users and do a reliable backup.
You have chosen to backup the .ind and .pag files by setting them into read-only mode and then copy them at OS level into a backup. To set the database into read-only mode, all users and requests must be stopped. You might give them priority by trapping the error-level of setting it into read-only mode and try it later the night again. So you will give the processes a chance to finish.
This might become problematic when the processes are taking too long and there is no backup possible. So you have to choose between bad and bad.
You might also consider the data backup with an export at level0. Assumed (and we all should do this) that data is loaded only at level0, you have a good method to backup your data. In case of a restore, you need to run the calculations that would generate level0 data again and then aggregate all data. This can take longer, but the other advantage is (when the export is on column format) a partial restore.
You will also need only a fraction of the backup space. BTW, no, do not do an incremental backup. This does not work for Essbase.
You can have this scheduled to run over night with some job scheduling system may be autosys,cron, etc..
If you want this to happen with a run time mode then already experts have suggested above , by which you can keep your db in read-only mode and what would be impacted if you are in read-only mode.