Oracle посмотреть активные сессии

Обновлено: 05.07.2024

Введение в представление 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, что указывает на то, что его пользовательские вызовы происходят чаще в течение часа, и вы можете сосредоточиться на статистике производительности этого сеанса.

Привет! Меня зовут Александра, я работаю в команде тестирования производительности. В этой статье расскажу базовые сведения об OEM от Oracle. Статья будет полезна для тех, кто только знакомится с платформой, но и не только для них. Основная цель статьи — помочь провести быстрый анализ производительности БД и поиск отправных точек для более глубокого анализа.
OEM (Oracle Enterprise Manager) — платформа для управления БД. OEM предоставляет графический интерфейс для выполнения большого количества операций с базами данных: резервное копирование, просмотр аварийных журналов, графиков производительности.

Performance Home

На вкладке Performance Home можно увидеть основные графики утилизации БД.

Average Runnable Process

Этот график дает общее понимание использования CPU.

№	Показатель	Описание
1	Instance Foreground CPU	Отображает утилизацию CPU процессами текущего инстанса, напрямую запущенными клиентом, например выполнение запросов. Список событий ожидания текущего инстанса можно посмотреть в AWR-отчете
2	Instance Background CPU	Отображает утилизацию CPU фоновыми процессами текущего инстанса, например LGWR. Список событий фонового процесса текущего инстанса можно посмотреть в AWR-отчете или в официальной документации Oracle
3	Non-database Host CPU	Отображает утилизацию CPU процессами, не относящимися к текущему инстансу
4	Load Average	Отображает среднюю длину очереди процессов, ожидающих выполнения
5	CPU Treads/CPU Cores	Отображает лимит максимально возможного использования CPU

Average Active Sessions

Если зафиксирован рост активных сессий, то должна расти пропускная способность (график Throughput).
Если Active Sessions превышает CPU Cores/CPU Threads, это свидетельствует о проблемах производительности.
Если зафиксирован рост времени отклика операций, но при этом активные сессии не превышают CPU, это значит, что узкое место не в CPU и нужно более детально смотреть, по каким классам события ожидания фиксируется рост, после чего можно на графике нажать на соответствующий класс и провалиться глубже в детализацию (откроется отчет ASH — Active Session History).

Throughput

Раздел Throughput отображает пропускную способность. Пропускная способность базы данных измеряет объем работы, которую база данных выполняет за единицу времени.

Пики на графике Throughput должны соответствовать пикам на графике Average Active Sessions. Если заметен рост времени ожидания, необходимо убедиться, что увеличивается пропускная способность. Если пропускная способность низкая, а время ожидания растет — необходимо изменить настройки БД.

Latency показывает задержку чтения блоков. Это разница между временем выполнения чтения и временем обработки чтения БД. Показатель должен стремиться к нулю.
Оптимальным считается значение до 10 мс. Этот график — основной показатель производительности в этом блоке. Если зафиксирован рост времени задержки, нужно посмотреть, не растет ли количество I/O операций и их вес, также на рост Latency может влиять утилизация CPU.

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

I/O Function

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

Можно выделить следующие категории:

№	Категория	Описание
1	Фоновые процессы	Включают в себя ARCH, LGWR, DBWR (полный список фоновых процессов есть в документации)
2	Активность	XML DB, Streams AQ, Data Pump, Recovery, RMAN
3	Тип I/O	Включает прямую запись и чтение (в том числе чтение из кэша)
4	Другое	Включает операции ввода/вывода управляющих файлов

I/O Type

Выводит статистику по тяжести операций ввода-вывода. Маленькими считаются операции, которые обрабатывают до 128 КБ. К большим операциям ввода-вывода относятся: сканирование таблиц и индексов, прямая загрузка данных, резервное копирование, восстановление и архивирование.

Consumer group

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

Parallel Executions

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

Services

Службы на этом графике представляют собой группы приложений. Отображаются только сессии активных служб, находящиеся в ожидании в определенный момент времени. Например, служба SYS$USERS — это установка пользовательского сеанса.

ASH Report

ASH Report (Active Session History) дает более подробную информацию по потреблению ресурсов. Чтобы перейти к графику, в меню Performance нужно выбрать пункт Performance Hub/ASH Report. Также перейти к ASH Report можно при выборе класса события ожидания на графике Average Active Session.

События ожидания и группы событий ожидания.
Группы пользователей, пользователи, сервисы, инстансы.
SQL-запросы.

AWR (Automatic Workload Repository) дает подробную информацию о процессах, происходящих с БД в определенный период. Для построения AWR-отчета нужно выбрать пункт меню Performance/AWR/AWR Report. Также есть возможность сравнивать два временных промежутка. Для этого нужно выбрать пункт меню Performance/AWR/Compare Period Report.
Ниже будут описаны наиболее показательные разделы AWR-отчета, описание остальных разделов можно поискать в официальной документации.

Load Profile

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

№	Параметр	Описание
1	DB Time(s)	Сумма времени утилизации процессора и время ожидания (без простоя)
2	DB CPU(s)	Нагрузка на процессор
3	Background CPU(s)	Загрузка процессора фоновыми задачами
4	Redo size	Объем чтения
5	Logical reads	Среднее количество логических чтений блоков
6	Block changes	Среднее значение измененных блоков
7	Physical reads	Физическое чтение в блоках
8	Physical writes	Количество записей в блоках
9	Read I/O requests	Количество чтений
10	Write I/O requests	Количество записей
11	Read I/O (MB)	Объем чтения
12	Write I/O (MB)	Объем записей
13	IM scan rows	Количество строк в In-Memory Compression Units (IMCU), которые были доступны
14	Session Logical Read IM	Чтения в In-Memory
15	User calls	Пользовательские вызовы
16	Parses	Разборы
17	Logons	Количество входов
18	Excecutes	Количество вызовов
19	Rollback	Количество откатов данных
20	Transacions	Количество транзакций

Instance Efficiency Percentages

№	Показатель	Критерии
1	Buffer nowait	Если показатель меньше 95%, значит, буферы data block buffer используются неправильно. Возможно, нужно увеличить data block buffer size
2	Buffer Hit	Если показатель меньше 95%, значит, буферы data block buffer используются неправильно. Возможно, нужно увеличить data block buffer size
3	Library cache hit	Если показатель меньше 95% — нужно расширять shared pool (либо причина в bind-переменных)
4	Redo NOWAIT	Если показатель меньше 95%, это говорит о проблеме в redo log buffer или redo log
5	Parse CPU to Parse Elapsd	Показатель должен быть больше или равен 90%, тогда большинство процессов не ожидает ресурсов, что говорит о правильной работе базы данных
6	Non-Parse CPU	Показатель должен приближаться к 100%, это значит, что большинство ресурсов CP используется в различных операциях, кроме parsing, что говорит о правильной работе базы данных. Если Non-Parse CPU низкий, значит, база много времени тратит на разбор запроса вместо реальной работы
7	In-memory sort	Значение меньше 100 говорит о том, что сортировка идет через диск, а также есть потенциальные проблемы с PGA_AGGREGATE_TARGET,SORT_AREA_SIZE,HASH_AREA_SIZE и bitmap setting
8	Soft Parse	Чем он выше, тем меньше у нас Hard Parse
9	Latch Hit	Чем он выше, тем меньше мы ждем Latches (если он низкий — у нас проблемы с CPU-Bound и Latches)

Top 10 Foreground Events by Total Wait Time

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

При анализе необходимо обратить внимание на класс события ожидания. Если wait class System I/O, User I/O или Other, это нормально для БД. Если класс события ожидания Concurrency, это может свидетельствовать о проблемах.
Классы события ожидания можно посмотреть в разделе Wait Classes by Total Wait Time. В разделе находится статистика по классам события ожидания с сортировкой по времени ожидания.

Описание некоторых событий ожидания:

№	Событие ожидания	Описание
1	DB CPU	Отображает процессорное время, затраченное на пользовательские операции над БД. Это событие должно находиться на первом месте списка
2	db file sequential read	Метрика сигнализирует, что пользовательский процесс не находит нужный блок в buffer cache, загружает его с диска в SGA и ждет физического ввода/вывода
3	db file scattered read	Указывает на проблему с фулл-сканами, возможно, нужны индексы
4	read by other session	Может говорить о том, что размер блока слишком большой или задержка (latency) слишком большая
5	enq TX – row lock contention	Событие возникает при ожидании блокировки строки для дальнейшей ее модификации DML-запросом. Если показатель больше 10%, необходимо разбираться в причинах. Более детальную информацию можно посмотреть в разделе Segments by Row Lock Waits, в котором есть сведения о том, какие таблицы были заблокированы и какими запросами
6	DB FILE SEQUENTIAL READ	Если среднее значение параметра больше 100 мс, это может свидетельствовать о том, что диск работает медленно
7	LOG FILE SYNC	Значение AVG WAIT более 20 мс может свидетельствовать о проблемах
8	DB FILE SCATTERED READ	Если это событие выполняется — возможно, имеет смысл создать дополнительные индексы. Для более подробной информации нужно перейти к разделу Segments By Physical Read, в котором находится информация по таблицам и индексам, в которых происходит физическое чтение
9	direct path read temp ИЛИ direct path write temp	Эти события дают информацию по использованию временных файлов
10	Buffer Busy Wait	Событие указывает на то, что несколько процессов пытаются обратиться к одному блоку памяти, то есть пока первый процесс работает с конкретным блоком памяти, остальные процессы находятся в статусе ожидания

