Oracle как посмотреть ошибки job

Check Scheduler job detail in CDB

select CON_ID, JOB_NAME,JOB_TYPE,ENABLED, STATE,NEXT_RUN_DATE, REPEAT_INTERVAL from cdb_scheduler_jobs;

Monitor currently running jobs

SELECT job_name, session_id, running_instance, elapsed_time, FROM dba_scheduler_running_jobs;

View the job run details

select * from DBA_SCHEDULER_JOB_RUN_DETAILS;

View the job related logs:

select * from DBA_SCHEDULER_JOB_LOG;

Check all scheduler schedules

set pagesize 200
set lines 299
col START_DATE for a45
col REPEAT_INTERVAL for a45
col schedule_name for a34
select schedule_name, schedule_type, start_date, repeat_interval from dba_scheduler_schedules;

History of all scheduler job runs

set pagesize 299
set lines 299
col JOB_NAME for a24
col actual_start_date for a56
col RUN_DURATION for a34
select job_name,status,actual_start_date,run_duration from DBA_SCHEDULER_JOB_RUN_DETAILS order by ACTUAL_START_DATE desc;

Check log information for all Scheduler jobs

set pagesize 299
set lines 299
col job_name for a24
col log_date for a40
col operation for a19
col additional_info a79
select job_name,log_date,status,OPERATION,ADDITIONAL_INFO from dba_scheduler_job_log order by log_date desc;

Check all scheduler windows details

set pagesize 300 linesize 200
select * from dba_scheduler_windows;

Информацию о журналах заданий можно найти в двух представлениях словаря данных: DBA_SCHEDULER_JOB_LOG и DBA_SCHEDULER_JOB_RUN_DETAILS.

Представление DBA_SCHEDULER_JOB_LOG

При создании, изменении, удалении и запуске заданий результаты таких операций загружаются в сводную таблицу, которая доступна через представление DBA_SCHEDULER_JOB_LOG. Перечень столбцов представления приведен в таблице ниже.

Представление DBA_SCHEDULER_JOB_RUN_DETAILS

Представление DBA_SCHEDULER_JOB_LOG, описанное в предыдущем разделе, выводит сводную журнальную информацию для заданий, но не детали выполнения. Подробные сведения о выполнении работы содержатся в представлении DBA_SCHEDULER_JOB_RUN_DETAILS, столбцы которого описаны в следующей таблице.

Журналирование заданий обеспечивает доступ к очень полезной информации, но если время от времени не очищать журналы, они будут неограниченно увеличиваться в объеме и заполнят все пространство базы данных. По умолчанию журнальная информация хранится в таблице (SYS.SCHEDULER$_JOB_RUN_DETAILS) табличного пространства SYSAUX. Oracle решает проблему, автоматически удаляя журнальные записи через определенные промежутки времени. Операция удаления выполняется заданием планировщика под названием PURGE_LOG, которое принадлежит пользователю SYS. Это задание автоматически устанавливается при создании базы данных Oracle в составе класса заданий DEFAULT_JOB_CLASS. Оно вызывает именованную программу PURGE_LOG_PROG, которая указывает на хранимую процедуру AUTO_PURGE самого пакета DBMS_SCHEDULER.

Это задание выполняется на основе именованного расписания DAILY_ PURGE_SCHEDULE, которое запускается в 3:00 утра ежедневно. Хотя это автоматически создаваемое задание, это не мешает управлять его выполнением. Как и для любых других видов заданий, вы можете изменять его свойства (например, изменить время его запуска, вызываемую программу или определить, следует ли связывать его с окном).

PURGE_LOG удаляет только те записи журнала, которые помечены для удаления, так как истек их период сохранения (retention period) (см. далее раздел «Задание периода сохранения»).

Уровень журналирования

Управлять объемом журнала заданий можно также за счет ограничения объема информации о задании, записываемой в журнал. Например, можно вести журнал только при выполнении задания, но не при его создании. В некоторых случаях можно вообще отказаться от жур- налирования.

Определить уровень журналирования можно при создании класса заданий, задав параметр logging_level процедуры CREATE_JOB_CLASS. Впоследствии задание унаследует свойства класса (при наличии ссылки на класс при создании задания).

DBMS_SCHEDULER поддерживает три уровня журналирования:

DBMS_SCHEDULER.LOGGING_OFF

Журналирование полностью отключено. DBMS_SCHEDULER.LOGGING_RUNS

Журналы ведутся только при выполнении задания. Значение по умолчанию.

DBMS_SCHEDULER.LOGGING_FULL

Журналы ведутся при выполнении задания, а также при осуществлении любых операций над заданиями (таких как создание, удаление и изменение).

Можно задать параметр logging_level процедуры CREATE_JOB_CLASS следующим образом:

Можно изменить уровень журналирования, задав атрибут logg- ing_level класса заданий как в следующем примере (см. далее раздел «Управление атрибутами»).

Задание периода сохранения

Существует еще один способ ограничения размера журналов — задание периода сохранения для записей в журнальных таблицах. При запуске автоматического задания PURGE_LOG из журнала удаляются только те записи, которые старше соответствующей даты. Длительность периода сохранения по умолчанию составляет 30 дней. Через 30 дней журнальные записи, созданные 31 день назад, будут автоматически удалены.

При необходимости можно указать разные периоды сохранения для всех классов заданий. Для этого задайте параметр log_history процедуры CREATE_JOB_CLASS (значение по умолчанию — 30 дней). Позже можно будет изменить период сохранения для существующего класса заданий, задав атрибут log_history.

В следующем примере период сохранения задается для уже существующего класса заданий DEFAULT_JOB_CLASS:

Зададим период сохранения для журнала продолжительностью 120 дней при создании класса заданий:

Текущее значение длительности периода сохранения журнала можно найти в представлении словаря данных DBA_SCHEDULER_JOB_CLASSES:

В большинстве случаев значения по умолчанию для уровня журнали- рования и периода сохранения оказываются вполне подходящими. Однако в некоторых случаях может возникнуть необходимость замены этих значений. Журналы обычно являются единственным средством, с помощью которого можно выявить проблемы после завершения заданий. Для особенно важных заданий можно включить полное жур- налирование. Для заданий, по которым вам необходимо просматривать более старые, чем обычно, сведения, можно указать более долгий (по отношению к значению по умолчанию) период сохранения.

When you have long-running Data Pump jobs, you should occasionally check the status of the job to ensure it hasn’t failed become suspended, and so on. There are several ways to monitor the status of Data Pump jobs:

• Screen output
• Data Pump log file
• Querying data dictionary views
• Database alert log
• Querying the status table
• Interactive command mode status
• Using the process status (ps) OS utility

The most obvious way to monitor a job is to view the status that Data Pump displays on the screen as the job is running. If you’ve disconnected from the command mode, then the status is no longer displayed on your screen. In this situation, you must use another technique to monitor a Data Pump job.

Data Pump Log File

By default, Data Pump generates a log file for every job. When you start a Data Pump job, it’s good practice to name a log file that is specific to that job:

$ impdp mv_maint/foo directory=dp_dir dumpfile=archive.dmp logfile=archive.log

This job creates a file, named archive.log, that is placed in the directory referenced in the database object DP. If you don’t explicitly name a log file, Data Pump import creates one named import.log, and Data Pump export creates one named export.log.

 Note  The log file contains the same information you see displayed interactively on your screen when running a Data Pump job.

Data Dictionary Views

A quick way to determine whether a Data Pump job is running is to check the DBA_DATAPUMP_JOBS view for anything running with a STATE that has an EXECUTING status:

select job_name, operation, job_mode, state
from dba_datapump_jobs;

Here is some sample output:

JOB_NAME                  OPERATION            JOB_MODE   STATE
------------------------- -------------------- ---------- ---------------
SYS_IMPORT_TABLE_04       IMPORT               TABLE      EXECUTING
SYS_IMPORT_FULL_02        IMPORT               FULL       NOT RUNNING



  


                       
  

You can also query the DBA_DATAPUMP_SESSIONS view for session information via the following query:

select sid, serial#, username, process, program
from v$session s,
     dba_datapump_sessions d
where s.saddr = d.saddr;

Here is some sample output, showing that several Data Pump sessions are in use:

      SID    SERIAL#  USERNAME             PROCESS         PROGRAM
---------- ---------- -------------------- --------------- ----------------------
      1049       6451 STAGING              11306           oracle@xengdb (DM00)
      1058      33126 STAGING              11338           oracle@xengdb (DW01)
      1048      50508 STAGING              11396           oracle@xengdb (DW02)

Database Alert Log

If a job is taking much longer than you expected, look in the database alert log for any messages similar to this:

statement in resumable session 'SYS_IMPORT_SCHEMA_02.1' was suspended due to
ORA-01652: unable to extend temp segment by 64 in tablespace REG_TBSP_3

This message indicates that a Data Pump import job is suspended and is waiting for space to be added to the REG_TBSP_3 tablespace. After you add space to the tablespace, the Data Pump job automatically resumes processing. By default a Data Pump job waits 2 hours for space to be added.

 Note  In addition to writing to the alert log, for each Data Pump job, Oracle creates a trace file in the ADR_HOME/trace directory. This file contains information such as the session ID and when the job started. The trace file is named with the following format: <SID>_dm00_<process_ID>.trc.

Status Table

Every time you start a Data Pump job, a status table is automatically created in the account of the user running the job. For export jobs the table name depends on what type of export job you’re running. The table is named with the format SYS_<OPERATION>_<JOB_MODE>_NN, where OPERATION is either EXPORT or IMPORT. JOB_MODE can be FULL, SCHEMA, TABLE, TABLESPACE, and so on.

Here is an example of querying the status table for particulars about a currently running job:

select name, object_name, total_bytes/1024/1024 t_m_bytes
,job_mode
,state ,to_char(last_update, 'dd-mon-yy hh24:mi')
from SYS_EXPORT_TABLE_01
where state='EXECUTING';

Interactive Command Mode Status

A quick way to verify that Data Pump is running a job is to attach in interactive command mode and issue a STATUS command; for example,

$ impdp mv_maint/foo attach=SYS_IMPORT_TABLE_04
Import> status

Here is some sample output:

Job: SYS_IMPORT_TABLE_04
  Operation: IMPORT
  Mode: TABLE
  State: EXECUTING
  Bytes Processed: 0
  Current Parallelism: 4



  


                       
  

You should see a state of EXECUTING, which indicates that the job is actively running. Other items to inspect in the output are the number of objects and bytes processed. Those numbers should increase as the job progresses.

OS Utilities

You can use the ps OS utility to display jobs running on the server. For example, you can search for master and worker processes, as follows:

$ ps -ef | egrep 'ora_dm|ora_dw' | grep -v egrep

Here is some sample output:

oracle 29871   717   5 08:26:39 ?          11:42 ora_dw01_STAGE
oracle 29848   717   0 08:26:33 ?           0:08 ora_dm00_STAGE
oracle 29979   717   0 08:27:09 ?           0:04 ora_dw02_STAGE

If you run this command multiple times, you should see the processing time (seventh column) increase for one or more of the current jobs. This is a good indicator that Data Pump is still executing and doing work.