Oracle параметры текущей сессии

Обновлено: 06.07.2024

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

Вот основные свойства уведомлений DBMS_ALERT , почерпнутые мной из официальной документации:

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

один сеанс посылает уведомления при помощи DBMS_ALERT.SIGNAL и COMMIT .
другой сеанс
1. подписывается на уведомления при помощи DBMS_ALERT.REGISTER ,
2. ожидает уведомления при помощи DBMS_ALERT.WAITONE (или WAITANY ) и обрабатывает их,
3. удаляет подписку на уведомления, когда в них больше нет необходимости.

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

Для этого создам процедуру signaller , которая будет посылать 10 уведомлений bang или boom , выбирая из двух случайным образом (строка 8 ниже). Отправив уведомление, процедура спит случайное число секунд между 1 и 7, имитируя занятость, и затем отправляет следующее уведомление. Для создания процедуры текущий пользователь должен явно (не через роль) получить привилегии EXECUTE на пакеты SYS.DBMS_ALERT и SYS.DBMS_LOCK .

Для получения уведомлений bang и boom создам процедуру consumer с параметром p_sleep - числом секунд между вызовами DBMS_ALERT.WAITANY . На это время consumer будет делать паузы между ожиданиями уведомлений, что приведет к потере некоторых уведомлений, если они отправляются достаточно часто. По умолчанию p_sleep равен 0, что практически устраняет паузы между ожиданиями, и уведомления не должны теряться.

Каждый раз процедура ожидает уведомления не более 10 секунд - см. значение параметра timeout при вызове DBMS_ALERT.WAITANY в строке 11.

Теперь, с помощью DBMS_SCHEDULER , я запущу процедуру signaller параллельно в двух сеансах и процедуру consumer в текущем сеансе:

Как видим, в текущем сеансе приняты все отправленные уведомления. Повторим эксперимент, введя паузу в 10 секунд между ожиданиями уведомлений:

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

В официальной документации по СУБД Oracle 11gR2 можно подробно познакомиться со всеми процедурами и функциями DBMS_ALERT . А я перейду к экспериментам с пакетом DBMS_PIPE , удалив ненужные теперь процедуры:

Пакет DBMS_PIPE позволяет двум или более сеансам пересылать друг другу данные по именованным каналам (pipes). Вот основные сведения о DBMS_PIPE :

Следующий PL/SQL блок открывает три канала - частный явный, публичный явный и публичный неявный:

Итак, каналы были созданы. Теперь удалю созданные каналы, воспользовавшись DBMS_PIPE.REMOVE_PIPE для явных каналов и прочитав данные из неявного:

Как видим, после удаления каналы остались во вью v$db_pipes . Однако, вызов DBMS_PIPE.REMOVE_PIPE сбросил в 0 размеры каналов и изменил тип канала my_private_pipe с PRIVATE на PUBLIC . Не совсем то, чего можно было ожидать! При этом вызовы функции DBMS_PIPE.REMOVE_PIPE вернули статус 0, следовательно, выполнились без ошибок. В утешение остается заметить, что вью v$db_pipes не упоминается в документации по пакету DBMS_PIPE . И нет необходимости в него смотреть.

Завершая разговор о DBMS_PIPE , замечу, что не все мои эксперименты с этим пакетом прошли гладко и привели к ожидаемому результату. Кто заинтересовался, может подробнее познакомиться с процедурами и функциями DBMS_PIPE по официально документации по СУБД Oracle и продолжить эксперименты.

Введение в представление v $ session в oracle (перевод)

В этом представлении каждый связан с база данных Экземпляр в сеансе У обоих есть запись. Включая пользователей session И фоновые процессы, такие как DBWR ， LGWR ， arcchiver и многое другое.

V$SESSION Общие столбцы в

V$SESSION Является ли базовое информационное представление, используемое для поиска пользователей SID или SADDR , Однако в нем также есть некоторые столбцы, которые динамически изменяются и могут использоваться для проверки пользователей. Например:

SQL_HASH_VALUE ， SQL_ADDRESS : Эти два столбца используются для идентификации по умолчанию session реализованы SQL Утверждение. Если null или 0 Тогда объясни это session Ничего не сделал SQL Утверждение. PREV_HASH_VALUE с участием PREV_ADDRESS Два столбца используются для идентификации session Последнее выполненное заявление.

Примечание: при использовании SQL*Plus Делая выбор, убедитесь, что ширина столбца, которую вы переопределяете, не меньше 11 Для того, чтобы увидеть полное значение.

STATUS : Этот столбец используется для оценки session Статус:

l Achtive : Выполняется SQL утверждение (waiting for/using a resource)

