SAP Oracle Log backups

[fresh]

Currently we have a requirement to run a redo log backup when the log filesystem reaches 30%.

I setup a perl script that monitors the directory and will run brarchive if the filesystem reaches 30%.

My problem is TSM doesn't know about the status of the backup (successful or failed).

Is there any way with TSM to run those backups and get notified if successful or not?

Thanks in advance,

-fresh

 

[cheffern]

If you are running it from a script on the client side based on %, then TSM will never know.
The only way you can get TSM to report is if you run a command job from the TSM central server for this.

-Chef.

 

[dylu]

Try this in your perl script:

export U=USERNAME
export P=PASSWORD
export TSM="dsmadmc"
export tsmadm="$TSM -id=$U -pa=$P"

$tsmadm "UPDATE SCHEDULE server_domain achivelog_backup desc="Monitor Alert" act=command obj="\dir_to_arch_backup_script\script.sh" pri=3 startd=today startt=NOW+00:15 duru=MINUTES dur=15 dayofm=Any month=Any week=Any"


and restart dsmcad

 

[fresh]

I was thinking about doing something like that but I'm afraid that the database backup will get missed because dsmc schedule will be running new backups every 15 mins.

Also I would assume that you need SCHEDMODE POLLING vs. PROMPTED.

Additionally the database backup takes about an hour, what happens to the backups every 15 mins? Do they fail, do the mess up the database backup?

I guess I'm wondering how other people keep backing up their log files on a daily basis. I though about just regularly scheduling log backups to run but on occasion the filesystem could fill up quickly.

Thanks in advance,

-fresh

 

[fresh]

Anyone have an answer or any input to my question above?

 

[cheffern]

1st thing first -

redo log backup = archive (brarchive)

When you say "backup" you should refer to the overall backup, and just call the redo log backup an "archive" so as to keep things straight.

Additionally the database backup takes about an hour, what happens to the backups every 15 mins? Do they fail, do the mess up the database backup?

You obviously can't run a script every 15 min if the backup takes an hour. (how often are you taking the backup, anyway? or did you mean the archive job here?)
It is never a good idea to try to run these types jobs in tandem on the same database -
after all, they are using the very same resources...

Can you try staggering it out (the archive job) to say, 1.5 hours without filling the dir up?

I was thinking about doing something like that but I'm afraid that the database backup will get missed because dsmc schedule will be running new backups every 15 mins.

Also I would assume that you need SCHEDMODE POLLING vs. PROMPTED.

Your perl script should have nothing to do with the dsmc scheduler - right?
Because you were not using the TSM server to manage this - hence not knowing if the backup failed or not. (at least that is how I understood this)

If you were to use the scheduler to call your perl script, you don't need all the time interval stuff in the perl script as the TSM server would run it at a set interval for you.
You would, in this case, need to use SCHEDMODE PROMPTED to accomplish that.

Hope that helps / makes sense to you.
-Chef.

 

[fresh]

Chef,

Thanks for the reply. I might have been a little confusing in my question.

My "old" method with the perl script of archiving the logs everything 15 mins works great minus the fact I cannot get the success/failed status through TSM (ie. q event * *). I did however setup email notification but it isn't acceptable as management is looking for a mechanism to query the status for any point in time over a 30 day period for auditing purposes. I have managed to keep every email and had to produce some from last month, very painful.

So my hope was to use TSM's scheduling feature, which keeps track.

Right now I use TSM's schedules to run the database archives (brbackup). It only runs once a night but takes ~1hour to complete. What I was asking was. If dsmc schedule is running, then starts the database archive (brbackup), during the 1 hours backup theoretically 4 attempts to run the redo log archive (brarchives) will run if I have them scheduled for every 15 mins. Will this fail? Will it cause the database archive to fail? Will it get missed or ignored? etc.

 

[cheffern]

Ok - let me see if I get this -

Brbackup is running via TSM and takes 1 hour to complete - nightly.
Brarchive is running every 15 min...

You should not allow these to intersect -
in fact, if you look at 'h def sched' it says specifically -
" Note:
Tivoli Storage Manager cannot run multiple schedules concurrently
for the same client node."

So I suggest that you run a job via TSM 1 for the brbackup nightly -
the rest (archives) you may have to rely on your script and redirect & append the output to a file locally stored on the client side.
The archive job output would be huge, but would give you the output you need to show mgmt.
You could even go as far to write a script that saves off the output daily into a zip or compressed file, and then cut a new file for the next day.
Mail yourself the 1 file for the day as "proof".

Unfortunately as I look closer, there just isn't a real "clean" way to do things so tightly spaced within TSM without issues (when managed from the TSM side).
For example, given a priority of 5, every job does not start exactly on time.
The DURATION parameter tells it how long it has to start -
so if you allow it 15 min to start, it could very well run over into the next job, etc.
There is also an issue there with skipping the 1 hour it takes to do the DB backup, as I am sure you have found out.

The closest I run any of my archive jobs is 4 hours.
This allows me ample time for the backups to run on a staggered schedule, and then I still get the archives as well without the jobs running into each other.

Anyway, hope this helps.
If there was a chance you could run this instead every hour and 1/2 at most, that would simplify your life.
But I understand it may fill up your log dir (30% is quite low, but I get the drift...)

Maybe you will get lucky and someone else has the golden answer that they have had to work out before you posted this...
At any rate, good luck -
-Chef.