Depending on what you mean by “multiple servers” this task can be either just
some mundane elbow grease built upon the idea of “semaphore files” that dates
back to early timesharing and which Mladen outlined well for the UNIX and the
plagiarized implementations following on to UNIX to a very sophisticated task
requiring a solution to byzantine generals across all the servers involved.
If you just want a tool that runs backups on a variety of single servers, but
is responsible for only one at a time, that is a case of the former. I
recommend you keep it as simple as possible and that might mean slight
differences for each operating system.
But it is OFTEN less total cost to maintain, say, 4 separate flavors of a very
simple script than it is too build a tool that runs on multiple different
platforms without change.
When I was responsible for porting the operating system run time library for
the SPREAD™ modelling language to 28 different OS/OPsys destinations, the RTL
for each might be completely different (though they were grouped in to 7
families.) A single integrated RTL would likely still be in beta testing.
Slapping upgrades into the 7 family groups and fine tuning the slight
differences per platform within groups, on the other hand, was quite
manageable. And it has the advantage that when you change one of them you
cannot have a side effect on the others.
Therefore I strongly recommend against the notion of a script OMNIBUS.
Now if you’re going to orchestrate the possibility of kicking off the backup
jobs for “n” servers each with 1 to “m” databases from “y” different
administration consoles, I wish you very good luck.
mwf
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On ;
Behalf Of V Raman
Sent: Saturday, May 26, 2018 3:28 PM
To: Rajeev Prabhakar
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: Hello list, script scheduling question.
Thanks Mladen and Rajeev.
I am aware of that solution, this script is expected to be a 'generic' script
to work on multiple servers, so we have some extra logic on channels,
parameters etc. So there will be more error checking and possible failure
points. I will have to add a call to clean up before every possible failure
point with the file approach. Not difficult, but if something like pgrep works,
there will be less code.
Venky.
On Sat, May 26, 2018 at 10:41 AM, Rajeev Prabhakar <rprabha01@xxxxxxxxx> wrote:
Venky,
One thought that comes to mind is :
create sid specific backup status file
and if that file exists, code your script
that it won't spawn a second instance
of backup for the same sid.
Of course, for any abnormally ending
/zombie backups, make sure the
script cleans up those kind of status
files.
Rajeev
On May 25, 2018, at 5:46 PM, V Raman <vraman4list@xxxxxxxxx> wrote:
I am trying to set up a backup script to be called for various DBs in the DB
server through crontab. If an instance of the script is running for the GIVEN
oracle_sid I dont want another instance of the backup script to be started.
However, if an instance of the script is running for a different oraclesid, I
am ok with starting a new instance run of the script. Linux RHES7, bash.
I tried using grep, grep -v $$, pgrep, etc inside the script and also tried
pgrep in crontab, not lucky. Web searching has not led me anywhere so far.
Any short and sweet solution for this issue?
Thanks,
venky.
