I went ahead and opened a case with Symantec. What they said was that restarting the Job ID from activity monitor "WOULD" restart the parent Job ID and in turn would rerun the backup for all clients which are a member of the policy as well as all scripts listed in the backup selection.
They suggested, as was posted here, to create one script per db. When a backup of a single instance fails, someone from our NOC or a DBA would need to manually run the script associated with the DB that failed from the client side. It would be great if initiating a manual backup of a policy configured for a type other than Windows NT or Standard would present the option to choose an object from the backup selection field but that simply does not exist today. They also said that while the request for a policy for each DB could be done technically, it not always optimal. It really depends on many variables of course for each environment. So what works for one company may not be optimal for ours. They suggested that for our environment, because we have Oracle servers hosting upwards of 20 instances on a single host not to create a single policy for each db / script. If we did, it would most likely become an issue with scheduling. Schedules would over lap due to the window size and time required to backup each DB. That would then create an issue performance as each policy would spawn its own set of bp processes. So given the variables for our environment, the best practice is to run manual backups from the client side using the unique DB scripts the DBAs create. Again, thanks to all that replied! +---------------------------------------------------------------------- |This was sent by norman_el...@discovery.com via Backup Central. |Forward SPAM to ab...@backupcentral.com. +----------------------------------------------------------------------
_______________________________________________ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu