NMDA for Oracle - retention control (rman vs networker)

Question

Hi All,

I just came into a new environment and I've noticed that all RMAN (NMDA) backups have a browse and retention set in networker (4 weeks) and then, another one in RMAN which is set to 7 days. The DBAs do not want to keep anything past 7 days.

They do a delete obsolete in RMAN daily, then a crosscheck. What happens is that everything is deleted from the RMAN catalog based on the 7 days retention, then the crosscheck just "reinserts" everything back into the catalog, because it is still in networker!

So, what I wanted to do is give full control to RMAN for the retention instead of networker to make sure that everything is always in sync and is expired at the appropriate time (knowing that they do inc0, inc1 and inc2). After reading the NMDA guide, I found that you can simply "disable" retention control in networker by using "NSR_RETENTION_DISABLED".

I've added that option in the RMAN script, but when I try and do a full backup with that setting set to "TRUE", I immediately get the following error:

-> The retention time should not be shorter than the browse time: retention time: 1351231199, browse time: 2147483647. (105:108:11)

Is it looking at past backups which used to have their retention set in networker ? I thought that this setting would override both the browse and retention times.

Anyone has experience with the NSR_RETENTION_DISABLED option and let RMAN/Oracle control the retention ?

Thanks!

coganb · Accepted Answer

Hi,

You're correct. There doesn't seem to be any knowledgebase article pointing to this defect. I will create one and update here when it's ready. Setting NSR_RETENTION_DISABLED to true sets the browse and retention time in NetWorker's media databse to 'forever' which means that NetWorker will never expire the saveset.

-Bobby

coganb · Answer

Hi,

You are using this correctly, but there is a bug (reference NW139619) which causes this not to work. There is a patched libnsrora binary available to fix this. You will need to open a Service Request or Chat with NetWorker support and request this patched binary quoting the reference NW139619.

-Bobby

lapfrank1234 · Answer

Thanks Bobby!

I'll open an SR about this and ask for the patch.

I searched powerlink and support.emc.com for that reference bug and I couldn't find it anywhere. Looks like this one is eyes only or I'm just searching in the wrong places.

I was also wondering how it worked.. by putting this NSR_RETENTION_DISABLED option to true, does it add specific flags to the savesets so it knows not to expire them and allow RMAN/NMDA to remove them when a delete obsolete is run ? It wasn't clear to me after reading the NMDA admin book.

lapfrank1234 · Answer

Hi Bobby,

Thanks for the info. After the fix, it's now working. I'm having issues with cloning now though.

Since it changes the browse and retention to "forever", Networker now considers those as "archives" and my current cloning job doesn't work anymore, saying that I need different clone pools for "backup" and "archive" data.

Is there a way around that or I really do need to create different pools / different clone jobs just to get around that ?

Especially since it's not "archive" data and will get deleted after 7 days.

Thanks!

coganb · Answer

Hi,

I had a look at this, but I can't think of any better way around the problem other than to send this data to an archive pool instead of your clone pool. You could log a Request for Enhancement to introduce the possiblity to lift this restriction.

The only other way around this that I see is to not use the nsr_retention_disable feature and then change the browse and retention of these savesets after they have already been cloned to your standard clone pool. You could script this:

This is just an example - not for use in production.

#!/usr/bin/ksh

change_retent () {

#- you'd need your criteria here to generate a list of relevant ssid's

list_of_ssids=`mminfo -q "client=[client name here],savetime>1 day ago,pool=Default Clone" -r ssid

for savesetid in $list_of_ssids ; do

nsrmm -S $savesetid -e "forever" -w "forever"

done

}

change_retent

The system does allow for a change to 'forever' for data that is already in a clone pool. I think the use of a separate archive pool is probably a cleaner and easier solution though.

-Bobby

NetWorker

NMDA for Oracle - retention control (rman vs networker)

Was this post helpful?