Managing Database Jobs 527 18 L ISTING 18.20 Verifying the Job Removal SELECT JOB from USER_JOBS; JOB --------- 25 109 You now have only two jobs. And the file C:\HELLO.TXT should look similar to this: Hello World! 06-22-97 09:37:42 PM Hello Again for the Second Time! 06-22-97 09:37:42 PM Hello World! 06-22-97 09:38:35 PM Hello Again for the Second Time! 06-22-97 09:38:35 PM Hello World! 06-22-97 09:38:36 PM Hello Again for the Second Time! 06-22-97 09:38:36 PM Hello World! 06-22-97 09:39:36 PM Hello Again for the Second Time! 06-22-97 09:39:36 PM Hello World! 06-22-97 09:39:37 PM Hello Again for the Second Time! 06-22-97 09:39:37 PM Hello World! 06-22-97 09:40:38 PM Hello Again for the Second Time! 06-22-97 09:40:38 PM Hello World! 06-22-97 09:40:38 PM Hello Again for the Second Time! 06-22-97 09:40:38 PM Hello World! 06-22-97 09:41:38 PM Hello Again for the Second Time! 06-22-97 09:41:38 PM Hello World! 06-22-97 09:41:38 PM Hello Again for the Second Time! 06-22-97 09:41:38 PM Hello World! 06-22-97 09:42:39 PM Hello Again for the Second Time! 06-22-97 09:42:39 PM Hello World! 06-22-97 09:42:39 PM Hello Again for the Second Time! 06-22-97 09:42:39 PM Hello World! 06-22-97 09:43:40 PM Hello Again for the Second Time! 06-22-97 09:43:40 PM Hello World! 06-22-97 09:43:40 PM Hello Again for the Second Time! 06-22-97 09:43:40 PM Hello World! 06-22-97 09:44:40 PM Your output might be a lot longer, depending on when you view this file. Notice that the two procedures HELLOFLE and SHAREFLE are appending to HELLO.TXT the phrase and the date and time every minute. I NPUT O UTPUT A NALYSIS O UTPUT 24 7982 ch18 11/30/99 1:04 PM Page 527 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Summary Today you have learned how to work with the DBMS_JOB package in Oracle8i. This pack- age handles all jobs by using background processes to check for jobs to execute at a spe- cific interval, and then places them in job queues. To submit a job for processing, you must submit the job to the queue first. After a job is submitted, if you are the owner, you can change the parameters. You can also fix any of your broken jobs, as well as remove your own jobs from the queue. This chapter also covered the techniques used to run a job immediately. You can also import and export jobs from one database to another. Always remember that the job number is unique, and any attempt to use the same job number will result in a failure of the job to execute. Q&A Q Can jobs be executed immediately, without being sent to the job queue? A No. All jobs must be submitted to a job queue, and then you can use DBMS_JOB.RUN to execute a given job immediately. The job then returns to executing at its sched- uled time interval. Q What is the difference between SUBMIT and ISUBMIT ? A ISUBMIT enables you to assign job numbers, provided that the job number is not being used in the system. Q Which parameters can be altered in the job? A All the parameters can be altered in a job. You can use CHANGE to alter them all immediately or use specific procedures such as WHAT , NEXT_DATE , and INTERVAL . Q Who can remove or alter a job? A Only the owner of the job can alter or remove the job. Q What can be done about a broken job? A You could either use RUN to execute the job immediately or use the BROKEN proce- dure to reschedule the job. If needed, you could also delete the job by using REMOVE . Q When submitting a job, what punctuation should be used around regular pro- cedure parameters? A Any parameters that normally are surrounded by a single quote ( ‘ ) must be sur- rounded by two single quotes ( ‘’ ); otherwise, the job never executes. 528 Day 18 24 7982 ch18 11/30/99 1:04 PM Page 528 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Managing Database Jobs 529 18 Workshop You can use this workshop to test your comprehension of this chapter and put what you’ve learned into practice. You’ll find the answers to the quiz and exercises in Appendix A, “Answers.” Quiz 1. If the server goes down for two days (Monday to Tuesday), and a job with an exe- cution of SYSDATE + 7 was supposed to run when the server went down (Tuesday), will the job always run on the original day of the week (that is, run every Tuesday)? 2. Why must you use two single quotes around parameters specified in SUBMIT , when you used to need only one set of single quotes? 3. Can you alter someone else’s job? 4. How do you assign your own job number to a job? 5. What interval would you use to run a procedure every hour on the hour, starting from the current date? Exercises 1. Write the code to submit a procedure called PAYDAY , where the parameters are FRIDAY , Bi_Monthly , and 6 . The job should always execute at 4 a.m. Saturday. 2. Write the code to view the JOB ,last-second run, and WHAT from USER_JOBS . 3. Write the code to submit job 200 once per day, starting from SYSDATE for the pro- cedure EASY , which has no parameters. 4. Write the code to alter job 200 to execute once per week for the interval SYSDATE + 7 . 5. Write the code to remove job 200. 24 7982 ch18 11/30/99 1:04 PM Page 529 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 24 7982 ch18 11/30/99 1:04 PM Page 530 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. D AY 19 W EEK 3 Alerting and Communicating with Other Procedures: The DBMS_ALERT and DBMS_PIPE Packages by Tom Luers Oracle provides two packages to assist the developer with creating applications: DBMS_PIPE establishes communications within sessions, and DBMS_ALERT noti- fies about events from other procedures. Both packages help make your appli- cations more robust and powerful within the Oracle database. 25 7982 ch19 11/30/99 1:31 PM Page 531 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Both packages come with your Oracle database. They are automatically installed when the database is created and the CATPROC.SQL procedure is executed. In today’s lesson, you will learn to •Work with the DBMS_ALERT package • Send and register an alert •Wait for an alert and remove an alert •Execute polling and events •Use DBMS_PIPE • Recognize the differences between public and private pipes •Use pipe messages • Know the differences between alerts and pipes The DBMS_ALERT Package As the name suggests, you can use alerts to notify you about an event for informational purposes. The DBMS_ALERT package is typically a one-way asynchronous communication that is triggered when a transaction commits. Unless a transaction commits, no informa- tion is sent to the alert. This means that a waiting procedure or application remains idle until the desired transaction commits. Because alerts provide one-way communication, they have limited usage. Consider these examples of how you can use alerts: An insur- ance company agent can be alerted to natural disasters so that she can dispatch a team of experts to aid the survivors. You can also be alerted if a trigger fails, which can corrupt your database. 532 Day 19 Because the DBMS_ALERT package uses COMMIT , you cannot use this package in Oracle Forms. Note Because the DBMS_ALERT package is transaction-based, any ROLLBACK removes any wait- ing alerts. The order for setting up an alert is •Use REGISTER to record your interest in a particular alert. • Issue the WAITONE procedure to wait for a specific alert. • Issue the WAITANY procedure to wait for any of your registered alerts. •Use SIGNAL when the condition for the alert is met and the transaction has been committed. 25 7982 ch19 11/30/99 1:31 PM Page 532 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Alerting and Communicating with Other Procedures 533 19 Using SIGNAL to Issue an Alert When you want to send an alert, you need to use the SIGNAL procedure. As mentioned earlier, this procedure only executes when a COMMIT is issued. The Syntax for the SIGNAL Procedure PROCEDURE SIGNAL(alert_name IN VARCHAR2, message_sent IN VARCHAR2); alert_name can be a maximum of 30 characters, and it is not case sensitive. In addition, the name must not start with ORA$ , which is reserved for use with Oracle. message_sent can be up to 1,800 characters, which allows for a generous concatenation of text, variable names, and so on. This message is sent to the waiting session. It is common for multiple sessions to concurrently issue signals on the same alert. In this case, as each session issues the alert, it blocks all other concurrent sessions until it com- mits. The net effect of this behavior is that alerts can cause transactions to become serial- ized. After the alert is sent, Oracle changes the state of the alert from not signaled to signaled. This information is recorded in the DBMS_ALERT_INFO data dictionary. Because there is only one record for each alert, any other sessions attempting to send an alert are blocked until the alert has been received. If no sessions have registered the alert, the alert remains signaled until the session has registered the alert. If multiple sessions have registered for the alert, after the alert has been signaled, all sessions receive the alert, and the alert returns to the nonsignaled state. Registering for an Alert Before you can even search for an alert, you must register the alert you want to monitor, which adds you to the master registration list. You take this first step by using the REGISTER procedure. To work with the DBMS_ALERT package, you must have the package installed, and you must have the EXECUTE permission for the package. Note , S YNTAX , 25 7982 ch19 11/30/99 1:31 PM Page 533 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. The Syntax for the REGISTER Procedure PROCEDURE REGISTER(alert_name IN VARCHAR2); In this syntax, alert_name is the name of the alert to monitor. A session can register interest in an unlimited number of alerts. You can monitor as many alerts as you are reg- istered for. You can remove yourself from the master registration list through the REMOVE or REMOVEALL procedures. 534 Day 19 , , S YNTAX Waiting for a Specific Alert If you want to monitor one alert, use the WAITONE procedure. The Syntax for the WAITONE Procedure PROCEDURE WAITONE(alert_name IN VARCHAR2, alert_message OUT VARCHAR2, alert_status OUT INTEGER, timeout IN NUMBER DEFAULT maxwait); Again, alert_name is the name of the alert you are monitoring. alert_message is the message that you receive when the alert has been signaled. This message is sent via the SIGNAL call. The alert_status parameter has two possible values: 0 if the alert is sig- naled before the timeout or 1 if the timeout occurs before any alert has been received. timeout is how long you will wait (in seconds) for the alert before the procedure contin- ues executing if no alert is received. The default time period for maxwait is 1,000 days. Simply registering an alert does not block the session from executing; rather, it simply records an interest in the alert. Only the WAITONE and WAITANY com- mands can block the session from executing. Although you can benefit from registering for all possible alerts and then checking for the alert later in a procedure, you are using valuable resources to monitor the registration. Use REGISTER only when necessary. Note , S YNTAX , When testing a DBMS_ALERT procedure, it is a good idea to make maxwait no longer than five minutes; otherwise, you could be at the keyboard for 1,000 days! Tip 25 7982 ch19 11/30/99 1:32 PM Page 534 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Alerting and Communicating with Other Procedures 535 19 If the alert_name specified has not been registered, you receive an error message: ORA-20000, ORU-10024: there are no alerts registered. Waiting for Any Registered Alert The WAITANY procedure allows you to constantly monitor for any alert for which you have registered in the current session. The Syntax for the WAITANY Procedure PROCEDURE WAITANY(alert_name OUT VARCHAR2, alert_message OUT VARCHAR2, alert_status OUT INTEGER, timeout IN NUMBER DEFAULT maxwait); alert_name is an OUT parameter of type VARCHAR2 instead of type IN VARCHAR2 . Instead of specifying alert_name as an input, you receive the alert_name of the first registered alert that was sent. alert_message is the message that you receive when the specific alert is signaled. This message is provided via the SIGNAL call. The alert_status para- meter has two possible values: 0 if any alert is signaled before the timeout or 1 if the timeout occurs before any alert is received. timeout is how long you will wait (in sec- onds) for the alert before the procedure continues executing. Again, the default for maxwait is 1,000 days. You receive the same error message as you do with WAITONE if you do not register the alert before trying to wait for it. Removing One Alert To remove only one specific alert from the registration list, use the REMOVE procedure. The Syntax for the REMOVE Procedure PROCEDURE REMOVE(alert_name IN VARCHAR2); alert_name is the alert you want to remove from the registration list. After you no longer need to wait for an alert, you should use REMOVE to remove the registration instead of using up valuable resources. Whether you wait for an alert or not, once registered, the alert attempts to signal all registered procedures. Not only does the system waste resources attempting to send an alert to what it believes is a waiting process, but also it takes longer for the system to process through the registration list when it contains alerts you no longer need. , S YNTAX , , S YNTAX , 25 7982 ch19 11/30/99 1:32 PM Page 535 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Removing All Alerts You can remove all registered alerts from the current session by placing a call to the pro- cedure REMOVEALL . The format for the REMOVEALL procedure is as follows: PROCEDURE REMOVEALL; After the procedure is executed, all registered alerts are deleted. An implicit COMMIT is executed with this call. Polling and Events with the SET_DEFAULTS Procedure As an Oracle event occurs, it is picked up in the system and processed. You see this hap- pen in the walkthrough example, Listing 19.3, of the DBMS_ALERT package using the WAITONE procedure. The WAITONE procedure waits for the specific event to occur and either alerts you when the alert occurs or eventually times out. On the other hand, some situations require polling or specifically searching for an alert: • When shared instances of a database can issue an alert, you need to poll for an alert for any of the shared instances. • When using the WAITANY procedure, you need to search for a specific alert. The WAITANY procedure enters a looping poll mode to search for any registered alerts. When WAITANY enters a sleep mode after polling for alerts, it picks up only the most recently signaled alert if three alerts are signaled during the sleep period. The default poll starts at 1 second and increases exponentially to 30 seconds. Because two possibilities[md]using shared instances or using WAITANY —can result in missed alerts, you can change the polling time in seconds using SET_DEFAULTS . The Syntax for the SET_DEFAULTS Procedure PROCEDURE SET_DEFAULTS(polling_interval IN NUMBER); You specify the interval between polling in seconds. The default interval for this proce- dure is 5 seconds. Demonstrating the DBMS_ALERT Package The best way to understand alerts is to use the DBMS_ALERT package. Your goal is to solve a security problem. Suppose that some employees gained access to the payroll database and had some fun changing around pay rates. The IS director has empowered you to devise an alert, which security will constantly monitor, to detect any changes in the pay- roll database. 536 Day 19 S YNTAX 25 7982 ch19 11/30/99 1:32 PM Page 536 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [...]... point in time, you can run a query against this table for Security.Verified = ‘N’ when no one has been watching the screen, waiting for the alert to occur Waiting for the Alert The next step is to wait for an alert and then finally cause an alert to happen Because you are going to practice inserting, deleting, and updating, I recommend that before you do anything else, you enter the code in Listings... to instantiating a graphical user interface (GUI) Because JServer’s JVM runs within the context of a database server, a PL/SQL and Java 561 GUI doesn’t make sense Oracle does support the GUI libraries in the sense that you can write them into code, but any attempt at actually instantiating a GUI interface within the server results in an exception being thrown Will PL/SQL Go Away? Will Java replace PL/SQL. .. Java classes and source code into the database • Call Java code from PL/SQL • Call PL/SQL code from Java One thing this lesson can’t do is teach you how to program in Java We would need another 21 days for that, at least In fact, you might look at Laura Lemay’s 560 Day 20 and Rogers Cadenhead’s book Sams Teach Yourself Java 2 in 21 Days by Sams Publishing The Java examples in this lesson are simple enough,... enter the SQL code in Listing 19.4 INPUT LISTING 19.4 Inserting a Record to Trigger an Alert 1: INSERT INTO employee 2: (emp_id, emp_name,supervised_by,pay_rate,pay_type,emp_dept_id) 3: VALUES(9109,’Benjamin Franklin’,209,20.50,’H’,10); 4: COMMIT; Without the final COMMIT statement, the alert never triggers When you execute the code from Listing 19.4, on the screen where you perform the insert, your output... This scheme is reminiscent of the Superman movie where Richard Pryor gives himself a huge raise after breaking into the payroll computer This change definitely bears investigation Using DELETE to Signal the Alert With your two sessions still open, execute in one of the SQL*Plus screens the code in Listing 19.3 On the other screen, execute the code in Listing 19.6 to practice deleting a record Before... Procedures 545 By default, pipes retain the information for up to 1,000 days However, all data buffered in a pipe is lost when the instance is shut down To define the duration of the retention period, use the PL/SQL constant maxwait This constant is defined in Oracle as maxwait CONSTANT INTEGER := 86400000; The constant is expressed in seconds, so 60 seconds/minute × 60 minutes/hour × 24 hours/day × 1,000... developing data-intensive applications Java, on the other hand, is the recommended choice for use when developing object-oriented applications Note I believe that the market will rule on this issue If everyone jumps ship to Java, and stops writing PL/SQL, then PL/SQL will almost certainly die off If people continue to program in both environments, then both will continue to exist In any case, I think... little likelihood of PL/SQL going away in the near future Too many sites have a considerable amount invested in it, and several of Oracle’s tools depend on it as well Will PL/SQL be around in five years? I believe so Will it be around in 10? That I couldn’t say Creating a Java Procedure Oracle8i allows you to load a Java class into the database, and then use that class from PL/SQL In order to do that,... record, as you expect, there is no data in the OLD values Alerting and Communicating with Other Procedures 541 Using UPDATE to Signal the Alert With your two sessions still open, execute in one of the SQL*Plus screens the code in Listing 19.3 On the other screen, execute the code in Listing 19.5 to practice updating a record Before you execute the code from Listing 19.3, make sure you change the time... resources by removing the pipes Enter and execute the code in Listing 19.9 INPUT LISTING 19.9 Removing Both Pipes 1: DECLARE 2: v_stat NUMBER ; 3: BEGIN 4: v_stat := dbms_pipe.remove_pipe(‘myprivatepipe’); 5: DBMS_OUTPUT.PUT_LINE(‘The status for removing the 6: private pipe is: ‘ || v_stat); 7: v_stat := dbms_pipe.remove_pipe(‘mypublicpipe’); 8: DBMS_OUTPUT.PUT_LINE(‘The status for removing the 9: public . need the time to enter the SQL code in Listing 19.4. L ISTING 19.4 Inserting a Record to Trigger an Alert 1: INSERT INTO employee 2: (emp_id, emp_name,supervised_by,pay_rate,pay_type,emp_dept_id). change the polling time in seconds using SET_DEFAULTS . The Syntax for the SET_DEFAULTS Procedure PROCEDURE SET_DEFAULTS(polling_interval IN NUMBER); You