l Inactive : В ожидании операции ( Это ждет, чтобы быть выполненным SQL утверждение )

l Killed : Помечено как удаленное

Следующие столбцы предоставляют session Информация может быть использована, когда один или несколько combination Найден, когда неизвестно session 。

Session Информация

l SID ： SESSION Логотип, обычно используемый для подключения Другой колонка

l AUDSID : Обзор session ID Уникальность, подтвердите, что он также обычно используется при поиске режима параллельного запроса

l USERNAME :ток session в oracle Имя пользователя в.

Client Информация

база данных session Быть запущенным сервером базы данных или с промежуточного сервера или даже с рабочего стола SQL*Net Запускается клиентский процесс, подключенный к базе данных, а в следующих столбцах представлена информация о клиенте.

l MACHINE : Машина, выполненная клиентом

l TERMINAL : Терминал работает на клиенте

l PROCESS : Клиентский процесс ID

l PROGRAM : Клиентская программа выполняется клиентом

Показывать подключенного пользователя PC из TERMINAL 、 OSUSER , Нужно PC из ORACLE.INI или Windows Установить ключевые слова в TERMINAL ， USERNAME 。

Application Информация

перевод DBMS_APPLICATION_INFO Пакет, чтобы установить некоторую информацию, чтобы отличить пользователей. Это отобразит следующие столбцы.

l CLIENT_INFO ： DBMS_APPLICATION_INFO Установить в

l ACTION ： DBMS_APPLICATION_INFO Установить в

l MODULE ： DBMS_APPLICATION_INFO Установить в

последующий V$SESSION Колонки также могут быть использованы:

V$SESSION Столбец подключения в ( Используется для связи с другими видами )

Column View Joined Column(s)

SID V$SESSION_WAIT,,V$SESSTAT,,V$LOCK,V$SESSION_EVENT,V$OPEN_CURSOR SID

(SQL_HASH_VALUE, SQL_ADDRESS) V$SQLTEXT, V$SQLAREA, V$SQL (HASH_VALUE, ADDRESS)

(PREV_HASH_VALUE, PREV_SQL_ADDRESS) V$SQLTEXT, V$SQLAREA, V$SQL (HASH_VALUE, ADDRESS)

TADDR V$TRANSACTION ADDR

PADDR V$PROCESS ADDR

Примеры:

1. Найди свой session Информация

2. когда machine Найти когда известно session

3. Найти назначенный в данный момент session Бег sql Утверждение. предполагать sessionID для 100

Ищу быть назначенным session реализованы SQL Заявление является публичным требованием, если session Является главной причиной узкого места, которое можно рассматривать в соответствии с утверждением, которое оно выполняет в настоящее время session Что делаешь.

Волшебное использование V $ сессионного стола

Описание нескольких часто используемых полей в таблице v $ session

б) запрашивать различные статистические данные о пользователях

В. Запросите переменную курсора, которую пользователь хочет открыть.

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

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

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

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

4. taddr Адрес текущей транзакции. Это поле можно использовать для просмотра информации о транзакции текущего сеанса, используемой информации сегмента отката и т. Д. ^ _ ^

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

6. (sql_address, sql_hash_value) (prev_sql_addr, prev_hash_value) В соответствии с этими двумя группами полей мы можем запросить подробную информацию об операторе SQL, выполняемом в текущем сеансе.

c) информация rowid заблокированного поля строится на основе вышеуказанных четырех полей.

8. logon_time Время входа в систему текущего сеанса.
9. last_call_et Время простоя сессии, обновляется каждые 3 секунды

Китайское введение каждой области:

SADDR - session address

AUDSID -Аудит идентификатор сессии. Вы можете запросить sid текущего сеанса через audsid. выберите sid из v $ session, где audsid = userenv ('sessionid');

USERNAME имя пользователя Равен имени пользователя в dba_users. Имя пользователя внутреннего процесса Oracle пусто.

COMMAND - Идентификатор sql, выполняемый сессией, где 1 представляет создание таблицы, а 3 - выбор.

TADDR Текущий адрес транзакции. Может использоваться для связи поля addr в v $ транзакции.

LOCKWAIT -Вы можете запросить соответствующую информацию о блокировке в настоящее время ожидает через это поле. sid + lockwait соответствует sid + kaddr в v $ loc.

STATUS -Используется для оценки статуса сессии. Активно: оператор SQL выполняется. неактивно: ожидание операции. убитый: помечен как убитый.

SERVER - Тип Обслуживания.

SCHEMANAME -схема логин. Внутренний процесс Oracle - это sys.

OSUSER Имя пользователя операционной системы клиента.

PROCESS Идентификатор процесса клиента.

MACHINE Имя клиента.

TERMINAL Имя терминала, выполненное клиентом.

PROGRAM -Клиентское приложение. Такие как ORACLE.EXE или sqlplus.exe

TYPE тип сессии

SQL_ADDRESS , SQL_HASH_VALUE, SQL_ID, SQL_CHILD_NUMBER - состояние sql выполняемой сессии, соответствующее адресу, hash_value, sql_id, child_number в v $ sql. PREV_SQL_ADDR,PREV_HASH_VALUE,PREV_SQL_ID,PREV_CHILD_NUMBER -Состояние последнего выполненного SQL.

MODULE,MODULE_HASH,ACTION,ACTION_HASH,CLIENT_INFO -Апп прошел

DBMS_APPLICATION_INFO Установите некоторую информацию.

FIXED_TABLE_SEQUENCE Значение, которое будет увеличиваться, когда сеанс завершит пользовательский вызов, то есть, если сеанс будет приостановлен, он не будет увеличиваться. Следовательно, производительность сеанса с определенного момента времени можно отслеживать на основе этого поля. Например, значение этого поля для сеанса один час назад было 10000, но теперь оно составляет 20 000, что указывает на то, что его пользовательские вызовы происходят чаще в течение часа, и вы можете сосредоточиться на статистике производительности этого сеанса.

Создаются контексты SQL-предложением CREATE CONTEXT. Из-за этого далее вместо «пространства имен» предпочтение отдается термину «контекст». Параметры контекста («атрибуты») устанавливаются процедурой DBMS_SESSION.SET_CONTEXT, а вот вычитываются в программу стандартной функцией SYS_CONTEXT. Пакет DBMS_SESSION содержит ряд других подпрограмм для работы с контекстами.

Здесь рассматривается лишь формальная сторона контекста сеанса, а способ его применения разработчик может определить сам или почерпнуть из описаний избирательного доступа к данным (FGAC или Label Security) и сервера приложений Oracle.

Готовый справочный контекст сеанса USERENV

Один контекст, с названием USERENV, создавать явным образом не требуется. Он доступен любому сеансу связи с СУБД Oracle в виде готового набора значений, разрешающего только прочтение, но не правку. Он позволяет узнать всевозможные сведения о сеансе, полезные для прикладного программирования. Ранее в Oracle существовала одноименная функция, но сейчас она поддерживается ради старых программ.

Пример информации, которую можно получить из контекста USERENV в программу:

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

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

Примеры поясняют отличие атрибутов CURRENT_SCHEMA и CURRENT_USER контекста USERENV друг от друга и от системной переменной USER.

Готовый изменяемый контекст сеанса CLIENTCONTEXT

либо через библиотеку OCI с помощью специального вызова OCIAppCtxSet
либо из программы на Java с помощью методов класса oracle.jdbc.internal.OracleConnection.

Тем самым контекст CLIENTCONTEXT способен при открытии сеанса передать информацию, дополнительную к традиционному имени пользователя и к ограниченному кругу сведений (адрес IP клиента, имя компьютера и пр.), доступному из контекста USERENV.

Значения переданных в сеанс атрибутов контекста CLIENTCONTEXT можно читать как обычно функцией SYS_CONTEXT, и изменять, но можно заводить и новые атрибуты:

Если бы атрибут A был установлен клиентской программой на C или на Java перед установлением соединения, значение B мы бы увидели сразу.

AWR snapshots (снимки) очень полезны, но Oracle по умолчанию делает их каждые 60 минут. Если вы заинтересованы в анализе проблем с производительностью, которая случилась 10 минут назад, то снимки AWR ничем не помогут. Однако все-таки способ получить эту информацию имеется. Oracle Database собирает статистику Active Session History (состоящую в основном из статистики ожидания для различных событий) для всех активных сеансов каждую секунду, и сохраняет ее в циклическом буфере в SGA. Таким образом, ASH записывает самую свежую активность сеанса (за последние пять или десять минут).

Процесс MMNL (в Oracle его называют manageability monitor light — облегченный монитор управляемости, хотя этот процесс отображается как “manageability monitor process 2”, когда запрашивается представление V$BGPROCESS) выполняет легковесные задачи управляемости, включая метрики и захват хронологической информации сеансов для средства ASH при некоторых обстоятельствах. Например, MMNL сбросит данные ASH на диск, если буфер памяти ASH заполнится до истечения часового интервала, что обычно заставляет MMON выталкивать его.
Анализ ASH предоставляет эффективные данные по производительности, поскольку сосредоточен только на активных сеансах. Анализ текущих активных сеансов выполняется с использованием представления V$ACTIVE_SESSION_HISTORY, а анализ хронологии более старых сеансов — с помощью представления DBA_HIST_ACTIVE_SESSION_HISTORY.