Host CPU и Instance CPU

Здесь стоит обратить внимание на %Idle и %Total CPU. Если показатель %Idle низкий, а %Total CPU высокий, это может свидетельствовать о том, что процессор является узким местом.

Foreground Wait Class, Foreground Wait events и Background Wait Events

Показывают классы и события, которые провели в ожидании большего всего. Foreground Wait events дополняет информацию раздела Top 10 Foreground Events By Total Wait Time. Background Wait Events показывает детализацию по событиям ожидания фоновых процессов.

SQL statistics

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

№	Параметр	Описание
1	SQL ordered by Elapsed Time	Топ SQL-запросов по затраченному времени на их выполнение
2	SQL ordered by CPU Time	Топ SQL-запросов по процессорному времени
3	SQL ordered by User I/O Wait Time	Топ SQL-запросов по времени ожидания ввода/вывода для пользователя
4	SQL ordered by Gets	Запросы к БД, упорядоченные по убыванию логических операций ввода/вывода. При анализе стоит учитывать, что для PL/SQL-процедур их количество прочитанных Buffer Gets будет состоять из суммы всех запросов в рамках этой процедуры
5	SQL ordered by Reads	Этот раздел схож с предыдущим: в нем указываются все операции ввода/вывода, наиболее активно физически считывающие данные с жесткого диска. Именно на эти запросы и процессы надо обратить внимание, если система не справляется с объемом ввода/вывода
6	SQL ordered by Physical Reads (UnOptimized)	В этом разделе выводятся неоптимизированные запросы. В Oracle неоптимизированными считаются все запросы, которые не обслуживаются DSFC или Exadata Cell Smart Flash Cache (ECSFC)
7	SQL ordered by Executions	Наиболее часто выполняемые запросы
8	SQL ordered by Parse Calls	Отображает количество попыток разбора SQL-запросов до его выполнения
9	SQL ordered by Sharable Memory	Запросы, занимающие больший объем памяти общего пула SGA
10	SQL ordered by Version Count	Здесь показано количество SQL-операторов экземпляров одного и того же оператора в разделяемом пуле
11	Complete List of SQL Text	Показывает полный SQL-запрос, не только его хэш. В этой таблице можно найти неоптимальные запросы (например, запросы по всем столбцам таблицы «select * from. », запросы с большим количеством «like» и т. п.)

Active Session History (ASH) Report

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

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

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.

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

"Пользователь пользователю рознь" — я всегда это говорю, когда меня спрашивают:

"Как посмотреть список пользователей?"

Собственно, вас какие именно пользователи интересуют?

Есть те, которые работают — так сказать, трудятся в поле лица. А есть "мёртвые души" — те, кто просто числится.

Начнём с тружеников.

Если речь идёт о получении списка работающих пользователей , то надо смотреть список текущих подключений к базе. Делается это под администратором:

Запрос выводит список текущих сессий. Имена работающих пользователей будут выведены в колонке "USERNAME", время подключения в "LOGON_TIME".

Следует заметить, что:

Есть, так называемые, серверные процессы, которые тоже могут инициировать коннект к базе. Чтобы отличить пользовательские сессии от служебных, следует смотреть на значение в колонке "TYPE".

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

Колонка "STATUS" показывает, кто работает именно в данный момент . Значение для таких сессий будет 'ACTIVE'. И надо понимать, что выполнение обычного запроса происходит быстро, как мимолётное мгновение. Хорошо видны только долгоиграющие запросы. Выполните запрос подряд несколько раз — может, что и заметите.

Иногда, смотря на список сессий, у вас может появиться сильное и непреодолимое желание кое-что сделать — не сдерживайте себя. Вот команда для отключения:

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

Внимание! Удаляйте только пользовательские сессии.

Теперь разберёмся со списочным составом пользователей в базе .

Делается это тоже просто. Вводим следующий запрос:

Как пополнить этот список новыми членами и как удалить неугодных пользователей, я рассказывал в этом посте —

P.S. И не забывайте про команду desc в SQL*Plus. В v$session и dba_users есть много интересных колонок.