DeepEdit!

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

  • Увеличить размер шрифта
  • Размер шрифта по умолчанию
  • Уменьшить размер шрифта

Область данных

бласть данных

Хорошая методика сбора данных о производительности Oracle требует соответствующих методик принятия решений в двух измерениях. Не­обходимо получить данные в правильной временной области и в пра­вильной области операций. Начнем с построения диаграммы, показы­вающей структуру времени отклика в виде последовательности вре­менных промежутков, соответствующих потреблению различных ре­сурсов. Результат показан на рис. 3.2. Для простоты будем считать, что наша воображаемая система состоит из ресурсов трех видов, обо­значенных C, D и S. Пусть это будут процессор, диск и некий ресурс с последовательным доступом (как, например, ядро Oracle, предостав­ляющее последовательный доступ блокировкам, защелками и опреде­ленным операциям с буферами памяти). На рис. 3.2 ось времени рас­положена горизонтально.
Рис. 3.2. Распределение времени между ресурсами в ходе выполнения пользовательской операции
Аналогично можно изобразить систему, выполняющую несколько поль­зовательских операций одновременно, поместив такие диаграммы од­ну под другой, как это показано на рис. 3.3. На этой диаграмме ось пользовательских операций расположена вертикально.
В следующих разделах данный способ представления помогает объяс­нить, почему методы сбора данных, практикуемые многими эксперта­ми по Oracle с 1980-х годов, лишь губят проекты повышения произво­дительности Oracle по всему миру.
Ошибки в определении области
Представьте, что в системе, изображенной на рис. 3.3, процесс выбора пользовательских операций, описанный в главе 2, показал следую­щее: наибольшая проблема производительности для бизнеса заключа­ется в том, что для пользователя Уоллеса время отклика (между моментами t1 и t2) недопустимо велико (рис. 3.4).
В последующем обсуждении будем использовать математиче­ское обозначение для закрытого интервала. Обозначение [a, b] соответствует множеству значений, заключенному между a и b

включая их:
[a, b] = {все значения x, для которых a < x < b}
Из рис. 3.4 легко видеть, что на проблемном интервале большая часть времени потребляется ресурсом S, а оставшаяся - ресурсом C (табл. 3.1). Понятно, что решение проблемы производительности для Уоллеса требует уменьшения времени, потребляемого ресурсом S, или C, или ими обоими. Закон Амдала говорит, что эффект от сокращения по­требления ресурса S будет в 1,5 раза выше, чем от ресурса C вследствие того, что доля S во времени отклика в 1,5 раза больше доли C.
Таблица 3.1. Профиль ресурсов для операции пользователя Уоллеса в интервале [t1, t2]

Ресурс
Время использования
Доля в общем времени
S C
Всего
3 2 5
60,0% 40,0% 100,0%
Пожалуй, самая распространенная ошибка в получении данных - это сбор данных, агрегированных по обоим измерениям. Рис. 3.5 иллюст­рирует эту ошибку. Толстая черная линия, охватывающая все блоки диаграммы, показывает, что были получены общие данные по всем про­цессам (не только для Уоллеса) и во всем временном интервале [t0, t3] (не только для [t1, t2]). Подсчет составляющих времени для всей систе­мы в интервале [t0, t3] дает профиль ресурсов, приведенный в табл. 3.2. Как видите, проблема пользователя Уоллеса, которая, как нам извест­но, заключается в слишком больших временных затратах на выполне­ние операции S, оказалась погребенной под кучей не относящихся к делу данных. Результатом небрежности, допущенной при сборе дан­ных, будет задержка в выполнении проекта повышения производи­тельности и, возможно, его меньшая результативность.
Рис. 3.5. Сбор данных в неверно определенной по обоим измерениям области полностью скрывает источник проблемы пользователя Уоллеса на интервале [tl,
На основании данных табл. 3.2 невозможно сделать вывод о том, что проблема пользователя Уоллеса связана с расходованием ресурса S. Более того, предположение о том, что проблема Уоллеса заключается в ресурсе S, было бы безответственным.
К сожалению, разобранный здесь порочный метод сбора данных приме­няется по умолчанию пакетом Statspack, парой сценариев utlbstat.sql и utlestat.sql, а также практически всеми инструментами исследова­ния производительности Oracle, созданными между 1980 и 2000 года­ми. Во всех наиболее провальных проектах повышения производи­тельности, в которых мне довелось участвовать, основной причиной неудачи чаще всего был именно такой способ сбора данных.
Решение описанной проблемы требует корректировки сбора данных по обоим измерениям. Недостаточно исправить ошибку в одном измере­нии. Посмотрите, например, на результаты сбора данных, показанные на рис. 3.6. Здесь временная область выбрана правильно, но область операций все еще слишком велика. Соответствующий профиль ресур­сов приведен в табл. 3.3. Не забывайте, вам известна истинная причи­на проблем пользователя Уоллеса, и она заключается в ресурсах S и C. Но данные, полученные для системы в целом, недвусмысленно «свиде­тельствуют» об обратном, несмотря на то, что были собраны в правиль­ном временном интервале.
Наконец, рассмотрим результаты сбора данных в правильной области операций, но в неправильной временной области, как показано на рис. 3.7. В табл. 3.4 приведен соответствующий профиль ресурсов. И здесь даже опытный специалист по производительности, основываясь на представленных данных, не справится с задачей диагностики. Про­блема пользователя Уоллеса связана с ресурсами S и C, но данные табл. 3.4 не позволяют сделать такой вывод.
Таблица 3.3. Профиль ресурсов системы в целом на интервале [t1, t2]

Ресурс
Время использования
Доля в общем времени
D
C S
Всего
23 9
3
35
65,7%
25,7%
8,6% 100,0%

Таблица 3.4. Профиль ресурсов операции пользователя Уоллеса на интервале
[t0, t3]

Ресурс
Время использования
Доля в общем времени
D
C S
Всего
8 8
4
20
40,0%
40,0%
20,0% 100,0%
На основании этих простых примеров хорошо видно, почему правиль­ная организация сбора диагностических данных жизненно важна для проекта повышения производительности. Примеры также раскрыва­ют равнозначность двух измерений, на основании которых можно су­дить о применимости имеющихся диагностических данных:
Протяженные во времени пользовательские операции
Целесообразно ли накапливать диагностические данные производи­тельности на всем протяжении пользовательской операции, которая вы­полняется действительно долго? К примеру, операция, выполнявшаяся на прошлой неделе за десять минут, сегодня висит уже четвертый час, и вы подумываете, не пора ли ее отменить. Надо ли перезапускать зада­ние для получения диагностики? Мне приходилось слышать о пакет­ных заданиях, выполнявшихся по несколько дней, прежде чем потеряв­шие терпение пользователи снимали их.1 Действительно ли необходимо собирать диагностические данные для всего задания целиком?
Ответ - нет. Конечно, сбор диагностики лишь на части проблемного интервала представляется нарушением правила выбора временной об­ласти, но в некоторых обстоятельствах такие данные могут быть дей­ствительно полезными. Например:
Если пользовательская операция должна выполняться за n минут, то данные, собранные в течение n+m минут, будут содержать не от­носящуюся к делу информацию как минимум за m минут. Например, если предполагается, что задание выполнится за 10 минут, дан­ные, собранные в течение 25 минут будут содержать не менее 15 ми­нут не относящейся к рассматриваемой операции нагрузки.
Если пользовательская операция состоит из последовательности по­вторяющихся действий, диагностические данные, полученные только для нескольких из них, дадут представление о расходах ре­сурсов для всей операции благодаря ее однородности.2
В главе 6 обсуждаются некоторые ошибки, которые могут возникнуть в случае начала процесса сбора данных в середине операции над базой данных. Но во многих случаях сбор данных на частичных интервалах может оказаться весьма полезным.
«Слишком много данных» -на самом деле их недостаточно
В некоторых из этих случаев я мог бы представить доказательства того, что всей нашей жизни не хватило бы на то, чтобы дождаться окончания выпол­нения заданий.
Хотя в этом разделе речь идет о допустимости или недопустимости сужения временной области, первый пример возвращает нас к вопросу о расширении временной области. Он напоминает, что расширение временной области сбо­ра диагностических данных - это явная ошибка, нарушение правила выбора временной области, последствия которого описаны выше. Второй же пример показывает, что сужение временной области вполне допустимо в некоторых случаях. По-видимому, эти примеры должны противопоставляться друг дру­гу, хотя явно автор этого не делает. - Примеч. науч. ред.
Может показаться, что проблемы с данными, приведенными в табл. 3.2, 3.3 и 3.4, возникли из-за того, что было собрано «слишком много дан­ ных». Однако дело не в том, какие данные были собраны, а в том, как они были агрегированы. Посмотрите еще раз на рис. 3.5. Здесь вполне достаточно информации для построения профиля ресурсов в правиль­ной области. Проблема с данными в табл. 3.2 возникла вследствие не­правильного обобщения данных из рис. 3.5. То же можно сказать и о рис. 3.6, 3.7 и соответствующих им профилях ресурсов. Дело не в избытке данных, а в том, что они некорректно агрегированы в про­филях ресурсов.
Неправильное агрегирование данных особенно сильно сказывается на проектах, в которых в качестве источника диагностических данных выступают запросы к фиксированным представлениям Oracle V$. Эти представления по природе своей способны предоставить только сово­купные данные либо для экземпляра с момента его запуска, либо для сеанса с момента установки соединения. Например, используя пред­ставления V$SYSSTAT или V$SYSTEM_EVENT, вы гарантированно получите ошибки в представлении данных, аналогичные показанным в табл. 3.2 и 3.3. Как бы аккуратно вы ни применяли V$SESSTAT и V$SESSION_EVENT, вы не избежите ошибок в определении временного интервала, проил­люстрированных данными в табл. 3.4 (в этом можно убедиться, поэкс­периментировав с программой vproof из главы 8).
При должном внимании к временной области данных представления V$SESSTAT и V$SESSION_EVENT могут дать общее представление о причинах задержек при выполнении пользовательских операций. Однако в них отсутствуют данные, необходимые для более детального анализа. Как быть, если, к примеру, предварительный анализ показал, что рассматриваемая операция большую часть времени проводит в ожидании со­бытия освобождения блокировки latch free? Тут потребуются данные из V$LATCH (и возможно, V$LATCH_CHILDREN) за тот же период времени. Но, получив их, вы заметите, что ни в одном из представлений нет идентификатора сеанса, в силу чего сбор информации о защелках в коррект­ной области операций оказывается невозможным.
Невозможность получения подробных данных из представлений V$ представляет собой серьезную проблему. И корень зла отнюдь не в пред­ставлении V$LATCH. Что, если бы большую часть времени занимало ис­пользование ЦПУ? Тогда вам понадобились бы данные, как минимум, из представления V$SQL для заданной операции в определенном ин­тервале времени. А если бы время уходило на ожидание db file scat­tered read? Тогда потребовались бы аналогичные данные из V$FILESTAT. А если проблема в ожидании buffer busy waits? Тогда надо обратиться к V$WAITSTAT. В Oracle9имеется около 300 событий, требующих для анализа подробных данных из нескольких десятков представлений V$. Даже если бы вам удалось получить из них данные для строго опреде­ленных моментов времени (в правильной временной области), вы все равно получите агрегированные значения, страдающие отсутствием детализации, которую можно получить из других источников.
К счастью, есть как минимум три пути получения нужных нам подроб­ных данных. Первый не очень хорош. Второй обойдется дорого, но у вас, возможно, уже есть все необходимое. Третий доступен по цене кни­ги, которую вы держите в руках. Подробности - в следующем разделе.

 









jAntivirus