Since the NMO saveset is the path of the RMAN script used to start the backup of the given database,can't you just use a local FS to store your RMAN scripts and NFS mount that location from the cluster members?
If your scenario is that you have multiple database on the given client, and you only want to backup the ones which is active on the physical host, the "documented" way of doing this is to create a client resoure for each virtual host name associated with the database. This way, when the database fails over to the other physical node, the scheduled backups can still backup this database.
So, let's say your virtual host name oracleprod.mycompany.com . Even to perform a RMAN disk backup (w/o NW), when you login to the virtual host, the script used to back up this database should be in on a file system that is owned by this cluster, or it should be local file system and NFS mounted by all the members of the cluster. So, I am missing why in your case, this is not the case. If you can provide me more details, I might be able to help better and see if our modules are not handling a scenario, which is used in real-time environment and request for an improvement.
To solve your problem, try to move the RMAN script(s) to one of the file system met the requirements mentioned above. If you cannot for some reason, there is also a feature called storing scripts to RMAN catalog using "CREATE SCRIPT" or "CREATE GLOBAL SCRIPT". So, no matter which cluster your login, you can always access to your RMAN scripts, as long as you use the same RMAN catalog:
yasemin
4 Posts
0
March 22nd, 2010 11:00
Hi,
Since the NMO saveset is the path of the RMAN script used to start the backup of the given database,can't you just use a local FS to store your RMAN scripts and NFS mount that location from the cluster members?
If your scenario is that you have multiple database on the given client, and you only want to backup the ones which is active on the physical host, the "documented" way of doing this is to create a client resoure for each virtual host name associated with the database. This way, when the database fails over to the other physical node, the scheduled backups can still backup this database.
thanks.
bairdc
11 Posts
0
March 29th, 2010 09:00
I have seperate client resources for each server, but I still get the error:
nsrnmostart returned status of 255
Because the cluster member that is not in charge of that mount point errors off the mount point is not mounted.
yasemin
4 Posts
0
March 29th, 2010 12:00
So, let's say your virtual host name oracleprod.mycompany.com . Even to perform a RMAN disk backup (w/o NW), when you login to the virtual host, the script used to back up this database should be in on a file system that is owned by this cluster, or it should be local file system and NFS mounted by all the members of the cluster. So, I am missing why in your case, this is not the case. If you can provide me more details, I might be able to help better and see if our modules are not handling a scenario, which is used in real-time environment and request for an improvement.
To solve your problem, try to move the RMAN script(s) to one of the file system met the requirements mentioned above. If you cannot for some reason, there is also a feature called storing scripts to RMAN catalog using "CREATE SCRIPT" or "CREATE GLOBAL SCRIPT". So, no matter which cluster your login, you can always access to your RMAN scripts, as long as you use the same RMAN catalog: