backing up twice

attaching an example of the various backup group runs that show this behaviour

the RMAN script has not changed at all, its been the same for the past 6 months, and this issue has started 1 month back.

you're correct about the names of backup sets from RMAN are different, but the backup size itself is more than the size of the database, thats not some thing that happens with Oracle RMAN as it compresses the backup.

what i see is the same "sequence" for the same "size" of backup set even if the names are different..

now recently what has happened is: "index pool" tape is separate from the other tapes, and after every backup, NetWorker writes the index on this tape, and of late this tape does not un-mount after the backup is done.. it needs to be physically unmounted. but some times it does it automatically.. its an intermittent issue..

I see that you refer to same size in log details and most likely that is true, but you also see that name of backup set is different - which is rather normal with RMAN.  Therefore, to see what is going on, you need RMAN output which will contain lines of RMAN script along with execution log and then it will become clear to you why is this so - it might be that Oracle admin changed script and now everything gets backed up twice

Unmount is controlled via paralemer.  Anyway, back to original issue; you must check RMAN log.  Do you have RMAN log?

Hi mnjm

is this rman backup group push or pull backup? if pull, in the group, check restart window..maybe showing default 12:00...change to 18:00 or 20:00

let know if that helps...

Interval means how often your backup will run within 24 hours.  Not sure how long it takes now, but interval of 6 hours (if it would run within 6 hours) would mean running this same backup 4 times a day.  Not sure I see the point of that with DB backup.

What you need is really timestamp so that you can cross check that with times in daemon.raw.  With NMO you could use something like NLS_DATE_FORMAT=DDMMYYYY_HH24:MI:SS, but in NMDA (until 1.5 which is beta) this is not possible so you need to add in RMAN script something like:

sql "alter session set NLS_DATE_FORMAT=''DDMMYYYY_HH24:MI:SS''";

This will give you times with HH:MM:SS and not just dates.

correct.. another thing i was suggested was that the "interval" should be reduced from 24 hours to 6 hours..

and incremental should not be used.. but I reviewed the networker admin's guide, it does'nt look relevant to me.. what do you think?

as for RMAN log, it shows the backup had completed the same day while networker as we see is dragging it's feet..

i can share the RMAN log and script if needed.

Hi Hrvoje

Pull - scheduled backup

Push - client initiated backup (typically by script)

Restart Window – How many hours after the start time will the group, if restarted, only re-run those savesets that failed or never ran, instead of re-running the entire group. (Defaults to 12 hours.)

In our env, we realized it ran twice and it was due to Restart Window...not only backing up failed ones but entire savesets...it ran automatically though...

It is a bit strange that it run automatically (well, there is automatic restart property on group which I don't use, but I believe in the past that was related to clusters only). I think best thing mnjm can do is to:

a) enable detailed time logging at RMAN level

b) have one such group running

c) have both daemon.raw and RMAN log for that run attached here

From there it should be more clear what is going on.

hello Hrvoje..

i'll be trying that today.. however i think i found some tape corruption..

could you pls check 2 attachments i'm giving from

1. Devices--> Libraries

2. Media--> Tape Volumes

Thierry101- your issue looks similar to mine.. but do you think restart window could be the culprit?

You can get there when nsrmmdbd is killed (like restarting machine during media check), but you will most likely find data is expired already.  You can check that by doing query to ~194BBKL4-1 (eg. mminfo -avot -q "volume=~194BBKL4-1" -r name,ssflags,sumflags and then check flags).  Another way to see this would be to run mminfo -av -r volflags,volume,state and check state value for given volume name.  If it can be removed, just remove it and relabel original volume then.

do you think this could be the root cause of the issue of long running backups that i'm facing?

mnjm wrote: do you think this could be the root cause of the issue of long running backups that i'm facing?

I can't see how it could be related. To be honest, I recently found 4-5 of those in my env too - no idea when this happened, but I found them during mdb cleanup (as I went from VTL to pure DD disk devices) and I could not see any relationship to anything else in my env.