We are having issues with our larger systems where the scheduled FULL backup fails and consumes all the free disk space leaving the disk with 0 bytes free. Problem looks like the intermediate sql file that gets created, and eventually added to the backup zip package, eventually consumes all the free disk space causing the backup to fail and and the disk running out of space. Clearly the size of our database to be backup up is larger that the free space available on the disk. Questions:
- Any ideas on how to handle this other than NOT taking backup with the database included which is not really an option.
- If we tell DM to use a different source disk for the backup will the intermediate sql file that gets created also uses this optional source disk or will it continue to use some default location on the main disk which would NOT resolve our issues. Thanks
Adding just my thoughts on this - other admins might have different views.
Ref point 1, till the disk issue is sorted, I'd say the back up without database is your only option: if nothing else, you are still saving the DMA set up in it, correlations and so on. By failing the full back-up you aren't saving anything for your archives, so I'd check the minimum set of things you can save.
As for point 2, I seem to recall the backup is created locally before being transferred to the destination disk ~ you might test the back up on a network path - it might have a different behaviour.
The option I would recommend would be a migration to Cassandra.
Last beach resort, if you have identified big tables in the DB, you might be able to trim the data (e.g. before a specific ToA/date) and check with the support the recommended course of actions to attempt shrinking the DB after deletion of older data that is no longer relevant.
Jeff, have you already identified any big tables in the DB?
Is it viable to migrate the DMA on a Cassandra DB?