Oracle События ожидания

Группы событий ожидания


I/O  (Write I/O, Read I/O)
Buffer Cache  (Buffer Busy, Cache Latches)
Library Cache  (Library Cache, Shared Pool)
Lock  (TX Row Lock, TX ITL Lock, HW Lock)
Redo  (Log File, Log Buffer, Log File Sync)
SQL*Net  (SQL*Net more data from client, SQL*Net more data to client)



Administrative
Ожидания, относящиеся к ожиданиям пользователей завершения команд DBA
( например таких как index rebuild )


Application

Ожидания, относящиеся к коду пользовательских приложений
(например, lock waits caused by row level locking or explicit lock commands)


Cluster

Ожидания, относящиеся к ресурсам Real Application Cluster
(например, global cache resources such as 'gc cr block busy')


Commit

Этот класс ожиданий включает всего одно событие  - ожидание подтверждения
записи redo log из буфера на диск после commit  ('log file sync')


Concurrency
Ожидания внутреннего ресурса БД (например, latches)


Configuration

Ожидание вызвано неадекватной конфигурацией БД  или ресурсов экземпляра
(например, undersized log file sizes, shared pool size)


Idle

Ожидания бездействия, пустое ожидание (например, 'SQL*Net message from client')


Network

Ожидания связанные с передачей сетевых сообщений
(например, 'SQL*Net more data to dblink')


Other

Ожидания, которые не должны типично проявляться в системе
(например, 'wait for EMON to spawn')


Scheduler

Ожидания относящиеся к Resource Manager (например, 'resmgr: become active')


System I/O

Ожидания ввода/вывода фоновых процессов
(например, DBWR wait for 'db file parallel write')


User I/O

Ожидания ввода/вывода пользовательских процессов
(например, 'db file sequential read')



Некоторые события ожидания

db file sequential read
log file sync
db file scattered read
latch free
enqueue
SQL*Net more data from client
direct patch read
direct patch write
buffer busy waits
SQL*Net more data to client
log buffer space
log file switch completion
library cache pin
SQL*Net break/reset to client
io done
file open
free buffer waits
db file parallel read
weite complete waits
library cache lock
SQL*Net more data from dblink
log file switch (checkpoint incomplete)
library cache load lock
row cache lock
local write wait
sort segment request
process startup
uread message
file identify
pipe put
switch logfile command
SQL*Net break/reset to dblink
log file switch (archivig needed)
wait for a undo record
direct patch write (lob)
undo segment extension



Enqueue ST - Use LMT or preallocate large extents
Enqueue HW - Pre allocate extents above HW (high water mark)
Enqueue TX - Increase inittrans/maxtrans
Enqueue TM - Index foreign key Check application locking tablex DML Locks




SQL*Net more data from client
Это единственное чистое ожидание бездействия из всех SQL*Net% ожиданий.
Оно возникает когда серверный процесс запущен, а клиент ему никаких запросов не присылает.
Пользователь запустил форму, открыл соединениес БД, что-то там поделал и начал пить чай.
Серверный процесс висит и ждёт.


SQL*Net more data to client
Это уже более содержательная штука.
Это ожидание возникает у серверного процесса когда он хочет отправить сообщенин клиенту и не может
(например сеть занята, сетевой драйвер занят)
Это может влиять на производительность даже очень заметно.
Ожидание возможности отправить клиенту порцию данных.
Select выполнил fetch, порцию получили, надо клиенту отослать и почему-то это сделать невозможно.
Приходится ждать, сеть сбоит.
Оно считается idle, потому что средствами Oracle не лечится, лечится только средствами OC или железа.
С ним можно бороться только настройкой сети.


db file sequential read
Ожидание дискового чтения.
Нормальное ожидание, зависания на нем не бывает.
Если таких ожиданий много, то значит плохо используется кэш буферов т.е. много обращений к диску.
Нужно настроить SQL-оператор, уменьшая количество логических чтений, надеясь что при этом и количество физических чтений уменьшится.
Или настраивать кэш буферов, т.е. увеличивать коэффициент попадания в кэш.


log file sync
Возникает при коммите, когда сбрасывается содержимое журнального буфера в файл оперативного журнала.
Серверный процесс, который получил от пользователя commit, дёргает процесс LGWR и говорит ему сбросить журнальный буфер.
Пока LGWR этим занимается, серверный процессвисит в этом ожидании.
Если это ожидание часто встречается и занимает много времени, то можно попробовать снизить количество коммитов (частоту коммитов).
А может проблема в том, что LGWR не успевает, тогда настройте журнальные файлы.


log file parallel write
Усли оно коррелирует с log file sync, то это уже проблема.
Скорее всего проблема в плохой настройке процесса LGWR.
Надо перебросить файл оперативного журнала на отдельный диск.
Уменьшить их дуплицирование, увеличить размер журнального буфера.


enqueue
Ожидание получения бблокировки.
Когда сессия стоит в очереди waiter-ов или converter-ов она находится в состоянии ожидания enqueue.
Смотрим в v$lock и разбираемся кто и кого ждёт и почему.


latch free
Ожидание освобождения защёлки.
Нельзя точно сказать что с ними делать, типов защёлок около 200.
Разобраться за какую именно защёлку идёт конкуренция, какую защёлку чаще всего ждут.


======================================================================


system_wait

set lines 100
set pages 100
clear breaks
clear columns

column c1 heading 'Event' format A30 wrap
column c2 heading 'Total Waits' format 999,999,999
column c3 heading 'Wait Time(s)' format 999,999
column c4 heading 'Timeouts' format 999,999,999
column c5 heading 'Avg. Wait (s)' format 99.999

select event c1,
total_waits c2,
time_waited/100 c3,
total_timeouts c4,
average_wait/100 c5
from v$system_event
where event not in (
'dispatcher timer',
'lock element cleanup',
'Null event',
'parallel query dequeue wait',
'parallel query idle wait - Slaves',
'pipe get',
'PL/SQL lock timer',
'pmon timer',
'rdbms ipc message',
'slave wait',
'smon timer',
'SQL*Net break/reset to client',
'SQL*Net message from client',
'SQL*Net message to client',
'SQL*Net more data to client',
'virtual circuit status',
'WMON goes to sleep'
)
and event not like 'DFS%'
and event not like '%done%'
and event not like '%Idle%'
and event not like 'KXFX%'
order by c2 desc ;




system_wait_details

set lines 132
set pages 1000
clear breaks
clear columns

column c1 heading 'ID' format 999
column c2 heading 'Process' format A10
column c3 heading 'Event' format A30
column c4 heading 'Total Waits' format 999,999
column c5 heading 'Wait Time(s)' format 999,999
column c6 heading 'Timeouts' format 999,999
column c7 heading 'Avg. Wait(s)' format 999
column c8 heading 'Max Wait(s)' format 999

select b.sid c1,
decode(b.username,NULL,c.name,b.username) c2,
event c3,
a.total_waits c4,
round((a.time_waited / 100),2) c5,
a.total_timeouts c6,
round((average_wait / 100),2) c7,
round((a.max_wait / 100),2) c8
from
sys.v_$session_event a,
sys.v_$session b,
sys.v_$bgprocess c
where
event not like 'DFS%' and
event not like 'KXFX%' and
a.sid = b.sid and
b.paddr = c.paddr (+) and
event not in (
'lock element cleanup',
'pmon timer',
'rdbms ipc message',
'smon timer',
'SQL*Net message from client',
'SQL*Net break/reset to client',
'SQL*Net message to client',
'SQL*Net more data to client',
'dispatcher timer',
'Null event',
'io done',
'parallel query dequeue wait',
'parallel query idle wait - Slaves',
'pipe get',
'PL/SQL lock timer',
'slave wait',
'virtual circuit status',
'WMON goes to sleep')
order by 4 desc ;


currently_waiting

set lines 200
set pages 100
clear breaks
clear columns

col c1 heading 'SID' format 999
col c2 heading 'User Name' format a16 wrap
col c3 heading 'Event Name' format a10 wrap
col c4 heading 'InWait(s)' format 999,999.99
col c5 heading 'Wait Time' format 999,999.99
col c6 heading 'state' format a10 wrap
col c7 heading 'P1 text' format a10 wrap
col c8 heading 'P1 Val' format 999,999,999
col c9 heading 'P1 Raw' format a10
col c10 heading 'P2 Text' format a10 wrap
col c11 heading 'P2 Val' format 999,999,999
col c12 heading 'P2 Raw' format a10
col c13 heading 'P3 Text' format a10 wrap
col c14 heading 'P3 Val' format 999,999,999
col c15 heading 'P3 Raw' format a10

SELECT
a.sid c1,
decode(b.username, NULL,c.name, b.username) c2,
a.event c3,
a.seconds_in_wait c4,
a.wait_time c5,
a.state c6,
a.p1text c7,
a.p1 c8,
a.p2text c10,
a.p2 c11,
a.p3text c13,
a.p3 c14
FROM
v$session_wait a,
v$session b,
v$bgprocess c
where
event not like 'DFS%' and
event not like 'KXFX%' and
a.sid = b.sid and
b.paddr = c.paddr (+) and
event not in
('lock element cleanup',
'pmon timer',
'rdbms ipc message',
'smon timer',
'SQL*Net message from client',
'SQL*Net break/reset to client',
'SQL*Net message to client',
'SQL*Net more data to client',
'dispatcher timer',
'Null event',
'parallel query dequeue wait',
'parallel query idle wait - Slaves',
'pipe get',
'PL/SQL lock timer',
'slave wait',
'virtual circuit status',
'WMON goes to sleep'
)
order by 4 desc ;







buffer busy waits

Индицирует ожидание буфера в буферном кэше базы данных.
Это означает, что сеанс считывает этот буфер в кэш и/или модифицирует его.
Может также служить симптомом нехватки списков свободных участков таблиц,
поддерживающих множество параллельно выполняющихся операций INSERT.


db file parallel write

Индицирует ожидания, относящиеся к процессам DBWR. Может быть связан с
числом конфигурированных процессов DBWR или подчиненных процессов
ввода/вывода DBWR. Может также означать низкую или высокую конкуренцию
устройств.


db file scattered read

Индицирует ожидания, ассоциируемые со сканированием всей таблицы.
Может означать конкуренцию ввода/вывода или чрезмерное количество
операций ввода/вывода.


db file sequential read

Индицирует (наряду с другими вещами) ожидания, ассоциируемые
со сканированием индекса. Может означать конкуренцию ввода/вывода или
чрезмерное количество операций ввода/вывода.


db file single write

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


direct path read

Индицирует ожидания, ассоциируемые с разрешенным прямым
вводом/выводом. Обычно указывает на конкуренцию ввода/вывода за
устройства.


direct path write

To же, что и выше. Относится к операциям чтения.


enqueue

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


free buffer inspected

Индицирует ожидания, ассоциируемые с процессом идентификации
свободного буфера в буферном кэше базы данных для переноса в него
данных.


free buffer waits

Индицирует недостаток свободных буферов в буферном кэше базы данных.
Это может означать одно из двух: либо буферный кэш базы данных слишком
мал, либо "грязный список" (список модифицированных блоков кэша) не
переписывается на диск достаточно быстро. Если дело в этом,
сконфигурируйте большее количество процессов DBWR или подчиненных
процессов ввода/вывода, в зависимости от обстоятельств. Это событие
происходит, когда инспектирующее свободные буферы событие не находит ни
одного свободного буфера.


latch free

Индицирует конкуренцию за защелку (внутреннюю блокировку) для
конкретного номера защелки (latch*). Убедитесь, что число защелок было
настроено на максимально разрешенное значение, для чего проверьте
релевантные (относящиеся к делу) параметры файла init.ora. Если проблема
остается, необходимо определить, что вызывает конкуренцию за защелку.
Событие latch free - это всего лишь симптом более серьезной проблемы.
Например, если получающийся в результате номер защелки является
защелкой библиотечного кэша (при этом коллективный пул настроен должным
образом), ситуация может означать значительный объем жесткого
синтаксического анализа. Это обычно является проблемой для приложений,
содержащих в себе жестко закодированные значения. Необходимо либо
переписать приложение, используя переменные связи, либо перейти к
Oracle8i и использовать CURSOR_SHARING=force (или искать другие способы).


library cache load lock

Требуется для загрузки объектов в библиотечный кэш. Такое событие
ожидания может произойти, если имеет место значительное число
загрузок/перезагрузок (обычно подобное происходит вследствие либо
недостаточного многократного использования операторов SQL, либо из-за
неправильно выбранного размера области коллективного пула).


library cache lock

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


library cache pin

Индицирует ожидания, которые ассоциируются с одновременными
обращениями к библиотечному кэшу и могут происходить в тех случаях, когда
необходимо модифицировать или проверить конкретный объект в
библиотечном кэше.


log buffer space

Индицирует потенциальную проблему: LGWR не способен поддерживать
скорость записи серверными процессами в буфер журнала обновлений.
Обычно означает, что имеет место проблема с размером буфера журнала (он
слишком мал), или слишком медленно работает устройство (а), или имеется
конкуренция устройств, на которых размещаются работающие в онлайновом
режиме журналы обновлений.


log file parallel write

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


log file single write

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


log file switch

(требуется архивирование)
Ожидание означает, что ARCH не работает синхронно с LGWR. Может
произойти из-за того, что онлайновые журналы обновлений слишком малы,
устройства медленны или высока конкуренция за устройства (обычно
возникающая вследствие размещения журнальных файлов на тех же
устройствах, что и файлы данных). Имеет смысл изучить возможность
создания нескольких процессов ARCH или подчиненных процессов
ввода/вывода, в зависимости от обстоятельств.


log file switch

(незавершенная контрольная точка)
Индицирует ожидания, ассоциируемые с неверно заданными размерами
журнальных файлов (обычно слишком малыми).


log file sync

Индицирует ожидания, ассоциируемые со сбрасыванием на диск буферов
журналов при выполнении операции фиксирования транзакции, Если
ожидания являются устойчивыми, это может означать конкуренцию устройств,
на которых размещены онлайновые файлы журналов обновлений и/или
медленную работу устройств.


SQL*Net more data from client/to client

Индицирует затраченное время в процессе взаимодействия
пользовательского и серверного процессов. В некоторых довольно редких
случаях указывает на проблемы при передаче по сети, но по большей части
может быть проигнорировано. Если приложение поддерживает конфигурацию
ARRAYSIZE (например, Oracle Forms, SQL*Plus, Рго*С и т. д.),
конфигурирование ARRAYSIZE на значение, превосходящее значение по
умолчанию, может потенциально уменьшить ожидания для этого события.


SQL*Net more data from dblink

Индицирует ожидание, ассоциируемое с распределенной обработкой
(выполнением SELECT из других баз данных). Это событие происходит, когда
онлайновые просмотры других баз данных выполняются через DBUNKS. Если
просматриваемые данные главным образом статические, их пересылка в
локальную (расположенную на этой же ЭВМ) таблицу и ее обновление по
мере необходимости могут дать существенное увеличение
производительности.



transaction

Индицирует ожидания, ассоциируемые с блокировкой транзакций операциями
отката.


undo segment extension

Индицирует динамическое выделение экстентов и расширение сегментов
отката. Это может означать нехватку (недостаточность) заданного числа
сегментов отката или слишком малое значение оптимального числа
MINEXTNTS для этих сегментов.


write complete waits

Индицирует ожидания, связанные с буферами, которые необходимо
переписать на диск. Такая запись может быть вызвана обычным старением
блоков из буферного кэша базы данных.

Более подробное описание событий ожидания:

События ожидания – это статистики, значения которых увеличиваются серверным процессом (потоком), что бы указать, что он должен был ожидать завершения события, перед тем как продолжить обработку. Увеличение количества и продолжительности событий ожиданий может свидетельствовать о возникающих проблемах производительности. Мониторинг событий ожидания является важной составной частью работы администратора баз данных.

Классы событий ожидания

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

Administrative - ожидание пользователем результатов выполнения DBA команд (например, пересоздание индекса).

Application - ожидание результатов из пользовательского программного кода (например, ожидание блокировки, вызванное блокировкой уровня строки или явными командами блокировки).

Cluster - ожидания, связанные с ресурсами Real Application Clusters (например, глобальные ресурсы кэша, такие как 'gc cr block busy').

Commit - класс включает только одно событие ожидания - ожидание подтверждения записи в журнал после фиксации транзакции ('log file sync').

Concurrency - ожидание внутренних ресурсов базы данных (например, защёлки).

Configuration - ожидания вызванные неправильной конфигурацией базы данных или ресурсов экземпляра (например, карликовые размеры файлов журнала или разделяемого пула).

Idle - ожидания, показывающие неактивность сеанса в ожидании работы (например, 'SQL*Net message from client').

Network - ожидания связанные с обменом сообщениями по сети (например, 'SQL*Net more data to dblink').

Other – ожидания, которые обычно не должны происходить в системе (например, 'wait for EMON to spawn').

Queue - содержит события, которые показывают задержки получения дополнительных данных в канальной среде. Время, затраченное в этих ожиданиях, указывает на неэффективность или другие проблемы в канале, что влияет на такие функции Oracle, как Oracle Streams, параллельные запросы или PL/SQL пакеты DBMS_PIPE.

Scheduler – ожидания связанные с менеджером ресурсов (например, 'resmgr: become active').

System I/O – ожидания ввода-вывода фоновых процессов (например, ожидание DBWR 'db file parallel write').

User I/O – ожидания ввода-вывода пользовательских процессов (например, 'db file sequential read' ).



Параметры событий ожидания