На заметку! Дополнительная статистика в Oracle Database не оказывает заметного влияния на производительность, поскольку поступает в основном прямо из SGA через фоновые процессы. Средство ASH использует около 2 Мбайт памяти в SGA на каждый процессор.

Данные текущего активного сеанса

Как должно быть известно, представление V$SESSION хранит данные обо всех текущих сеансах. Оно содержит 72 столбца информации, и потому слишком громоздко для анализа данных сеанса. Вот почему ASH упрощает представление V$SESSION и получает из него наиболее важную информацию ожидания. Oracle предлагает новое представление V$ACTIVE_SESSION_HISTORY, которое содержит по одной строке для каждого активного сеанса, откуда ASH делало выборку, и возвращает строку самого последнего сеанса первой.
Представление V$ACTIVE_SESSION_HISTORY — это место, где база данных хранит пример данных всех активных сеансов. В этом представлении имеется столбец по имени SESSION_STATE, который показывает, активен ли сеанс. Столбец SESSION_STATE принимает два значения: ON CPU или WAITING. Сеанс считается активным в следующих случаях:

состояние сеанса ON CPU, что означает активное использование сеансом процессора для выполнения работы с базой данных;
состояние сеанса WAITING, но столбец EVENT указывает, что сеанс не ожидает никаких событий в классе IDLE.

Обратите внимание, что ASH — скользящий буфер в SGA; это находящаяся в памяти хронология активного сеанса. Таким образом, в загруженной базе данных старая информация часто перезаписывается, поскольку ASH собирает данные из представления V$SESSION каждую секунду.

На заметку! Использование статистики ASH для настройки производительности экземпляра рассматривается в главе 20.

Хронологические данные более старых сеансов

Представление словаря данных DBA_HIST_ACTIVE_SESSION_HISTORY хранит хронологическую информацию о последнем активном сеансе. Другими словами, это представление — не что иное, как коллекция снимков представления V$ACTIVE_SESSION_HISTORY, которое само по себе является образом данных активного сеанса.
Существуют два способа заполнения DBA_HIST_ACTIVE_SESSION_HISTORY.

В процессе получения регулярных (по умолчанию — ежечасных) снимков, выполняемых AWR, фоновый процесс MMON передает AWR данные ASH.
Oracle может понадобиться передать данные в представление DBA_HIST_ACTIVE_SESSION_HISTORY между моментами получения регулярных снимков, если буфер памяти окажется заполненным, и база данных не сможет записать в него данные об активности сеанса. В этом случае новый фоновый процесс MMNL выполнит выталкивание данных из буфера памяти в представление словаря данных.

Генерация отчета ASH

Для получения отчета ASH можно воспользоваться сценарием ashrpt.sql, находящимся в каталоге $ORACLE_HOME/rdbms/admin. Применение этого сценария аналогично использованию сценария awrrpt.sql, описанного ранее в этой главе. Этот сценарий генерирует информацию об операторах SQL, которые выполнялись в указанный период времени, и включает детали о блокировках и ожидании. Вот как можно запустить сценарий ashrpt.sql для получения отчета ASH:

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

Первый раздел отчета ASH, Top User Events, предоставляет информацию о верхних пользовательских событиях, как показано в листинге 2:

Раздел Top Background Events (Верхние фоновые события), показанный в листинге 3 ниже, демонстрирует события ожидания в базе данных.

Раздел Top Service/Module (Верхняя служба/модуль), показанный в листинге 4, отображает активность, разделенную в соответствии со службами и модулями экземпляра.

В листинге 5 ниже показана информация о важнейших типах команд SQL (раздел Top SQL Command Types), выполненных в базе данных за последний час.

В листинге 6 ниже идентифицируются верхние операторы SQL (раздел Top SQL Statements), выполненные за анализируемый период ASH.

После этого следует раздел под названием Top SQL Using Literals (Верхние операторы SQL, использующие литералы), который поможет идентифицировать SQL-операторы, не использующие переменные привязки.

Следующие два сегмента, показанные в листинге 7, относятся Top Sessions (Ведущие сеансы) и Top Blocking Sessions (Ведущие блокирующие сеансы), основанные на ожиданиях в очереди и статистике ожидания занятого буфера.

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

В этом примере часовой период времени разбит на десять шестиминутных интервалов. Данный пример поможет более точно выявить моменты ухудшения производительности.

Читайте также: