«Технологии баз данных (СУБД Oracle)» (стр. 8 )

SELECT CAST (empno as VARCHAR2(20)) e FROM emp.

Извлечение значений:

SELECT d. deptno, d. dname, emp.* FROM dept_and_emp D, TABLE (d. emps) emp;

Изменение данных:

UPDATE TABLE (SELECT emps FROM dept_and_emp WHERE deptno = 10 ) SET comm = 100;

В условии оператора SELECT есть таблица значений. Оператор UPDATE показывает, что для каждой строки есть таблица. Мы выбрали отдельную таблицу для изменения; у этой таблицы нет имени - только идентифицирующий ее запрос. Если бы использовался запрос SELECT, возвращающий более одной виртуальной таблицы или не возвращающий ни одной, были бы выданы сообщения об ошибках.

Примеры базового синтаксиса операторов для запросов и изменения вложенных таблиц:

INSERT INTO TABLE (SELECT emps FROM dept_and_emp WHERE deptno = 10)

VALUES (1234, 'NewEmp', 'CLERK', 7782, SYSDATE, 1200, NULL);

DELETE FROM TABLE (SELECT emps FROM dept_and_emp WHERE deptno = 20) WHERE ename = 'SCOTT';

SELECT d. dname, e. empno, ename FROM dept_and_emp d, TABLE (d. emps) e WHERE d. deptno IN (10, 20);

Следующий тип наборов - VARRAY. Массив VARRAY используется для хранения массива данных, связанных с одной строкой. Массив VARRAY во многом похож на вложенную таблицу, но реализуется абсолютно иначе. Например, если необходимо хранить в таблице PEOPLE дополнительные таблицы (скажем, массив прежних адресов проживания, начиная с самого старого), можно сделать следующее:

CREATE OR REPLACE TYPE Address_Array_Type as VARRAY (25) of Address_Type

ALTER TABLE people ADD previous_addresses Address_Array_Type

SET DESCRIBE DEPTH ALL

DESC PEOPLE

Массивы VARRAY либо хранятся в строке как столбец типа RAW, либо (при достаточно большом объеме) как большой объект. Дополнительных ресурсов для поддержки данных типа VARRAY (по сравнению с вложенной таблицей) надо очень мало, что делает массив VARRAY привлекательным методом хранения повторяющихся данных. Поиск по массиву VARRAY можно реализовать, преобразовав его данные в таблицу, что сделает его не менее гибким, чем вложенные таблицы:

UPDATE people SET previous_addresses = Address_Array_Type (

Address_Type ('312 Johnston Dr', null,'Bethlehem', 'PA', 18017),

Address_Type ('513 Zulema S t ' , 'Apartment #3", 'Pittsburg', 'PA', 18123),

Address_Type ('840 South Frederick S t ' , null, 'Alexandria', 'YA', 20654));

SELECT name, prev. city, prev. state, prev. zip_code FROM people p,

TABLE (p. previous_addresses) prev WHERE prev. state = 'PA';

Существенное различие состоит в том, что при реализации с помощью вложенной таблицы можно создать индекс по столбцу STATE вложенной таблицы, и оптимизатор этот индекс использовал бы. В данном случае столбец STATE проиндексировать нельзя. Итак, основные отличия вложенных таблиц от массивов переменной длины (VARRAY) представлены в следующей таблице.

Вложенная таблица	VARRAY
Элементы "массива" не упорядочены. Данные из набора могут возвращаться совсем не в том порядке, в каком они туда вставлялись.	VARRAY - настоящие массивы. Данные после вставки остаются упорядоченными. В рассмотренном ранее примере данные добавлялись в конец массива. Это означает, что самый старый адрес идет в массиве первым, а последний по времени адрес находится в конце массива. При использовании внешней таблицы для упорядочения адресов по давности потребуется дополнительный атрибут.
Вложенные таблицы физически хранятся в виде пары родительской и дочерней таблиц с суррогатными ключами.	Массивы VARRAY хранятся как столбец типа RAW или как большой объект. При этом для обеспечения их работы требуются минимальные дополнительные ресурсы.
Вложенные таблицы не имеют ограничения на количество хранящихся элементов.	Для массивов VARRAY при создании типа задается ограничение на количество хранящихся элементов.
Вложенные таблицы можно изменять (добавлять/изменять/удалять в них данные) с помощью языка SQL.	Массивы VARRAY необходимо изменять процедурно. Нельзя выполнять операторы вида: INSERT INTO TABLE (SELECT P. PREVIOUS ADDRESSES FROM PEOPLE P) VALUES... как для вложенной таблицы. Для добавления адреса придется использовать процедурный код.
Для получения данных строки при использовании вложенных таблиц необходимо выполнять реляционное соединение. В случае небольших наборов это повлечет чрезмерное использование ресурсов.	Для получения данных массива VARRAY соединение выполнять не нужно. В случае небольших наборов данные хранятся в самой строке; если же наборы большие - в сегменте большого объекта. При обращении к элементам массива VARRAY требуется меньше ресурсов, чем при обращении к вложенной таблице. При изменении же данных массива VARRAY ресурсов требуется больше, чем при изменении вложенной таблицы, поскольку заменять приходится весь массив, а не один элемент.

Применение основных стандартных пакетов

Причина использования стандартных пакетов проста: гораздо проще разрабатывать и сопровождать код, использующий стандартные средства, чем создавать их самому. Если корпорация Oracle поставляет пакет для определенных целей (например, шифрования данных), не имеет смысла писать такой пакет самому. Часто разработчики по незнанию создают средства, уже существующие в базе данных. Знание того, какие готовые инструментальные средства имеются, существенно упрощает разработку. Рассмотрим основные стандартные пакеты.

DBMS_APPLICATION_INFO

Пакет DBMS_APPLICATION_INFO позволяет устанавливать значения трех столбцов - CLIENT_INFO, ACTION и MODULE - соответствующей сеансу строки в представлении V$SESSION. Пакет предоставляет функции не только для установки этих значений, но и для их получения. Значения, устанавливаемые в представлениях V$, сразу же доступны в других сеансах. Фиксировать их не нужно, что позволяет эффективно использовать эти представления для взаимодействия с "внешним миром". Пакет DBMS_APPLICATION_INFO позволяет задать значения в представлении динамической производительности V$SESSION_LONGOPS (LONG OPerationS). Это удобно для записи сделанного в продолжительных заданиях. Многие инструментальные средства Oracle, например SQL*Plus, уже используют возможности этого пакета. Для установки соответствующих значений в представлении V$SESSION используются следующие вызовы.

• SET_MODULE. Эта процедура позволяет установить в представлении V$SESSION значения столбца MODULE. В качестве имени модуля обычно указывается имя приложения.

• SET_ACTION. Эта процедура позволяет установить в представлении V$SESSION значение столбца ACTION (действие). Это значение должно быть таким, чтобы можно было понять, какая часть кода программы выполняется. В качестве действия можно указывать, например, имя текущей активной экранной формы, имя функции в программе на Pro*C или имя PL/SQL-подпрограммы.

• SET_CLIENT_INFO. Эта процедура позволяет сохранить до 64 байт специфической информации о приложении, которая может понадобиться. Обычно так сохраняются параметры представления или запроса.

Процедура SET_CLIENT_INFO позволяет установить не только значения в столбцах представления V$SESSION, но и значение переменной CLIENT_INFO, которое можно получить с помощью встроенных функций userenv или sys_context. Например, можно создать параметризованное представление, результаты выборки данных из которого зависят от значения переменной CLIENT_INFO. Эту идею можно проиллюстрировать следующим примером:

BEGIN

DBMS_APPLICATION_INFO. SET_CLIENT_INFO ('KING');

END;

SELECT userenv ('CLIENT_INFO') FROM dual;

SELECT sys_context ('userenv','client_info') FROM dual;

Многие действия в базе данных могут выполняться достаточно долго. При выполнении этих продолжительных действий информация о ходе работы записывается в представление динамической производительности V$SESSION_LONGOPS, что позволяет оценить объем сделанного. Это представление можно использовать и в приложениях. В представлении отражается состояние действий, выполняющихся в базе данных более шести секунд. Другими словами, в функции сервера Oracle, которые, по предположению разработчиков, обычно выполняются дольше шести секунд, включены вызовы процедуры, вставляющей данные в представление V$SESSION_LONGOPS. Это не означает, что при выполнении любого действия продолжительностью более шести секунд в это представление автоматически будет что-то записываться. К таким действиям сейчас относятся многие функции резервного копирования и восстановления, сбора статистической информации и выполнение запросов. В каждой новой версии Oracle появляются новые действия. Изменения в этом представлении сразу же доступны для других сеансов, т. е. транзакцию фиксировать не нужно. Можно контролировать ход процесса, изменяющего это представление, из другого сеанса с помощью запросов к представлению V$SESSION_LONGOPS. Разработчики могут добавлять строки в это представление. Обычно приложение вставляет и изменяет одну строку, но при необходимости можно вставлять и несколько.

Процедура для установки значений в этом представлении имеет следующие параметры:

• RINDEX. Указывает серверу, какую строку в представлении V$SESSION_LONGOPS необходимо изменить. Если в качестве значения этого параметра указать DBMS_APPICATION_INFO. SET_SESSION_LONGOPS_NOHINT, в это представление будет автоматически вставлена новая строка, индекс которой будет записан в RINDEX. При указании в последующих вызовах процедуры SET_SESSION_LONGOPS этого индекса в качестве значения параметра RINDEX будет изменяться добавленная строка.

• SLNO. Служебное значение. Первоначально надо передать значение NULL, а полученное в результате выполнения значение - игнорировать. При каждом вызове надо передавать одно и то же значение.

• OP_NAME. Имя продолжительно выполняющегося процесса. Его длина не должна превышать 64 байт, а в качестве значения необходимо задавать строку, по которой легко определить, что именно выполняется.

• TARGET. Обычно используется для передачи идентификатора объекта, с которым выполняется продолжительное действие (например, идентификатор таблицы, в которую загружаются данные). Можно передать любое значение, в том числе NULL.

• CONTEXT. Число, задаваемое пользователем. Это число должно быть информативным для пользователя. Передать можно любое число.

• SOFAR. В качестве значения можно передавать любое число, но если это число будет представлять собой процент или другую количественную характеристику уже выполненной части действия, сервер сможет автоматически оценить, сколько времени осталось до завершения действия. Например, если необходимо обработать 25 объектов и на обработку каждого из них уходит примерно одинаковое время, можно задать в качестве значения параметра SOFAR количество обработанных объектов, а общее их количество передать как следующий параметр, TOTALWORK. Сервер определит, сколько времени потребовалось для выполнения уже сделанной части, и оценит время, необходимое для завершения действия.

• TOTALWORK. В качестве значения можно передавать любое число, но имеет смысл сопоставлять его со значением параметра SOFAR. Если SOFAR представляет собой процент от TOTALWORK, отражающий ход выполнения действия, сервер сможет вычислить, сколько времени осталось до завершения действия.

• TARGET_DESC. Этот параметр описывает значение TARGET, представленное выше. Если в качестве параметра TARGET передан идентификатор объекта, параметр может содержать имя объекта с этим идентификатором.

• UNITS. Описательный параметр, задающий единицу измерения для значений параметров SOFAR и TOTALWORK. Это могут быть, например, файлы, итерации или вызовы.

Перечисленные выше значения может устанавливать пользователь. Если обратиться к представлению V$SESSION_LONGOPS, то в нем можно обнаружить намного больше столбцов, чем описано выше:

DESC v$session_longops

Результат:

SID NUMBER

SERIAL# NUMBER

OPNAME VARCHAR2(64) **

TARGET VARCHAR2(64) **

TARGET_DESC VARCHAR2(32) **

SOFAR NUMBER **

TOTALWORK NUMBER **

UNITS VARCHAR2(32) **

START_TIME DATE

LAST_UPDATE_TIME DATE

TIME_REMAINING NUMBER

ELAPSED_SECONDS NUMBER

CONTEXT NUMBER **

MESSAGE VARCHAR2(512)

USERNAME VARCHAR2(30)

SQL_ADDRESS RAW(4)

SQL_HASH_VALUE NUMBER

QCSID NUMBER

Значения столбцов, помеченных двумя звездочками (**), может устанавливать пользователь.

Остальные столбцы имеют следующие значения.

• Столбцы SID и SERIAL# используются при соединении с представлением V$SESSION для получения информации о сеансе.

• Столбец START_TIME содержит время создания записи (обычно это время первого вызова процедуры DBMS_APPLICATION_INFO. SET_SESSION_LONGOPS, с помощью которого и была создана строка).

• Столбец LAST_UPDATE_TIME представляет время последнего вызова процедуры SET_SESSION_LONGOPS.

• Столбец TIME_REMAINING содержит предполагаемое время, оставшееся до завершения действия. Его значение вычисляется как:

ROUND(ELAPSED_SECONDS*((TOTALWORK/SOFAR)-1)).

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

• Столбец MESSAGE - производный. Он представляет собой конкатенацию значений столбцов OPNAME, TARGET_DESC, TARGET, SOFAR, TOTALWORK и UNITS, описывающую выполняемое действие.

• Значение в столбце USERNAME - имя пользователя, выполняющего действие.

• Значения столбцов SQL_ADDRESS и SQL_HASH_VALUE можно использовать для поиска в представлении V$SQLAREA последнего SQL-оператора, выполненного процессом.

• Значение столбца QCSID используется при распараллеливании запроса. Это идентификатор сеанса-координатора параллельного запроса.

Итак, что же можно получить с помощью данного представления? Небольшой пример поможет прояснить это. Выполним в одном сеансе следующий блок кода:

DECLARE

l_nohint NUMBER DEFAULT dbms_application_info. set_session_longops_nohint;

l_rindex NUMBER DEFAULT l_nohint;

l_slno NUNBER;

BEGIN

FOR i IN 1 .. 25

LOOP

dbms_lock. sleep(2);

dbms_application_info. set_session_longops

(rindex => l_rindex,

slno => l_slno,

op_name => 'my long running operation',

target => 1234,

target_desc => '1234 is my target',

context => 0,

sofar => i,

totalwork => 25,

units => 'loops'

);

END LOOP;

END;

Этот блок кода представляет собой продолжительное действие, выполняющееся в течение 50 секунд (вызов DBMS_LOCK. SLEEP просто приостанавливает выполнение на две секунды). В другом сеансе можно следить за ходом данного сеанса с помощью представленного ниже запроса:

BEGIN

print_table('SELECT b.*

FROM v$session a, v$session_longops b

WHERE a. sid = b. sid

AND a. serial# = b. serial#');

END;

Может возникнуть вопрос: зачем представление V$SESSION_LONGOPS соединяется с представлением V$SESSION, если из V$SESSION не выбирается информация?

Дело в том, что представление V$SESSION_LONGOPS содержит строки, как для текущего, так и для прежних сеансов. По завершении сеанса это представление не очищается. Данные остаются, пока какой-нибудь другой сеанс не использует повторно соответствующий слот. Поэтому, чтобы получить информацию только для текущих сеансов, необходимо использовать соединение или подзапрос.

Этот пример демонстрирует, что из представления V$SESSION_LONGOPS можно получить информацию, весьма ценную для пользователей и администраторов базы данных, которым необходимо контролировать ход выполнения продолжительных хранимых процедур, пакетных заданий, отчетов и т. п. Добавив лишь несколько вызовов, можно получить точную информацию в производственной среде. Вместо того чтобы гадать, что именно происходит в задании и сколько оно будет выполняться, можно получить точную информацию о том, что сделано, и обоснованную оценку времени, необходимого для завершения работы.

Oracle Enterprise Manager (OEM) и многие инструментальные средства независимых производителей обращаются к этому представлению и автоматически отображают информацию, которую приложения в нем устанавливают.

DBMS_JOB

Пакет DBMS_JOB позволяет запланировать однократное или регулярное выполнение заданий в базе данных. Задание представляет собой хранимую процедуру, анонимный блок PL/SQL или внешнюю процедуру на языке С или Java. Эти задания выполняются серверными процессами в фоновом режиме. Задания можно выполнять регулярно (в 2 часа ночи каждые сутки) или однократно (выполнить задание сразу после фиксации транзакции и удалить его из очереди). Задания выполняются в той же среде (пользователь, набор символов и т. п.), из которой они посланы на выполнение. Задания выполняются аналогично процедурам с правами создателя. Рекомендуется вообще не использовать средства ОС для планирования заданий в базе данных, а вместо этого написать хранимую процедуру, выполняющую необходимые действия, и запланировать ее выполнение с помощью средств пакета DBMS_JOB. При этом ни имя пользователя, ни пароль нигде не хранится, и задание выполнится только в том случае, когда доступна база данных. Если сервер базы данных не будет работать в соответствующий момент, задание, естественно, не выполнится, поскольку именно сервер базы данных и отвечает за выполнение задания.

Для корректной работы пакета DBMS_JOB необходимо выполнить небольшую настройку сервера. Надо установить два параметра инициализации.

• job_queue_interval. Задает периодичность (в секундах) проверки очередей и поиска заданий, готовых к выполнению. Если задание должно выполняться раз в 30 секунд, но параметр job_queue_interval имеет (стандартное) значение 60, это задание не будет выполняться раз в 30 секунд - в лучшем случае, раз в 60 секунд.

• job_queue_processes. Задает количество фоновых процессов для выполнения заданий. Значением может быть целое число от 0 (по умолчанию) до 36. Это значение можно менять без перезапуска сервера с помощью оператора

ALTER SYSTEM SET job_queue_processes = <nn>.

Если оставить стандартное значение 0, задания из очереди автоматически никогда выполняться не будут.

Многие системы работают со значением параметра job_queue_interval, равным 60 (другими словами, проверяют очереди раз в минуту), и значением параметра job_queue_processes, равным 1 (выполняют одновременно не более одного задания). При интенсивном использовании заданий или возможностей, для реализации которых используются задания (в частности, репликация и поддержка материализованных представлений используют очереди заданий), может потребоваться добавление дополнительных процессов и увеличение значения параметра инициализации job_queue_processes. После настройки и автоматического запуска очередей заданий можно начинать их использование.

Основная процедура пакета DBMS_JOB - процедура SUBMIT. Назначение аргументов процедуры SUBMIT:

• JOB. Идентификатор задания. Присваивается системой (этот параметр передается в режиме OUT). Его можно использовать для получения информации о задании из представлений USER_JOBS или DBA_JOBS по идентификатору задания. Кроме того, некоторые процедуры, в частности RUN и REMOVE, требуют единственного параметра - идентификатора задания - для определения того, какое именно задание выполнять или удалять из очереди.

• WHAT. Действие, которое необходимо выполнить. Можно передавать PL/SQL-оператор или блок кода.

• NEXT_DATE. Время следующего (а поскольку мы только посылаем задание - первого) выполнения задания. Стандартное значение - SYSDATE - означает "выполнять немедленно" (после фиксации транзакции).

• INTERVAL. Строка, содержащая функцию, вычисляющую время следующего выполнения задания. Можно считать, что значение этой функции выбирается с помощью оператора 'select... from dual'. Если передать строку sysdate+l, сервер выполнит SELECT sysdate+l INTO :NEXT_DATE FROM DUAL. Ниже описаны особенности задания интервала выполнения задания, предотвращающие его смещение.

• NO_PARSE. Указывает, анализировался ли параметр WHAT при отправке задания. Анализируя строку, можно определить, выполнимо ли вообще задание. В общем случае параметру NO_PARSE надо всегда оставлять стандартное значение, False. При установке значения True параметр WHAT принимается "как есть", без проверки допустимости.

• INSTANCE. Этот параметр имеет значение только в режиме Parallel Server, когда сервер Oracle работает на кластере слабо связанных машин. Он задает экземпляр, на котором будет выполняться задание. По умолчанию он имеет значение ANY_INSTANCE.

• FORCE. Этот параметр также имеет значение только в режиме Parallel Server. При установке значения True (принятого по умолчанию) можно посылать задание с любым идентификатором экземпляра, даже если при отправке соответствующий экземпляр недоступен. При установке значения False отправка задания завершится неудачно, если указанный экземпляр недоступен.

В пакете DBMS_JOB есть и другие подпрограммы. Задание посылается на выполнение с помощью процедуры SUBMIT, a остальные подпрограммы позволяют манипулировать заданиями в очередях и выполнять действия по их запуску (RUN), удалению из очереди (REMOVE) и изменению (CHANGE). Ниже описаны наиболее часто используемые подпрограммы, включая входные данные и назначение.

REMOVE< номер задания> - удаляет задание из очереди. Учтите, что если задание выполняется, удаление не остановит его выполнение. Удаление из очереди гарантирует, что задание не будет выполнено снова, но уже выполняющееся задание при этом не останавливается. Для остановки выполняющегося задания необходимо прекращать работу соответствующего сеанса с помощью оператора ALTER SYSTEM.

CHANGE <номер задания, WHAT, NEXT_DATE, INTERVAL, INSTANCE, FORCE > - эта процедура работает как оператор UPDATE для представления JOBS. Она позволяет изменить любой параметр задания.

BROKEN <номер задания, BROKEN (булево задание), NEXT_DATE > - позволяет "разрушить" или "восстановить" задание. Разрушенное задание не выполняется. Задание, не выполнившееся успешно 16 раз подряд, автоматически помечается как разрушенное, и сервер Oracle больше не будет его выполнять.

RUN <номер задания> - выполняет задание немедленно, в приоритетном режиме (в пользовательском сеансе). Полезно при отладке не срабатывающих заданий.

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

CREATE OR REPLACE PROCEDURE analyze_my_tables

AS

BEGIN

FOR x IN (SELECT table_name FROM user_tables)

LOOP

EXECUTE IMMEDIATE

'analyze table ' || x. table_name || ' compute statistics';

END LOOP;

END;

Чтобы запланировать ее выполнение сегодня ночью в 3 часа (точнее, завтра утром), а затем ежесуточно в 3 часа ночи, можно использовать следующий вызов:

DECLARE

l_job NUMBER;

BEGIN

DBMS_JOB. SUBMIT (JOB => l_job,

WHAT => 'analyze_my_tables;',

NEXT_DATE => TRUNC (SYSDATE) +l+3/24,

INTERVAL => 'TRUNC (SYSDATE)+l+3/24');

END;

SELECT job, to_char (sysdate,'dd-mon'), to_char (next_date,'dd-mon-yyyy hh24:mi:ss'),

interval, what FROM user_jobs;

Здесь использованы функции для работы с датами, так что при выполнении, независимо от времени вызова, всегда будет возвращаться 3 часа следующего утра. Это важно. Точно такую же функцию, но в виде строки мы передали в качестве значения параметра INTERVAL. Используется функция, всегда возвращающая 3 утра завтрашнего дня, независимо от времени ее выполнения. Это предотвращает смещение заданий (jobs sliding). Может показаться, что, поскольку первый раз задание выполняется в 3 часа утра, можно задать интервал sysdate+l. Если выполнить это вычисление в 3 утра во вторник, в результате мы получим 3 утра среды. Получим, если задание гарантированно выполнится в указанное время, но это вовсе не обязательно.

Задания в очереди обрабатываются последовательно, в соответствии с указанным временем выполнения. При наличии одного процесса обработки очереди сообщений и двух заданий, назначенных на 3 утра, очевидно, что одно из них не выполнится точно в 3 утра. Придется подождать, пока завершится выполнение первого задания. Даже при отсутствии заданий, назначенных на то же время, очереди заданий просматриваются периодически, например каждые 60 секунд. Задание, назначенное на выполнение в 3 утра, может быть выбрано из очереди в 3:00:45 утра. Если использовать функцию sysdate+l, в следующий раз задание может быть поставлено на выполнение в 3:00:46 утра. На следующий день в 3:00:45 утра задание еще не будет готово для выполнения и выполнится при следующем просмотре очереди, в 3:01:45 утра. Время выполнения задания медленно сдвигается. Однако это не самое худшее. Предположим, на следующий день в 3 утра с таблицами будут работать, и проанализировать их не удастся. Хранимая процедура не сработает и будет возвращена в очередь для выполнения. Теперь это задание окажется смещенным на несколько минут позже 3 утра. Поэтому, чтобы предотвратить смещение времени выполнения заданий, необходимо использовать функцию, возвращающую фиксированный момент времени, если выполнение в конкретный момент времени является существенным. Если важно, чтобы задание выполнялось именно в 3 утра, надо использовать функцию, всегда возвращающую время 3 утра, независимо от времени ее выполнения.

Для контроля заданий в базе данных используется три основных представления.

• USER_JOBS. Список всех заданий, посланных текущим зарегистрированным пользователем. У этого представления есть также общедоступный синоним, ALL_JOBS. ALL_JOBS содержит ту же информацию, что и USER_JOBS.

• DBA_JOBS. Полный список всех заданий, находящихся в очередях базы данных.

• DBA_JOBS_RUNNING. Список выполняющихся заданий. Обычно представление USER_JOBS доступно всем пользователям, а представления DBA_* - только пользователям с привилегией DBA или получившим привилегию SELECT непосредственно для этих представлений. В этих представлениях находится следующая информация.

• LAST_DATE/LAST_SEC. Когда последний раз выполнялось задание. LAST_DATE - столбец типа DATE. LAST_SEC - строка символов, содержащая только время (в формате часов:минут:секунд).

• THIS_DATE/HIS_SEC. Если задание в настоящий момент выполняется, в этом столбце будет время начала выполнения. Как и пара столбцов LAST_DATE/LAST_SEC, столбец THIS_DATE содержит дату и время, а столбец THIS_SEC - символьную строку, в которой указано только время.

• NEXT_DATE/NEXT_SEC. Время, когда задание будет выполнено в следующий раз.

• TOTAL_TIME. Общее время выполнения задания в секундах. Включает время выполнения предыдущих прогонов - это суммарное значение.

BROKEN. Флаг Yes/No, показывающий, что задание разрушено. Разрушенные задания не выполняются процессами обработчик очередей. Задание разрушается после 16 неудачных попыток выполнения. Для разрушения задания можно и