We are using the br* tools to backup out SAP-systems (R/3 4.5B, Tru64, Oracle) without any backint software or something.

On our production system I make an full online + archive log backup every working day and once during the weekend.

But what to do if there runs a very big job, which make the archivelog-filesystem full? If I write a little script in unix which is watching about that I have the problem that brarchive begins every time I call it a new tape... And if I make a brarchive -f what happens if anybody changes the tape during this is still running?

Any suggestions or hints?

Thanks in advance for reading this
 

We have asked the users to send us a message before they schedule a job that generates lot of redologs.
If the saparch is nearly full we gzip the older redulogs and store in a temporary backup directory.
We tried the brarchive -f but it didn't work properly... maybe it is corrected now...
 

Here are couple of tips:
1. backinit is a agent from 3rd party Backup software.
2. Schedule a redolog back up at least twice a day or more...it depends on the activity.... and will ensure that your dont get archival stuck message.
 

There are many answers to this, it really depends on how much you are willing to change your current backup schedule:
1) no impact - add a pair of 36GB or 72GB drives (or whatever) to your server, mirror them, and move your brarchive directory there, should be lots of space for redolog files for big jobs. I like this best, especially if you get enough disk space, you can actually use the copy_delete_save option so you get 2 tape copies of the same redo log files.

2) almost no impact - as previously suggestet, anytime anyone does anything big, then have them let you know in advance and you can do brarchive -f 5 onto a scratch tape (I always have one at the end of each magazine in the library) and then before the backup starts, brarchive -f stop If some rocket scientist doesn't give you warning, simple explain to his manager that his
incompetence was the reason the production system halted and I am sure he will be more cooperative next time.

3) big impact - double your tapes and do redo logs seperate from your backups, again, you can schedule (in your OS) brarchive -f 5 after the backup is done and brarchive -f stop just before it starts again.

4) big impact but best solution - get another tape drive of same type (DLT or SDLT or whatever) and do solution 3 but to a seperate tape drive.

One final note to everyone:
I know for at least versions 4.6x, no matter what kernel you have (I am running 4.6B with 4.6B kernel) you shoud still use the 4.6D br tools and sapdba (if you are running windows, just make sure you put librfc32 in the right place). There is a note on this, don't have it handy though.

Make sure you download the MKS 7.5(?) tools (dd, etc) from SAPs FTP server.
 

1) We've about 50 GB capacity for our redologs..... But our realy BIG jobs write this 50 GB full in less than 48 hours

2) I and our DLT-Library don't like SCRATCH-tapes.

3) That would be fine, but what about tape-change??? How can I tell the running brarchive -f that there is another tape in the drive, especially if I don't know the time of the change?

4) I've "solved" it know for me in the following way: The very BIG jobs are started during the weekends, there will be know tape-changes so I can start brarchive -f on friday and brarchive -f stop before the backup an after it brarchive -f again. Like your (2.)!
 

Beam Back to Basis Index SAP Cafe for Basis Components Beam Back to Main Index SAP Cafe for SAP Professional