Сентябрь 2005
Профессионалу администратору
Аруп Нанда
Наиболее важные возможности для АБД
Oracle Database 10g: Выпуск 2 - Дополнительные свойства
(Oracle Database 10g: Top Features for DBAs
Release 2 Features Addendum,
by Arup Nanda, Oracle ACE)
Часть 3: Особенности производительности
Источник: сайт корпорации Oracle, раздел “Технологические статьи” (Technical Articles), 01 июля 2005,
http://www.oracle.com/technology/pub/articles/10gdba/nanda_10gr2dba_part3.html
Аруп Нанда, Oracle ACE, представляет свой список наиболее важных новых возможностей для администраторов баз данных.
Ранее на русском языке в журнале “Oracle Magazine/Русское Издание” опубликованы:
Открывает этот список зависший запрос в памяти SGA
(любимая особенность Arup Nanda в выпуске 2)
, но также неотразимы и управление статистикой оптимизатора, и новый отчет "сравнение периодов" сообщение, и другие новые особенности.
Содержание этого выпуска:
- *Зависший, но непарализованный: неподвижный запрос в памяти SGA
- *Прерывание выполнения SQL Access Advisor
- *Проверка Включения Трассировки
- *Хронология Активности Сессий
- *Управление Статистикой Оптимизатора
- *Транспортировка AWR-Данных
- *Сравнение Отчетов по Периодам
Зависший, но непарализованный: неподвижный запрос в памяти SGA
(Hung But Not Paralyzed: Memory-Attached SGA Query)
Давайте предположим, что вы используете Oracle Enterprise Manager, чтобы диагностировать и разрешить проблемы производительности. Однажды возникает противная проблема: плохо разработанное приложение является причиной серьезных блокировок библиотечного кэша, и кажется, что база данных зависла. Вам нужно быстро идентифицировать и уничтожить сессии виновника.
Можно запустить Oracle Enterprise Manager, чтобы продиагностировать эту проблему. Но, подождите! Если взятая в целом база данных насыщена зависшими сессиями, то не зависнет ли тоже запуск Oracle Enterprise Manager?
База данных Oracle Database 10g выпуск 2 отвечает: "Нет". Как я объяснил в части 2 http://www.oracle.com/technology/pub/articles/10gdba/nanda_10gr2dba_part2.html в этом выпуске опция "Monitor in Memory Access Mode" (Мониторинг в Режиме Доступа к памяти) позволяет Enterprise Manager выбирать сессии непосредственно из памяти SGA, а не из представления V$SESSION. Следовательно, поскольку в этом режиме обходится уровень SQL, зависшая база данных не препятствует выполниться этому запросу. И запрос выполняется автоматически.
Давайте посмотрим, как это работает. На экране Enterprise Manager выберем закладку Performance (Производительность) и сделаем прокрутку вниз до основания страницы к разделу, обозначенному "Additional Monitoring Links" (Дополнительный мониторинг ссылок), который выдаст экран, подобный тому, что показан ниже.
Обратите внимание, что гиперссылка с именем "Hang Analysis" (Анализ зависаний) окружена красным овалом [Овала я не заметил, но ссылка есть – прим. А.Бачин]. По щелчку открывается экран, подобный показанному ниже.
Здесь видна карта различных застывших (frozen) сессий. В этом примере можно увидеть, что сессия с идентификатором (SID) 193, корневая сессия [блокировки], заблокировала две другие сессии - 192 и 214. Цвет сессий на карте показывает, как долго сессии, возможно, были блокированы. Можно кликнуть по любому из SID, чтобы получить более подробную информацию, которую доставит экран Session Details (детали по сессии).
Помните утилиту ORADEBUG? Oracle Enterprise Manager получает данные о зависаниях системы, используя эту же самую утилиту. Когда вы применяете прямое соединение с SGA, Oracle использует отдельный SQL-коллектор для экземпляра. Этот коллектор автоматически стартует вместе с Enterprise Manager. Данные подучаются из следующих представлений:
V$SESSION
V$SESSION_WAIT
V$SYSTEM_EVENT
V$SYSSTAT
[Обнаружение] неподвижных запросов в памяти SGA представляет собой очень мощную возможность, которая однажды вполне поможет сохранить ваш рассудок [в оригинале – skin – кожа, шкура. Прим. А.Б. ]. Мы слишком знакомы с приложениями, припадающих к коленям базы данных, а затем вопрошающих объяснить, почему [они медленно работают]. Теперь вы можете предоставить ответ. Эта особенность получает мой голос как одна из самых полезных для АБД возможностей в выпуске 2.
Прерывание выполнения SQL Access Advisor
(Interruptible SQL Access Advisor)
Вы может быть знакомы с SQL Access Advisor (Советчик SQL-доступа) в Oracle Database 10g. По существу он предлагает автоматизированный подход к настройке рабочий SQL-нагрузки, идентифицируя индексы и материализованные представления, которые улучшат производительность SQL.
Но рассмотрим такую ситуацию. Вы сталкиваетесь с некоторыми проблемами производительности и хотите запустить SQL Access Advisor для группы SQL-предложений. Для получения более точного анализа вы выбираете опцию “Comprehensive mode” (полный режим), и затем ждете.
Если рабочая SQL-нагрузка велика, включает несколько сотен предложений, а сами SQL-предложения сложные, то ваше время ожидания может существенно затянуться. Тем временем некий пользователь сильно вас нагибает, чтобы получить ответ. И что вы можете сделать?
В базе данных Oracle Database 10g Выпуск 2 можно просто прервать деятельность советчика и рассмотреть только уже выполненные результаты и рекомендации. Эта возможность была доступна в Выпуске 1 в утилите SQL Tuning Advisor, и теперь она внедрена в SQL Access Advisor.
Давайте посмотрим, как это происходит. На экране Advisor Central надо кликнуть по ссылке SQL Access Advisor.
Выбираем опцию "Interrupt" (Прерывание) в раскрывающемся на правой стороне списке рядом с заголовком "Actions" (Действия) и нажимаем кнопку Go. Эта команда прервет выполнение SQL Access Advisor SQL и позволит немедленно увидеть рекомендации. Конечно, это будет незаконченный набор рекомендаций, но в большинстве случаев их может быть достаточно, чтобы удовлетворить потребности пользователей.
Если используется версия командной строки в SQL Access Advisor, а не Oracle Enterprise Manager, можно ли все же увидеть, сколько было сделано? Конечно, это возможно при помощи нового представления V$ADVISOR_PROGRESS.
SQL> desc v$advisor_progress
Name Null? Type
----------------------------------------- -------- -----------
SID NUMBER
SERIAL# NUMBER
USERNAME VARCHAR2(30)
OPNAME VARCHAR2(64)
ADVISOR_NAME VARCHAR2(64)
TASK_ID NUMBER
TARGET_DESC VARCHAR2(32)
SOFAR NUMBER
TOTALWORK NUMBER
UNITS VARCHAR2(32)
BENEFIT_SOFAR NUMBER
BENEFIT_MAX NUMBER
FINDINGS NUMBER
RECOMMENDATIONS NUMBER
TIME_REMAINING NUMBER
START_TIME DATE
LAST_UPDATE_TIME DATE
ELAPSED_SECONDS NUMBER
ADVISOR_METRIC1 NUMBER
METRIC1_DESC VARCHAR2(64)
В нем столбцы TOTALWORK и SOFAR показывают, сколько работы было сделано, также как показывается вся работа, подобно тому, что можно увидеть в представлении V$SESSION_LONGOPS.
Проверка Включения Трассировки
(Check for Tracing Enabled)
Если сессия не делает того, что ей полагается делать, или делает это медленно, первым шагом большинства АБД должна быть проверка событий ожидания.
Чтобы определить свое мнение, возможно, вам захочется проследить работу сессии за какой-либо период времени, в течение которого в директории user_dump_dest будет формироваться файл трассировки.
Теперь представьте, что вы в течение некоторого времени задействовали сквозную (end-to-end) трассировку для нескольких сессий, и теперь понятия не имеете, для каких сессий была разрешена трассировка. Как вы это узнаете?
Один из способов состоит в том, чтобы просеять бесчисленные трассовые файлы, извлекая столбцы SID и Serial# и соответствующие им базе данных значения в представлении V$SESSION. Само собой разумеется, этот процесс сложен, труден и подвержен ошибкам. Но в базе данных Oracle Database 10g выпуск 2 есть более изящный и намного более простой подход. Все, что нужно сделать, это проверить представление V$SESSION, которое вы так или иначе все равно проверяете.
Три новых столбца теперь показывают состояние трассировки:
- sql_trace — показывает (TRUE/FALSE), разрешена ли SQL-трассировка в этой сессии
- sql_trace_waits — если трассировка разрешена, вы можете получить информацию об ожиданиях, записанную в трассовом файле; это очень полезно для диагностики проблем производительности.
- sql_trace_binds — если сессия использует связанные переменные, можно получить трассировку с записью значений связанных переменных в трассовом файле. Этот столбец содержит TRUE/FALSE.
Если в сессии трассировка не включена, то выбирая эти столбцы:
select sid, serial#, sql_trace, sql_trace_waits, sql_trace_binds
from v$session
where username = 'HR'
The output is:
SID SERIAL# SQL_TRAC SQL_T SQL_T
---------- ---------- -------- ----- -----
196 60946 DISABLED FALSE FALSE
Ответ показывает, что трассировка не допускается в сессии с SID 196 и Serial# 60946.
Теперь разрешим трассировку событий ожиданий, но без связанных переменных. Чтобы разрешить трассировку можно использовать пакет dbms_monitor.
begin
dbms_monitor.session_trace_enable (
session_id => 196,
serial_num => 60960,
waits => true,
binds => false
);
end;
/
И снова посмотрев информацию о сессии:
select sid, serial#, sql_trace, sql_trace_waits, sql_trace_binds
from v$session
where username = 'HR'
The output is:
SID SERIAL# SQL_TRAC SQL_T SQL_T
---------- ---------- -------- ----- -----
196 60960 ENABLED TRUE FALSE
Обратим внимание, что наполняется представление V$SESSION только, если для разрешения трассировки используется процедура session_trace_enable из пакета dbms_monitor, но не команда alter session set sql_trace = true или установка события 10046. Если через какое-то время надо узнать, в каких сессиях разрешена трассировка, это можно сделать, использовав приведенный выше запрос.
Если вы разрешили трассировку, используя другие процедуры из пакета dbms_monitor, например, SERV_MOD_ACT_TRACE_ENABLE или CLIENT_ID_TRACE_ENABLE, представление V$SESSION не будет показывать подобную информацию. Данные вместо него будут записаны в другое представление DBA_ENABLED_TRACES. Это представление можно соединить с другими уместными источниками информации, чтобы увидеть сессии, где разрешена трассировка. Например, на запрос
SELECT *
FROM (SELECT SID, 'SESSION_TRACE' trace_type
FROM v$session
WHERE sql_trace = 'ENABLED')
UNION
(SELECT SID, t.trace_type
FROM v$session s, dba_enabled_traces t
WHERE t.trace_type = 'CLIENT_ID' AND s.client_identifier = t.primary_id)
UNION
(SELECT SID, t.trace_type
FROM v$session s, dba_enabled_traces t, v$instance i
WHERE t.trace_type = 'SERVICE'
AND s.service_name = t.primary_id
AND (t.instance_name IS NULL OR t.instance_name = i.instance_name))
UNION
(SELECT SID, t.trace_type
FROM v$session s, dba_enabled_traces t, v$instance i
WHERE t.trace_type = 'SERVICE_MODULE'
AND s.service_name = t.primary_id
AND s.module = t.qualifier_id1
AND (t.instance_name IS NULL OR t.instance_name = i.instance_name))
UNION
(SELECT SID, t.trace_type
FROM v$session s, dba_enabled_traces t, v$instance i
WHERE t.trace_type = 'SERVICE_MODULE_ACTION'
AND s.service_name = t.primary_id
AND s.module = t.qualifier_id1
AND s.action = t.qualifier_id2
AND (t.instance_name IS NULL OR t.instance_name = i.instance_name))
UNION
(SELECT SID, t.trace_type
FROM v$session s, dba_enabled_traces t, v$instance i
WHERE t.trace_type = 'DATABASE'
AND (t.instance_name IS NULL OR t.instance_name = i.instance_name))
получаем ответ:
SID TRACE_TYPE
---------- ---------------------
136 SERVICE_MODULE
136 SERVICE_MODULE_ACTION
Как можно видеть, трассировка разрешена для Service Module и Service Module Action для сессии 136. Однако представление DBA_ENABLED_TRACES не показывает [трассируются ли] связанные переменные и события ожидания.
Хронология Активности Сессий
(Activity Session History)
К настоящему моменту читатель должен уже понять насколько важен и полезен механизм AWR (Automatic Workload Repository - Автоматизированный Репозиторий Рабочей нагрузки). (Об AWR можно прочитать в статье “Неделя 6” прошлой серии http://www.oracle.com/technology/pub/articles/10gdba/week6_10gdba.html [или в русском переводе в http://www.oracle.com/global/ru/oramag/sepoct2004/admin_10g_20f_3.html ].) Если коротко повторить, AWR регулярно по заранее определенным интервалам собирает связанные с рабочей нагрузкой данные о производительности на пользовательском и системном уровнях, включая статистику производительности в различных измерениях, метриках, а также статистику OS и данные ASH (Active Session History - Хронология Активности Сессий).
Хронология Активности Сессий (ASH - Activity Session History) представляет историю действий всех активных в последнее время сессий, оперативно фиксируемых в циклическом буфере в памяти и оперативно записываемых в AWR, чтобы минимизировать накладные расходы. ASH-данные могут накапливаться по различным измерениям: TOP SQL, объект (object), файл (file), сессия (session), модуль (module), действие (action) и так далее.
Однако, большинство АБД обычно интересует диагностика скоротечных проблем производительности. Для разрешения таких проблем база данных Oracle Database 10g выпуск 2 представляет ASH-отчет. ASH-отчет может использоваться, чтобы показать всю базу данных или же конкретную сессию, SQL_ID, модуль, действие или комбинация этих измерений.
Один из путей получения ASH-отчета лежит через страницу Database. Выбор закладки Performance сгенерирует подобный экран:
Обратите внимание на кнопку (в красном овале) с названием "Run ASH Report" ("Запустить ASH-отчет"). Кликнув по ней, получаем отчет “Хронология Активности Сессий”:
Этот экран позволяет вводить дату и время начала и конца периода, которым вы интересуетесь. Введите дату и время как необходимо нажмите кнопку "Generate Report" (“Сформировать отчет”) в верхнем правом угле. По умолчанию дата и время задаются в 5-минутных интервалах.
После щелчка по этой кнопке появляется на экране ASH-отчет за заданный период. Если внимательно присмотреться, то можно увидеть, что этот отчет напоминает отчет STASPACK; но так как он получен на AWR-данных, статистика в нем намного более полезна. Небольшая часть экрана показана ниже:
Можно сохранить отчет в файле для более позднего рассмотрения, нажав на кнопку "Save to File" ("Сохранить в файле").
Обратите внимание на ссылки в разделе "ASH Report" ("ASH-отчет"). Здесь одним взглядом можно увидеть различные типы доступных метрик и статистики, связанной с производительностью. Например, кликнув по ссылке, можно только увидеть Top Events (Главные События) в течение заданного периода. Если проблемы производительности имели место в течение этого периода, подобная информация окажет существенную помощь. Вообще можно идентифицировать критические узости (bottlenecks), которые вызвали кратковременные всплески, наблюдая за асимметричностью по различным измерениям, приведенным в ASH-отчете.
Помните, этот отчет получен из данных, собранных AWR или в буферах в оперативной памяти, соответственно. Следовательно, если надо диагностировать имевшие место ранее проблемы производительности, можно просто запустить ASH-отчет за тот более ранний период и увидеть любые проблемы, которые, возможно, всплывали уже тогда.
ASH-отчет может также быть получен из командной строки, выполнив SQL-скрипт, расположенный в $OH/rdbms/admin/ashrpt.sql.
Управление Статистикой Оптимизатора
(Optimizer Statistics Management)
База данных Oracle Database 10g предлагает несколько очень полезных возможностей для управления статистикой оптимизатора, например, блокировать статистику, чтобы предотвратить последующую ее перезапись. Эти особенности делают задачу сбора и управления статистикой оптимизатора очень легкой (breeze). В базе данных Oracle Database 10g выпуск 2 это можно сделать с использованием Oracle Enterprise Manager.
На домашней странице Database кликните по закладке Administration. Спуститесь до раздела, названного "Statistics Management" ("Управление Статистикой"), где увидите ссылку Manage Optimizer Statistics (Управление Статистикой Оптимизатора), как показано ниже.
Щелчок по гиперссылке вызовет появление экрана Manage Optimizer Statistics.
На этом экране можно воспользоваться гиперссылками по правой стороне, чтобы выполнить различные задачи, связанные со статистикой. Используя, например, кнопку Configure (Конфигурация), можно легко задать выбрав новое Окно (Window) другое время для выполняемой работы.
Еще одна особенно полезная возможность – это ссылка Statistics Options (Варианты Статистики), расположенная в области "Related Links" ("Зависимые Ссылки"). Кликнув по ней, получаем следующий экран:
на котором можно сделать много нужных действий, например, изменить значения по умолчанию для параллелизма и процентной оценки.
Транспортировка AWR-Данных
(Transport AWR Data)
Предположим, вы пытаетесь решить какие-то проблемы производительности в промышленной базе данных. Как было показано в других местах этой статьи, AWR- данные очень важны для анализа. Однако, анализ AWR-данных, полученных в ходе нормальной эксплуатации, может быть не желателен или даже не выполним. Для сравнительного анализа вы бы предпочли загрузить данные в некоем другом месте. Как это можно сделать?
Для этой цели применяется новый пакет DBMS_SWRF_INTERNAL, поставляемый в базе данных Oracle Database 10g выпуск 2. Чтобы загружать данные в дамп-файл Data, надо использовать процедуру AWR_EXTRACT:
1 begin
2 DBMS_SWRF_INTERNAL.AWR_EXTRACT (
3 dmpfile => 'awr_data.dmp',
4 dmpdir => 'TMP_DIR',
5 bid => 302,
6 eid => 305
7 );
8* end;
Давайте посмотрим на эти строки более внимательно.
|
Строка |
Описание |
|
3 |
Имя целевого файла для разгружаемых здесь данных. Это - файл экспорта Data Pump. Если имя файла не задается, то значение по умолчанию awrdat.dmp. |
|
4 |
Директория, где формируется этот файл экспорта. В нашем случае для директории TMP_DIR, возможно, была определена [файловая система] /tmp. |
|
5 |
Идентификатор снимка (snapshot ID) для начального снимка периода. |
|
6 |
Идентификатор (ID) конечного снимка. В нашем случае экспортируются снимки с идентификаторами от 302 до 305. |
Теперь можно перенести дамп-файл awr_data.dmp на новое место и загрузить его, используя другую процедуру AWR_LOAD того же пакета:
1 begin
2 DBMS_SWRF_INTERNAL.AWR_LOAD (
3 SCHNAME => 'ARUP',
4 dmpfile => 'awr_data',
5 dmpdir => 'TMP_DIR'
6 );
7* end;
Этим кодом производится загрузка содержимого файл экспорта awr_data.dmp в директорию, указанную объектом директории TMP_DIR. При загрузке AWR-данных они не грузятся непосредственно в схему SYS; предпочтительнее сначала их разместить в другой схеме. Имя такой схемы задается параметром SCHNAME, как показано в строке 3. После размещения данные переносятся в схему SYS:
1 begin
2 DBMS_SWRF_INTERNAL.MOVE_TO_AWR (
3 SCHNAME => 'ARUP'
4 );
5* end;
Так происходит перемещение AWR-данных из схемы ARUP в SYS.
Как я упоминал выше, перемещение AWR к другую базу данных имеет много применений и преимуществ. Вы можете проанализировать данные в другой базе данных, не затрагивая промышленную базу. Кроме того, можно сформировать центральный репозиторий AWR-данных, собранных от нескольких баз данных.
Все описанные шаги по разгрузке присутствуют в едином файле awrload.sql, расположенном в директории $ORACLE_HOME/rdbms/bin. Точно так же скрипт awrextr.sql содержит все шаги для процесса извлечения.
Коль скоро реализован механизм автономной (off-loading) выгрузки промышленных AWR-данных во вспомогательную базу данных, их главным назначением в базе данных Oracle Database 10g выпуск 2 является помощь в расследовании любых проблем, о которых сообщают клиенты. Используя этот механизм, клиенты могут послать необработанные данные в форме файлов экспорта AWR, которые персонал поддержки затем импортирует в свою схему, обеспечивая воспроизведение и диагностирование проблем.
Сравнение Отчетов по Периодам
(Compare Periods Report)
Представим себе такой сценарий. Вас только что вызвали на срочную встречу с группами бизнеса и приложений. Причина предельно очевидна: база данных медленно работает. (Была ли когда-либо какая другая причина?) Технический руководитель разработчиков говорит: “Пакетная программа, запущенная ночью, между часом и тремя утра выполнялась очень медленно. Она всегда выполняется в течение приблизительно 30 минут, но сегодня ей потребовалось два часа”. И, вторя ему, руководитель бизнес-команды заявляет: "В нашей компании произошла потенциальная потеря дохода". Вы спрашиваете: "Были ли недавно какие-либо изменения?" Следует быстрый ответ технического директора: "Нет, никаких". ("Ну да, конечно" - это вы думаете про себя.) Знакомая ситуация?! И вы согласно киваете головой. Но что же все-таки надо делать?
К счастью, вы имеете дело с базой данных Oracle Database 10g выпуск 2 и можете применить механизм сравнения Snapshot (Снимок) или Time Periods (Периоды времени) в Oracle Enterprise Manager. Используя этот механизм, можно увидеть изменения показателей между двумя интервалами времени, а не только две точки во времени. Например, в нашем случае вы можете запросить изменения снимка между 1 и 3 утра сегодня ночью и то же самое в течение предыдущего дня. Если пакетный процесс выполнился прекрасно позавчера, но не вчера ночью, изменения снимка дадут вам главный ключ [к разгадке].
Вот как это работает: зайдите в Oracle Enterprise Manager и идите на закладку Performance. У основания страницы вы увидите раздел "Additional Monitoring Links" (“Ссылки Дополнительного Мониторинга”). В этой группе ссылок найдите "Snapshots" ("Снимки"). После щелчка по ней, появляется экран, подобный показанному ниже.
Обратите внимание на раскрывающийся список в красном овале. Выберите "Compare Periods" ("Сравнение Периодов") и нажмите кнопку "Go" (“Переход”). Это откроет экран для выбора конечной точки снимка первого периода, что показано ниже:
В блоке, заключенном в красный овал, выберите приблизительное время и дату периода, который вы хотите исследовать. Вас интересует период между 1 и 3 утра, поэтому выберите 3 утра. Нажмите кнопку Next, чтобы получить следующий экран.
В красном овале выберите опцию Select Beginning Snapshot (Выбор начала снимка), как показано на рисунке. Будет отображен список доступных снимков. Выберите дату и время, соответствующих 1 утра. На результирующем отображении выберите "радио" кнопку, которая соответствует до 1:00 - в этом примере - 248. Щелчок по "Next" ("Следующий").
Повторите те же самые шаги в для второго периода - 1-3 утра 22 апреля. Наконец, нажмите кнопку "Finish" (“Завершение”). Подошел совместный (side-by-side) анализ зафиксированных и расчетных показателей обоих периода. Следующий рисунок показывает первую половину экрана анализа:
Обратите внимание, что можно увидеть начальное и конечное время каждого периода. Первый столбец показывает различные показатели, собранные или вычисленные из других метрик; следующие столбцы показывают, как этот показатель выглядит в каждом периоде. Эта метрика дает вам основные аргументы, которые вы искали, чтобы выявить различия в производительности.
Кликнув по столбцу Second Period Rate Per Second (Скорость второго периода в секундах), что отсортирует его значения, можно облегчить себе задачу. Сортировка показывает самые плохие значения наверху, начиная от наиболее значимых и кончая самыми низкими значениями. Предположим, что в этом примере экран говорит, что физических чтений было намного больше во втором периоде. Теперь Вы знаете, почему так много было потрачено времени. Чтобы узнать причину увеличения количества физических чтений, следует выполнить отчет обо всех действиях и всех показателях, подобно AWR-отчету, но в сравнении, а не в течение определенного периода. Щелчок на закладке Report (Отчет) и будет выдан отчет, подобный следующему экрану:
Прокрутите вниз или отыщите раздел SQL Statistics (SQL-Статистика), который покажет примерно следующее меню:
В этой точке можно исследовать SQL-предложения, которые стали причиной увеличения числа физических чтений. Щелчок на ссылке "Top 10 SQL Comparison by Physical Reads" ("Сравнение по физическому чтению 10 лучших SQL") покажет Вам сетку (grid) всех идентификаторов SQL-предложений и числа их физических чтений. Теперь можно спускаться далее вниз, кликая по идентификатору SQL.
Конечно, это простой демонстрационный случай. Независимо от проблемы, делая сравнительный анализ, вы можете легко спуститься вниз, чтобы найти точную причину отличия в производительности в двух периодах. Отчет также приводит все изменения в параметрах настройки конфигурации базы данных для этих двух сравниваемых периодов времени. Дополнительно, поскольку все метрики и статистика двух сравниваемых периодов соответственно нормализованы по времени, периоды могут быть не равны по продолжительности.
В
части 4 , я расскажу об особенностях технологий информационных хранилищ и интеграции.
[От редакции OM/RE: перевод следующей статьи
А.Нанда планируется опубликовать
в декабрьском выпуске нашего журнала.]
| 
