Advanced Techniques for the Oracle Reports Server. An Oracle Technical White Paper March 2000

Transcription

1 An Oracle Technical White Paper

2 INTRODUCTION The benefit of Internet Computing, that is universally accessible information, is also one of the greatest causes of concern for those whose job it is to administer the web site. That is, the web site must scale to meet the requirements of the increased user community and also ensure that only those authorized to see the information can do so. User satisfaction for a web site is determined not only by the information served, but also by the speed at which it is delivered. If the site is unable to serve information in a timely manner due to increased load, users are less likely to use the site. Therefore it is extremely important that the underlying architecture scales to meet the user expectations. In addition, it is often the case that user authorization is defined not only by the privileges on the data itself (that is, database object level privilege) but also the functions performed on it. As access to a web document is through the use of its Uniform Resource Locator (URL), knowledge of the URL allows access to any unprotected document. To combat this, most web servers allow for the securing of the directory in which the documents may be found but are unable to secure individual files within that directory. The use of CGI executables to serve up dynamic pages has allowed many organizations to personalize the users view of the available information. These complex CGI coding techniques have not really addressed the issue of application-level security. Hence, it has been difficult for most web sites or information Portals to implement much more than the most rudimentary of security models. This paper focuses on the security and scaleability issues faced by system administrators when implementing a centralized reporting infrastructure. Specifically, it looks at the functionality available within the Oracle Reports Server to address these issues, and indicates the tasks required to implement it. It does not cover the design of the Reports Server and assumes a basic understanding of the architecture and the methods required to implement it. Note: For further information on the Oracle Reports Server please refer to the white paper Enterprise Reporting available from FUNCTIONAL SECURITY In it s simplest form, an authorization scheme designed to enforce application level security (one based on the right of the user to access the function as well as the data) should allow for the definition of the following criteria: 2

3 Who has the appropriate privileges to access the defined function or object. What business functions and objects are available to be accessed. When may the defined function or object be accessed. That is, is the availability determined by either organizational or procedural controls (e.g. only available during business hours or after the close of books in a financial period). How may the function be implemented by the user. That is, given the authorization to access given function a user may only specify certain parameters to that function (e.g. may only specify output formats or printers). SECURE ORACLE REPORTS SERVER By integration with the Oracle WebDB security model Oracle Reports is able control user access to defined reports being run against the Oracle Reports Server. As a user makes a request for a given report to be generated, Oracle Reports uses the information stored within WebDB to verify their access rights to run the requested report at that time and on the requested server. The security model of WebDB is tightly tied to that of the database itself. That is, the definition of a user within the WebDB environment matches a schema within the Oracle RDBMS. The use of roles allowing for the definition of both functional groups (e.g., DEVELOPER, CLERK) and a hierarchical security structure. The Report itself is represented as a packaged procedure containing the relevant information on how to run the report. Once a user is defined within WebDB they may be included within the security framework of Oracle Reports. Though the creation of a user within WebDB results in the creation of a user within the Oracle database it is not required that the report being executed connect to the database as that user. Oracle Reports differentiates between an application user and the database user used to connect to the data server (though they are often one and the same). The use of AUTHID (discussed later in this document) allows the Site administrator to differentiate the application user from the database user. NOTE: Application users are currently authenticated as a user defined within the database, future releases of WebDB, however, will allow for the authentication of users in a number of different ways, from a lightweight authentication model to use of external sources, such as an LDAP server. 3

4 In order to implement the Secure Reports Server it is first necessary to perform a number of steps prior to the definition of the security model itself. 1. The definitions held within the WebDB repository which relate to the running of secured Oracle Reports are an extension to the standard WebDB installation. As such, it is necessary to insert the required object definitions and related menu structure into the Administration area of the WebDB application environment. This is achieved by running the supplied installation script (%ORACLE_HOME%\Reports60\Server\Security\RWWWVINS) within the same schema that was used to install WebDB itself. The script will create the appropriate Object definitions and menu entries as well as define the RW_BASIC_USER, RW_DEVELOPER, and RW_ADMINISTRATOR roles. NOTE: In order to define Reports access security via the Oracle Reports Security Wizards within Oracle WebDB the user must be granted the RW_ADMINISTRATOR role (otherwise Reports Security Option will not appear as the user menu structure). In addition the user must have BUILD IN privileges to any schema that will own the Reports Packaged Procedure or List of Values used within a parameter form. 1. The Reports Server must know where to look in order to find access privilege information. That is the server must be told the name of the database instance in which WebDB and the security repository have been installed. It is necessary to: 1.1 Add an alias in the TNSNAMES.ORA file on the machine where the Reports Server is located which points to the instance where WebDB is installed. 1.2 Add an entry SECURITYTNSNAME= <tnsname alias> in the Reports Server configuration file (e.g. RepServer.ora) which references the alias to the WebDB SID. Once the SECURITYTNSNAME entry has been added to the server s configuration file (and the Reports Server restarted) access control will be enforced. Users who request a report run against this server will be challenged and required to identify themselves for subsequent authentication. Once the WebDB integration has been installed and the Report Server started as a secure server it is possible to define the required access security model. From the Oracle Reports Security page (linked to the WebDB Administer page), it is possible to define the objects which define the criteria of the security model. 4

5 Figure 1: Reports Security Administration What: As a given report may reside on more than one Reports Server the definition of a user s access privileges must go beyond the report itself to include the available hardware on which that report may be executed/output. For example, a given report resides on both the central Reports Server and the one used by senior management. Even though a given user may have the right to run the report, he/she should be prevented from executing it on the management server. As such, the Oracle Reports Security allows for the securing of a number of different objects relating to the execution of a report. Printer Access: What local or network printers are available. Who has the appropriate privileges to use a given printer. When is this printer available for printing reports. Servers Access: 5

6 What Report Servers have been registered within the WebDB repository and hence are available to accept job requests. What Printers are available on a given Reports Server. Who has the appropriate privileges to submit job requests to a given Reports Server. When is a given Reports Server available to accept job requests. What is the URL required to call a given server via the Web. Can a given Reports Server run any available report or only those registered with WebDB that have secure access control. Report Definition File Access: What Oracle Reports *.RDF, *.REP, or *.XML files have been registered for secure access. What is the name by which a given report will be known within the WebDB environment. Who has the appropriate privileges to run a given report. Which Reports Servers have a given report available. When is a given report available for execution. When: It is often the case that a user s ability to access a report, server, or printer is determined by the point in time the job was submitted to execute. With the universal access afforded by the web, the simple physical security of not being able to access the appropriate hardware (PC, Printer etc.) outside of a defined time period is removed, hence the need to define an availability window as part of the report/object definition becomes paramount. For example, it has been decided that a given report may only be accessed during standard business hours. By applying an availability calendar which defines standard business hours employees would not be able to log-in from home after hours and access the report. The secure Oracle Reports Server supports the ability to define availability calendars for either: The individual report. The Reports Server on which jobs may be executed. The printers to which the report output may be sent. 6

7 In all cases, the availability calendar determines when the specific object is accessible for processing. There are two different availability calendar types, simple and combined. Simple: 5:00pm daily). An availability calendar based on a single rule (e.g., between 9:00am and Combined: A compound availability calendar determined from the addition of two or more simple calendars. The definition of a combined calendar supports both the inclusion and exclusion of the time periods specified within included simple calendars. That is, the combined availability calendar may be defined as Availability := (Sum of all included Calendars) - (Sum of all excluded Calendars) For example, to define a standard business hours availability calendar, it would first be necessary to create two simple calendars to be included/excluded as follows; 1. 9:00am - 5:00pm repeat every day. (Include) 2. Saturday/Sunday repeat every week. (Exclude) The resultant availability calendar would only allow access during the period of 9am to 5pm, Monday to Friday. Note: combined availability calendars can also include/exclude other combined calendars. Hence it is possible to create complex calendar definitions from a hierarchy of both simple and complex calendars. Only one availability calendar can be applied to a given secured Reports Server object (i.e., report definition, server or printer). Hence, if more complex time frames are required, it is necessary to build a single combined calendar (through the addition or exclusions of simpler calendars), which reflects the desired time period. 7

8 EveryDay Availability Calendar Week-Ends Availability Calendar Include Exclude Rule: 9:00am to 5:00pm Frequency: Everyday Rule: 12:00am Saturday to 12:00am Monday Frequency: Every week Business Day Calendar How: It is often important not only to specify which report a user may access (and when) but also how that user may interact with the report. The secure Reports Server achieves this by restricting the report request options (i.e. required and optional report parameters), which are exposed to a given user at job submission. By specifying which parameters are exposed, the administrator can allow different users or groups to apply different options to the same physical report definition file. For example, a given report may limit not only the server and printers to which it may be run but also the possible values for DESTYPE and DESFORMAT. In this case, the administrator wants to restrict the report to Web viewing only, hence DESTYPE will be fixed at CACHE and the possible options for DESFORMAT limited to HTML and HTMLCSS. SINGLE SIGN-ON SUPPORT Unless the username/password is hard coded into the server side keymap file (or supplied as part of the URL), any user accessing the Oracle Reports Server will be challenged to identify themselves for authentication purposes. As the HTTP 1.0 protocol is stateless, that is, each call to the server is effectively independent of all others, it would result in the user needing to authenticate themselves for each report request. 8

9 To solve this issue, and to allow a user to authenticate only once, the report makes use of client side cookies to store the required authentication information within the browser for the current session. Once the user is authenticated, an encrypted cookie is created in the browser allowing for multiple report jobs to be submitted without the need to re-authenticate at each request. NOTE: If there is a requirement to force a re-authentication on the submission of a given report, use the SHOWAUTH and AUTHTYPE command line arguments or include a %D in the respective report entry in the keymap file (use of %D will force the user to re-enter their username and password each time the report is called). It is often the case that within a given Web site that users will access reports which run against multiple instances of the Oracle database (or ODBC data sources). To minimize the number of times a user must authenticate themselves (once to each different server), multiple encrypted cookies are created. Each cookie is keyed to the SID used in the connection string. If a report is submitted using the place holder $<username> in conjunction with a SQL*Net80 database alias, a separate cookie will being created in the browser for each referenced SID. For example the following keymap file entries REP1: Report=Rep1.rdf userid=$username@orcl Destype=CACHE Desformat=HTML REP2: Report=Rep2.ref userid=$username@prod Destype=CACHE Desformat=HTML would result in the user being authenticated against the two different servers and two encrypted cookies being created in the browser. One for ORCL and one for PROD. With any subsequent request for either server the User name and Password will be retrieved from the appropriate cookie and used to authenticate the user against that server. If no connect string is defined in the command line (i.e. either no USERID is defined or no SQL*Net80 alias is specified), the Oracle Reports CGI executable will use the last database connect string which achieved a successful connection. This value is stored in a separate cookie within the client browser ("lastdbid"). The cookies will be removed if the user closes the browser session, but it is also important to limit the lifetime of the cookie within a given session. For example, a user may have logged on then gone off to lunch leaving the browser session open! To control this type of security breach the 9

10 administrator may define the REPORTS60_COOKIE_EXPIRE environment variable on the server. When the Oracle Reports CGI executable (or OWS cartridge) receives a job request from the client it will compare the time saved in the cookie with the current system time. If the time is longer than the number of minutes defined in the environment variable (e.g., 30 minutes), the cookie is rejected and the user again challenged to identify themselves for authentication. Environment Variables effecting user Authentication Environment Variable REPORTS60_COMMON_AUTH REPORTS60_DB_AUTH REPORTS60_ENCRYPTION_KEY Description Specifies the template used to determine the common properties of the authentication form, such as the size of the form and whether a toolbar is visible. This template is used in conjunction with the HTML template set in the REPORT60_DB_AUTH environment variable. Default: Value=common.htm Specifies the database authentication template used to authenticate the user name, password, and database. Default: Value=dbauth.htm Specifies the encryption key used to encrypt the user name and password for the cookie. The encryption key can be any character string. Default: Value=reports6.0 10

11 REPORT SERVER SCALEABILTY The Oracle Reports Server allows for the automatic load balancing of report execution across a number of pre-spawned runtime engines. However, if the user community is sufficiently large, there will be a point where, as new runtime engines are spawned, the processing power of a single computer is consumed and new report requests are forced to be queued rather than executed immediately. While the number of report requests at which this occurs is determined by the complexity of the report, the number of CPUs in the machine and operating system, there will always be a limit to the scaleabilty that may be achieved from a single computer. The scaleabilty achievable on a single server is directly proportional to the number of CPUs available and the nature of the reports being executed on the server. If a report spends the majority of it s execution within the RDBMS (i.e., running the query) more CPU cycles are available to process other reports on the middle tier. If, however, the majority of time is actually spent in formatting the final output then the CPU cycles available to process other reports will be decreased. It is possible to determine where the report is spending most of its time by use of the profile options available within Oracle Reports REPORTS PROFILE The Reports Profile option, when set, produces a log file that gives accurate figures as to where the report spent its processing time. To set the profile option, use the PROFILE=<filename> command line argument, where <filename> is the name of the required log file. A typical profile is shown below: Reports Profiler statistics TOTAL ELAPSED Time: Reports Time: ORACLE Time: UPI: SQL: seconds seconds (82.75% of TOTAL) 5.00 seconds (17.24% of TOTAL) 1.00 seconds 4.00 seconds 11

12 TOTAL CPU Time used by process: N/A From the profile it is possible to see the total execution time for the report, the amount of time that was spent formatting the retrieved data (Reports Time), and the amount of time spent waiting for the data to be retrieved (ORACLE Time). UPI time is the time spent establishing the database connection, and parsing and executing the SQL, whilst the SQL time is the time spent performing the RDBMS fetches and execution of SRW.DO_SQL() statements. Note: From initial internal testing within the Oracle Tools Division it was found that the number of Runtime engines which could be supported by a given CPU was as follows; Format Intensive reporting: 2 Engines per available CPU Data Intensive Reporting: 4 Engines per available CPU REPORT SERVER CLUSTERING In order to scale beyond the bounds of a single machine, the Oracle Reports Server is able to leverage more of an organizations existing hardware, by implementing a heterogeneous cluster of individual servers. The result is almost infinite scaleabilty. 12

13 Time Clustered Clustered vs. vs. Unclustered Unclustered Without Clustering With Clustering # Reports Engines By registering individual Reports Servers into a cluster (maintained through a master server), they are able to act as a single logical, but distributed, reporting engine. As jobs are submitted to the Reports Server they are automatically re-routed to an available engine running on any machine within the cluster. In this manner, if the reporting needs of the user base is such that performance is degrading, it is simply a matter of defining a new machine to the cluster, to further extend the available processing power. As machines are added to the cluster the Reports Server will automatically recognize their existence and start to issue job requests to them. Conversely, if one of the machines becomes unavailable (due to failure or shutdown) the server will automatically cease to issue requests to that specific machine. The automatic Plug-n-play nature of an Oracle Reports Server cluster means that scaleabilty is limited by the total number of available machines, and not by the processing power of any one computer. CONFIGURING THE SERVER FOR HETEROGENEOUS CLUSTERING When in a clustered configuration, all interaction with the Reports Server is performed via the master server, which both controls the number of engines spawned on each slave server, as well as the allocation of jobs to those slaves. This allocation process currently uses a round-robin algorithm. Note: It is possible for a slave server to be a fully functional Reports Server in its own right. That is, it may start and own it s own runtime engines independent of the Master server. In this case, any job submission would be to the slave server directly rather than the master and would be local to that server. That is, the master server would be unaware of any direct requests to the slave and hence would be unable to either check for a duplicate request or use any cached output. 13

14 All servers in the cluster must be able to share a file system such that the reporting engines on each slave are able to write their output to a centralized cache. A central cache ensures that the master server is able to serve duplicate job requests, both current and those within tolerance, regardless of the server on which a job request was processed. Note: A further benefit of a shared file system is the use of a centralized source directory which would eliminate the need to copy the report definition files to each slave server. Reports Servers within a cluster communicate via SQL*Net80 and as such each individual server must have an entry in their tnsnames.ora which refers to any server with which it will need to communicate. That is, each slave must have an entry referencing the master server and vice versa. The following examples show the tnsnames.ora file for both master and slave servers. Master Server (RepServ) RepServ.world = (Address=(Protocol=TCP)(Host=RepServ)(Port=1949)) RepSlave1.world = (Address=(Protocol=TCP)(Host=RepServ)(Port=1949)) RepSlave2.world = (Address=(Protocol=TCP)(Host=RepServ)(Port=1949)) Slave Server1 (RepSlave1) RepServ.world = (Address=(Protocol=TCP)(Host=RepServ)(Port=1949)) RepSlave1.world = (Address=(Protocol=TCP)(Host=RepServ)(Port=1949)) Slave Server2 (RepSlave2) RepServ.world = (Address=(Protocol=TCP)(Host=RepServ)(Port=1949)) RepSlave2.world = 14

15 (Address=(Protocol=TCP)(Host=RepServ)(Port=1949)) When the master server is started, it evaluates the value of the CLUSTERCONFIG parameter within its own configuration file. From this parameter it is able to determine which remote Reports Servers are slaves and how many engines are to be started on each. Master Server Configuration File (RepServ.ora) MaxConnect=4096 SourceDir= P:\Rep60\Source CacheDir= P:\Rep60\Cache CacheSize=50 MinEngine=1 MaxEngine=4 InitEngine=4 MaxIdle=60 EngLife=50 ClusterConfig= (RepSlave1 MinEngine=1 MaxEngine=2 InitEngine=2 CacheDir= M:\ReportsCache ) (RepSlave2 MinEngine=1 MaxEngine=3 InitEngine=3 CacheDir= /Shared/Cache ) In this example the master server would start two engines on the slave server RepSlave1, and three on RepSlave2. The MinEngine and MaxEngine parameters within the ClusterConfig would specify the minimum and maximum number of engines the server should control on each of the respective slave Reports Servers. It is not necessary that each slave server see the shared cache directory by the same name, nor do they have to be based on the same operating system. As long as each can write to the shared drive. Note: To allow more even distribution of load across the available servers, it is important to have both the maximum allowable idle time and engine life be consistent across all runtime engines. As such, the values of MAXIDLE and ENGLIFE defined for the master server s engines are implied for all slave engines. 15

16 PLUG AND PLAY SERVERS As the master server in the cluster is started, it will attempt to contact each of the slave servers defined within the CLUSTERCONFIG parameter in a top down manner. If the slave is up and running the master will: Enter the slave server s information into its list of active servers. Instruct the slave server to spawn the specified number of runtime engines. Take control of each engine and add it to its list of available runtime engines. Communication is now directly to the runtime engines, rather than through the slave server. The master only contacts the slave if there is the requirement to spawn further engines on that machine. If the master cannot communicate with one or more of the slaves defined in the list, they will be assumed to be off line, and hence unable to accept job submissions. In this case, the round-robin based job assignment will jump over this server and send the request to the next one that is in the list of active servers. In order for the master server to determine when new cluster members have become available, it explicitly polls for those machines that are in the cluster definition but not in it s list of active servers. Note: The polling interval is approximately every five seconds. However, polling only takes place during the times when the server is in an idle state, i.e., when there have been no job submission for the previous five seconds. Once the slave indicates it is available (i.e. the server is now up), the master will automatically add it to its list of active servers, obtain control of the appropriate number of runtime engines, and start issuing submissions to be executed on that platform. The master server also maintains a connection to all slaves in its active list. If a given slave server was to go down for some reason, this connection would be broken and hence the master would remove it from the active list of servers. following will result: Depending upon the cause of the break in connection the 1. If the slave Reports Server process dies, the runtime engines controlled by the master are still available. In this case, job submissions would continue until the currently spawned engines are either saturated or they expire through idle time or engine life. No new engines can be spawned, hence if all the current engines are processing reports, this server will be skipped in the roundrobin. 16

17 2. The entire machine is taken off line, no runtime engines are available. With the connections to both slave server and runtime engines broken, the master would skip this machine until it was notified (via poll) that the slave node was once again available to receive job requests. RepServ (Master) ClusterConfig= (RepSlave1) Ping Slave until it comes on-line & available (RepSlave2) Runtime Engine Engines owned by Master server Runtime Engine Runtime Engine Runtime Engine RepSlave1 RepSlave2 Runtime Engine Local Engine owned by Slave Runtime Engine Runtime Engine RepSlave1 - OnLine RepSlave2 - OffLine Once the cluster has been defined, the actual nodes may be added or removed at any time and the Reports Server will adjust accordingly. In a master/slave hierarchy the failure of the master node can result in the breakdown of the cluster structure (though each slave server may still act independently). If a high availability solution is required, the Oracle Reports Server tightly integrates with Oracle Fail-safe to allow for the automatic switching of the master server if it should go down. In this manner the Reports Server may not only scale to the required number of users but also support a 24x7 environment. Note: information on Oracle FailSafe may be found on the Oracle web site ( KEEPING TRACK OF SERVER USE The move to a centralized reporting infrastructure introduces the requirement to supply certain operational information. 1. Users want to know the status of any report they have submitted 2. Administrators need to know how many concurrent users there are on the Reports Server. This is useful for both sizing the environment and to ensure license compliance. 17

18 The Oracle Reports Server makes it possible to answer both of these questions, by posting the current Report queue to the database each time a job request is submitted. This information is inserted into a table RW_SERVER_QUEUE and includes such data as: The name of the Job Who submitted it What output format was chosen The job s current status When it was queued, started, and subsequently finished (See appendix for description of the RW_SERVER_QUEUE table structure.) By granting users SELECT access to this, they may query the job submission of interest and determine it s current status. In the same manner it is possible to implement a Reports Server Queue screen directly within the Web site itself simply by creating a report based directly on this table. In this case the queue report itself would appear as a job submission by the user! Note: For Oracle Forms based applications the basing of a block against the RW_SERVER_QUEUE table would allow users to track their reports without the need to leave the forms environment or resort to use of the Web.Show_Document built-in. Conversely, the real time update of the table with the status of jobs submissions makes it very easy for administrators to know exactly how many concurrent users have requested jobs to be executed on the Reports server. By counting the number of entries in the RW_SERVER_QUEUE table which have a status code indicating that the job has been queued but not completed, it is possible to return an accurate number of the current active users on the server. E.g. SELECT Count(*) FROM RW_SERVER_QUEUE WHERE STATUS_CODE IN (1, -- ENQUEUED 2, -- OPENING 3 -- RUNNING) AND JOB_TYPE!= Scheduled 18

19 Note: Whereas the table contains the date and time a report was Queued, Run, and subsequently Finished, it is not a good idea to use a query based on the that fact that a job has a defined QUEUED and STARTED time but no FINISHED value. If a report terminates due to an unexpected error, such as an invalid input, the FINISHED column will remain NULL, however, the STATUS_CODE and STATUS_MESSAGE will both indicate that there has been a failure and the cause thereof. (See appendix for definition of available status codes.) CONFIGURING THE SERVER TO UPDATE DATABASE WITH QUEUE ACTIVITY. The Reports Server queue is implemented through the use of a PL/SQL based API. It functions to clear out the queue information each time the server is restarted and to update the table with queue information as requests are made. Note: Defined in %ORACLE_HOME%\Reports60\Sql\Rw_Server.sql. In order to implement the queue the following steps are required: 1. Create a schema which will own the report queue information and have execute privileges on the server-queue API. 2. Set the REPOSITORYCONN parameter in the Reports Server s configuration file to the connection string of the schema which owns the queue data. When the server starts it will connect as the defined user, clear out the queue table and begin to log job submissions. Note: If the Reports Server and Oracle RDBMS have been installed on a single stand-alone Windows-NT machine, the definition of REPOSITORYCONN may prevent the automatic startup of the Reports Server service as NT boots. This is due to the fact that the Oracle RDBMS service may yet to have started, thus preventing the Reports Server from performing the required login. Once the RDBMS has started, the Reports Server Service may be started manually. CONCLUSION The move to a centralized reporting infrastructure based on Internet Computing, allows organizations to both minimize their costs and maximize access to information. It does, however, introduce issues which till now have made many system administrators reticent to adopt the new paradigm, i.e., the security implications of a Web-based solution and the need to scale to a larger user community. 19

20 Oracle Reports, in conjunction with Oracle WebDB, answers these issues by allowing for the implementation of both a scaleable, clustered environment and user authentication and access control. 20

21 APPENDIX STRUCTURE OF THE RW_SERVER_QUEUE TABLE Column Name JOB_TYPE JOB_ID JOB_NAME STATUS_CODE STATUS_MESSAGE Description States whether the job listed is CURRENT, PAST, or SCHEDULED System generated job identification number Job submission name (or file name if no value for JOBNAME is specified) Current status of the job - (see below for definitions) Full message text relating to status code (includes Oracle error message if reports terminated) COMMAND_LINE OWNER DESTYPE DESNAME SERVER QUEUED STARTED FINISHED LAST_RUN NEXT_RUN Complete command line submitted for this job submission User who submitted the job. On the Web, the default user is the OS user who owns the web server. Format of the report output Name the report output if not going to the Reports Server cache. Reports Server to which the report was submitted Date and time the job submission was received and queued by the given Reports Server. Date and time the job submission was executed Date and time the submitted job completed Date and time a scheduled job was last executed Date and time a scheduled job will next execute. REPEAT_INTERVAL Frequency on which to execute a job REPEAT_PATTERN Repeat pattern (every minute, hour, day, etc.) 21

22 JOB SUBMISSION STATUS CODES Status Code Defined PL/SQL Constant Description of Status code 0 UNKNOWN No such job 1 ENQUEUED Job is waiting in queue 2 OPENING Server is opening report definition 3 RUNNING Report is currently running 4 FINISHED Job submission has completed successfully 5 TERMINATED_W_ERR Job has terminated with an error 6 CRASHED Engine has crashed during execution of the job 7 CANCELED Job was canceled by user request 8 SERVER_SHUTDOWN Job was canceled due to the Server shutting down 9 WILL_RETRY Job failed and is queued for RETRY 10 SENDING_OUTPUT Job has completed and is returning output? 22

23 Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA U.S.A. Worldwide Inquiries: Fax Copyright Oracle Corporation 1999 All Rights Reserved This document is provided for informational purposes only, and the information herein is subject to change without notice. Please report any errors herein to Oracle Corporation. Oracle Corporation does not provide any warranties covering and specifically disclaims any liability in connection with this document. Oracle is a registered trademark, and Oracle8i, Oracle8, PL/SQL, and Oracle Expert are trademarks of Oracle Corporation. All other company and product names mentioned are used for identification purposes only and may be trademarks of their respective owners.