Section 8.7. Managing Logging


8.7. Managing Logging

Like most scheduling systems, the Oracle Scheduler executes programs in the background, where no direct feedback to users or administrators can take place. Given this situation, how can you diagnose issues related to jobs after those jobs have stopped running? The Scheduler allows you to do so with the extensive logging information generated by your job operations and window operations. I'll describe logging for both in the following sections.

8.7.1. Job Logs

There are two data dictionary views that show information about job logs : DBA_SCHEDULER_JOB_LOG and DBA_SCHEDULER_JOB_RUN_DETAILS.

8.7.1.1. DBA_SCHEDULER_JOB_LOG

When jobs are created, altered, dropped, and run, the results are loaded into a summary table that is visible through the DBA_SCHEDULER_JOB_LOG view . Its columns are listed in the following table.

Column name

Description

LOG_ID

Unique identifier for each record.

LOG_DATE

Timestamp of the log entry.

OWNER

Owner of the job.

JOB_NAME

Name of the job.

JOB_CLASS

Job class, if any.

OPERATION

What happened during the job entry (e.g., CREATE, RUN, BROKEN).

STATUS

What happened after the operation was performed by the job (e.g., SUCCEEDED, FAILED).

USER_NAME

Name of the user who invoked the job.

CLIENT_ID

Client identifier, if set using DBMS_SESSION.SET_IDENTIFIER.

GLOBAL_UID

If the user is a global user, the global UID is shown here.

ADDITIONAL_INFO

Any additional information about the job execution is stored as a CLOB in this column. For example, if the job was dropped automatically after it was successfully executed (provided that the auto_drop parameter was set to TRUE), then the OPERATION column shows DROP. However, you will not know from that column whether the job was dropped automatically or explicitly by a user. This column shows the specific reason for the drop. In this case, the column shows:

     REASON="Auto drop job dropped". 

Similarly, any other relevant information about the job execution is also stored here.


8.7.1.2. DBA_SCHEDULER_JOB_RUN_DETAILS

The DBA_SCHEDULER_JOB_LOG view described in the previous section shows the summary log for your jobs, not the details. For detailed information about job execution, see the view DBA_SCHEDULER_JOB_RUN_DETAILS. Its columns are listed in the following table.

Column name

Description

LOG_ID

Unique number representing the specific log entry.

LOG_DATE

Timestamp of the log entry, shown in the TIMESTAMP with TIMEZONE datatype.

OWNER

Owner of the job.

JOB_NAME

Name of the job.

STATUS

Status of the job after the operation (e.g., FAILED, SUCCEEDED).

ERROR#

Oracle error number, if there was an error.

REQ_START_DATE

Scheduled or requested time of the job run, which may not be the actual time the job started.

ACTUAL_START_DATE

The job may not start at the scheduled or requested timeperhaps because the window was not opened before the job was scheduled, a higher priority job was running, or the like. In this case, the actual timestamp of the start of the job is recorded here.

RUN_DURATION

Duration of the job run, shown in the TIMESTAMP datatype.

INSTANCE_ID

If this is a RAC database, then the job must have run on a specific instance of the database; the instance number is recorded here.

SESSION_ID

SID of the session that kicked off the job process.

SLAVE_PID

Process ID of the job slave process.

CPU_USED

Amount of CPU used in execution of the job.

ADDITIONAL_INFO

Additional information about the specific detail of the job execution is stored as a CLOB in this column. This information may be very helpful in diagnosing job execution issues. For example, suppose that a job fails and you find the following information in this column:

     ORA-01014: ORACLE shutdown in progress 

Or suppose that a statistics collection job failed and you find the following information in this column:

     ORA-28031: maximum of 148 enabled roles exceeded 

In both cases, you will be able to find out specifically why the job failed. Similarly, any other relevant information related to this line in the DETAILS view is also shown here.


8.7.1.3. Pruning the job log

Job logging provides very helpful information, but unless the logs are pruned from time to time, they will grow to an unmanageable size and overwhelm your database space. By default, the table where this information is stored (SYS. SCHEDULER$_JOB_RUN_DETAILS) is located in the SYSAUX tablespace . Oracle addresses this issue by automatically pruning the log entries after a certain period of time. This operation is accomplished by a Scheduler job, named PURGE_LOG, which is owned by the SYS user. This job is automatically installed when the Oracle database is created as a part of the job class DEFAULT_JOB_CLASS. It calls a named program called PURGE_LOG_PROG, which points to the stored procedure AUTO_PURGE in the DBMS_SCHEDULER package itself.

The job is scheduled on a named schedule called DAILY_PURGE_SCHEDULE, which runs at 3:00 A.M. every day. Although this is an automatic job, it is still a scheduling job. As with any other kind of job, you can change its propertiesfor example, when it runs, what program it calls, and whether it is assigned a window.

PURGE_LOG prunes only the log entries that are marked for deletion because their retention periods have expired. To control this retention period, see the later section "Setting the retention period."

8.7.1.4. Log levels

One way that you can control the size of your log is to limit the amount of logging information that is recorded for a job. For example, you may want to record when the jobs are run but not when they are created. In some cases, you may not want any logging at all.

You can control the level of logging by assigning a value for the CREATE_JOB_CLASS parameter logging_level when you create a job class. Later, when the job class is referenced in a job creation, the properties of the job will be inherited from the job class.

DBMS_SCHEDULER supports three levels of logging:


DBMS_SCHEDULER.LOGGING_OFF

Logging is completely disabled.


DBMS_SCHEDULER.LOGGING_RUNS

Logs are written only when the job runs. This is the default.


DBMS_SCHEDULER.LOGGING_FULL

Logs are written when the job runs; in addition, all actions on the job (e.g., creation, drop, alteration) are also logged.

I can specify the logging_level parameter in the CREATE_JOB_CLASS procedure as follows:

     BEGIN        DBMS_SCHEDULER.create_job_class                  (job_class_name      => 'MONITOR',                   logging_level       => dbms_scheduler.logging_full                   );     END; 

I can also change the level by setting the logging_level attribute of the job class as follows. (See the discussion of attributes in the later section "Managing Attributes.")

     BEGIN        DBMS_SCHEDULER.set_attribute (NAME           => 'sys.default_job_class',                                      ATTRIBUTE      => 'logging_level',                                      VALUE          => dbms_scheduler.logging_full                                     );     END; 

8.7.1.5. Setting the retention period

Another way to limit the size of your logs is to set the retention period of the log entries in the log tables. When the automatic PURGE_LOG job runs, it purges from the logs only those entries that are older than the associated retention period. The default retention period is 30 days. After 30 days, the 31st oldest day's log is automatically deleted.

If you wish, you can specify a different retention period for each job class. You do this by setting the log_history parameter in the CREATE_JOB_CLASS procedure. (The default value is 30 days.) You can also modify the retention period for an existing job class by setting the log_history attribute at a later time.

In the following example, I specify a log retention period of 120 days when the job class is created:

     BEGIN        DBMS_SCHEDULER.create_job_class (job_class_name      => 'MONITOR',                                         log_history         => 120                                        );     END; 

The next example sets the retention period for an existing job class called DEFAULT_JOB_CLASS:

     BEGIN        DBMS_SCHEDULER.set_attribute (NAME           => 'sys.default_job_class',                                      ATTRIBUTE      => 'log_history',                                      VALUE          => 120                                     );     END; 

I can check the current settings for log retention in the data dictionary view DBA_SCHEDULER_JOB_CLASSES, as shown here:

     SQL> SELECT job_class_name, logging_level, log_history       2    FROM dba_scheduler_job_classes;     JOB_CLASS_NAME                 LOGG LOG_HISTORY     ------------------------------ ---- -----------     DEFAULT_JOB_CLASS              RUNS         120     AUTO_TASKS_JOB_CLASS           RUNS     MONITOR                        RUNS         120 

The default logging level and retention period are adequate in most cases. However, in certain cases, you may want to override these defaults. Logs usually provide the only way that you can diagnose problems after jobs have completed. For particularly important jobs, you may want to enable full logging. For jobs where you may need to look further into the past than is customary, you may want to specify a higher retention period than the default.

8.7.2. Window Logs

Like jobs, windows produce logging entries , which you can examine via the two data dictionary views described in the following sections.

You do not have the same ability to fine-tune the level and the retention period of the logs for window operations as you do for job operations.


8.7.2.1. DBA_SCHEDULER_WINDOW_LOG

When windows are created, altered, and dropped, the results are loaded into a summary table that is visible through the DBA_SCHEDULER_WINDOW_LOG view . Its columns are listed in the following table.

Column name

Description

LOG_ID

Unique identifier for the record.

LOG_DATE

Timestamp of the log entry.

WINDOW_NAME

Name of the window.

OPERATION

What happened to the window during the log entry (e.g., CLOSE, DISABLE, ENABLE, OPEN, UPDATE).

STATUS

What happened after the operation was performed by the job (e.g., SUCCEEDED, FAILED).

USER_NAME

Name of the user who invoked the job.

CLIENT_ID

The client identifier, if set using DBMS_SESSION.SET_IDENTIFIER, is recorded here. If this command was issued from Oracle's Enterprise Manager or Grid Control, this column is populated as follows:

     SYSMAN@192.168.1.1@Mozilla/4.0 (compatible; MSIE 6.0; Windows N 

This example shows that the Grid Control user was SYSMAN, logged in from the IP address 192.168.1.1, and so on.

GLOBAL_UID

If the user is a global user, the global UID is recorded here.

ADDITIONAL_INFO

Any additional information is stored as a CLOB in this column. For example, if the program is disabled forcibly, the OPERATION column shows DISABLE, but not specifically how the program was disabled. The ADDITIONAL_INFO column shows detailed information. For example, if the window was manually disabled, this column will show:

     FORCE="TRUE", REASON="manually disabled" 


8.7.2.2. DBA_SCHEDULER_WINDOW_DETAILS

The DBA_SCHEDULER_WINDOW_LOG view described in the previous section shows the summary log for your windows, not the details. For detailed information about window use, see the view DBA_SCHEDULER_WINDOW_DETAILS. Its columns are listed in the following table.

Column name

Description

LOG_ID

Unique number representing the specific log entry.

LOG_DATE

Timestamp of the log entry, shown in the TIMESTAMP with TIMEZONE datatype.

WINDOW_NAME

Name of the window.

REQ_START_DATE

Scheduled or requested time of the window operation, which may not be the actual time the operation started.

ACTUAL_START_DATE

The window may not open or close at the scheduled or requested time. There are a variety of reasons why this might occurfor example, the window was not enabled; a higher priority window was open; and so on. In this case, the actual timestamp of the start of the window operation is recorded here.

WINDOW_DURATION

Specified duration of the window, shown in the INTERVAL datatype. This might be different from the actual duration of the window.

ACTUAL_DURATION

Actual duration of the window, shown in the INTERVAL datatype. This might be different from the specified duration of the window.

INSTANCE_ID

If this is a RAC database, the instance number is recorded here.

ADDITIONAL_INFO

Any additional information is stored as a CLOB in this column. This information may help in diagnosing window problems.





Oracle PL(s)SQL For DBAs
Oracle PL(s)SQL For DBAs
ISBN: N/A
EAN: N/A
Year: 2005
Pages: 122

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net