| More considerations of database batch job [message #117928] |
Sun, 01 May 2005 13:03  |
chunyuh
Messages: 13
Registered: April 2005
|
Junior Member |
|
|
Usually DBA have many batch jobs running on production database environments and many of these batch jobs are actually shell scripts which invoke SQL*Plus to do DB tasks. Usually, batch jobs are scheduled to run by crontab.
A typical batch job looks like:
export ORACLE_HOME=...
export ORACLE_SID=...
export PATH=$ORACLE_HOME/bin:$PATH
sqlplus -s /nolog<
connect userid/passwd
--sql statements here
quit
EOF
Some concerns We have are:
1. batch job could fail because SQL*Plus can not connect to database for exceeding max sessions limit. We can not suppose that there are not many connections to Oracle when batch job runs.
2. Even SQL*Plus can access Oracle, it's still a lot of cost for SQL*Plus to connect and discconect again and again.
3. Crontab is not perfect. First, cron daemon examines cron entries once every minute, which is not very satisfactory. Second, crontab can be changed by anyone who can have oracle OS account access. We want a more restrictive protection mechanism for submitting or changing batch job.
Solution:
A batch job system should be developped. This batch job system should take all the above 3 points into consideration. The main idea is:
1. A typical number of Oracle sessions are kept for batch jobs. The number should be configurable.
2. Authentication, Authorization and Accounting (AAA) functionality should be included for submitting or changing batch jobs.
3. An admin dameon is listenning the request from the users all the time. A commond line user interface is provided for user to submit or change batch jobs. GUI is not necessary. 
Perl can be used to develop this batch system quickly.
Original Post is http://mtsmart.kmip.net/archives/2005/05/more_considerat.html
|
|
|
|
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