Большинство  событий ожидания имеют параметры, с помощью которых можно получить дополнительную информацию об ожидании. Некоторые из этих параметров специфичны для конкретного события ожидания, другие имеют общее предназначение. Ниже приведены наиболее часто встречающиеся общие параметры событий ожидания:

block#

Номер ожидаемого блока относительно начала файла.

break?

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

class

Класс блока описывает, как используется содержание блока. Например, класс 1 представляет блок данных, и класс 4 представляет заголовок сегмента.

dba

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

driver id

Адрес функции отсоединения используемого в настоящий момент драйвера.

file#

Номер файла базы данных.

id1

Первый идентификатор (id1) очереди с ожиданием или глобальной блокировки принимает своё значение от P2 или P2RAW. Значение идентификатора зависит от имени (P1).

id2

Второй идентификатор (id1) очереди с ожиданием или глобальной блокировки принимает своё значение от P3 или P3RAW. Значение идентификатора зависит от имени (P1).

le

Относительный индекс в V$GC_ELEMENT

mode

Параметр обычно хранится в младших байтах P1 или P1RAW и указывает на режим запроса очереди или глобальной блокировки. Существуют следующие значения этого параметра:

Значение режима

Описание
1    Null mode
2    Sub-Share
3    Sub-Exclusive
4    Share
5    Share/Sub-Exclusive
6    Exclusive


name and type

Имя или тип блокировки с очередью или глобальной блокировки может быть определены по двум старшим байтам P1 или P1RAW. Имя определяется всегда двумя символами.

session#

Идентификатор неактивного сеанса (SID).

waited

Общая сумма времени, которую ожидал сеанс, прежде чем закончиться.

Описания событий ожидания

Ниже перечислены названия событий ожидания, их краткие описания,  единицы измерения времени и параметры:

alter system set dispatcher

Сеанс выполнил оператор ALTER SYSTEM SET DISPATCHER = string и ожидает старта диспетчеров.

Время ожидания: сеанс будет ждать 1 / 100 секунды, чтобы затем проверить, стартовали ли диспетчеры. Если нет, сеанс ожидает их старта снова.

Параметры:

waited                 Показывает, сколько раз сеанс ожидал интервал в 1 / 100 секунды.

batched allocate scn lock request

Сеанс ожидает другой процесс, чтобы выделить системный номер изменения (SCN).  Если время, в течение которого приоритетный процесс ожидал получения другим процессом SCN, истекло, то такой приоритетный процесс получит SCN.

Время ожидания: составляет 1 секунду при условии, что для выделения SCN требуется меньше времени.

BFILE check if exists

Сеанс ожидает проверки на существование внешнего большого объекта (LOB).

Время ожидания: общее время, прошедшее с начала вызова exists

Параметры:  session#, waited

BFILE check if open

Сеанс ожидает открытия внешнего большого объекта (LOB).

Время ожидания: общее время, прошедшее с начала вызова isopen

Параметры:  session#, waited

BFILE closure

Сеанс ожидает закрытия внешнего большого объекта (LOB).

Время ожидания: общее время, прошедшее с начала вызова close

Параметры:  session#, waited

BFILE get length

Сеанс ожидает, чтобы проверить размер  внешнего большого объекта (LOB).

Время ожидания: общее время, прошедшее с начала вызова проверки размера

Параметры:  session#, waited

BFILE get name object

Сеанс ожидает, чтобы найти или сгенерировать внешнее имя внешнего большого объекта (LOB).

Время ожидания: общее время, прошедшее до завершения  make external file name.

Параметры:  session#, waited

BFILE get path object

Сеанс ожидает, чтобы найти или сгенерировать внешний путь внешнего большого объекта (LOB).

Время ожидания: общее время, прошедшее до завершения  make external path.

Параметры:  session#, waited

BFILE internal seek

Сеанс ожидает окончания позиционирования в пределах внешнего большого объекта (LOB).

Время ожидания: общее время, прошедшее до завершения seek.

Параметры:  session#, waited

BFILE open

Сеанс ожидает открытия внешнего большого объекта (LOB).

Время ожидания: общее время, прошедшее с начала вызова isopen.

Параметры:  session#, waited

BFILE read

Сеанс ожидает окончания чтения внешнего большого объекта (LOB).

Время ожидания: общее время, прошедшее до завершения read.

Параметры:  session#, waited

broadcast mesg queue transition

Процессы входят в "wait for broadcast mesg queue transition", когда очистка дескриптора канала публикатора обращается к надёжному  широковещательному каналу. Публикатор ответственен за перемещение сообщения в свободную очередь, но он не может это сделать, пока сообщение не находится в готовой очереди. Если сообщение всё ещё не находится в готовой очереди, то процесс ожидает при входе. Это ожидание события наиболее вероятно обнаружиться, когда процесс Oracle собирается нормально завершиться или когда PMON очищает мёртвый процесс. Переданное сообщение находится в очереди восстановления другого дескриптора канала (например, ch2).

Время ожидания: изменяется

Параметры:

channel handle -  указатель дескриптора канала публикатора

message -  указатель широковещательного сообщения

location -  число, указывающее на функцию в KSR, где процесс ожидает

>= 10.2 |

broadcast mesg recovery queue transition

Процессы входят в "wait for broadcast mesg recovery queue transition", когда очистка дескриптора канала публикатора обращается к надёжному  широковещательному каналу. Широковещательное сообщение находится в очереди восстановления другого дескриптора канала. Процесс ожидает при входе, если сообщение должно быть удалено из очереди восстановления другого дескриптора канала.  Это ожидание события наиболее вероятно обнаружиться, когда процесс Oracle собирается нормально завершиться или когда PMON очищает мёртвый процесс. Переданное сообщение находится в очереди восстановления другого дескриптора канала (например, ch2).

Время ожидания: изменяется

Параметры:

channel handle  -  указатель дескриптора канала публикатора.

message -  указатель широковещательного сообщения

location -  число, указывающее на функцию в KSR, где процесс ожидает

>= 10.2 |

buffer busy waits

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

Время ожидания: Нормальное время ожидания составляет 1 секунду. Если сеанс уже ожидал буфер во время последнего ожидания, то следующее время ожидания будет 3 секунды.

Параметры:  file#, block#

Id - событие ожидания занятого буфера, вызываемое из различных мест в сеансе

buffer deadlock

Oracle в действительности не ожидает на этом событии, приоритетный процесс возвращает CPU. Поэтому возможность отловить это событие крайне мала. Это не взаимная блокировка вызванная приложением, а лишь предполагаемая взаимная блокировка на уровне кэша. Она возникает, когда слой кэша не может получить буфер в определенном режиме в пределах определенного количества времени.

Время ожидания: 0 секунд. Приоритетный процесс только возвращает CPU, после чего обычно помещается в конец CPU очереди выполнения.

Параметры:  class, mode, dba

Flag - флаг указывает на внутренние флаги, используемые сеансом, чтобы получить блок

buffer for checkpoint

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

Время ожидания:          1 секунда.

Параметры:                     mode, dba

state – состояние указывает статус содержимого буфера

buffer# - индекс блока находящегося в буфферном кэше (V$BH)

 <= 10.1 |

buffer latch

Сеанс ожидает получения защёлки хешированной цепочки буферов (buffer hash chain).  Прежде всего, используется в подпрограммах получения дампа.

Время ожидания: 1 секунда.

Параметры:  class, mode, dba

latch addr – виртуальный адрес в SGA, где эта защёлка расположена.

chain# - индекс в массиве хешированной цепочки буферов. Когда индекс равен 0xfffffff,  приоритетный процесс ожидает защёлку LRU.

buffer read retry

Событие имеет место только тогда, когда экземпляр монтируется в разделяемом режиме (Oracle Real Application Cluster). Возникает, если во время чтения буфера его содержимое изменилось. Это означает одно из двух:

Номер версии, адрес блока данных или номер инкарнации больше не соответствуют порядковому номеру, сохранённому в блоке
Полученная и хранимая контрольная сумма блока  не соответствует друг другу
Блок будет повторно прочитан (может быть  до 3 неудачных попыток), после чего предполагается повреждение, и поврежденный блок выводится в файл трассировки.

Время ожидания: общее время чтения

Параметры:  file#, block#

checkpoint completed

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

Время ожидания: 5 секунд.

cleanup of aborted processes

Когда порождаемый процесс прерывается в середине порождения, текущий сеанс должен ожидать, пока идентификатор (pid) нового процесса не заполниться. Как только pid будет заполнен, порождаемый процесс будет прерван.

Время ожидания: Обычно 3 секунды.

Параметры:

location – местоположение ожидания

control file parallel write

Событие возникает тогда, когда сеанс осуществляет запись физических блоков во все контрольные файлы. Это происходит в следующих случаях:

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

Параметры:

files – количество контрольных файлов в которые записывает сеанс

blocks – количество блоков, которые сеанс записывает в контрольный файл

requests – количество запросов ввода-вывода нужных сеансу для записи

control file sequential read

Чтение из контрольного файла. Может происходить, например при:

Создание резервной копии контрольных файлов
Разделении информации из контрольных файлов (между экземплярами)
Чтения других блоков контрольных файлов
Чтение блока заголовка
Время ожидания: общее время чтения.

Параметры:

file# – номер контрольного файла из которого сеанс читает.

block# – номер блока в контрольном файле, с которого сеанс начинает чтение. Размер блока является физическим размером блока порта (обычно 512 байтов, у некоторых портов в UNIX может быть 1 или 2 Кбайта).

blocks – количество блоков, которые сеанс пытается прочитать.

control file single write

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

Время ожидания: общее время записи.

Параметры:

file# – номер контрольного файла в который сеанс записывает.

block# – номер блока в контрольном файле, с которого сеанс начинает запись. Размер блока является физическим размером блока порта (обычно 512 байтов, у некоторых портов в UNIX может быть 1 или 2 Кбайта).

blocks – количество блоков, которые сеанс пытается прочитать.

cursor: mutex S

Ожидание события возникает тогда, когда сеанс делает запрос на получения мьютекса (mutex)  курсора в разделяемом режиме, в то время как мьютекс на этот же курсор был ранее захвачен в монопольном режиме другим сеансом.

Параметры:

P1 – Значение хэш-функции курсора

P2 – Значение mutex (верхние 2 байта содержат SID сеанса захватившего mutex в монопольном режиме, нижние 2 байта содержат значение 0)

P3 – Условие mutex (internal code locator) или Mutex Sleeps

cursor: mutex X

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

Параметры:

P1 – Значение хэш-функции курсора

P2 – Значение mutex (верхние 2 байта содержат SID сеанса захватившего mutex в монопольном режиме, нижние 2 байта содержат значение 0)

P3 – Условие mutex (internal code locator) или Mutex Sleeps

cursor: pin S

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

Время ожидания: микросекунды

Параметры:

P1 – Значение хэш-функции курсора

P2 – Значение mutex (верхние 2 байта содержат SID сеанса захватившего mutex в монопольном режиме, нижние 2 байта содержат значение 0)

P3 – Условие mutex (internal code locator) или Mutex Sleeps

cursor: pin S wait on X

Ожидание события возникает тогда, когда сеанс запрашивает закрепление (pin) разделяемого мьютекса, в то время как другой сеанс удерживает закрепление мьютекса в монопольном режиме для того же самого курсора.

Время ожидания: микросекунды

Параметры:

P1 – Значение хэш-функции курсора

P2 – Значение mutex (верхние 2 байта содержат SID сеанса захватившего mutex в монопольном режиме, нижние 2 байта содержат значение 0)

P3 – Условие mutex (internal code locator) или Mutex Sleeps

cursor: pin X

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

Время ожидания: микросекунды

Параметры:

P1 – Значение хэш-функции курсора

P2 – Значение mutex (верхние 2 байта содержат SID сеанса захватившего mutex в монопольном режиме, нижние 2 байта содержат значение 0)

P3 – Условие mutex (internal code locator) или Mutex Sleeps

Data Guard: process clean up

Ожидание события возникает во время аварийного завершения процесса Data Guard. Data Guard будет ждать одну секунду для освобождения ресурсов процесса.

Data Guard: process exit

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

Data Guard Broker: single instance

Процесс  Data Guard Broker (DMON) ожидает полной остановки других экземпляров в кластере перед продолжением операций брокера.

Время ожидания: зависит от числа экземпляров, но не превышает 30 секунд

db file parallel read

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

Время ожидания: ожидание пока все операции ввода-вывода не завершаться

Параметры:

files – число файлов из которых читает сеанс

blocks– общее количество блоков, которые будут  считаны

requests– общее количество запросов ввода-вывода (равное количеству блоков)

db file parallel write

Событие возникает в DBWR. Оно показывает, что DBWR выполняет параллельную запись в файлы и блоки. Когда выполняется последний ввод –вывод на диск, возникает ожидание окончания операции.

Время ожидания: Ожидание пока операция ввода-вывода не завершится

Параметры:

requests - общее количество запросов ввода-вывода (равное количеству блоков)

interrupt

timeout - значение тайм-аута в сотых частях секунды (до завершения операции ввода-вывода).

db file scattered read

Событие подобно “db file sequential read” за исключением того, что сеанс читает несколько блоков данных.

Время ожидания: время требуемое для завершения всех операций ввода-вывода.

Параметры:  file#, block#

Blocks– Число блоков которые сеанс пытается считать из file#,начиная с блокаblock#

db file sequential read

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

Время ожидания: время, требуемое для завершения всех операций ввода-вывода.

Параметры:  file#, block#

Blocks – Число блоков, которые сеанс пытается считать (должно равняться 1).

db file single write

Событие ожидания используется при записи в заголовки файлов.

Время ожидания: фактическое время, требуемое для завершения всех операций ввода-вывода.

Параметры:  file#, block#

Blocks – Число блоков, которые сеанс пытается записать в file#,начиная с блокаblock#

DFS db file lock

Событие имеет место только для DBWR в Real Application Clusters. Каждый DBWR в каждом экземпляре держит глобальную блокировку (DF) в разделяемом режиме на каждый файл. Экземпляр, который пытается перевести файл в offline режим, расширяет глобальную блокировку от разделяемого до монопольного режима. Событие сигнализирует другим экземплярам, что надо синхронизировать их SGA и контрольные файлы, перед тем как файл будет переведён в  offline режим.

Время ожидания: 1 секунда в цикле. DBWR ожидает в цикле (sleep, check) пока другие экземпляры не понизят блокировки до NULL режима.  В это время, DBWR не может выполнять другие задачи, например, такие как запись буферов.

Параметры:  file#

DFS lock handle

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

Время ожидания: Сеанс ожидает в цикле, пока не получит дескриптор блокировки из DLM. Длительность ожидания в цикле 0.5 секунд.

Параметры:  name, mode, id1, id2

direct path read

Во время операций прямого доступа, данные асинхронно читаются из файлов базы данных. На некотором этапе сеанс должен удостовериться, что весь асинхронный ввод-вывод на диск был завершён. Событие так же может произойти, если во время прямого чтения нет больше доступных слотов для хранения невыполненных запросов загрузки (запрос загрузки мог состоять из нескольких операций ввода-вывода).

Время ожидания: 10 секунд. Сеанс будет осведомлён о завершении асинхронного ввода-вывода. Сеанс не будет ожидать все 10 секунд.  Ожидание длиться в цикле, пока все операции ввода-вывода не завершатся. 

Параметры:

descriptor address - указатель на контекст незавершённых  операций прямого ввода-вывода, завершения которых ожидает сеанс.

first dba – адрес блока (dba) самой первой операции ввода-вывода в контексте, на который ссылается адрес дескриптора.

block cnt – Число корректных буферов в контексте на который ссылается адрес дескриптора.

direct path sync

Во время операций прямого доступа, данные асинхронно пишутся в файлы базы данных. В некоторый момент времени сеанс должен гарантировать, что весь ожидающий асинхронный ввод-вывод был завершён на диск. В это время Unix fsync команда, которая синхронизует данные с диском, подтверждает, что все записи завершились и все данные на диске.

Время ожидания: время, потраченное на завершение операций fsync, которое обычно является временем, потраченным, чтобы завершить ожидающий ввод-вывод.

Параметры: file#

flags - флаги используемые для отладки

direct path write

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

Время ожидания: 10 секунд. Сеанс будет осведомлён о завершении асинхронного ввода-вывода. Сеанс не будет ожидать все 10 секунд.  Ожидание длиться в цикле, пока все операции ввода-вывода не завершатся. 

Параметры:

descriptor address - указатель на контекст незавершённых  операций прямого ввода-вывода, завершения которых ожидает сеанс.

first dba – адрес блока (dba) самой первой операции ввода-вывода в контексте, на который ссылается адрес дескриптора.

block cnt – Число корректных буферов в контексте на который ссылается адрес дескриптора.

Disk file operations I/O

Событие ожидания используется для файловых операций (к примеру, open, close, seek, resize).  Оно так же может использоваться и для различных операций ввода-вывода, таких как дамп блока и доступ к файлу паролей.

Время ожидания: фактическое время, которое требуется для того, чтобы сделать ввод-вывод.

Параметры:

FileOperation – тип файловой операции

fileno – идентификационный номер файла

filetype – тип файла (для примера, файл данных, файл журнала)

dispatcher shutdown

Во время завершения работы (normal, immediate) экземпляр должен ожидать завершения работы диспетчеров. Сеанс, который инициировал завершение работы экземпляра, посылает сигналы каждому диспетчеру и ожидает завершения диспетчерского процесса.

Время ожидания: 1 секунда

Параметры:

waited - Указывает на общее время ожидания. После истечения 5 минут сеанс записывает в alert файл и файлы трассировки сообщение о возможной проблеме.

dispatcher timer

Событие в основном означает, что диспетчер неактивен и ожидает некоторой работы.

Время ожидания: 60 секунд

Параметры:

sleep time – Задаваемое время засыпания. Диспетчер быстрее возвратиться к работе, если получит сообщение от данных полученных из сети или процессов разделяемого сервера о том, что данные надо отослать обратно клиенту.

duplicate cluster key

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

Время ожидания: 0.01 секунды

Параметры:

dba – адрес блока, в который сеанс пытается вставить кластерный ключ

enq: OW – initialization

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

Время ожидания:  Общее время, необходимое для инициализации контекста wallet

enq: OW – termination

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

Время ожидания: Общее время, необходимое для освобождения памяти  используемой контекстом wallet и завершения контекста.

enqueue

Сеанс ожидает локальной блокировки. Ожидание зависит от имени блокировки.

Время ожидания:  зависит от имени блокировки

Параметры: name, mode


flashback buf free by RVWR

Событие ожидания имеет место тогда, когда включен Flashback Database. Сеанс ожидает процесса (RVWR), который записывает данные журнала flashback на диск, когда буферы заполнены. Сеанс будет ожидать до тех пор, пока RVWR не освободит буферы.

Если данное событие выходит на вершину ожиданий, это означает, что файловая система или хранение области Fast Recovery на уровне системы не имеют достаточной пропускной способности чтобы записывать журналы flashback.

Время ожидания: 1 секунда

flashback logfile sync

Ожидание данных flashback database, которые будут записаны на диск.

Время ожидания: Включает время записи данных flashback  процессом RVWR плюс  регистрацию процесса.

free buffer waits

Событие может произойти если:

Все чтения буфера приостановлены. Это происходит в случаях, когда файл был в режиме только для чтения, а стал в режиме записи-чтения. Все существующие буферы должны стать недействительными, так как они не связаны с элементами блокировок (необходимыми при монтировании  в параллельном (разделяемом) режиме). Поэтому буферы кэша не назначаются адресам блоков данных до тех пор, пока они не станут недействительными.
Сеанс перемещал некоторые модифицированные (грязные) буферы в очередь модифицированных буферов и эта очередь стала полной. Очередь должна быть записана сначала. Сеанс будет ожидать на этом событии, а затем попробует ещё раз найти свободный буфер.
Осуществляется поиск свободных буферов. Если свободный буфер не найден, то Oracle ожидает одну секунду, а затем пытается снова получить буфер (зависит от контекста).
Время ожидания: 1 секунда

Параметры: file#, block#

free global transaction table entry

Сеанс ожидает свободный слот в глобальной таблице транзакции (используемой опцией Distributed Database). Сеанс будет  ожидать в течение 1 секунды, после чего повторит запрос.

Время ожидания: 1 секунда

Параметры:

tries – число попыток поиска свободного слота в глобальной таблице транзакции

free process state object

Используется во время создания процесса. Сеанс сканирует таблицу процессов и ищет свободный слот процесса. Если ни один свободный слот не найден, PMON проверяет, все ли процессы, находящиеся в таблице живы. Если найдены мёртвые процессы, то PMON уберёт их и сделает слот доступным для новых процессов. После этого, ожидающий процесс повторно сканирует таблицу процессов, что бы найти новый слот.

Время ожидания: 1 секунда

gc recovery quiesce

Восстановление экземпляра ожидает завершения операции глобального кэша.

Время ожидания: Общее время завершения операции глобального кэша.

Параметры: file#, block#, class

GCS lock open S

Сеанс ожидает получения ресурса в разделяемом режиме на блоке, который идентифицируется параметрами  file# и block#.

Время ожидания: 1 секунда

Параметры: file#, block#, class

GCS lock open X

Сеанс ожидает получения ресурса в монопольном режиме на блоке, который идентифицируется параметрами file# и block#.

Время ожидания: 1 секунда

Параметры: file#, block#, lenum

gcs remastering wait for drop pkey

Сеанс, удаляющий объект ожидает демона менеджера блокировок (LMD), чтобы удалить связь объекта с экземпляром.

 Время ожидания: 20 сотых частей секунды

Параметры:    

pkey – идентификатор удаляемого объекта

global cache busy

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

Время ожидания: 1 секунда

Параметры: file#, block#, le

global cache lock cleanup

PMON ожидает очистки процессом LCK контекста блокировки после того, как приоритетный процесс аварийно завершился во время операции блокировки глобального кэша.

Время ожидания: 1 секунда

Параметры: file#, block#, lenum

global cache freelist

Все освобождённые блокировки использованы и была запрошена новая блокировка. Чтобы сделать элемент ресурса доступным, он проверяется с помощью запроса ping.

Время ожидания:  продолжительность операции проверки элемента ресурса с помощью запроса ping.

inactive session

Это событие используется в двух целях:



Переключение сеансов. Если определён период тайм-аута, то сеанс будет ожидать заданное количество времени, после чего отсоединиться.
Уничтожение сеансов. Может выполняться с помощью KILL SESSION или внутреннего запроса. Уведомив сеанс об уничтожении, событие ожидает завершения сеанса в течение 1 минуты.


Время ожидания: 1 секунда

Параметры: session#, waited

inactive transaction branch

Сеанс ожидает ветвь транзакции, которая в настоящий момент используется другим сеансом.

Время ожидания: 1 секунда

Параметры: waited

branch#- порядковый номер транзакции, которую ожидает сеанс

index block split

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

Время ожидания: сеанс отдаёт CPU, таким образом нет никакого фактического времени ожидания.

Параметры:                   

rootdba – корневой блок индекса

level – уровень блока индекса, который сеанс пытается расщепить. Для листовых блоков уровень равен 0. Если уровень > 0, то это - блок ответвления. (Корневой блок можно считать специальным блоком ответвления).

сhilddba – блок который сеанс пытается расщепить

instance state change

Сеанс ожидает процесс SMON чтобы включить или выключить кэш или восстановление транзакции. Такое обычно происходит во время команд ALTER DATABASE OPEN или CLOSE.

Время ожидания:  Время ожидания зависит от количества времени, которое занимает действие (то есть, количество необходимого для восстановления)

Параметры:                   

layer - значение может быть 1 или 2. Если 1, это означает, что уровень транзакции хочет, чтобы восстановление транзакции было выполнено. Если 2, это означает, что будет выполняться восстановление кэша.

value - значение может быть 0 (отключено) или 1 (включено)

waited- число секунд ожидания

io done

Сеанс ожидает завершения ввода-вывода, или доступности подчинённого  процесса, для передачи ему запроса ввода-вывода. Это событие имеется на платформах, которые не поддерживают асинхронный ввод-вывод.

Время ожидания: 50 миллисекунд

Параметры:    

msg ptr – указатель на запрос ввода-вывода

kcl bg acks

Сеанс ожидает завершения операций фонового процесса (ов) LCK. Например:



Восстановление блокировки
Инициализация блокировок (запуск)
Завершение блокировок (завершение)


Время ожидания: 10 секунд

Параметры:    

count – число закончившихся процессов LCK

loops – колличество ожиданий  завершения операций процесса LCK

ksxr wait for mount shared

Межэкземплярное широковещательное средство экземпляра Oracle ожидает завершение монтирования базы данных в разделяемом режиме.

Время ожидания:  время, потраченное на монтирование экземпляра. Если значение неопределенное, то, скорее всего, запуск экземпляра завис.

ktm: instance recovery

Сеанс ожидает процесс SMON, чтобы завершить экземпляр, восстановить транзакцию или очистить сегмент сортировки.

Время ожидания: время ожидания может измениться и зависит от объёма необходимого восстановления

Параметры:

undo segment# - если значение 0, SMON, вероятно, выполняет восстановление экземпляра. Если P1 > 0, то для поиска сегмент отката можно использовать следующий запрос:

select *
  from v$rollstat
 where usn = undo segment#;

latch activity

Событие используется для определения того, должна ли быть защёлка очищена.

Время ожидания: от 0.05 сек. до 0.1 сек.

Параметры:

address – адрес проверяемой защёлки

number – номер активной защёлки. Для поиска дополнительной информации можно использовать следующий запрос:

select *
from v$latchname
where latch# = number;

latch free

Процесс ожидает защёлку, которая в настоящий момент захвачена другим процессом.

Время ожидания: Время ожидания увеличивается по экспоненте и не включает в себя повторение процесса получения защёлки (spin активное ожидание).  Максимальное время ожидания так же зависит от числа защёлок, которые захватил процесс. В пределах 2 секунд ожидание инкрементное.

Параметры:

address – адрес ожидаемой защёлки

number – номер защёлки. Для поиска дополнительной информации можно использовать следующий запрос:

select *
from v$latchname
where latch# = number;

latch: cache buffers chains

Событие ожидания получения защёлки cache buffers chains. Данная защёлка служит для того, чтобы защитить буферный список в буферном кэше. Используется при поиске, добавлении и удалении буфера из буферного кэша. При этих операциях на цепочку состоящую из нескольких буферов буферного кэша накладывается защёлка, которая препятствует доступу других сеансов к конкретному блоку находящемуся в данной буферной цепочке. В это время другие сеансы осуществляющие доступ к блоку будут ожидать получения защёлки на данной буферной цепочке. После завершения операции защёлка снимается.

Большое количество данного события ожидания может свидетельствовать о наличии «горячего» (интенсивно используемого) блока в буферном кэше.

library cache load lock

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

Время ожидания: 3 секунды (1 секунда для PMON)

Параметры:

object address – адрес загружаемого объекта

lock address –адрес используемой блокировки загрузки

mask – указывает какие части данных объекта должны быть загружены

library cache lock

Событие управляет конкуренцией между клиентами библиотечного кэша. Оно получает блокировку на указатель  объекта, чтобы:



Один из клиентов мог препятствовать тому, чтобы другие клиенты получили доступ к этому объекту
Один из клиентов мог поддерживать зависимость в течение долгого времени (например, что бы никакие другие сеансы не могли изменить объект).


Блокировка так же может запрашиваться для поиска объекта в кэше библиотеки.

Время ожидания: 3 секунды (1 секунда для PMON)

Параметры:  namespace

handle address - адрес загружаемого объекта

lock address – адрес используемой блокировки загрузки. Это не защёлка (latch) или блокировка (enqueue), а   объект состояния (State Object).

mode – указывает какие части данных объекта должны быть загружены

library cache pin

Событие управляет конкуренцией библиотечного кэша. Закрепление объекта вызывает загрузку «кучи» в память. Если клиент хочет изменить или просмотреть объект, он должен получить закрепление после блокировки.

Время ожидания: 3 секунды (1 секунда для PMON)

Параметры: namespace

handle address - адрес загружаемого объекта

pin address – адрес используемой блокировки загрузки. Это не защёлка (latch) или блокировка (enqueue), а   объект состояния (State Object).

mode – указывает какие части данных объекта должны быть загружены

library cache shutdown

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

LMON global data update

Операция прокручивающей миграции ожидает от  процесса LMON подтверждения, что глобальные данные обновлены.

lock manager wait for remote message

Менеджер блокировок ожидает сообщение от  удаленного менеджера блокировок в той же самой конфигурации.

Время ожидания: Прошедшее время ожидания

Параметры:

waittime - время фактического ожидания

Log archive I/O

Используется при архивировании журнальных файлов (для основной и резервной базы данных). Когда процесс архивирования исчерпывает все свои буферы ввода-вывода, он будет ожидать свободного буфера.

Время ожидания: Зависит от скорости дисков

log buffer space

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

Время ожидания: Обычно 1 секунда, но если переключение журнала то 5 секунд

log file parallel write

Ожидание, возникающее при перезаписи журнальных записей из журнального буфера в файлы журнала.

Время ожидания: Время завершения ввода - вывода. Несмотря на то, что журнальные записи пишутся параллельно, запись  не считается законченной, пока не завершится последний ввод-вывод  на диск.

Параметры:

files – количество записываемых файлов

blocks – количество блоков, которые будут записаны

requests- число запросов ввода-вывода

log file sequential read

Ожидание завершения чтения из файла журнала. Используется для чтения журнальных записей из файла журнала.

Время ожидания: Время завершения физического ввода-вывода (чтение).

Параметры:  block#

log#  – Относительный порядковый номер журнального файла в группе журнальных файлов (используется только при дампе журнального файла).

blocks – число читаемых блоков

log file single write

Ожидание завершения записи в файл журнала. Используется при обновлении заголовка файла журнала. Возникает при добавлении журнального файла в группу и увеличении порядкового номера (sequence number).

Время ожидания: Время завершения физического ввода-вывода (запись).

Параметры:  block#

log#  – номер  группы  (файла) , в которую в настоящий момент времени сеанс осуществляет запись

blocks – число записываемых блоков

log file switch (archiving needed)

Ожидание переключения журнала, в связи с тем, что файл журнала, переключаемый LGWR, ещё не был заархивирован.  Необходимо проверить сигнальный файл, чтобы удостовериться, что архивирование не остановилось из-за ошибки записи. Для ускорения архивирования можно добавить дополнительные процессы архивирования или разместить архивные файлы на быстрых дисках.

Время ожидания: 1 секунда

log file switch (checkpoint incomplete) 

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

Время ожидания: 1 секунда

log file switch (clearing log file)

Ожидание переключения журнала, в связи с тем, что была выполнена команда CLEAR LOGFILE или из-за того, что была неявная очистка файла журнала при восстановлении.

Время ожидания: 1 секунда

log file switch (private strand flush incomplete)

Пользовательские сеансы при попытке генерации журнальной информации ожидают на событии, когда LGWR ждёт DBWR, чтобы завершить сбрасывание журнальной информации из IMU буферов в журнальный буфер; Когда DBWR заканчивает работу, LGWR может закончить запись в текущий журнал, и затем переключить файл журнала.

Время ожидания: 1 секунда

log file switch completion

Ожидание завершения переключения  журнала

Время ожидания: 1 секунда

log file sync

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

Время ожидания: включает время затраченное на запись информации из журнального буфера и отправку сообщения.

Параметры:                   

buffer# – количество физических буферов в журнальном буфере, которые должны синхронизироваться.

log switch/archive

Используется в качестве части оператора ALTER SYSTEM ARCHIVE LOG CHANGE scn. Сеанс ожидает текущий журнальный файл от всех открытых потоков, которые будут заархивированы.

Время ожидания: до 10 секунд

Параметры:                   

thread# – номер потока, который в настоящее время архивирует текущий журнальный файл.

optimizer stats update retry

Когда сеансы пытаются обновить статистику оптимизатора для одного и того же объекта, они могут ожидать в случаях, когда один из сеансов уже получил все необходимые блокировки (закрепления) на  записях библиотечного кэша (кэша строки)  относящихся к объекту. После короткого периода времени ожидания запрос на блокировку записей повторяется. В дополнение к неявным операциям сбора и обслуживания статистики с использованием пакета DBMS_STATS, Oracle может попытаться обновить статистику для некоторых объектов или от имени пользователя или в собственных целях обслуживания.

Время ожидания: 10 миллисекунд

parallel recovery change buffer free

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

Время ожидания: 100 миллисекунд

parallel recovery control message reply

Координатор параллельного восстановления ожидает все подчинённые процессы, что бы ответить на  синхронное управляющее сообщение.

Время ожидания: 100 миллисекунд

parallel recovery coord send blocked

Координатор параллельного восстановления не может отправить сообщение с журнальными изменениями, потому что подчинённый процесс восстановления  всё ещё  активно применяет изменения, и полученный им канал ещё не освобождён.

Время ожидания: 100 миллисекунд

parallel recovery coord wait for reply

Координатор параллельного восстановления ожидает завершения всех подчинённых процессов восстановления.

Время ожидания: 100 миллисекунд

parallel recovery coordinator waits for slave cleanup

Координатор параллельного восстановления ожидает завершения всех подчинённых процессов восстановления, чтобы завершиться корректно.

Время ожидания: 10 миллисекунд

parallel recovery read buffer free

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

Время ожидания: 100 миллисекунд

parallel recovery slave next change

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

Время ожидания: 100 миллисекунд

pending global transaction(s)

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

Время ожидания: 30 секунд

Параметры:

scans – сколько раз сеанс просматривал таблицу PENDING_TRANS$.

pipe get

Сеанс ожидает сообщение, которое будет получено по каналу, или истечение таймера канала.

Время ожидания: 5 секундное пробуждение (проверка) или таймер канала, установленный пользователем

Параметры:

handle address – указатель на объект библиотечного кэша для канала

buffer length – длина буфера

timeout – таймер канала установленный пользователем

pipe put

Сеанс ожидает истечение таймера канала для отправки сообщения или выделения пространства в канале.

Время ожидания: 5 секундное пробуждение (проверка) или таймер канала, установленный пользователем

Параметры:

handle address – указатель на объект библиотечного кэша для канала

buffer length – длина записи или буфера, который был помещён в канал

timeout – таймер канала установленный пользователем

PL/SQL lock timer

Событие вызывается через процедуру DBMS_LOCK.SLEEP. Наиболее вероятно произойдёт из процедур написанных пользователем.

Время ожидания: Время ожидания задаётся в сотых частях секунд и зависит от пользовательского контекста.

Параметры:

duration - продолжительность, которую пользователь определил в процедуре DBMS_LOCK.SLEEP

pmon timer

Это основное событие ожидания PMON. Когда PMON неактивен, он ожидает на этом событии.

Время ожидания: до 3 секунд, если заранее небыло уведомления

Параметры:

duration – фактическое количество времени, которое PMON провёл в режиме ожидания

prewarm transfer retry

Ожидание возникает при повторном получении хэш-защёлки, после её освобождения.

Время ожидания: 10 миллисекунд

prior process spawner to be cleaned up

Когда предшествующий процесс умирает во время порождения фонового процесса, текущий процесс который пытается породить новый фоновый процесс, ожидает, пока состояние предшествующего процесса не очистится.

Время ожидания: обычно 3 – 10 секунд

Параметры:

process_pid –идентификатор процесса (см. V$PROCESS.PID) состояние которого должно быть очищено

process_sno –порядковый номер процесса (см. V$PROCESS. SERIAL#) состояние которого должно быть очищено

process startup

Ожидание разделяемого сервера, диспетчера, или другого фонового процесса при старте.

Время ожидания:        

Ожидание 1 секунда для фонового процесса при старте. Если время истекло,  то повторное ожидание в течении 5 минут и далее в случае неудачи выдача ошибки. Если процесс запустился то событие подтвердит это.

Параметры:

type –типзапускаемогопроцесса

process# –порядковый номер запускаемого процесса

waited –общее время ожидания старта процесса

PX Deque wait

Процесс ожидает сообщения во время параллельного выполнения.

Время ожидания:

Время ожидания зависит от того, как быстро сообщение приходит, и может измениться, но это это будет короткий период времени.

Параметры:

reason –причина извлечения из очереди

sleeptime –время бездействия (sleep) сеанса

loop –общее время бездействия (sleep) сеанса

PX qref latch

У каждого процесса выполняющего параллельный запрос есть qref защёлка, которая должна быть получена прежде чем можно управлять очередью буферов.

Время ожидания: ожидание до 1 секунды

Параметры:

function – указывает тип ожидания

sleeptime –время ожидания сеанса (в сотых частях секунды)

qref –адрес процесса очереди, для которой сеанс, ожидает

PX server shutdown

Во время нормального или непосредственного (immediate) завершения работы подчинённые параллельные процессы оповещаются, чтобы они нормально очистились. Если какие-либо параллельные процессы все еще живы после 10 секунд, то они уничтожаются.

Время ожидания: ожидание до 0.5 секунды

Параметры:

nalive – число параллельных подчинённых процессов которые ещё работают

sleeptime –время бездействия начиная с момента ожидания сеанса

loop –сколько раз сеанс ожидал на этом событии

PX signal server

Это событие может произойти только в монопольном режиме. Координатор запросов сигнализирует подчинённым запросам (Query Slaves), что произошла ошибка.

Время ожидания: ожидание до 0.5 секунды

Параметры:

serial – порядковый номер подчинённого процесса очереди

error –происшедшая ошибка

nbusy –число занятых подчинённых процессов



rdbms ipc message

Фоновые процессы (LGWR, DBWR, LMS0) используют это событие, чтобы указать, что они неактивны и ждут от приоритетных процессов IPC сообщения, для того что бы сделать некоторую работу.

Время ожидания: до 3 секунд. Параметр timeout показывает истинное значение простоя

Параметры:

timeout - количество времени в течении которого сеанс ожидает сообщения IPC

rdbms ipc message block

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

Время ожидания: до 60 секунд

rdbms ipc reply

Событие используется для ожидания ответа от одного из фоновых процессов.

Время ожидания: определяется пользователем и показывается параметром timeout

Параметры:

from_process – фоновый процесс, которого ожидает сеанс. Ожидается ответ на сообщение IPC, отправленное этим  сеансом.

timeout – время в секундах в течении которого процесс ожидает ответ

read by other session

Событие имеет место, когда сеанс запрашивает буфер, который в настоящий момент читается в буферный кэш другим сеансом. До релиза 10.1 это событие было сгруппировано с другими ожиданиями в событие 'buffer busy wait'.

Время ожидания: буфера, который будет считан другим сеансом (в микросекундах)

Параметры: file#, block#, class#

recovery read

Параллельный подчинённый или последовательный процесс восстановления ожидает завершения чтения блока данных.

Время ожидания: время необходимое чтобы завершить физический ввод-вывод (чтение)

resmgr: become active

Сеанс ожидает активный сессионный слот ресурсного менеджера. Событие имеет место, когда включается ресурсный менеджер и число активных сеансов в текущей потребительской группе превышает текущий ресурсный план. Для уменьшения этого ожидания необходимо увеличить лимит активных сеансов для текущей потребительской группы.

Время ожидания: время, затраченное на ожидание сеансом свободного слота активных сеансов

Параметры: location – местоположение ожидания

resmgr: cpu quantum

Сеанс ожидает выделения кванта времени процессора. Событие имеет место когда менеджер ресурсов включён и регулирует потребление процессрного времени. Чтобы уменьшить возникновение этого ожидания необходимо увеличить выделение лимита CPU для сеансов текущей потребительской группы.

Время ожидания: время, затраченное на ожидание сеансом кванта процессора

Параметры: location – местоположение ожидания

resmgr: pq queued

Сеанс ожидает в очереди параллельных операторов.

Время ожидания:

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

Параметры: location – местоположение ожидания

rolling migration: cluster quiesce

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

Время ожидания: 1 секунда

Параметры:

location – Будет равно 1, если это ожидание завершения привилегированных операций, после которых стартует rolling upgrade/downgrade. Будет равно 2, если это ожидание завершения rolling upgrade/downgrade на всех нодах кластера.

waits –  Число секунд ожидания в текущем местоположении.

row cache lock

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

Время ожидания: до 60 секунд

Параметры: mode

cache id – столбец CACHE# в представлении V$ROWCACHE

request – таймер канала установленный пользователем

RVWR wait for flashback copy

Ожидание конца работы процесса RVWR копирующего ретроспективные данные в flashback буфер, что бы затем записать запрошенные ретроспективные данные.

Время ожидания: 10 миллисекунд

Параметры:

copy latch # - количество защёлок копирования flashback на которых процесс ожидал RVWR

sbtbufinfo

Эта функция вызывается, когда Oracle должен обнаружить размер и число буферов ввода-вывода, выделенных на уровне SBT. Ожидание быстрое и никогда не блокируется.

Время ожидания: меньше чем одна миллисекунда

sbtgetbuf

Эта функция получает один буфер ввода-вывода, который Oracle будет использовать для ввода-вывода во время резервного задания.

Время ожидания: меньше чем одна миллисекунда

sbtmapbuf

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

Время ожидания: меньше чем одна миллисекунда

sbtrelbuf

Эта функция освобождает буфер ввода-вывода, который уже был обработан во время выполнения задания восстановления, для того чтобы уровень SBT мог заполнить его данными.

Время ожидания: меньше чем одна миллисекунда

scginq AST call

Вызывается сеансом, что бы найти самый высокий режим блокировки установленный на ресурсе.

Время ожидания:

0.2 секунды, но ожидание будет продолжаться пока не будет иницированно прерывание Acquisition AST в режиме NULL.

SGA: allocation forcing component growth

Процесс ожидает перемещения памяти в immediate режиме (автоматическая настройка SGA) после выдачи  ошибки 4031 для MMAN, что бы получить память и разместить её.

Время ожидания: 10 миллисекунд

SGA: MMAN sleep for component shrink

Процесс MMAN  ожидает и засыпает, что бы удовлетворить запрос автонастройки памяти по освобождению замороженных гранул памяти компонента. В релизе 10.1 это событие называлось 'wait for SGA component shrink'.

Время ожидания: 10 миллисекунд

Параметры:

P1 – идентификатор компонента (соответствующий пулу памяти)

P2 – текущий размер в гранулах

P3 – целевой размер в гранулах

SGA: sga_target resize

Запросы изменения памяти ожидают, пока sga target изменяется. В релизе 10.1 это событие называлось 'wait for sga_target resize'.

Время ожидания: 10 миллисекунд

Shared IO Pool Memory

Ожидание, пока буфер разделяемого пула ввода вывода не станет доступным. Такое происходит, когда процессы используют эти буферы для ввода-вывода, и текущий процесс должен ожидать освобождения буфера.

Время ожидания: 10 миллисекунд

11.2 |

single-task message

Выполняя единственную задачу, это событие указывает, что сеанс ожидает клиентскую сторону выполняемой программы.

Время ожидания: общее время затраченное сеансом в приложении

shared server idle wait

Событие ожидания простоя разделяемого сервера. Сервер ожидает в общей очереди виртуального канала.

Время ожидания: 30 секунд

smon timer

Основное событие простоя для SMON. SMON будет ожидать на этом событии большую часть времени, пока не наступит предел времени или не поступит уведомление от другого процеса.

Время ожидания: 5 минут (300 секунд)

Параметры:

sleeptime – время, в течении которого SMON ожидает на этом событии (в секундах)

failed – сколько раз процессу SMON поступало уведомление об ошибке

SQL*Net break/reset to client

Сервер отправляет сообщение прерывания или сброса клиенту. Серверный сеанс ожидает ответа от клиента.

Время ожидания:        

Фактическое время требуемое для возврата от клиента сообщения о прерывании и сбросе

Параметры: driver id, break?

SQL*Net break/reset to dblink

То же самое  что и SQL*Net break/reset to client, но сообщение посылается через связь базы данных.

Время ожидания:        

Фактическое время, требуемое для возврата от другого серверного процесса сообщения о прерывании и сбросе.

Параметры: driver id, break?

SQL*Net message from client

Серверный процесс ожидает сообщения от клиентского процесса.

Время ожидания:        

Время, прошедшее с момента отправки последнего сообщения  клиенту до момента времени получения сообщения от этого клиента.

Параметры: driver id

#bytes – количество байт полученных серверным процессом от клиента

SQL*Net message from dblink

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

Время ожидания:        

Время, прошедшее с момента отправки последнего сообщения серверному процессу до момента времени получения сообщения от этого серверного процесса.

Параметры: driver id

SQL*Net message to client

Серверный процесс отправляет сообщение клиенту

Время ожидания: фактическое время затраченное на отправление

Параметры: driver id

#bytes – количество байт отправленных серверным процессом клиенту

SQL*Net message to dblink

Серверный процесс передаёт сообщение другому серверному процессу через связь

Время ожидания: фактическое время затраченное на отправление

Параметры: driver id

#bytes – количество байт отправленных серверным процессом другому серверному процессу через связь

SQL*Net more data from client

Сервер ожидает клиента, что бы отправить дополнительные данные клиентскому теневому процессу в уже начатой операции.

Время ожидания: зависит от времени, которое потребовалось, что бы получить данные (включая время ожидания)

Параметры: driver id

#bytes – количество байт принятых от клиента

Обычно это событие регистрируется при передаче значительных объемов информации в сторону клиента и проблемы не представляет.

SQL*Net more data from dblink

Приоритетный процесс ожидает дополнительные данные через связь базы данных

Время ожидания: зависит от времени, которое потребовалось, что бы получить данные (включая время ожидания получения данных)

Параметры: driver id

#bytes – количество принятых байт

SQL*Net more data to client

Серверный процесс отправляет дополнительные данные клиенту. Предыдущая операция так же была отправлением.

Время ожидания: Фактическое время завершения отправления

Параметры: driver id

#bytes – число байт отправленных клиенту

SQL*Net more data to dblink

Событие указывает, что сервер снова отправляет данные по связе базы данных. Предыдущая операция так же была отправлением.

Время ожидания: Фактическое время отправления данных другому серверу

Параметры: driver id

#bytes – число байт отправленных по связи базы данных другим серверным процессам

Streams AQ: waiting for messages in the queue

Сеанс ожидает на пустой очереди OLTP (Advanced Queuing) поступления сообщения, что бы исключить это сообщение из очереди.

Время ожидания: время, которое сеанс хочет ожидать, определяется параметром wait time

Параметры:

queue id - ID очереди OLTP, в которой ожидает сеанс

process# - номер процесса сеанса

wait time – намеченное время ожидания

switch logfile command

Сеанс ожидает завершения команды SWITCH LOGFILE.

Время ожидания: 5 секунд

TCP Socket (KGAS)

Сеанс ожидает внешнего хоста для предоставления запрашиваемых данных через сетевой сокет. Большое время ожидания этого события ещё указывает на  возникновение проблемы. Приложение,  которое взаимодействует с удалённым хостом, должно ожидать, пока данные, которые оно считает, не прибыли. Кроме того, в Microsoft Windows, отдельный поток отслеживает прибытие трафика. Этот поток тратит большую часть своей жизни в ожидании отслеживания события ожидания TCP Socket (KGAS).

Время ожидания: общее время для установления сетевого соединения или прихода данных из сети

Параметры:                   

P0 – только для внутреннего пользования Oracle. Значения 8, 9, и 10 могут возникнуть только в рамках специального потока Microsoft Windows; в нормальных сеансах  значения параметра другие.

P1 – только для внутреннего пользования Oracle.

timer in sksawat

Сеанс ожидает завершения асинхронного ввода-вывода процесса ARCH.

Время ожидания: 0.01 секунда

transaction

Ожидание отката блокирующей транзакции.

Время ожидания: 1 секунда

Параметры:    

undo seg# - ID сегмента отката

slot# - ID слота в сегменте отката

wrap# - номер изменения, который последовательно увеличивается для каждой транзакции

count – сколько раз сеанс ожидал на этой транзакции

unbound tx

Сеанс ожидает, что бы увидеть, есть ли какие-либо запущенные транзакции, которые не связаны с  сегментами отката.

Время ожидания: 1 секунда

undo_retention publish retry

Это ожидание может произойти по двум причинам. Сеанс, выполняющий ALTER SYSTEM SET UNDO_RETENTION, может ожидать пока идёт кластерная реконфигурация. Или фоновый процесс MMNL может ожидать кластерного реконфигурирования, пытаясь определить максимальное значение UNDO_RETENTION.

Время ожидания: 1 секунда

Параметры:    

P1 – идентификатор показывающий, где происходит повторение. 1 - повторение публикации макимального значения  undo_retention. 2 – повторение доступа к макимальному значению  undo_retention

P2 – количество повторений (максимальное кол-во 5)

undo segment extension

Сегмент отката может расширяться или сжиматься. Сеанс должен ожидать пока все операции на сегменте отката не закончатся.

Время ожидания: 0.01 секунды

Параметры:

segment# - ID расширяющегося или сжимающегося сегмента отката

undo segment recovery

Процесс PMON откатывает мёртвую транзакцию. Ожидание продолжается, пока откат не закончится.

Время ожидания: 3 секунды

Параметры:

segment# - ID сегмента отката, содержащего откатываемую транзакцию

tx flags -  набор флагов (опций) откатываемой транзакции

undo segment tx slot

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

Время ожидания:          1 секунда

Параметры:

segment# - ID сегмента отката, содержащего откатываемую транзакцию

virtual circuit status

Сеанс ожидает виртуального канала, чтобы возвратить тип сообщения показывающий статус. Событие является устаревшим и заменено на событие virtual circuit wait.

Время ожидания: 1 секунда

Параметры:

circuit# - указывает на виртуальный канал

type- указывает чего ожидает сеанс

virtual circuit wait

Сеанс ожидает завершения операции виртуального канала.

Время ожидания: 30 секунд

Параметры:

circuit# - указывает на виртуальный канал

type- указывает тип операции которую ожидает сеанс

11.2 |

WCR: replay client notify

Во время воспроизведения, Workload Replay Client всегда сохраняет открытое соединение с базой данных, чтобы обнаружить некоторые специальные ошибки. Сеанс будет находиться в ожидании, пока не произойдёт некоторое связанное с воспроизведением исключение.

Время ожидания: Ожидание пока не будет уведомление. Время каждые 30 секунд

Параметры:

who am I - идентифицирует причину ожидания администраторского потока

1 - ожидание выдачи REPLAY.START ()

2- ожидание завершения запуска воспроизведения или выдачи REPLAY.CANCEL().

11.1 |

WCR: replay clock

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

Время ожидания:

Зависит от количества конкурирующих блокировок строк в исходном сборе нагрузки.

Параметры:

wait for scn's hi 4 bytes – старшие 4 байта из 8 байтового replay SCN, на котором, на котором ожидает сеанс

wait for scn's lo 4 bytes – младшие 4 байта из 8 байтового replay SCN, на котором, на котором ожидает сеанс

11.1 |

WCR: replay lock order

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

Время ожидания:

Зависит от количества конкурирующих блокировок строк в исходном сборе нагрузки.

Параметры:

wait for scn's hi 4 bytes – старшие 4 байта из 8 байтового replay SCN, на котором, на котором ожидает сеанс

wait for scn's lo 4 bytes – младшие 4 байта из 8 байтового replay SCN, на котором, на котором ожидает сеанс

11.1 |

WCR: replay paused

Когда пользователь ввыполняет команду DBMS_WORKLOAD_REPLAY.PAUSE_REPLAY, все сеансы которые осуществляют воспроизведение ожидают на этом событии, пока воспроизведение не возобновится.

11.1 |

WCR: Sync context busy

В режиме воспроизведения по умолчанию, фиксации синхронизируются тем же  порядком как сбор нагрузки. Фиксации сериализируются с помощью Sync context. Воспроизводящий сеанс будет ожидать на этом событии, если попытается фиксировать изменения одновременно с другим воспроизводящим сеансом.

11.1 |

WMON goes to sleep

WMON является UNIX специфичным монитором ожиданий, который может использоваться, чтобы сократить количество системных вызовов, связанных с установкой таймеров для отправления или ожидания в Oracle. Должны быть установлены параметры инициализации, которые включают процесс WMON.

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

write complete waits

Сеанс ожидает буфера, который будет записан. Запись вызывается нормальным старением или кросс- экземлярным вызовом.

Время ожидания: 1 секунда

Параметры:

file# - идентификатор сегмента отката содержащего откатываемую транзакцию

block# - набор флагов (опций) откатываемой транзакции

id - идентифицирует причину ожидания

writes stopped by instance recovery or database suspension

Сеанс блокируется, пока экземпляр, который запустил Instance Recovery, не закончится.

Время ожидания: 5 секунд

Параметры:

bythread# - идентификатор сегмента отката содержащего откатываемую транзакцию

ourthread# - номер потока текущего экземпляра

Oracle Сегменты отката

В oracle 8i все было так :

Создание сегмента отката

!!! Все экстенты сегмента отката в БД должны быть одинаковы

при создании используются следующие параметры:

initial - размер начального экстента сегмента отката

next - размер следующего экстента сегмента отката
указывайте его равным initial

minextents - минимальное число экстентов в сегменте отката
должно быть больше или равно 2

maxextents - максимально разрешенное число экстентов в сегменте отката
ставте число а не unlimited
особенно полезно это для autoextend

optimal - общий оптимальный размер сегмента отката
он не меньше чем initial*minextents, так как initial=next


create rollback segment rollseg01
tablespace orgdbrbs
storage (
initial 10k
next 10k
minextents 20
maxextents 450
optimal 300k
);


alter rollback segment имя online;

Отключить сегмент отката можно только если в нем нет
активных экстентов с незафиксированными транзакциями.

alter rollback segment имя offline;


Изменим параметры
(можно менять все параметры за исключением initial)
изменение параметра next не изменит размер уже существующих
экстентов и делать это не рекомендуется

alter rollback segment rollseg01
storage ( maxextents 200
optimal 310k );



Удалить сегмент отката

drop rollback segment rollseg01;


Вручную сузить область область, отведенную сегменту отката до размера
не меньше чем указано в optimal


alter rollback segment rollseg01 shrink to 220k;

по умолчанию сегмент отката сжимается до optimal

alter rollback segment rollseg01 shrink;

Оракл не уменьшает размер сегмента откатаб если активны его экстенты,
размер которых превышает указанный


select r.usn, r.name, ((sum(e.blocks)+min(s.curblk))*min(p.value))/(1024*1024) Mb
from v$rollname r, v$rollstat s, v$parameter p, dba_extents e
where p.name='db_block_size'
and s.usn=r.usn
and s.usn in (select xidusn from v$transaction)
and e.segment_type='ROLLBACK'
and e.segment_name=r.name
and e.extent_id<=s.curext
group by segment_type, segment_name, r.name, r.usn;



select a.name,
b.xacts,
b.extents,
b.rssize,
b.optsize,
b.hwmsize,
b.status
from v$rollname a,
v$rollstat b
where a.usn=b.usn



select a.username,
a.sid,
a.serial#,
b.name as rbsname,
c.used_ublk
from v$session a,
v$rollname b,
v$transaction c
where a.saddr=c.ses_addr
and b.usn=c.xidusn;


Не закоммиченная транзакция
такого пользователя нужно убить
оракл откатит убитую транзакцию

select a.username,
a.sid,
a.serial#,
to_char(b.start_time,'MM/DD/YY HH24:MI:SS') as start_time,
c.name
from v$session a,
v$transaction b,
v$rollname c,
v$rollstat d
where a.saddr=b.ses_addr
and b.xidusn=c.usn
and c.usn=d.usn
and ((d.curext=b.start_uext-1) or
((d.curext=d.extents-1) and b.start_uext=0))


select s.username,
s.sid,
s.serial#,
t.start_time, t.xidusn
from v$session s,
v$transaction t,
v$rollstat r
where s.saddr=t.ses_addr
and t.xidusn=r.usn
and ((r.curext=t.start_uext-1)
or
((r.curext=r.extents-1)
and (t.start_uext=0)));



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

dba_rollback_segs - информация о всех сегментах отката

v$rollstat - размер, текущее число экстентов, наивысшая точка,
оптимальный размер

v$rollname - имя сегмента отката и его номер,
соответствующий записям в v$rollstat

v$transaction - адрес сеанса и использование сегментов
отката текущими транзакциями

v$session - имя sid и порядковый номер адреса сеанса,
соответствуют адресу сеанса в v$transaction


Ошибки

ORA-01562 insufficient space in rollback segment
недостаточно места в сегменте отката

ORA-01560 insufficient space in the tablespace
недостаточно места в табличной области

ORA-01628 MAXEXTENTS has been reached
достигнуто значение MAXEXTENTS



ORA-01555 snapshot to old (rollback segment to small)
моментальный снимок слишком стар
сегмент отката слишком мал
простое повышение maxextents тут не поможет
тут нужно повысить minextents и optimal пересоздав сегмент отката


select s.username, s.sid, rn.name, rs.extents
,rs.status, t.used_ublk, t.used_urec
,do.object_name
from v$transaction t
,v$session s
,v$rollname rn
,v$rollstat rs
,v$locked_object lo
,dba_objects do
where t.addr = s.taddr
and t.xidusn = rn.usn
and rn.usn = rs.usn
and t.xidusn = lo.xidusn(+)
and do.object_id = lo.object_id;


To monitor rollback usage (waits/gets should be < 1 %)

select name, waits, gets
from v$rollstat, v$rollname
where v$rollstat.usn = v$rollname.usn;



select
substr(s.username,1,18) username,
substr(s.program,1,15) program,
decode(s.command,
0,'No Command',
1,'Create Table',
2,'Insert',
3,'Select',
6,'Update',
7,'Delete',
9,'Create Index',
15,'Alter Table',
21,'Create View',
23,'Validate Index',
35,'Alter Database',
39,'Create Tablespace',
41,'Drop Tablespace',
40,'Alter Tablespace',
53,'Drop User',
62,'Analyze Table',
63,'Analyze Index',
s.command||': Other') command
from
v$session s,
v$process p,
v$transaction t,
v$rollstat r,
v$rollname n
where s.paddr = p.addr
and s.taddr = t.addr (+)
and t.xidusn = r.usn (+)
and r.usn = n.usn (+)
order by 1


undo_management=auto and bounce your database:

CREATE UNDO TABLESPACE ts_undo
DATAFILE '/u01/oradata/prod/ts_undo.dbf'
SIZE 2M REUSE AUTOEXTEND ON;

Alter system set undo_tablespace=ts_undo;
Alter system set undo_management=auto;

Календарные строки

Синтаксис использования календарной строки для значения параметра repeat_interval процедуры CREATE_JOB чрезвычайно прост.

Например, если вы определяете задание, которое выполняется с понедельника по пятницу ровно в 7 часов утра и 3 часа дня,
то значением параметра repeat_interval может быть такая календарная строка:


FREQ=DAILY; BYDAY=MON,TUE,WED,THU,FRI; BYHOUR=7,15  с понедельника по пятницу ровно в 7 часов утра и 3 часа дня

Предложение FREQ может быть ровно одно, а предложений BY может быть несколько разных видов.

Предложение FREQ задает интервал между повторными выполнениями.

Если задание должно повторяться каждый день FREQ = DAILY.

FREQ=DAILY;
FREQ=HOURLY;
FREQ=MINUTELY;
FREQ=SECONDLY;

FREQ=YEARLY;
FREQ=MONTHLY;
FREQ=WEEKLY;

Предложение BY определяет, когда именно задание будет выполняться.

В примере, определяя частоту выполнения, мы указали, что задание выполняется ежедневно (FREQ=DAILY).
Теперь следует ограничить множество дней (задание должно выполняться только в рабочие дни), указав BYDAY=MON,TUE,WED,THU,FRI.
Далее необходимо потребовать, чтобы задание запускалось в 7 часов утра и в 3 часа дня, указав BYHOUR=7,15.


Разрешены следующие ключевые слова:
BYMONTH,
BYMONTHDAY,
BYYEARDAY,
BYHOUR,
BYMINUTE и
BYSECOND


Предположим, что задание следует запускать ежедневно (вне зависимости от дня недели) в 10 часов утра, в 2 часа дня и в 8 часов вечера.
Тогда параметр repeat_interval может быть таким:

FREQ=DAILY; BYHOUR=10,14,20   ежедневно (вне зависимости от дня недели) в 10 часов утра, в 2 часа дня и в 8 часов вечера.

FREQ=DAILY; INTERVAL=2, BYHOUR=10,14,20  через день, а не каждый день Используем новое ключевое слово – INTERVAL

Предложение INTERVAL=2 изменяет частоту вдвое по отношению к значению, указанному в предложении FREQ. В нашем случае FREQ=DAILY,
поэтому задание будет выполняться каждые два дня.

FREQ=DAILY; BYHOUR= - 2  Отрицательные значения означают отсчет от конца периода. Например, следующая строка задает второй час, начиная с конца дня

BYMONTH Планирование выполнение задания в определенные месяцы.
BYMONTH=JUN,DEC чтобы выполнялось только в июне и декабре
BYMONTH=6,12  по номерам месяцев
Точная дата внутри месяца, когда задание будет выполнено, совпадает с днем его запуска.
Например, если задание запускается 4 июля, то в декабре и в июне оно будет выполнено 4 числа.
Если необходимо, чтобы задание выполнялось в другой день, следует использовать ключевое слово BYMONTHDAY.

BYMONTHDAY Указывает, в какой именно день месяца должно выполняться задание.
FREQ=MONTHLY; BYMONTHDAY=1; BYHOUR=15 первого числа каждого месяца в 3 часа дня
Если опустить предложение BYHOUR, задание по умолчанию будет выполняться в полночь.

BYYEARDAY Указывает, в какой день года должно выполняться задание.
FREQ=YEARLY; BYYEARDAY=15 в пятнадцатый день каждого года

BYHOUR Планирование выполнения задания в определенные часы.
FREQ=DAILY; BYHOUR=3,6,9    каждый день в 3, 6 и 9 часов утра задаем:
FREQ=MINUTELY; BYHOUR=3,6,9 каждую минуту в определённые часы ( 03:00:00-03:59:00, 06:00:00-06:59:00, 09:00:00-09:59:00)

BYMINUTE Планирование выполнения задания в определенную минуту.
FREQ=MINUTELY; BYMINUTE=30 каждые полчаса
FREQ=HOURLY; BYMINUTE=30 каждые полчаса так как составляющая часа не указывается
FREQ=DAILY; BYMINUTE=30  выполняется каждый день в 00:30  округление будет вестись с точностью до дня

BYSECOND  планирования выполнения задания в определенную секунду.
Отрицательное значение какого то ключевого слова означает отсчет от конца (а не от начала) периода.
Например, следующая календарная строка
FREQ=YEARLY; BYYEARDAY= - 1  указывает на первый день года, начиная с его конца.
Поэтому такое задание будет выполняться каждый год 31 декабря.


Примеры календарных строк:

Пусть сегодня 5 июля 2005 года

FREQ=YEARLY  будет выполняться 5 июля каждый год, начиная с 2006 в полночь

FREQ=YEARLY; INTERVAL=2  будет выполнено 5 июля в 2007 году, 2009, 2011 и т. д. (через год)

FREQ=YEARLY; BYMONTH=JAN будет выполняться ежегодно 5 января (опять таки в полночь) просто поменялся месяц.

FREQ=YEARLY; BYMONTH=JAN; BYMONTHDAY=2  будет выполняться 2 января 2006 года, 2 января 2007 года и т. д.

FREQ=YEARLY; BYMONTH=JAN; BYDAY=SUN  будет выполняться ежегодно каждое воскресенье января

FREQ=YEARLY; BYMONTH=JAN; BYMONTHDAY=2; BYDAY=SUN будет выполняться каждое воскресенье января, если оно выпадет на 2-е число

FREQ=YEARLY; BYYEARDAY=60 выполнение задания каждый 60-й день года
планировщик учел високосность 2008 года: в нем 60-й день выпадает на 29 января В остальных случаях шестидесятым днем года является 1 марта

FREQ=YEARLY; BYYEARDAY=60; BYMONTHDAY=1 Пусть задание выполняется в 60-й день года и в первый день месяца (високосный год будет пропущен)

FREQ=YEARLY; BYWEEKNO=2 выполняться каждый день второй недели года  Все семь дней второй недели каждого года

FREQ=DAILY; BYHOUR=3,6,9 выполняется ежедневно ровно в три, шесть и девять часов утра

FREQ=DAILY; INTERVAL=2; BYHOUR=3,6,9  тоже но через два дня  Задание выполняется 6 июля ровно в три, шесть и девять часов утра, затем 8 июля

FREQ=DAILY; BYHOUR=3,6,9; BYMINUTE=00,15,30,45  выполняется ежедневно в 3, 6 и 9 часов дня, но в указанные минуты

Oracle Создание тестовой базы

1. Создаем все каталоги

export ORACLE_SID=sapdbt1
export ORACLE_BASE=/app/oracle
export ORACLE_HOME=/app/oracle/product/10.2.0/db_1
export ORACLE_DATA=/app/oracle/oradata/$ORACLE_SID
export ORACLE_ADMIN=$ORACLE_BASE/admin/$ORACLE_SID

mkdir $ORACLE_ADMIN
mkdir $ORACLE_ADMIN/pfile
mkdir $ORACLE_ADMIN/bdump
mkdir $ORACLE_ADMIN/cdump
mkdir $ORACLE_ADMIN/udump
mkdir $ORACLE_ADMIN/create

2. Скопируем файл параметров

cp $ORACLE_HOME/dbs/initsapdb.ora $ORACLE_HOME/dbs/initsapdbt1.ora

в винде делаем так:

> cp $ORACLE_HOME\dbs\initsapdb.ora d:\app\oracle\admin\sapdbt1\pfile\initsapdbt1.ora

> notepad $ORACLE_HOME\dbs\initsapdbt1.ora > IFILE = d:\app\oracle\admin\sapdbt1\pfile\initsapdbt1.ora

3. Отредактируем файл initsapdbt1.ora

*.db_block_size=8192
*.compatible='10.2.0.3.0'
*.optimizer_features_enable='9.2.0'
*.optimizer_secure_view_merging=FALSE
*.timed_statistics=TRUE

*.db_name='sapdbt1'
*.db_domain='msk.oracle.com'


*.audit_sys_operations=TRUE
*.audit_trail='XML'
*.audit_file_dest='/app/oracle/admin/sapdbt1/adump'

*.background_dump_dest='/app/oracle/admin/sapdbt1/bdump'
*.user_dump_dest='/app/oracle/admin/sapdbt1/udump'
*.core_dump_dest='/app/oracle/admin/sapdbt1/cdump'
*.control_files='/app/oracle/oradata/sapdbt1/control1/control01.ctl','/app/oracle/oradata/sapdbt1/control2/control02.ctl'

*.db_recovery_file_dest='/app/oracle/flash_recovery_area'
*.db_recovery_file_dest_size=2147483648

*.log_archive_dest_1='LOCATION=/app/oracle/archlogs/arch01/sapdbt1/ MANDATORY'
*.log_archive_dest_2='LOCATION=/app/oracle/archlogs/arch02/sapdbt1/ OPTIONAL'
*.log_archive_format='sapdb_%t_%s_%r.arc'

*.dispatchers='(PROTOCOL=TCP) (SERVICE=sapdbt1XDB)'
*.nls_language='AMERICAN'
*.remote_login_passwordfile='EXCLUSIVE'
*.archive_lag_target=900
*.db_cache_advice='READY'

*.db_file_multiblock_read_count=16

*.sga_max_size=48318382080
*.db_cache_size=9663676416
*.db_keep_cache_size=8589934592
*.db_recycle_cache_size=12884901888
*.dbwr_io_slaves=4
*.shared_pool_size=1363148800
*.shared_pool_reserved_size=136314880
*.pga_aggregate_target=5368709120
*.large_pool_size=100M
*.java_pool_size=157286400
*.job_queue_processes=20
*.open_cursors=700
*.processes=1500
*.sessions=1655

*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.undo_retention=21600


4. Создаем файл паролей

orapwd file=$ORACLE_HOME/dbs/orapwsapdbt1 password=TEST entries=4

в винде еще создаем сервис

oradim -new -sid sapdbt1 -intpwd TEST


5. Выполняем горячее резервное копирование


6. Создаем сценарий управляющего файла

alter database backup controlfile to trace resetlogs;

он будет создан в каталоге

select value from v$parameter where name='user_dump_dest';

или

> show parameter user_dump_dest

переименуйте его в mk_sapdbt1.sql и поместите в
$ORACLE_BASE/admin/sapdbt1/create

отредактируйте его примерно так

STARTUP NOMOUNT pfile='/u01/app/oracle/oracle/product/10.2.0/db_1/dbs/initsapdbt1.ora';
CREATE CONTROLFILE SET DATABASE "SAPDBT1" RESETLOGS NOARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 732
LOGFILE
GROUP 1 '/app/oracle/oradata/sapdbt1/redoa/redo01.log' SIZE 50M,
GROUP 2 '/app/oracle/oradata/sapdbt1/redoa/redo02.log' SIZE 50M,
GROUP 3 '/app/oracle/oradata/sapdbt1/redoa/redo03.log' SIZE 50M
DATAFILE
'/app/oracle/oradata/sapdbt1/system/system01.dbf',
'/app/oracle/oradata/sapdbt1/undotbs/undotbs01.dbf',
'/app/oracle/oradata/sapdbt1/sysaux/sysaux01.dbf',
'/app/oracle/oradata/sapdbt1/users/users01.dbf'
CHARACTER SET CL8MSWIN1251
;
alter database recover automatic FROM '/app/oracle/archlogs/arch01/sapdbt1/' until cancel using backup controlfile;
alter database recover automatic cancel;
alter database open resetlogs;
ALTER TABLESPACE TEMP ADD TEMPFILE '/app/oracle/oradata/sapdbt1/temp/temp01.dbf'
SIZE 29360128 REUSE AUTOEXTEND ON NEXT 655360 MAXSIZE 32767M;


выполните его

export ORACLE_SID=sapdbt1
cd $ORACLE_BASE/admin/$ORACLE_SID/create
sqlplus /nolog
connect sys/passw as sysdba;
@mk_sapdbt1.sql


Можно и руками восстановить (накатить базу) sapdbt1:

sql> set logsource /app/oracle/archlogs/arch01/sapdbt1;
sql> recover database using backup controlfile until cancel;

когда закончатся все архивные логи, можно попробовать скормить
и оперативный текущий редо-лог, предварительно остановив базу sapdb

просто введите путь:
/app/oracle/oradata/sapdb/redoa/redo01.log
в ответ на приглашение начать восстановление

или не закрывая переключите несколько раз журналы и скормите архивные файлы.

Откройте БД supdbt1

alter database open resetlogs;


С помощью RMAN восстанавливать так:

export ORACLE_SID=testdb
rman target /

CATALOG START WITH '/u09/tape_restore/testdb';
recover database;

alter database open resetlogs;

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

STARTUP NOMOUNT pfile='/u01/app/oracle/product/10.2.0.4/db_1/dbs/inittestdb.ora';
CREATE CONTROLFILE SET DATABASE "TESTDB" RESETLOGS NOARCHIVELOG
    MAXLOGFILES 40
    MAXLOGMEMBERS 3
    MAXDATAFILES 300
    MAXINSTANCES 8
    MAXLOGHISTORY 2920
LOGFILE
  GROUP 1 '/u09/app/oracle/oradata/testdb/redoa/redo01a.log'  SIZE 500M,
  GROUP 2 '/u09/app/oracle/oradata/testdb/redoa/redo02a.log'  SIZE 500M,
  GROUP 3 '/u09/app/oracle/oradata/testdb/redoa/redo03a.log'  SIZE 500M,
  GROUP 4 '/u09/app/oracle/oradata/testdb/redoa/redo04a.log'  SIZE 500M,
  GROUP 5 '/u09/app/oracle/oradata/testdb/redoa/redo05a.log'  SIZE 500M,
  GROUP 6 '/u09/app/oracle/oradata/testdb/redoa/redo06a.log'  SIZE 500M,
  GROUP 7 '/u09/app/oracle/oradata/testdb/redoa/redo07a.log'  SIZE 500M,
  GROUP 8 '/u09/app/oracle/oradata/testdb/redoa/redo08a.log'  SIZE 500M
DATAFILE
  '/u09/app/oracle/oradata/testdb/sysaux01.dbf',
  '/u09/app/oracle/oradata/testdb/system01.dbf',
  '/u09/app/oracle/oradata/testdb/temp01.dbf',
  '/u09/app/oracle/oradata/testdb/undotbs1_01.dbf',
  '/u09/app/oracle/oradata/testdb/undotbs2_02.dbf',
  '/u09/app/oracle/oradata/testdb/users01.dbf'
CHARACTER SET CL8MSWIN1251
;

или так:

STARTUP NOMOUNT pfile='/u01/app/oradb/product/11.2.0.3/dbhome_1/dbs/inittestdb.ora';
CREATE CONTROLFILE SET DATABASE "TESTDB" RESETLOGS NOARCHIVELOG
    MAXLOGFILES 40
    MAXLOGMEMBERS 3
    MAXDATAFILES 300
    MAXINSTANCES 8
    MAXLOGHISTORY 2920
LOGFILE
  GROUP 1 '+REDO/redo01a.log'  SIZE 500M BLOCKSIZE 512,
  GROUP 2 '+REDO/redo02a.log'  SIZE 500M BLOCKSIZE 512,
  GROUP 3 '+REDO/redo03a.log'  SIZE 500M BLOCKSIZE 512,
  GROUP 4 '+REDO/redo04a.log'  SIZE 500M BLOCKSIZE 512,
  GROUP 5 '+REDO/redo05a.log'  SIZE 500M BLOCKSIZE 512,
  GROUP 6 '+REDO/redo06a.log'  SIZE 500M BLOCKSIZE 512,
  GROUP 7 '+REDO/redo07a.log'  SIZE 500M BLOCKSIZE 512,
  GROUP 8 '+REDO/redo08a.log'  SIZE 500M BLOCKSIZE 512
DATAFILE
  '+TEST/testdb/datafile/system.584.824808053',         
  '+TEST/testdb/datafile/undotbs1.702.824808053',       
  '+TEST/testdb/datafile/sysaux.701.824808053',         
  '+TEST/testdb/datafile/users.589.824808213'          
CHARACTER SET CL8MSWIN1251
;

Файл параметров:

$more inittestdb.ora
*.aq_tm_processes=0
*.archive_lag_target=900
*.audit_file_dest='/u01/app/oracle/admin/testdb/adump'
*.audit_sys_operations=TRUE
*.audit_trail='XML'
*.background_dump_dest='/u01/app/oracle/admin/testdb/bdump'
*.compatible='10.2.0.3.0'
*.control_files='/u09/app/oracle/oradata/testdb/control/control01.ctl','/u09/app/oracle/oradata/testdb/control/control02.ctl','/u09/ap
p/oracle/oradata/testdb/control/control03.ctl'
*.core_dump_dest='/u01/app/oracle/admin/testdb/cdump'
*.db_block_size=8192
*.db_cache_size=3221225472
*.db_domain='msk.vbrr.loc'
*.db_files=1024
*.db_name='testdb'
*.db_recovery_file_dest='/u01/app/oracle/flash_recovery_area'
*.db_recovery_file_dest_size=21474836480
*.dispatchers='(PROTOCOL=TCP) (SERVICE=testdbt0XDB)'
*.fast_start_mttr_target=300
*.fast_start_parallel_rollback='LOW'
*.java_pool_size=268435456
*.job_queue_processes=0
*.large_pool_size=200M
*.log_archive_dest_1='LOCATION=/u09/app/oracle/archlogs/arch01/testdb/ MANDATORY'
*.log_archive_format='testdb_%t_%s_%r.arc'
*.log_archive_max_processes=10
*.log_archive_min_succeed_dest=1
*.open_cursors=1000
*.optimizer_features_enable='9.2.0'
*.optimizer_secure_view_merging=FALSE
*.pga_aggregate_target=1g
*.processes=2500
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_max_size=5368709120
*.shared_pool_size=1073741824
*.smtp_out_server='solaris-mx.sun.com'
*.standby_file_management='AUTO'
testdb.streams_pool_size=335544320
*.undo_management='AUTO'
*.undo_retention=14400
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='/u01/app/oracle/admin/testdb/udump'


или так:


*.archive_lag_target=900
*.audit_sys_operations=TRUE
*.audit_trail='DB'
*.compatible='11.2.0'
*.control_files='+TEST/testdb/controlfile/current.866.822734201','+TEST/testdb/controlfile/current.867.822734201'#Restore Controlfile
*.control_management_pack_access='DIAGNOSTIC+TUNING'
*.db_block_size=8192
*.db_cache_size=12884901888
*.db_create_file_dest='+TEST'
*.db_create_online_log_dest_1='+REDO'
*.db_domain='msk.vbrr.loc'
*.db_files=1024
*.db_name='testdb'#Reset to original value by RMAN
*.db_recovery_file_dest='+RECO'
*.db_recovery_file_dest_size=107374182400
*.diagnostic_dest='/u01/app/oradb'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=testdbXDB)'
*.fast_start_mttr_target=300
*.fast_start_parallel_rollback='LOW'
*.java_pool_size=268435456
*.job_queue_processes=60
*.large_pool_size=268435456
*.log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES, ALL_ROLES)'
*.log_archive_dest_state_3='ENABLE'
*.log_archive_format='%t_%s_%r.arc'
*.log_archive_max_processes=4
*.log_archive_min_succeed_dest=1
*.open_cursors=1000
*.optimizer_secure_view_merging=FALSE
*.os_authent_prefix='OSP$'
*.pga_aggregate_target=6442450944
*.processes=300
*.remote_login_passwordfile='EXCLUSIVE'
*.resource_manager_plan=''
*.sec_case_sensitive_logon=FALSE
*.sga_max_size=16106127360
*.shared_pool_size=2147483648
*.smtp_out_server='afina-mx.vbrr.ru'
*.standby_file_management='AUTO'
*.undo_retention=14400
*.undo_tablespace='UNDOTBS1'


Добавление временных файлов:

ALTER TABLESPACE TEMP ADD TEMPFILE '/app/oracle/oradata/sapdbt1/temp/temp01.dbf'
SIZE 29360128 REUSE AUTOEXTEND ON NEXT 655360 MAXSIZE 32767M;

или так:

CREATE TEMPORARY TABLESPACE "TEMP" TEMPFILE SIZE 61865984 AUTOEXTEND ON NEXT 655360 MAXSIZE 32767M EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1048576;
ALTER DATABASE DEFAULT TEMPORARY TABLESPACE "TEMP";
ALTER TABLESPACE "TEMP" ADD TEMPFILE SIZE 500M AUTOEXTEND ON NEXT 655360 MAXSIZE 32767M;


Установить DBID для тестовой базы можно так:

set ORACLE_SID=TESTDB
sqlplus sys/sys as sysdba
shutdown immediate;
startup open read only;

declare
  v_chgdbid   binary_integer;
  v_chgdbname binary_integer;
  v_skipped   binary_integer;
  old_name    varchar2(100);
  old_dbid    varchar2(100);

begin

  select name, dbid into old_name, old_dbid from v$database;
  dbms_backup_restore.nidbegin('TESTDB', old_name, 97255669, old_dbid, 0, 0, 10);
  dbms_backup_restore.nidprocesscf(v_chgdbid,v_chgdbname);
  for i in (select file#,name from v$datafile) loop
     dbms_backup_restore.nidprocessdf(i.file#,0, v_skipped,v_chgdbid,v_chgdbname);
  end loop;
  for i in (select file#,name from v$tempfile) loop
     dbms_backup_restore.nidprocessdf(i.file#,1, v_skipped,v_chgdbid,v_chgdbname);
  end loop;
  dbms_backup_restore.nidend;
end;

/

shutdown immediate;
startup mount;
alter database open resetlogs;
startup force;

Oracle Трассировка

Находим sid и serial# сессии:

select  s.username
,   s.sid
,   s.serial#
,   s.osuser
,   s.machine
,   s.terminal
,   p.spid
,   last_call_et
,   status
from    V$SESSION s
,   V$PROCESS p
where   s.PADDR = p.ADDR
and s.sid='123';


Включить трассировку:

BEGIN
SYS.DBMS_System.Set_Ev(156, 13, 10046, 12, '');
END;
/

Отключить трассировку сессии:

BEGIN
SYS.DBMS_System.Set_Ev(156, 13, 10046, 0, '');
END;
/

Файлы трассировок находятся:

show parameter dump_dest

или так:


select name, value
 from v$parameter
 where name like '%dump_dest%';

set serveroutput on
exec dbms_output.put_line( scott.get_param( 'user_dump_dest' ) )


В 11g так:

with home
 as
 (select value home
    from v$diag_info
  where name = 'ADR Home'
 )
 select name,
        case when value <> home.home
                 then replace(value,home.home,'$home$')
                        else value
        end value
from v$diag_info, home
/



 select c.value || '/' || d.instance_name || '_ora_' ||
 a.spid || '.trc' ||
 case when e.value is not null then '_'||e.value end trace
 from v$process a, v$session b, v$parameter c, v$instance d, v$parameter e
 where a.addr = b.paddr
 and b.audsid = userenv('sessionid')
 and c.name = 'user_dump_dest'
 and e.name = 'tracefile_identifier'
/


Обработка файлов трассировки:

Обработка файла трассировки выполняется при помощи утилиты tkprof, поставляемой
в комплекте Oracle Server. Формат вызова команды:

$tkprof trace_file processed_trace_file explain=username/password sort=exeela fchela

где

- trace_file - исходный необработанный файл трассировки;
- processed_trace_file - имя результирующего обработанного файла трассировки;
- username - имя пользователя, под которым работала трассируемая сессия;
- password - пароль пользователя.

Анализ файлов трассировки.
Анализ статистики работы сессии.
Выявление проблемных SQL предложений.

Обработанный файл трассировки состоит из последовательно расположенных
блоков SQL-предложений, выполняемых данной сессией. В конце файла приводится
суммарная статистика по всем SQL-предложениям, выполнявшимся данной сессией.
SQL-предложения в файле располагаются в порядке, зависящем от параметра
sort команды tkprof. Наиболее полезным параметром сортировки является
elapsed time (общее затраченное время). Наибольшее время обычно занимает
процедура выполнения (execute) или выборки (fetch) SQL-предложений,
поэтому используются параметры sort = exeela или sort = fchela соответственно.


tkprof test1_j000_10411.trc test1_j000_10411.prf explain=user/passw@test1 table=user.tun_plan_table sort=(exeela,fchela)





Трассировка сессии

Включение/выключение трассировки. Получение и обработка файлов
Для того чтобы получить файл трассировки заданной сессии необходимо включить
для нее режим трассировки, подождать необходимое для накопления информации
время, выключить режим трассировки и обработать полученный файл.
Иногда может возникнуть необходимость исследования необработанного
файла трассировки. В этом случае для получения более детальной информации
о трассируемом процессе рекомендуется включать трассировку через
Server Manager, используя 12-ый уровень отладки.

Процедура включения / выключения трассировки при помощи SQLPlus

Включение

Для включения трассировки сессии с параметрами SID и SERIAL# необходимо
выполнить из SQLPlus следующую последовательность команд:

SQL>alter system set timed_statistics = true;
SQL>alter system set max_dump_file_size = unlimited;
SQL>exec dbms_system.set_sql_trace_in_session( , , TRUE);

Выключение

Для выключения трассировки сессии с параметрами SID и SERIAL# необходимо
выполнить из SQLPlus следующую последовательность команд:


SQL>exec dbms_system.set_sql_trace_in_session( , , FALSE);

Скрипт: ode.sql




Процедура включения / выключения трассировки при помощи Server Manager

Включение

Для включения трассировки сессии необходимо определить SPID
соответствующего ей процесса и выполнить следующую последовательность
команд:

SVRMGRL> oradebug setospid
SVRMGRL> oradebug unlimit
SVRMGRL> oradebug event 10046 trace name context forever, level 8

или для более детальной информации в необработанном файле трассировки
(в том числе вывода bind переменных и oracle events)

SVRMGRL> oradebug event 10046 trace name context forever, level 12


Выключение

Для выключения трассировки сессии необходимо определить SPID
соответствующего ей процесса и выполнить следующую последовательность
команд:

SVRMGRL> oradebug event 10046 trace name context off

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

SVRMGRL> oradebug setospid
SVRMGRL> oradebug close_trace

Файл трассировки создается в каталоге, указанном в параметре базы данных
background_dump_dest для фоновых процессов или в параметре user_dump_dest
для пользовательскиx процессов.

Имя файла формируется по маске _*_.trc, где

- DBNAME - имя базы данных;
- SPID - идентификатор процесса в UNIX.

Имя файла трассировки также можно узнать, выполнив в Server Manager следующую
последовательность команд:

SVRMGRL> oradebug setospid
SVRMGRL> oradebug tracefile_name

Обработка файла трассировки выполняется при помощи утилиты tkprof, поставляемой
в комплекте Oracle Server. Формат вызова команды:

$tkprof \
explain=/ sort=exeela fchela

где

- - исходный необработанный файл трассировки;
- - имя результирующего обработанного файла
трассировки;
- - имя пользователя, под которым работала трассируемая сес-сия;
- - пароль пользователя.

Анализ файлов трассировки. Анализ статистики работы сессии.
Выявление проблемных SQL.предложений

Обработанный файл трассировки состоит из последовательно расположенных
блоков SQL-предложений, выполняемых данной сессией. В конце файла приводится
суммарная статистика по всем SQL-предложениям, выполнявшимся данной сессией.
SQL-предложения в файле располагаются в порядке, зависящем от параметра
sort команды tkprof. Наиболее полезным параметром сортировки является
elapsed time (общее затраченное время). Наибольшее время обычно занимает
процедура выполнения (execute) или выборки (fetch) SQL-предложений,
поэтому используются параметры sort = exeela или sort = fchela соответственно.

При анализе файла трассировки необходимо обращать внимание на следующие
статистики, сигнализирующие о возможном наличии узких или проблемных мест:

1. Большое общее затраченное время (столбец elapsed).
Большое затраченное процессорное время (столбец cpu) в данном случае
означает, что сессия тратит большое количество процессорного времени
на данную операцию. Возможно проблема в неоптимальном SQL-предложении.

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

Большое время, зарачиваемое на разбор (parse) SQL-предложения
сигнализирует о проблемах в настройках памяти базы данных. Возможно
слишком маленький размер shared pool.

2. Большое количество обращений к блокам базы данных (большое суммарное
значение столбцов query и current). Обычно сигнализирует о неверном
плане выполнения SQL-предложения.

3. Большой процент чтений блоков с диска (большое значение отношения
disk/(query + current) может быть вызван неоптимальным планом выполнения
SQL-предложения или неверной настройкой базы данных.

4. Частые разборы SQL-предложений (поле Parse count > 1), скорее всего,
вызваны неверной настройкой размера shared pool.

5. Большое количество вызовов данного SQL-предложения, не согласующееся с
выполняемыми им функциями, возможно вызвано ошибкой в данном программном
модуле.
Наиболее простой и продуктивный метод анализа файла трассировки
- сравнение его с аналогичным файлом трассировки, собранной во время
нормального функционирования программного модуля. Поскольку в различных
файлах обычно содержится информация, накопленная за различное время,
сравнивать следует нормированные значения статистик. Например, можно
поделить все временные статистики SQL-предложения на количество вызовов
той или иной операции, а статистики по обращениям к блокам базы данных
- на количество обработанных записей.

Пример 1

Проблема длительных разборов SQL-предложения.
На 19 разборов было затрачено 691.42 сек. процессорного времени
и прошло 853.79 сек. реального времени. То есть на один разбор
тратится 853/19 = 45 сек. реального времени.

select count(up) from num_calls where up=:up and strt=to_date(:strt,
:d_mask) and dur=:dur and srv_a=:srv_a and ((:num_a is null and num_a is
null) or num_a=:num_a) and ((num is null and :num is null) or num=:num)
and ((:onls='@' and services is null) or :onls=services) and
billpar>:billpar

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 19 691.42 853.79 0 0 0 0
Execute 0 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 19 691.42 853.79 0 0 0 0

Misses in library cache during parse: 15
Optimizer goal: RULE
Parsing user id: 19 (MTS24E)

Rows Execution Plan
------- ---------------------------------------------------
0 SELECT STATEMENT GOAL: RULE
0 SORT (AGGREGATE)
0 PARTITION RANGE (SINGLE) PARTITION:KEYKEY
0 TABLE ACCESS (BY LOCAL INDEX ROWID) OF 'NUM_CALLS'
PARTITION:KEYKEY
0 INDEX (RANGE SCAN) OF 'NUM_CALLS_UP' (NON-UNIQUE)
PARTITION:KEYKEY



Пример 2

Проблема большого количества чтений с диска.
Из файла трассировки следует, что из запрошенных 2157 + 48438 = 50595 блоков
- 7464 прочитано с дисков, что составляет 15% от всего количества.
Кроме того, сильно отличаются elapsed time и cpu time. Это означает,
что сессия простаивает, ожидая выполнения каких либо условий.
В нашем случае - это ожидание чтения блоков с диска.


insert into num_calls (N_BLK, UP ,SRV_A ,SRV_B ,IND_B,STRT ,PTT ,AIR, PTT_TOLL, ptt_toll2,srv_toll,srv_toll2 ,NUM ,DUR ,INCOMING ,OUTGOING ,NUM_A, DIR ,TA, CELL_ID,SERVICES ,STATUS,DSC ,BILLPAR, r_roamfile_seq, AIR_SUB,PTT_SUB, imei,rtype,r_mscid,r_calls_log,utc)
values (decode(:n_blk,:nullnumber,null,:n_blk),:app, decode(:srv_a, :nullnumber,null, :srv_a) ,decode(:srv_b,:nullnumber,null,:srv_b) ,decode(:zoneindex, :nullnumber,null,:zoneindex), to_date(:strt,'yyyymmddhh24miss'), decode(:ptt,:nullnumber,null, round(:ptt,10)) ,decode(:air,:nullnumber,null,round(:air,10)) ,decode(:ptt_toll,:nullnumber,null,round(:ptt_toll,10)) ,
decode(:ptt_toll2, :nullnumber,null, round(:ptt_toll2,10)) ,decode(:srv_toll, :nullnumber,null,:srv_toll) , decode(:srv_toll2, :nullnumber,null, :srv_toll2), :num_b,decode(:dur,:nullnumber,null,:dur) ,decode(:routei,:nullnumber,null, :routei) ,decode(:routeo, :nullnumber, null,:routeo) ,:num_a ,:dir,:ta, :cell_id,:services,'', :dsc,0, decode(:roamfile_seq, :nullnumber,null, :roamfile_seq), decode(:air_sub, :nullnumber,null,:air_sub),null,:imei,:rtype, decode(:r_mscid, :nullnumber,null,:r_mscid), :r_calls_log, decode(:utc,100000,null,:utc))


call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 0 0.00 0.00 0 0 0 0
Execute 95 13.43 341.97 7464 2157 48438 9500
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 95 13.43 341.97 7464 2157 48438 9500

Поиск причин низкой производительности SQL-предложений.
Анализ планов выполнения SQL-предложений.
Одной из причин замедления работы приложений может быть несоответствие
плана выполнения (Execution Plan) SQL-предложений тому плану, который был
предусмотрен разработчиком при написании программного кода.
В частности, следует обращать внимание на наличие выборок по таблицам в
режиме FULL SCAN, в котором перебираются последовательно все строки таблицы
без использования индекса.
Следует, однако, иметь в виду, что наличие FULL SCAN не является ошибкой
в случаях, когда бизнес-логика запроса действительно требует сканирования
всей таблицы, либо при малом количестве записей в таблице, когда использование
индекса нецелесообразно.
Еще одной из причин несоответствия планов выполнения является наличие
статистики по таблицам и индексам БД. При этом, при отсутствии подсказок
оптимизатор строит план выполнения запроса исходя из данных статистики,
а не в соответствии с правилами разбора SQL-предложений. Т.к. при работе с
приложениями CBOSS предусматривается использование Rule-based optimisation,
то наличие статистики также приводит к искажению планов выполнения.
Также имеет смысл анализировать соответствие плана разбора SQL-предложения
подсказкам оптимизатора, указанным в запросе. Например, если при выполнении
запроса не используются указанные в хинте индексы, то следует проверить
наличие и доступность этих индексов в базе.

Пример:

В данном примере происходит полное сканирование таблицы, содержащей несколько
десятков тысяч строк.

SELECT R_SERVICE
FROM
ENCOURAGEMENTS_TMP WHERE R_APP = :b1 AND COND_ID = :b2 AND ACT_ID = :b3
AND ((:b4 IS NULL AND :b5 BETWEEN FD AND TD ) OR (:b4 IS NOT NULL AND
:b7 IS NULL AND (:b4 < TD AND FD < :b5 )) OR (:b7 IS NOT NULL AND :b7 <
TD )) AND :b12 = SRV_CODE

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 0 0.00 0.00 0 0 0 0
Execute 30821 2.83 2.74 0 0 0 0
Fetch 30821 1404.64 1473.50 1604 5035350 123284 13016
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 61642 1407.47 1476.24 1604 5035350 123284 13016

Misses in library cache during parse: 0
Optimizer goal: RULE
Parsing user id: 18 (VOXTEL) (recursive depth: 4)

Rows Execution Plan
------- ---------------------------------------------------
0 SELECT STATEMENT GOAL: RULE
0 TABLE ACCESS (FULL) OF 'ENCOURAGEMENTS_TMP'

Анализ необработанных файлов трассировки

Если планируется производить анализ необработанного файла трассировки,
то трассировку сессии следует запускать из Server Manager, используя при
этом 12-й уровень отладки. Полученный таким образом файл будет содержать
кроме обычной статистической информации все переменные, передаваемые
SQL-предложениям и системные события, выполнение которых ожидалось сессией
в процессе ее работы. Кроме того, по необработанному файлу трассировки можно
определить последовательность операций, выполняемых трассируемой сессией.

Создание резервной БД Oracle

Два сервера OMEGA01 и OMEGA02

Создадим

на сервере omega01.localdomain  Primary DB
на сервере omega02.localdomain  Standby DB


На сервере  omega01.localdomain  создаем DB:

Global Database Name: TEST_OMEGA01
SID: TEST


*************************************************************************************************************************************
Во время создания базы должно быть сконфигурирована область FRA:
alter system set DB_RECOVERY_FILE_DEST = '+FRA' scope=spfile sid='*';
-- alter system set DB_RECOVERY_FILE_DEST = '/u01/app/oracle/fast_recovery_area' scope=both sid='*';
alter system set DB_RECOVERY_FILE_DEST_SIZE = 10G scope=spfile sid='*';
alter system set LOG_ARCHIVE_DEST_1 = 'LOCATION=USE_DB_RECOVERY_FILE_DEST' scope=spfile sid='*';
*************************************************************************************************************************************


На сервере omega01.localdomain создаем следующую конфигурацию:


$ vi $ORACLE_HOME/network/admin/listener.ora

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
      (ADDRESS = (PROTOCOL = TCP)(HOST = omega01.localdomain)(PORT = 1521))
    )
  )

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = TEST_OMEGA01)
      (ORACLE_HOME   = /u01/app/oracle/product/11.2.0.4)
      (SID_NAME      = TEST)
    )
    (SID_DESC =
      (GLOBAL_DBNAME = TEST_OMEGA01_DGMGRL)
      (ORACLE_HOME   = /u01/app/oracle/product/11.2.0.4)
      (SID_NAME      = TEST)
    )
  )

#################################
# standard parameters
#################################
ADR_BASE_LISTENER = /u01/app/oracle
ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER=ON
VALID_NODE_CHECKING_REGISTRATION_LISTENER=SUBNET
#################################
# extended parameters
#################################
TRACE_LEVEL_LISTENER       = OFF
STARTUP_WAIT_TIME_LISTENER = 0
CONNECT_TIMEOUT_LISTENER   = 120
INBOUND_CONNECT_TIMEOUT_LISTENER = 120
SUBSCRIBE_FOR_NODE_DOWN_EVENT_LISTENER=OFF



$ vi $ORACLE_HOME/network/admin/sqlnet.ora

NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)
SQLNET.EXPIRE_TIME = 10
ADR_BASE = /u01/app/oracle



$ vi $ORACLE_HOME/network/admin/tnsnames.ora

TEST_OMEGA01 =
  (DESCRIPTION =
    (ENABLE=BROKEN)
    (ADDRESS_LIST=
        (ADDRESS = (PROTOCOL = TCP)(HOST = omega01.localdomain)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = TEST_OMEGA01)
    )
  )

TEST_OMEGA02 =
  (DESCRIPTION =
    (ENABLE=BROKEN)
    (ADDRESS_LIST=
        (ADDRESS = (PROTOCOL = TCP)(HOST = omega02.localdomain)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = TEST_OMEGA02)
    )
  )


