RE: Hello list, script scheduling question.

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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of V Raman Sent: Saturday, May 26, 2018 3:28 PM
To: Rajeev Prabhakar
Cc: oracle-l_at_freelists.org
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_at_gmail.com> 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_at_gmail.com> 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.
 

--
http://www.freelists.org/webpage/oracle-l