Получите перечень текущих соединений с инстансом oracle
Обновлено: 04.07.2024
- Главная /
- Статьи /
- Oracle /
- RMAN в примерах - Быстрый старт. Глава 1.
Практическое администрирование Oracle - Экземпляр - Уничтожение сеансов
С еанс – это специфическое соединение пользователя к экземпляру Oracle через пользовательский процесс. При работе с выделенным сервером для каждого такого сеанса создается отдельный серверный процесс. Обмен пользователя с экземпляром базы данных происходит через пользовательский процесс на клиентской машине, который в свою очередь через драйвер клиента Oracle Net работает с выделенным серверным процессом, взаимодействующим непосредственно с самим экземпляром Oracle. Иногда возникают ситуации, когда требуется уничтожить какие либо сеансы. Такое обычно такое происходит, когда требуется прервать долго выполняющийся сеанс или возникает необходимость в проведении административных работ с отключением всех сеансов. Так же может понадобиться и просто откатить незафиксированную транзакцию, если за данным сеансом выстроилась большая очередь. Бывают и так называемые “потерянные сеансы”, нуждающиеся в уничтожении. В этой главе мы научимся идентифицировать такие сеансы, уничтожать их, а так же рассмотрим сложности, возникающие при этом процессе.
Идентифицируем сеанс
Параметры получены. Теперь можно приступить к уничтожению сеанса.
Уничтожаем неактивный сеанс
Выполним команду ALTER SYSTEM KILL SESSION для указанного выше сеанса:
Посмотрим состояние сеанса:
Если сеанс неактивный и не содержит незавершенных транзакций, то он помечается со статусом KILLED . Поле PADDR уже не указывает на адрес структуры выделенного серверного процесса. Но серверный процесс не освобождается:
Информация при этом о сеансе из представления v$session исчезает:
Но остаётся в таблице x$ksuse:
Серверный процесс при этом всё ещё существует:
Если пользователь продолжит пытаться выполнять команды, то экземпляр на все дальнейшие попытки будет отвечать ошибкой ORA-01012: not logged on:
В дальнейшем серверный процесс будет уничтожен только в том случае, если пользователь предпримет попытку сам разорвать соединение. Только в этом случае процесс уничтожения сеанса можно считать законченным.
Уничтожаем сеанс с незафиксированными транзакциями
Если в сеансе имеются незафиксированные транзакции, то при выдаче команды ALTER SYSTEM KILL SESSION происходит откат этих транзакций. Занимается откатом мертвых транзакции фоновый процесс Oracle SMON . Убедимся в этом, выполнив следующий пример:
Теперь попытаемся уничтожить этот сеанс:
Сеанс уничтожается, не дожидаясь окончания отката транзакции. Через некоторое время в каталоге, определяемом параметром background_dump_dest, появится трассировочный файл процесса SMON, который будет содержать строку примерно следующего вида:
Это означает, что мёртвая транзакция 0x0006.00a.00000091 была восстановлена процессом SMON. Если же в экземпляре используется параллельное восстановление, то функции отката берёт на себя вновь образующийся от SMON дочерний процесс. Его можно увидеть, если выполнить следующий запрос сразу после уничтожения сеанса:
Выбрано: 1 строка
В данном случае трассировочного файла не образуется, но в журнальном файле Oracle появляется запись вида о попытке параллельного восстановления:
Так как фоновый процесс SMON обладает низким приоритетом обработки, то при большой загрузке он может длительное время откатывать транзакции. Поэтому надо с осторожностью уничтожать такие сеансы.
Уничтожаем серверный процесс
Иногда бывает, что пользовательское приложение завершается аварийно, вместе с ним аварийно завершается и пользовательский процесс. К примеру, отключите сеть, выгрузите приложение, затем снова включите сеть. Для того чтобы уничтожить такие сеансы, Oracle с периодичностью в минутах задаваемой параметром sqlnet.expire_time, который находится в файле sqlnet.ora посылает по всем соединениям пустые пакеты, которые игнорируются работающими пользовательскими процессами. Если физического соединения нет, то Oracle помечает сеанс как убитый и приступает к его уничтожению. В некоторых случаях данный механизм не срабатывает, и возникают так называемые “потерянные сеансы”, то есть сеансы не связанные с пользовательскими процессами. Такие сеансы могут находиться в неопределённом состоянии долгое время. Обычно они легко уничтожаются с помощью команды ALTER SYSTEM KILL SESSION. Но если выполнение команды не приносит результатов, и сеанс продолжает долгое время, находится в статусе KILLED, то придется вмешаться в уничтожение такого сеанса на уровне операционной системы, то есть уничтожить серверный процесс средствами ОС. Операция эта опасная и делать её надо очень аккуратно, чтобы случайно не уничтожить фоновые процессы экземпляра. Для этого желательно всегда запоминать значение идентификатора SPID серверного процесса относящегося к сеансу. Если же значение поля PADDR в представлении v$session уже не соотноситься с адресом в поле ADDR представления v$process , то серверный процесс придется искать приблизительно. В Unix это можно сделать с помощью команды ps , примерно сравнивая время соединения сеанса в поле logon_time представления v$session со временем образования процесса в колонке STARTED результата выполнения команды ps.
В системе Windows сеансы существуют в виде потоков. Поэтому определить такой сеанс будет сложнее. Чтобы облегчить задачу можно выполнить запрос к представлению v$process, который покажет все процессы, у которых значения поля ADDR не соответствует ни одному значению в поле PADDR представления v$session:
Здесь мы видим такой процесс со значением идентификатора процесса в операционной системы SPID равным 652. Попробуем уничтожить данный серверный процесс. В системе Windows это делается с помощью утилиты командной строки orakill:
В Unix с помощью команды kill -9 spid .
Уничтожаем активный сеанс
У нас есть приложение, работающее локально, где мы видим следующую ошибку:
ORA-12514: TNS: слушатель в настоящее время не знает об услуге, запрошенной в дескрипторе соединения
Я протестировал соединение, TNSPing которое было разрешено правильно, и попытался SQLPlus установить соединение, которое не удалось с той же ошибкой, что и выше Я использовал этот синтаксис для SQLPlus :
Мы убедились, что:
- прослушиватель TNS на сервере работает.
- Сам Oracle на сервере работает.
Мы не знаем о каких-либо изменениях, которые были сделаны в этой среде. Что-нибудь еще мы можем проверить?
Какую команду TNSPing (с параметрами) вы использовали? когда вы говорите «работает локально», вы имеете в виду, что приложение подключается к базе данных на том же хосте? Кроме того, каково содержимое вашего файла sqlnet.ora? какие версии указаны для sqlplus и tnsping, и вы уверены, что они находятся в одном и том же ORACLE_HOME? попробуйте перезапустить базу данных. Так как они должны сообщить Слушателю об их существовании при запуске, это может решить вашу проблему. ALTER SYSTEM REGISTER менее радикальна, чем перезапуск базы данных.У меня возникла эта проблема, и исправление состояло в том, чтобы убедиться, что в вашей базе данных tnsnames.ora указано SERVICE_NAME правильное имя службы. Чтобы узнать действительные имена сервисов, вы можете использовать следующий запрос в Oracle:
Однажды я обновился tnsnames.ora до:
тогда я побежал:
Успех! Слушатель в основном говорит вам, что какое бы имя_службы вы не использовали, оно не является действительным сервисом в соответствии с БД.
(* Я запускал sqlplus с клиентской рабочей станции Win7 на удаленную БД и обвинял администраторов БД;) *)
Как я могу запросить БД, если я не могу даже подключиться к ней? Можете ли вы напрямую подключиться к серверу БД и запустить оттуда sqlplus? это может быть не тот случай, когда несколько клиентов / серверов установлены или использовались для установки на одном компьютере. (tnsping выводит местоположение каталога, который он использует) - в моем случае, listener.ora в этом каталоге содержал информацию, относящуюся к старому экземпляру базы данных, который я удалил - быстрым и грязным способом было скопировать все содержимое listener.ora из моя текущая установка Oracle Express в этот другой каталог, который слушатель, кажется, проверяет (я думаю, что я изменил его через реестр или что-то в этом роде, и он имеет приоритет над ORACLE_HOME (?))Я знаю, что это старый вопрос, но все еще без ответа. Это заняло у меня целый день исследований, но я нашел самое простое решение, по крайней мере, в моем случае (Oracle 11.2 в Windows 2008 R2) и хотел поделиться им.
Ошибка, если смотреть непосредственно, указывает, что слушатель не распознает имя службы. Но где он хранит названия сервисов? В %ORACLE_HOME%\NETWORK\ADMIN\listener.ora
«SID_LIST» - это просто список SID и имен сервисов в паре в формате, который вы можете скопировать или найти.
Я добавил проблему Service Name, затем в панели управления Windows «Службы» произвел «Перезапуск» в службе прослушивания Oracle. Теперь все хорошо.
Например, ваш файл listener.ora может изначально выглядеть так:
. И чтобы он распознал имя службы orcl , вы можете изменить его на:
vapcguy, вы должны быть на сервере базы данных. Похоже, вы на клиенте Следуя инструкциям Sepideh, касающимся сетевого менеджера, я заметил, что мой файл listeners.ora был обновлен и теперь содержит новую запись SID_LIST. Я отредактировал этот ответ, чтобы включить пример синтаксиса «до и после» для читателей, которые по какой-либо причине не могут использовать Net Manager.У меня была эта проблема на Windows Server 2008 R2 и Oracle 11g
перейдите в Net Manager> Слушатель> выберите службы баз данных из поля со списком> «Глобальное имя базы данных» должно совпадать с «SID», а «Oracle Home Directory» должен быть правильным.
Если у вас нет записей для служб баз данных, создайте их и задайте правильную глобальную базу данных sid и oracle home.
Мой дескриптор в tnsnames.ora :
Итак, приступаю к регистрации сервиса в listener.ora ручном режиме:
Наконец, перезапустите слушатель по команде:
Запуск OracleServiceXXX из services.msc работал для меня в Windows.
В Windows, если вы используете Oracle Release 12.x, убедитесь, что служба OracleServiceORCL запущена. Если эта служба не запущена, то вы также получите тот же код ошибки.Это действительно должен быть комментарий к ответу Брэда Риппе , но, увы, недостаточно реп. Этот ответ дал мне 90% пути туда. В моем случае установка и настройка баз данных помещают записи в файл tnsnames.ora для баз данных, которые я запускал. Во-первых, я смог подключиться к базе данных, установив переменные среды (Windows):
а затем подключение с помощью
Далее запустим команду из ответа Брэда Риппе:
показал, что имена не совпадают точно. Записи, созданные с помощью Oracle Database Configuration Assistant, где изначально:
Я перезапустил службу прослушивателя TNS (я часто использую lsnrctl stop и lsnrctl start из командного окна администратора [или Windows Powershell] вместо панели управления службами, но оба работают.) После этого я смог подключиться.
У меня такая же проблема. Для меня просто пишу
сделал трюк, делая так, он подключается к имени службы по умолчанию, я думаю.
У нас была похожая проблема с нашей строкой соединения, вызывающая эту ошибку. Мы подключали с помощью тонкого драйвера Oracle, JDBC со строкой подключения: jdbc:oracle:thin:@//localhost:1521/orcl . Скорректированная строка подключения , чтобы устранить эту ошибку было: jdbc:oracle:thin:@localhost:1521 . это зависит от того, сработает ли это - я думаю, что этот способ подключения, судя по тому, что говорили другие, полностью обходит слушателя, используя имя хоста компьютера вместо SID - этот способ подключения вызывает проблемы у сторонних клиентов, - я думаю, это также работает, только когда EZCONNECT указан в sqlnet.ora: NAMES.DIRECTORY_PATH = (TNSNAMES, EZCONNECT)То, что работало для меня, было действительно простым, мне просто нужно было вручную запустить службу в «Службах Windows» (services.msc в cmd trompt). мое сервисное имя: OracleServiceXXXXX.
В моем случае, хотя Тип запуска установлен на Автоматический, он не запускается при загрузке компьютера. После запуска вручную службы «OracleServiceXE» она работает с Oracle Database 11g Express для подключения к БД и веб-странице APEX (Oracle Application Express).Проверьте, что база данных работает. Войдите на сервер, задайте для переменной среды ORACLE_SID SID базы данных и запустите SQL * Plus в качестве локального соединения.
Это была именно моя проблема. Наша база данных размещена на виртуальной машине, которая была недоступна, когда я пытался использовать другую программу, которая использовала DP. После просмотра этой темы я понял, что это, вероятно, было вниз.Эта ошибка может возникать, когда приложение устанавливает новое соединение для каждого взаимодействия с базой данных или соединения не закрываются должным образом. Одним из бесплатных инструментов для мониторинга и подтверждения этого является Oracle Sql developer (хотя это не единственный инструмент, который вы можете использовать для мониторинга сеансов БД).
Вы можете скачать инструмент с сайта оракула Sql Developer
Вот скриншот того, как следить за вашими сессиями. (если вы видите много сессий, накапливающихся для пользователя вашего приложения во время, когда вы видите ошибку ORA-12514, то это хороший признак того, что у вас может быть проблема с пулом соединений).
Я решил эту проблему в своей среде linux, обновив IP-адрес моей машины в файле / etc / hosts.
Вы можете проверить свой сетевой IP (inet end.) С помощью:
Посмотрите, совпадает ли ваш IP с файлом / etc / hosts:
Отредактируйте файл / etc / hosts, если он подключен:
это старый, но нет смысла добавлять ваш IP в / etc / hosts. ОП отсутствует SERVICE_NAME, другие вещи совершенно не связаныДля тех, кто может использовать Oracle на виртуальной машине (например, я), я видел эту проблему, потому что моей виртуальной машине не хватало памяти, что, по-видимому, препятствовало правильному запуску / запуску OracleDB. Увеличение моей виртуальной памяти и перезапуск исправили проблему.
Для меня ошибка 12514 была решена после указания правильного SERVICE_NAME. Вы обнаружите, что на сервере в файле, tnsnames.ora который поставляется с 3 предопределенными именами служб (одно из них «XE»).
Если SERVICE_NAME=XE вы ошиблись, вы получите ошибку 12514. Это SERVICE_NAME необязательно. Вы также можете оставить это в стороне.
Большое спасибо, из вашего решения я нашел хитрость, в моем случае это был антивирус, который блокировал программу, и поэтому не смог получить соединение с Oracle db.Я также столкнулся с той же самой проблемой и потратил 3 дня, чтобы выкопать это.
Это происходит из-за неправильного входа в службу TNS.
Сначала проверьте, можете ли вы подключиться к резервной базе данных из первичной базы данных, используя sql> sqlplus sys@orastand as sysdba ( orastand резервная база данных).
Если вы не можете подключиться, то это проблема с сервисом. Исправьте запись имени службы в файле TNS на первичном конце.
Проверьте резервную базу данных таким же образом. Внесите изменения и здесь, если требуется.
Привет! Меня зовут Александра, я работаю в команде тестирования производительности. В этой статье расскажу базовые сведения об 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 оператора.
В том числе: Проверьте состояние экземпляра Oracle, проверьте процесс обслуживания Oracle, проверьте процесс мониторинга Oracle, всего три части.
1.1 Проверьте состояние экземпляра Oracle
Среди них «STATUS» указывает текущее состояние экземпляра Oracle, которое должно быть «OPEN», «DATABASE_STATUS» указывает текущее состояние базы данных Oracle, которое должно быть «ACTIVE».
1.2 Проверка состояния журнала онлайн Oracle
Выходной результат должен иметь более 3 записей (включая 3) записи, «STATUS» должен быть не «INVALID», не «DELETED». Примечание: «СТАТУС» пуст для обозначения нормального.
1.3 Проверьте состояние табличного пространства Oracle
СОСТОЯНИЕ должно быть ОНЛАЙН на выходе.
1.4 Проверьте состояние всех файлов данных Oracle
«STATUS» на выходе должно быть «ONLINE». или:
«STATUS» на выходе должно быть «ДОСТУПНО».
1.5 Проверка на недействительные объекты
Если запись возвращается, это означает, что существует недопустимый объект. Если эти объекты связаны с приложением, вам нужно перекомпилировать его для создания или:
1.6 Проверьте состояние всех сегментов отката
«СОСТОЯНИЕ» всех сегментов отката на выходе должно быть «ОНЛАЙН».
2. Проверьте использование ресурсов, связанных с Oracle
содержать:
А. Проверьте значения соответствующих параметров в файле инициализации Oracle.
б. Проверьте подключение к базе данных и проверьте место на системном диске.
В. Проверьте использование различных табличных пространств Oracle, проверьте некоторые объекты с ненормальными расширениями,
г. Проверьте содержимое системного табличного пространства, проверьте следующее расширение объекта и максимальное значение расширения табличного пространства, всего семь частей.
2.1 Проверьте значения соответствующих параметров в файле инициализации Oracle
Если LIMIT_VALU-MAX_UTILIZATION <= 5, это означает, что параметры инициализации Oracle, связанные с RESOURCE_NAME, должны быть скорректированы. Можно изменить, изменив файл параметров инициализации Oracle $ ORACLE_BASE / admin / CKDB / pfile / initORCL.ora.
2.2. Проверка соединения с базой данных
Проверьте, находится ли текущий номер подключения сеанса в пределах нормального диапазона.
Среди них: SID сеанса (сеанса), идентификационный номер;
USERNAME - имя пользователя, с которого был установлен разговор;
Какой инструмент используется для сеанса PROGRAM для подключения к базе данных;
STATUS Текущее состояние этого сеанса. ACTIVE означает, что сеанс выполняет определенные задачи. INACTIVE означает, что текущий сеанс не выполняет никаких операций.
Если установлено слишком много подключений, это потребляет ресурсы базы данных. В то же время некоторые «зависшие» подключения, возможно, придется очистить вручную. Если администратор базы данных хочет отключить сеанс вручную, выполните:
(Обычно не рекомендуется использовать этот метод для разрыва соединения с базой данных, поэтому иногда сеанс не будет отключен. Легко вызвать прерывание соединения. Рекомендуется проверить spid операционной системы через sid и использовать ps –ef | grep spidno для подтверждения spid Не фоновый процесс ORACLE. Используйте команду kill -9 операционной системы, чтобы разорвать соединение)
Примечание. В приведенном выше примере сеансы с SID от 1 до 10 (столбец USERNAME пуст) являются фоновыми процессами Oracle и не выполняют никаких операций в этих сеансах.
2.3 Проверьте место на системном диске
Если оставшееся пространство файловой системы слишком мало или увеличивается быстрее, вам необходимо подтвердить его и удалить неиспользуемые файлы, чтобы освободить место.
Filesystem Size Used Avail Use% Mounted on
/dev/sda5 9.7G 3.9G 5.4G 42% /
/dev/sda1 479M 16M 438M 4% /boot
/dev/sda2 49G 19G 28G 41% /data
none 1014M 0 1014M 0% /dev/shm
2.4 Проверьте использование табличного пространства
select f.tablespace_name,
a.total,
f.free,
round((f.free / a.total) * 100) "% Free"
from (select tablespace_name, sum(bytes / (1024 * 1024)) total
from dba_data_files
group by tablespace_name) a,
(select tablespace_name, round(sum(bytes / (1024 * 1024))) free
from dba_free_space
group by tablespace_name) f
WHERE a.tablespace_name = f.tablespace_name(+)
order by "% Free";
Если процент простоя% Free составляет менее 10% (включая 10%), обратите внимание на увеличение файла данных для расширения табличного пространства вместо использования функции автоматического расширения файла данных. Пожалуйста, не добавляйте слишком много файлов данных в табличное пространство.Принцип увеличения файлов данных заключается в том, что размер каждого файла данных составляет 2G или 4G, а максимальное ограничение для автоматического расширения составляет 8G.
2.5 Проверьте некоторые расширенные ненормальные объекты
Если запись возвращается, расширение этих объектов почти достигло максимального значения расширения, когда оно было определено. Для этих объектов необходимо изменить параметры его структуры хранения.
2.6 Проверка содержимого системного табличного пространства
Если запись возвращается, это указывает на то, что в системном табличном пространстве есть некоторые не системные и системные пользовательские объекты. Далее следует проверить, относятся ли эти объекты к нашему приложению. Если это уместно, переместите эти объекты в несистемное табличное пространство, и вам следует проверить значение табличного пространства по умолчанию для владельца этих объектов.
2.7 Проверьте следующее расширение объекта и максимальное значение расширения табличного пространства
Если запись возвращается, это указывает, что следующее расширение этих объектов больше, чем максимальное значение расширения табличного пространства, к которому принадлежит объект, и параметры хранения соответствующего табличного пространства должны быть скорректированы.
3. Проверьте результаты резервного копирования базы данных Oracle
содержать:
a. Проверьте информацию журнала резервного копирования базы данных;
б. Проверьте время создания файлов в томе резервной копии;
c. Проверьте электронную почту пользователя оракула.
3.1. Проверьте информацию журнала резервного копирования базы данных
Предположение: временный каталог для резервного копирования - / backup / hotbakup, нам нужно проверить результат резервного копирования 22 июля 2009 года, а затем использовать следующую команду для проверки:
cat /backup/hotbackup/hotbackup-09-7-22.log|grep –i error
Файл журнала сценария резервного копирования - hotbackup-month-date-year.log, находящийся во временном каталоге резервного копирования. Если в файле есть «ОШИБКА:», это означает, что резервное копирование не было успешным, и существует проблема, которую необходимо проверить.
3.2 Проверьте время создания файлов в томе резервной копии
Том резервной копии является временным каталогом для резервного копирования. Дата просмотра файла в результате вывода должна быть сгенерирована сценарием горячего резервного копирования ранним утром того же дня. Если время указано неверно, это означает, что сценарий горячего резервного копирования не был успешно выполнен.
3.3 Проверьте электронную почту пользователя оракула
4. Проверьте производительность базы данных Oracle
В этом разделе мы в основном проверяем производительность базы данных Oracle, в том числе: проверяем события ожидания базы данных, проверяем взаимоблокировки и обработку, проверяем процессор, ввод-вывод, производительность памяти, проверяем, существует ли процесс взаимоблокировки, проверяем связь / перенос строк и регулярно выполняем статистический анализ , Проверьте частоту попаданий в буфер, проверьте частоту попаданий в общий пул, проверьте область сортировки, проверьте буфер журнала, всего десять частей.
4.1. Проверка базы данных на события ожидания
Если в базе данных много событий ожидания, таких как освобождение защелки, постановка в очередь, ожидание занятости буфера, последовательное чтение файла db, чтение файла db, разбросанное по разным данным и т. Д., В течение длительного времени, их необходимо проанализировать, и могут возникнуть проблемные утверждения.
4.2 Получить оператор SQL с самым высоким показанием диска
4.3. Найти десятку плохо работающих SQL
4.4 Пять систем с наибольшим временем ожидания ждут сбора событий
4.5 Проверка долгосрочного SQL
4.6. Проверьте процесс, который потребляет больше всего процессора
4.7 Проверьте таблицы с высокой фрагментацией
4.8 Проверьте соотношение ввода-вывода в табличном пространстве
4.9 Проверьте соотношение ввода / вывода файловой системы
4.10 Проверка на тупик и обработку
Запрос информации о текущем объекте блокировки:
Уровень Oracle убивает сессию:
Сеанс уничтожения на уровне операционной системы:
5. Проверьте базу данных процессора, ввода-вывода, производительность памяти
Запишите использование ЦП, ввода-вывода, памяти и т. Д. Базы данных, используйте команды vmstat, iostat, sar, top и другие для сбора информации и проверки информации для определения использования ресурса.
5.1 Использование процессора:
top - 10:29:35 up 73 days, 19:54, 1 user, load average: 0.37, 0.38, 0.29
Tasks: 353 total, 2 running, 351 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.2% us, 0.1% sy, 0.0% ni,98.8% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 16404472k total, 12887428k used, 3517044k free, 60796k buffers
Swap: 8385920k total, 665576k used, 7720344k free, 10358384k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
30495 oracle 15 0 8329m 866m 861m R 10 5.4 7:53.90 oracle
32501 oracle 15 0 8328m 1.7g 1.7g S 2 10.6 1:58.38 oracle
32503 oracle 15 0 8329m 1.6g 1.6g S 2 10.2 2:06.62 oracle
Обратите внимание на синий шрифт выше, эта часть представляет оставшийся ЦП системы. Когда среднее значение падает ниже 10%, это рассматривается как ненормальное использование ЦП. Вам необходимо записать это значение и записать состояние как ненормальное.
5.2 Использование памяти:
total used free shared buffers cached
Mem: 2026 1958 67 0 76 1556
-/+ buffers/cache: 326 1700
Swap: 5992 92 5900
Как показано выше, синяя часть представляет общую память системы, красная часть представляет память, используемую системой, а желтая часть представляет оставшуюся память системы. Когда оставшаяся память составляет менее 10% от общей памяти, она считается ненормальной.
5.3 Ситуация с системным вводом / выводом:
Linux 2.6.9-22.ELsmp (AS14) 07/29/2009
avg-cpu: %user %nice %sys%iowait %idle
0.16 0.00 0.05 0.36 99.43
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 3.33 13.16 50.25 94483478 360665804
avg-cpu: %user %nice %sys%iowait %idle
0.00 0.00 0.00 0.00 100.00
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 0.00 0.00 0.00 0 0
Как показано выше, синий шрифт указывает состояние чтения и записи диска, а красный шрифт указывает состояние ожидания ввода-вывода ЦП.
5.4 Системная нагрузка:
12:08:37 up 162 days, 23:33, 15 users, load average: 0.01, 0.15, 0.10
Как показано выше, синий шрифт обозначает нагрузку на систему. Если следующие три значения превышают 2,5, это указывает на то, что система работает при перегрузке. Запишите это значение в таблицу проверки и сочтите его ненормальным.
5.5 Проверьте, есть ли процесс зомби
Некоторые процессы зомби блокируют нормальную работу других сервисов и регулярно убивают процессы зомби.
5.6 Проверьте ссылку на линию / миграцию
Примечание. Обычно таблица с длинными необработанными столбцами имеет ссылку на строку, находит строку миграции и сохраняет ее в таблице chained_rows. Если такой таблицы нет, выполните ее.
Вы можете увидеть, какие строки являются перенесенными строками по таблице имя_хеда, head_rowid в таблице chained_rows
5.7 Регулярный статистический анализ
Для системы, использующей Oracle Cost-Based-Optimizer, необходимо регулярно собирать и обновлять статистическую информацию объектов данных, чтобы оптимизатор мог составить правильный план объяснения на основе подготовленной информации. Статистическая информация должна обновляться в следующих ситуациях:
а. Изменения в приложении
б. Масштабная миграция данных, миграция исторических данных, импорт других данных и т. д.
C. Количество данных изменилось
Проверьте, нужно ли обновлять статистику таблицы или индекса, например:
Если количество строк сильно отличается, таблица должна обновлять статистическую информацию, поэтому рекомендуется собирать статистическую информацию раз в неделю, например:
5.8 Проверьте частоту попаданий в буфер
Если частота попаданий ниже 90%, вам нужно увеличить параметр базы данных db_cache_size.
5.9 Проверка коэффициента попадания в общий пул
Если оно ниже 95%, вам необходимо настроить приложение для использования переменных связывания или настроить размер общего пула параметров базы данных.
5.10 Проверьте область сортировки
Если отношение диск / (памятка + строка) слишком велико, вам нужно настроить sort_area_size (workarea_size_policy = false) или pga_aggregate_target (workarea_size_policy = true).
5.11 Проверьте буфер журнала
Если повторное размещение буфера повторных попыток / повторных записей превышает 1%, вам нужно увеличить log_buffer.
6. Проверьте безопасность базы данных
В этом разделе мы в основном проверяем безопасность базы данных Oracle, в том числе: проверяем информацию о безопасности системы, регулярно меняем пароль, всего две части.
6.1 Проверьте информацию журнала безопасности системы
Каталог файла журнала безопасности системы находится в / var / log, который в основном проверяет информацию журнала пользователя об успешном или неудачном входе в систему.
Проверьте журнал успешного входа в систему:
Jan 8 08:44:43 rac2 sshd[29559]: Accepted password for root from ::ffff:10.10.10.6 port 1119 ssh2……
Проверьте журнал неудачного входа в систему:
Jan 9 10:30:44 rac2 sshd[3071]: Invalid user ydbuser from ::ffff:192.168.3.5
Jan 9 10:30:56 rac2 sshd[3071]: Failed password for invalid user ydbuser from ::ffff:192.168.3.5 port 36005 ssh2
Jan 9 10:30:56 rac2 sshd[3071]: Failed password for invalid user ydbuser from ::ffff:192.168.3.5 port 36005 ssh2
Jan 10 22:44:38 rac2 sshd[21611]: Failed password for root from ::ffff:10.10.10.6 port 1723 ssh2
6.2 Проверьте пользователя, чтобы сменить пароль
В системе баз данных часто бывает много пользователей, таких как: сторонние системы мониторинга баз данных, демонстрационные пользователи во время первоначальной установки базы данных, пользователи-администраторы и т. Д. Пароли этих пользователей часто пишутся, и многие люди знают, что они будут скрытыми мотивами. Люди привыкли атаковать систему и даже изменять данные. В число пользователей, которым необходимо изменить свои пароли, входят:
Пользователи администратора базы данных SYS, SYSTEM; другие пользователи.
После входа в систему введите cat / etc / passwd в командной строке, чтобы проверить, есть ли среди перечисленных пользователей неиспользуемые или странные учетные записи. Если он существует, он записывается как ненормальный.
Метод изменения пароля:
7. Другие проверки
В этом разделе мы в основном проверяем, является ли текущая задача crontab нормальной и не сработала ли работа Oracle. Существует шесть частей.
7.1 Проверьте, является ли текущая задача crontab нормальной
7.2 Сбой работы Oracle
Если есть проблемы, рекомендуется перестроить задание, например:
7.3. Контролировать рост объема данных
Согласно ежедневной проверке на этой неделе, найдите объекты базы данных с быстро расширяющимся пространством и примите соответствующие меры:
- Удалить исторические данные
Мобильные правила предусматривают, что в базе данных должно храниться не менее 6 месяцев исторических данных, поэтому предыдущие исторические данные можно рассмотреть для резервного копирования, а затем очистить, чтобы освободить занимаемое ими пространство ресурса.
--- Расширить табличное пространство
Примечание: При изменении структуры базы данных, такой как добавление табличного пространства, добавление файлов данных или файлов журнала повторов, эти операции вызовут изменения в контрольном файле базы данных Oracle. Администратор базы данных должен создать резервную копию контрольного файла. Метод резервного копирования:
Выполнить оператор SQL:
Таким образом, команда SQL для создания управляющего файла будет сгенерирована в каталоге USER_DUMP_DEST (указан в файле параметров инициализации).
7.4 Проверка на неуспешные индексы
Примечание. Обычно состояние индекса в таблице разделов равно N / A. Если индекс не выполнен, перестройте его, например:
(ORACLE SID = ora816)
При подключении к выделенному серверу процесс прослушивания автоматически запустит выделенный сервер. В ОС UNIX это делается с помощью системных вызовов fork() и ехес() (единственный способ создать новый процесс после инициализации ОС UNIX - использовать системный вызов iork()). Теперь мы физически подключены к базе данных. В Windows процесс прослушивания требует от серверного процесса создания нового потока для подключения. После создания этого потока клиент перенаправ-
ляется на него, и тем самым обеспечивается физическое подключение. В случае ОС UNIX это можно представить следующей схемой:
В режиме MTS процесс прослушивания работает иначе. Ему известно, какие процессы-диспетчеры работают в составе экземпляра. При получении запроса на подключение процесс прослушивания выбирает процесс-диспетчер из пула доступных диспетчеров. Затем он посылает клиенту информацию, позволяющую подключиться к процессу-диспетчеру. Это необходимо, поскольку процесс прослушивания работает на известном порту соответствующего хоста, а вот диспетчеры будут принимать подключения через произвольно выделенные порты. Процессу прослушивания известны эти выделенные порты, поэтому он автоматически выбирает свободный диспетчер. Затем клиент отключается от процесса прослушивания и подключается непосредственно к диспетчеру. В результате устанавливается физическое соединение с СУБД. Графически это можно представить так:
Итак, обзор архитектуры Oracle закончен. Мы описали, что такое экземпляр Oracle, что такое база данных и как можно подключиться к базе данных через выделенный и разделяемый сервер. На следующей схеме показано взаимодействие с сервером Oracle клиента, подключенного к разделяемому серверу, и клиента, работающего с выделенным серверным процессом. Один экземпляр Oracle может поддерживать оба типа подключений одновременно:
Теперь подробно рассмотрим процессы, образующие сервер, их назначение и взаимодействие друг с другом, а также содержимое области SGA и назначение ее компонентов. Но начнем мы с описания различных типов файлов, которые сервер Oracle использует для управления данными.
В состав базы данных и экземпляра входит шесть типов файлов. С экземпляром связаны файлы параметров. По этим файлам экземпляр при запуске определяет свои характеристики, например размер структур в памяти и местонахождение управляющих файлов.
Базу данных образуют следующие файлы.
Файл1 данн1х. Собственно данные (в этих файлах хранятся таблицы, индексы и
все остальные сегменты).
Файл1 журнала повторного в1полнения. Журналы транзакций.
Управляющие файл1. Определяют местонахождение файлов данных и содержат другую необходимую информацию о состоянии базы данных.
Временн1е файл1. Используются при сортировке больших объемов данных и для хранения временных объектов.
Файл1 паролей. Используются для аутентификации пользователей, выполняющих
администрирование удаленно, по сети. Мы не будем их подробно рассматривать.
Наиболее важны первые два типа файлов, поскольку именно в них хранятся накопленные данные. В случае потери остальных файлов хранящиеся данные не пострадают. Если будут потеряны файлы журнала повторного выполнения, некоторые данные могут быть потеряны. Если же будут потеряны файлы данных и все их резервные копии, данные, безусловно, будут потеряны навсегда.
Читайте также: