Execute any procedure???

Question

Inorder to execute the job at the allotted time the user need to be able to create a procedure and execute it.
but is execute any procedure privilege required to enable scheduling???
what could be the reason??
this allow the user to run procedures created by other users, right?

Answer 1

Hi Visakh
From my own notes here is what I have:
Setting up Workbook Scheduling
==============================
The workbook scheduling feature in Discoverer uses native features in the Oracle DBMS, and is therefore only available when running against the Oracle database. This feature uses the same highly scalable and reliable processing procedures within the kernel, since the summary management capability and the setup for both features is similar. These procedures use standard packages in the DBMS called DBMS_JOB.
To enable the processing procedures for workbook scheduling in Discoverer, follow these steps:
A. Grant Schedule Workbook Privilege to the user.
B. Confirm that DBMS_JOBS has been installed.
C. Specify result set storage.
D. Set the time period at which the process kicks in.
These procedures are described in the following sections:
A.  Grant Schedule Workbook Privilege to the User
The user must be granted the Schedule Workbooks privilege in the Privileges dialog. Connect to the Administration Edition, and grant the Schedule Workbooks privilege in Tools | Privileges dialog.
B.   Confirming that DBMS_JOBS is Installed
1. Log onto SQL*Plus as the Administrator, and execute the following SQL statement:
SQL> select * from all_objects where object_name='DBMS_JOB' and object_type = 'PACKAGE';
2. If you get no rows returned you need to install this package. Your DBA will know how to do it.
C.  Specifying Result Set Storage
When a scheduled workbook is run, the results are stored in database tables within the database. The resulting data created as part of the workbook scheduling process may be stored in one of two areas: the user's own schema or a centralized schema.
User's Schema
In order to enable workbook scheduling in the user's own database schema, the user requires the following database privileges:
Create Procedure - needed to create the job
Create Table - needed to create tenporary holding table(s) for the results, each run of the same scheduled worksheet produces a new temporary table - see general notes at end for more help
Create View - needed to pull the results from the database
You will also need these three grants:
SELECT ON SYS.V_$PARAMETER;
EXECUTE ON SYS.DBMS_JOB; won't be able to execute the job without this
UNLIMITED TABLESPACE; needed to stop user's schema running out of space while creating the table(s) of results. Discoverer does not leave it to the DBA to set artificial limits. The only way it knows for certain that it will have enough is to have this privilese.
As you can see, execute any procedure is not needed.
When the schedule is first created a view is created. This allows Discoverer to run that view at the scheduled time using whatever conditions and parameters you have set. The results are populated into the table when the query is run. If you subsequently have multiple sets of results you will see them named T1, T2 and so on.
To grant these privileges, do the following:
1. Log onto SQL*Plus or SQLDBA as the Database Administrator.
2. Type the following:
SQL> Grant CREATE PROCEDURE to <USER>;
SQL> Grant CREATE TABLE to <USER>;
SQL> Grant CREATE VIEW to <USER>;
where <USER> is the userid of the person who is to be allowed to schedule workbooks.
These privileges must be granted directly to the user and not to a database role.
Advantages: A database limit can be specified on the maximum amount of data a user can store in the database. If the result set is stored under the user's schema, then you keep control over the maximum amount of space one individual user can fill with result sets. If the user creates a scheduled workbook that fills that space, it affects only his/her own scheduled workbook.
Disadvantage: The user is required to have the above privileges in the database.
Repository User's Schema
In order to enable workbook scheduling using a centralized repository user's schema, the SQL script batchusr.sql must be run in SQL*Plus or SQLDBA as a database administrator (such as, SYSTEM). This script creates a new user that is granted the above privileges.
In addition, the administrator of the EUL must change the user so that the Repository User property is pointing to the repository user's schema just created. The centralized repository user's schema may be customized by the database administrator for space management purposes and underlying data access.
NOTE: SELECT ANY TABLE access is given by the script batchusr.sql, but this may be limited provided the repository user's schema is granted access to the underlying data that will be accessed for workbook scheduling.
The repository user created will not be able to directly schedule a workbook through the User Edition.
Advantages: Each user does not need DML procedures to run scheduled workbooks.
Disadvantages: One user can potentially run a scheduled workbook that fills the available result set space, preventing other scheduled workbooks from running until it is cleared.
D.  Setting the Start Time for Workbook Processing
The workbook processes run within the database on the server, and are controlled by parameters in the initialization file of the Oracle DBMS - the INIT<SID>.ORA file.
To limit the number of processing requests that can run simultaneously:
The parameter job_queue_processes specifies the number of concurrent processes to use to process DBMS_JOB. It controls the number of processing requests that can be handled simultaneously. The default value is zero, which means processing requests will not be created. You should set it to a minimum of 2 or more if you have any other applications that use DBMS_JOB.
You need more than one job queue process, because if one job fails for any reason, it may keep getting re-submitted, and thus, prevent everything else in the queue from being completed. If you want to have 10 simultaneous processing requests handled, then you will need to set this to 10.
The INIT<SID>.ORA parameter job_queue_interval is the time in seconds that controls how often the job processes wake up to process pending jobs. The default is 60, which is quite frequent. What you set this to depends on how frequently you want the process to wake up and serve the requests that have been made. Oracle recommends that you update the 60 seconds default to at least 10 minutes (a value of 600).
NOTE: This parameter also affects summary management.
To enable these parameters:
1. Locate the INIT<SID>.ORA file.
For example, on Personal Oracle7 the INIT<SID>.ORA file is held in <ORACLE_HOME>\database. Its default name is INITORCL.ORA where ORCL is the <SID> name.
2. Enter 2 lines into the file. For example:
job_queue_processes = 2
job_queue_interval = 600 (equivalent to 10 minutes)
GENERAL NOTES:
The summary management and workbook scheduling features both use this scheduling capability within the Oracle DBMS. The interval you specify and the number of concurrent requests affect both features.
The results from the worksheet are held in a temporary table until you remove the results or you delete the scheduled workbook.
Tables look like this: EUL5_B060914015847Q1R1
Views look like this: EUL5_B060914015847Q1V1
These temporary tables are stored within the schema of the user who owns the workbook - not within the standard EUL schema. The format of the table is as follows:
EUL5_B060914015847Q1R1 which can be broken into six separate pieces.
These pieces are as follows:
EUL5_ B YYMMDD HHMISS Q9 R9, where
EUL5_ is a fixed name
B means Batch and is a constant
YYMMDD is the date that the worksheet was run,
HHMISS is the time when the worksheet was run, the time is in the 24 hour clock format,
Q9 means this is the letter Q followed by a number - E.g. Q1, which signifies the query number. I believe Oracle have some plans to allow multiple queries but for now this is always Q1,
R9 means this is the letter R followed by a number - E.g. R1, R2 and so on. This is the run number.
Using the above logic therefore, this is a valid example:
EUL5_B090914015847Q1R1
This means this is result set number 1 for query 1, run at 1:58:46 AM on 14th September 2009.
So if you can figure out which worksheet was scheduled and when it was run you can build a view that sits on top of the latest table to give you the latest results. Something else which adds interest here is that the column names within the table do not match the column names as in your original query. The scheduled results column names use generic names such as BRVC1, BRVC2, BRD1, BRD2, BRN1 and BRN2.
These are codes and can be interpreted as follows:
BRCV1 and BRCV2 mean Batch Result Var Char 1 and 2,
BRD1 and BED2 mean Batch Result Date 1 and 2,
BRN1 and BEN2 mean Batch Result Number 1 and 2
Best wishes
Michael