На сервере omega02.localdomain создаем следующую конфигурацию:


$ vi $ORACLE_HOME/network/admin/listener.ora

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
      (ADDRESS = (PROTOCOL = TCP)(HOST = omega02.localdomain)(PORT = 1521))
    )
  )

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = TEST_OMEGA02)
      (ORACLE_HOME   = /u01/app/oracle/product/11.2.0.4)
      (SID_NAME      = TEST)
    )
    (SID_DESC =
      (GLOBAL_DBNAME = TEST_OMEGA02_DGMGRL)
      (ORACLE_HOME   = /u01/app/oracle/product/11.2.0.4)
      (SID_NAME      = TEST)
    )
  )

#################################
# standard parameters
#################################
ADR_BASE_LISTENER = /u01/app/oracle
ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER=ON
VALID_NODE_CHECKING_REGISTRATION_LISTENER=SUBNET
#################################
# extended parameters
#################################
TRACE_LEVEL_LISTENER       = OFF
STARTUP_WAIT_TIME_LISTENER = 0
CONNECT_TIMEOUT_LISTENER   = 120
INBOUND_CONNECT_TIMEOUT_LISTENER = 120
SUBSCRIBE_FOR_NODE_DOWN_EVENT_LISTENER=OFF



$ vi $ORACLE_HOME/network/admin/sqlnet.ora

NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)
SQLNET.EXPIRE_TIME = 10
ADR_BASE = /u01/app/oracle



$ vi $ORACLE_HOME/network/admin/tnsnames.ora

TEST_OMEGA01 =
  (DESCRIPTION =
    (ENABLE=BROKEN)
    (ADDRESS_LIST=
        (ADDRESS = (PROTOCOL = TCP)(HOST = omega01.localdomain)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = TEST_OMEGA01)
    )
  )

TEST_OMEGA02 =
  (DESCRIPTION =
    (ENABLE=BROKEN)
    (ADDRESS_LIST=
        (ADDRESS = (PROTOCOL = TCP)(HOST = omega02.localdomain)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = TEST_OMEGA02)
    )
  )



Подготовка параметров инициализации для Primary БД (TEST_OMEGA01):


alter system set DB_UNIQUE_NAME = 'TEST_OMEGA01' scope=spfile sid='*';

-- В случае использования ASM+OMF
alter system set DB_CREATE_FILE_DEST = "+DATA" scope=both sid='*';
alter system set DB_CREATE_ONLINE_LOG_DEST_1 = "+REDO1" scope=both sid='*';
alter system set DB_CREATE_ONLINE_LOG_DEST_2 = "+REDO2" scope=both sid='*';

-- Параметры
alter system set LOG_ARCHIVE_DEST_1 = 'LOCATION=USE_DB_RECOVERY_FILE_DEST' scope=spfile sid='*';
alter system set LOG_ARCHIVE_DEST_2 = '' scope=both sid='*';
alter system reset LOG_ARCHIVE_DEST_2 scope=spfile sid='*';
alter system set FAL_SERVER = 'TEST_OMEGA02' scope=both sid='*';
alter system set FAL_CLIENT = 'TEST_OMEGA01' scope=both sid='*';
alter system set STANDBY_FILE_MANAGEMENT = 'AUTO' scope=both sid='*';
alter system set REMOTE_LOGIN_PASSWORDFILE = "EXCLUSIVE" scope=spfile sid='*';

alter system set DB_FILE_NAME_CONVERT  =
                       '+DATA/TEST_OMEGA02/', '+DATA/TEST_OMEGA01/',
                       '+REDO1/TEST_OMEGA02/','+REDO1/TEST_OMEGA01/',
                       '+REDO2/TEST_OMEGA02/','+REDO2/TEST_OMEGA01/' scope=spfile sid='*';

alter system set LOG_FILE_NAME_CONVERT =
                       '+DATA/TEST_OMEGA02/', '+DATA/TEST_OMEGA01/',
                       '+REDO1/TEST_OMEGA02/','+REDO1/TEST_OMEGA01/',
                       '+REDO2/TEST_OMEGA02/','+REDO2/TEST_OMEGA01/' scope=spfile sid='*';



******************************************************************************************************
Немного про параметры конвертации:

Если Primary и Standby находятся на ASM, то параметры для DB_FILE_NAME_CONVERT и LOG_FILE_NAME_CONVERT
на Primary можно установить примерно так:

alter system set DB_FILE_NAME_CONVERT  =
                       '+DATA/TEST_OMEGA02/', '+DATA/TEST_OMEGA01/',
                       '+REDO1/TEST_OMEGA02/','+REDO1/TEST_OMEGA01/',
                       '+REDO2/TEST_OMEGA02/','+REDO2/TEST_OMEGA01/' scope=spfile sid='*';

alter system set LOG_FILE_NAME_CONVERT =
                       '+DATA/TEST_OMEGA02/', '+DATA/TEST_OMEGA01/',
                       '+REDO1/TEST_OMEGA02/','+REDO1/TEST_OMEGA01/',
                       '+REDO2/TEST_OMEGA02/','+REDO2/TEST_OMEGA01/' scope=spfile sid='*';

на Standby в обратном порядке:

alter system set DB_FILE_NAME_CONVERT  =
                       '+DATA/TEST_OMEGA01/', '+DATA/TEST_OMEGA02/',
                       '+REDO1/TEST_OMEGA01/','+REDO1/TEST_OMEGA02/',
                       '+REDO2/TEST_OMEGA01/','+REDO2/TEST_OMEGA02/' scope=spfile sid='*';

alter system set LOG_FILE_NAME_CONVERT =
                       '+DATA/TEST_OMEGA01/', '+DATA/TEST_OMEGA02/',
                       '+REDO1/TEST_OMEGA01/','+REDO1/TEST_OMEGA02/',
                       '+REDO2/TEST_OMEGA01/','+REDO2/TEST_OMEGA02/' scope=spfile sid='*';


Но лучше уточнить, может TEST_OMEGA01/02  придётся задать в нижнем регистре test_omega01/02
Для брокера эти команды будут выглядеть примерно так:

-- On Primary
dgmgrl /
edit database 'TEST_OMEGA01' set property 'StandbyFileManagement'='AUTO';
edit database 'TEST_OMEGA01' set property 'ArchiveLagTarget'=1200;
edit database 'TEST_OMEGA01' set property 'DbFileNameConvert' = '+DATA/test_omega02/  , +DATA/test_omega01/ ,  +DATA, +DATA' ;
edit database 'TEST_OMEGA01' set property 'LogFileNameConvert'= '+REDO/test_omega02/  , +REDO/test_omega01/ ,  +REDO, +REDO' ;

-- On Standby
dgmgrl /
edit database 'TEST_OMEGA02' set property 'StandbyFileManagement'='AUTO';
edit database 'TEST_OMEGA02' set property 'ArchiveLagTarget'=1200;
edit database 'TEST_OMEGA02' set property 'DbFileNameConvert' = '+DATA/test_omega01/  , +DATA/test_omega02/ ,  +DATA, +DATA' ;
edit database 'TEST_OMEGA02' set property 'LogFileNameConvert'= '+REDO/test_omega01/  , +REDO/test_omega02/ ,  +REDO, +REDO' ;



Если StandbyDB TEST_OMEGA02 будет располагаться на файловой системе а Primary на ASM.
например так:

Primary                                                  Standby
----------------------------------------------      --------------
+DATA/TEST_OMEGA01/datafile/        /u02/oradata/TEST_OMEGA02/
+DATA/TEST_OMEGA01/tempfile/       /u02/oradata/TEST_OMEGA02/

+DATA/TEST_OMEGA01/onlinelog/     /u02/oradata/TEST_OMEGA02/


То параметры  DB_FILE_NAME_CONVERT и LOG_FILE_NAME_CONVERT необходимо установить только на Standby
например так:

