A reader, February 21, 2016 - 7:06 pm UTC
Yes you are right, this is actually how I have the scripts running at the moment. I have some scripts running from database control and some in cron. My reasoning for wanting to run from within the database is to avoid the schema password in plain text within the scripts (solved that using external identified user), allow the script to run on any available RAC instance and easy to disable. My other reason is cron is not very user friendly, if there are a lot of jobs in cron, it can be hard to glance and find what you are looking to change (Maybe there are GUI tools I am not aware of). Scripts that need to be run on the OS would be called from within the pl/sql scripts. For example one of the jobs I run has the following steps
- use ftp to pull in flat file from filezilla server
- sqlplus script to load the flat file as an external table and import it into an oracle table
- send an email to an external agency with a subset of that data
So my shell script calls an ftp script and then calls the sql script and then calls a pl/sql procedure to email the file. I figure using one pl/sql script for the entire process makes more sense and I dont have to worry about schema passwords and it is easy to see all the jobs for that particular database under dba_scheduler_jobs.
The create program package allows me to create the program but how do I execute it?
Come to think of it if the database has packages that can handle emailing, ftping, write and read files there might be no need for shell scripts at all.
fynix, February 21, 2016 - 7:22 pm UTC
I forgot to mention, database control and its issues in a RAC environment is what got me thinking about this in the first place. If the node running the EM console goes down then the procedures won't run and currently management is cutting budget so getting a server for running OEM is like pulling teeth lol.
February 22, 2016 - 12:29 am UTC
:-)