alter system set DB_FILE_NAME_CONVERT  = '+DATA/test_omega01/datafile/' ,'/u02/oradata/TEST_OMEGA02/','+DATA/test_omega01/tempfile/','/u02/oradata/TEST_OMEGA02/' scope=spfile sid='*';
alter system set LOG_FILE_NAME_CONVERT = '+DATA/test_omega01/onlinelog/','/u02/oradata/TEST_OMEGA02/'

Или с помощью брокера:

EDIT DATABASE 'TEST_OMEGA02' SET PROPERTY 'DbFileNameConvert'  = '+DATA/test_omega01/datafile/  , /u02/oradata/TEST_OMEGA02/ , +DATA/test_omega01/tempfile/ , /u02/oradata/TEST_OMEGA02/';
EDIT DATABASE 'TEST_OMEGA02' SET PROPERTY 'LogFileNameConvert' = '+DATA/test_omega01/onlinelog/ , /u02/oradata/TEST_OMEGA02/';

На Primary параметры  DB_FILE_NAME_CONVERT и LOG_FILE_NAME_CONVERT в этом случае устанавливать не нужно.
**************************************************************************************************************************************************************************

Применим эти параметры:

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;




Подготовка файла паролей для резервной БД (TEST_OMEGA02):

Необходимо обеспечить наличие файла паролей перед запуском нового AUXILIARY экземпляра резервной БД.
В зависимости от режима клонирования необходимы выполнить следующее:

Active Database Duplication    

Создать новый файл паролей с паролем, совпадающим с основной БД.
Это будет временный файл паролей,
который будет перезаписан утилитой RMAN в время процесса клонирования.  

Пример:
cd $ORACLE_HOME/dbs 
orapwd file=orapw${ORACLE_SID}  


Backup-based Duplication

Взять существующий файл паролей с основной БД


Подготовка файла параметров для резервной БД

Если используется DUPLICATE без соединения TARGET,
вы не можете использовать SPFILE, иначе получите:

RMAN-05537: DUPLICATE without TARGET connection when auxiliary instance is started
with spfile cannot use SPFILE clause


1) Создать текстовую копию файла параметров на Primary БД

SQL> create pfile='/tmp/init$ORACLE_SID.ora' from spfile;

2) Скопировать полученный файл на сервер резервной БД в $ORACLE_HOME/dbs

3) Модифицировать (заменить) значение TEST_OMEGA01 на TEST_OMEGA02

cd $ORACLE_HOME/dbs
vi -c "%s/TEST_OMEGA01/TEST_OMEGA02/gi" -c "wq" init${ORACLE_SID}.ora

4) Преобразовать PFILE в SPFILE и запустить AUXILIARY экземпляр в режиме NOMOUNT

cd $ORACLE_HOME/dbs
sqlplus / as sysdba
SQL> startup nomount pfile= init${ORACLE_SID}.ora
SQL> create spfile from pfile;
SQL> shutdown immediate
SQL> STARTUP NOMOUNT


Подготовка параметров инициализации для Standby БД:

alter system set CONTROL_FILES='+DATA','+REDO1','+REDO2' scope=spfile sid='*';
alter system set DB_UNIQUE_NAME = 'TEST_OMEGA02' scope=spfile sid='*';

-- В случае использования ASM+OMF
alter system set DB_CREATE_FILE_DEST = "+DATA" scope=both sid='*';
alter system set DB_CREATE_ONLINE_LOG_DEST_1 = "+REDO1" scope=both sid='*';
alter system set DB_CREATE_ONLINE_LOG_DEST_2 = "+REDO2" scope=both sid='*';

-- Параметры
alter system set LOG_ARCHIVE_DEST_1 = 'LOCATION=USE_DB_RECOVERY_FILE_DEST' scope=spfile sid='*';
alter system set LOG_ARCHIVE_DEST_2 = '' scope=both sid='*';
alter system reset LOG_ARCHIVE_DEST_2 scope=spfile sid='*';
alter system set FAL_SERVER = 'TEST_OMEGA01' scope=both sid='*';
alter system set FAL_CLIENT = 'TEST_OMEGA02' scope=both sid='*';
alter system set STANDBY_FILE_MANAGEMENT = 'AUTO' scope=both sid='*';
alter system set REMOTE_LOGIN_PASSWORDFILE = "EXCLUSIVE" scope=spfile sid='*';


Параметры конвертации возможно такие:

alter system set DB_FILE_NAME_CONVERT  =
                       '+DATA/TEST_OMEGA01/', '+DATA/TEST_OMEGA02/',
                       '+REDO1/TEST_OMEGA01/','+REDO1/TEST_OMEGA02/',
                       '+REDO2/TEST_OMEGA01/','+REDO2/TEST_OMEGA02/' scope=spfile sid='*';

alter system set LOG_FILE_NAME_CONVERT =
                       '+DATA/TEST_OMEGA01/', '+DATA/TEST_OMEGA02/',
                       '+REDO1/TEST_OMEGA01/','+REDO1/TEST_OMEGA02/',
                       '+REDO2/TEST_OMEGA01/','+REDO2/TEST_OMEGA02/' scope=spfile sid='*';


Применим эти параметры:

SHUTDOWN IMMEDIATE;
STARTUP NOMOUNT;



Создание резервной БД с помощью RMAN


На основной БД (Primary database) включить режим игнорирования NOLOGGING операций

SQL> alter database force logging;

SQL> select force_logging from v$database;

На основной БД (Primary database) добавить Standby Redo Log files по формуле N+1

SQL> alter database add standby logfile thread 1 SIZE X[G|M];

где X[G|M] – размер журнала на Primary database
N - количество групп оперативных журналов на Primary database


ALTER DATABASE ADD STANDBY LOGFILE SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE SIZE 52428800;


SQL> select group#,bytes/1024/1024 from v$standby_log;


На резервной БД (Standby database) запустить AUXILIARY экземпляр в режиме NOMOUNT.

SQL> STARTUP NOMOUNT



Active Database Duplication:

Копирование файлов с основной БД с помощью утилиты RMAN
Подключение к RMAN каталогу не требуется

$ORACLE_HOME/bin/rman target=sys/password@TEST_OMEGA01 \
                      auxiliary=sys/password@TEST_OMEGA02

RMAN> run {

   set archivelog destination to '+DATA';

   duplicate target database for standby from active database nofilenamecheck dorecover;

}



Backup-based Duplication:

Копирование файлов из резервной копии БД с помощью утилиты RMAN
Необходимо выполнить подключение к RMAN каталогу

$ORACLE_HOME/bin/rman catalog=login/password@RCAT \
                      target=sys/password@TEST_OMEGA01 \
                      auxiliary=/
RMAN> run {

   set archivelog destination to '+DATA';
   duplicate target database for standby nofilenamecheck dorecover;

}



**********************************************************************************************************
cd $ORACLE_HOME/dbs
sqlplus / as sysdba
SQL> startup nomount pfile= initTEST.ora
SQL> create spfile from pfile;
SQL> shutdown immediate
SQL> STARTUP NOMOUNT

startup nomount pfile=initTEST.ora

$ORACLE_HOME/bin/rman target=sys/welcome1@TEST_OMEGA01  auxiliary=sys/welcome1@TEST_OMEGA02

RMAN>

run {
set archivelog destination to '+DATA';
duplicate target database for standby from active database
spfile
parameter_value_convert 'TEST_OMEGA01','TEST_OMEGA02'
set db_unique_name='TEST_OMEGA02'
set db_file_name_convert='+DATA/TEST_OMEGA01/datafile/','/u02/oradata/TEST_OMEGA02/','+DATA/TEST_OMEGA01/tempfile/','/u02/oradata/TEST_OMEGA02/'
set log_file_name_convert='+DATA/TEST_OMEGA01/onlinelog/','/u02/oradata/TEST_OMEGA02/'
set db_recovery_file_dest='/u01/app/oracle/fast_recovery_area'
set control_files='/u02/oradata/TEST_OMEGA01/control01.ctl','/u01/app/oracle/fast_recovery_area/TEST_OMEGA02/control02.ctl'
nofilenamecheck dorecover;
}

*************************************************************************************************************



Настроить авто-удаление архивных логов на стороне Primary + Standby database

На стороне PRIMARY database
Необходимо выполнить подключение к RMAN каталогу

rman catalog=login/password@RCAT  target=/
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY BACKED UP 1 TIMES TO 'SBT_TAPE';

На стороне STANDBY database
Подключение к RMAN каталогу не требуется

rman nocatalog target=/
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;



Настройка FRA репозитария для хранения архивных и flashback логов

Выполнить на обоих БД

alter system set DB_RECOVERY_FILE_DEST = '+FRA' scope=spfile sid='*';
alter system set DB_RECOVERY_FILE_DEST_SIZE = 10G scope=spfile sid='*';
alter system set LOG_ARCHIVE_DEST_1 = 'LOCATION=USE_DB_RECOVERY_FILE_DEST' scope=spfile sid='*';


Настройка Data Guard

Перед созданием DG конфигурации необходимо убиться что Data Guard Broker
запущен на каждом экземпляре БД входящей в будущую конфигурации:

SQL> alter system set dg_broker_start=TRUE scope=both sid='*';

На Primary узле выполнить следующее:

$ dgmgrl

DGMGRL> connect sys/******

DGMGRL> show configuration;
DGMGRL> disable configuration;
DGMGRL> remove configuration;

DGMGRL> create configuration 'TEST' as primary database is 'TEST_OMEGA01' connect identifier is TEST_OMEGA01;

DGMGRL> add database 'TEST_OMEGA02' as connect identifier is TEST_OMEGA02 maintained as physical;

DGMGRL> show configuration;
DGMGRL> enable configuration;


Установка режима защиты данных

MAXPERFORMANCE
Данный режим защиты устанавливается по умолчанию.

MAXAVAILABILITY
$ dgmgrl /
DGMGRL> EDIT DATABASE 'TEST_OMEGA01' SET PROPERTY 'LogXptMode'='SYNC';
DGMGRL> EDIT DATABASE 'TEST_OMEGA02' SET PROPERTY 'LogXptMode'='SYNC';
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;

MAXPROTECTION
$ dgmgrl /
DGMGRL> EDIT DATABASE 'TEST_OMEGA01' SET PROPERTY 'LogXptMode'='SYNC';
DGMGRL> EDIT DATABASE 'TEST_OMEGA02' SET PROPERTY 'LogXptMode'='SYNC';
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXPROTECTION;


Проверка режима защиты данных в основной БД (Primary database)

SQL> SELECT PROTECTION_MODE FROM V$DATABASE;


Выполнение операции "Failover" с помощью Data Guard

Существует два режима активации резервной БД в случае исчезновения основной БД.

Операция "Complete Failover" с помощью Data Guard

Эта операция активации резервной БД вследствие недоступности или потери основной БД.
Перед данной операцией будут применены ВСЕ накопленные изменения на резервной БД
для недопущения потери данных.

Подключаемся к Standby:

$ dgmgrl

DGMGRL> connect sys/******@TEST_OMEGA02
DGMGRL> show configuration;

Configuration - DBNAME

  Protection Mode: MaxPerformance
  Databases:
    TEST_OMEGA01 - Primary database
    TEST_OMEGA02 - Physical standby database

-- Активировать резервную БД

DGMGRL> FAILOVER TO 'TEST_OMEGA02';


Операция "Immediate Failover" с помощью Data Guard

Эта операция активации резервной БД вследствие недоступности или потери основной БД.
Перед данной операцией НЕ будут применены накопленные изменения на резервной БД,
т.е. резервная БД будет активирована в том состоянии в котором она находилась на момент запуска команды.

Данный режим активации обычно используют если произошло следующее:

An ORA-752 error has occurred at the standby database
An ORA-600 [3020] error has occurred at the standby database and Oracle support has determined
that it was caused by a lost write at the primary database
A complete failover is not possible

Подключаемся к Standby:

$ dgmgrl

DGMGRL> connect sys/******@TEST_OMEGA02
DGMGRL> show configuration;

Configuration - DBNAME

  Protection Mode: MaxPerformance
  Databases:
    TEST_OMEGA01 - Primary database
    TEST_OMEGA02 - Physical standby database


-- Активировать резервную БД

DGMGRL> FAILOVER TO 'TEST_OMEGA02' IMMEDIATE;



Выполнение операции "Switchover" (смена ролей) с помощью Data Guard

Данная операция выполняет плановую смену ролей между серверами БД.
На основании документа техподдержки: Doc ID 1582837.1 + Doc ID 1305019.1

Запретить отложенный накат изменений на Standby БД, если он включен

Подключаемся к Standby:

$ . oraenv
$ dgmgrl
DGMGRL> connect sys/******@TEST_OMEGA02
DGMGRL> SHOW DATABASE 'TEST_OMEGA02' DELAYMINS;
DGMGRL> EDIT DATABASE 'TEST_OMEGA02' SET PROPERTY 'DELAYMINS'='0';


Запретить работу резервной БД в режиме Real Time Query (Active Data Guard Mode)

Согласно документации (требованиям) перед выполнением операции Switchover необходимо запретить
использование режима Real Time Query (Active Data Guard Mode) для резервной БД.

Проверка использования режима Real Time Query (Active Data Guard)

Подключаемся к Standby:

$ . oraenv
$ sqlplus / as sysdba

SQL> select database_role, open_mode from v$database;

DATABASE_ROLE   |OPEN_MODE
----------------|--------------------
PHYSICAL STANDBY|READ ONLY WITH APPLY - > Real Time Query is ON


Выполнить смену режима работы резервной БД – отменить режим Real Time Query (запретить ADG)

(!) Убедиться, что работы проводятся на сервере с ролью STANDBY
(!) Будет выполнена перезагрузка резервной БД

Подключаемся к Standby:

Вариант 1 – SQL*Plus
$ . oraenv
$ sqlplus / as sysdba
SQL> shutdown immediate;
SQL> startup nomount;
SQL> alter database mount standby database;  

Подключаемся к Standby:

Вариант 2 - DGMGRL
$ dgmgrl
DGMGRL> connect sys/******@TEST_OMEGA02
DGMGRL> EDIT DATABASE 'TEST_OMEGA02' SET STATE='OFFLINE';
DGMGRL> STARTUP MOUNT
DGMGRL> EDIT DATABASE 'TEST_OMEGA02' SET STATE='APPLY-ON';


Проверка отмены режима Real Time Query (Active Data Guard)

Подключаемся к Standby:

$ . oraenv
$ sqlplus / as sysdba

SQL> select database_role, open_mode from v$database;

DATABASE_ROLE   |OPEN_MODE
----------------|--------------------
PHYSICAL STANDBY|MOUNTED              - > Real Time Query is OFF



Выполнить операцию Switchover (Смена Ролей)

Обратите внимание, что при подключении к DGMGRL вы должны использовать
имя пользователя и пароль для SWITCHOVER.
Если вы подключаетесь к DGMGRL с использованием учетных данных хоста (dgmgrl / ),
то SWITCHOVER отработает, и новый Primary будет автоматически доступен,
но Standby (старую Primary), придется перезапустить вручную в режиме Physical standby.

Подключаемся к Primary:

$ dgmgrl

DGMGRL> connect sys/******@TEST_OMEGA01
DGMGRL> show configuration;

Configuration - DBNAME

  Protection Mode: MaxPerformance
  Databases:
    TEST_OMEGA01 - Primary database
    TEST_OMEGA02 - Physical standby database


-- Выполнить проверку готовности БД к смене роли | 12c only
DGMGRL> VALIDATE DATABASE 'TEST_OMEGA02';

-- Выполнить смену ролей между серверами БД

DGMGRL> SWITCHOVER TO 'TEST_OMEGA02';


Восстановить отложенный накат изменений на Standby БД, если он нужен
Сейчас Standby (TEST_OMEGA01)

Подключаемся к Standby:

$ . oraenv
$ dgmgrl
DGMGRL> connect sys/******@TEST_OMEGA01
DGMGRL> SHOW DATABASE 'TEST_OMEGA01' DELAYMINS;
DGMGRL> EDIT DATABASE 'TEST_OMEGA01' SET PROPERTY 'DELAYMINS'='';


Открытие резервной БД в режиме READ ONLY (Active Data Guard Mode)

Подключаемся к Standby:

$ dgmgrl

DGMGRL> connect sys/******@TEST_OMEGA01
DGMGRL> show configuration;

Configuration - DBNAME

  Protection Mode: MaxPerformance
  Databases:
    TEST_OMEGA02 - Primary database
    TEST_OMEGA01 - Physical standby database


-- Открыть резервную БД в режиме READ ONLY (Active Data Guard Mode)

DGMGRL> edit database 'TEST_OMEGA01' set state='APPLY-OFF';
DGMGRL> SQL "ALTER DATABASE OPEN READ ONLY";
DGMGRL> edit database 'TEST_OMEGA01' set state='APPLY-ON';


Мониторинг Data Guard конфигурации


Проверка статуса конфигурации

DGMGRL> SHOW CONFIGURATION;

Проверка статуса БД

DGMGRL> SHOW DATABASE 'TEST_OMEGA01';
DGMGRL> SHOW DATABASE 'TEST_OMEGA02';


Проверка несовпадающих параметров между экземпляром БД и репозиторием DG брокера

DGMGRL> SHOW DATABASE 'TEST_OMEGA01' INCONSISTENTPROPERTIES;
DGMGRL> SHOW DATABASE 'TEST_OMEGA02' INCONSISTENTPROPERTIES;


Проверка несовпадающих параметров между экземпляром БД и репозиторием DG брокера для службы Redo Transport

DGMGRL> SHOW DATABASE 'TEST_OMEGA01' INCONSISTENTLOGXPTPROPS;
DGMGRL> SHOW DATABASE 'TEST_OMEGA01' INCONSISTENTLOGXPTPROPS;