Документация Oracle на русском языке





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

Главная :: Карта


Oracle Database или Oracle RDBMS — объектно-реляционная система управления базами данных компании Oracle.



 

DeepEdit!

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

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

Избыточные данные о вызовах при включении трассировки


В некоторых случаях отмеченная в файле трассировки длительность вызова базы данных превышает тот период времени, на который была включена трассировка. Такое явление наблюдается, когда время нача­ла вызова базы данных (значение tim - e) меньше времени начала сбора данных, т. е. когда tim - e < t0. Мы несколько раз наблюдали подобные случаи, когда трассировка была включена сторонним сеансом в ходе длительного выполнения блока PL/SQL. (Отличие этого случая от только что рассмотренного заключается во включении трассировки именно в ходе долго выполняющегося блока PL/SQL, а не просто в хо­де выполнения длительного вызова базы данных). Единственная часть файла трассировки, которая может пострадать от феномена избыточ­ного времени, - это первые отмеченные в файле трассировки операции с определенной рекурсивной глубиной (значением поля dep).
Подобное явление не так просто заметить, если несколько тысяч строк WAIT (не содержащих полей tim) предшествуют строке первого вызова ба­зы данных, содержащей это поле. В главе 5 вы узнали, как выполнить обратный отсчет времени, начиная со значения первого поля tim файла через значения всех полей ela и до достижения первой строки. Однако этот метод подвержен заметному накоплению систематической ошиб­ки, как это было показано при описании отсчета времени в главе 5.
Гораздо более удачный способ вычисления «виртуального» значения tim для первой строки WAIT файла трассировки заключается в том, что­бы ввести функции преобразования, которые позволяют преобразовы­вать значения полей tim Oracle к значениям системного времени и об­ратно. Соотношение между величиной tim и системным временем можно установить, сделав следующие шаги:
2. Исследуйте полученные данные трассировки. Он будет содержать такие строки:
1. Выполните приведенные ниже команды в SQL*Plus для системы, соотношение времен для которой вы хотите установить:
3. По этой информации вы можете установить прямое соответствие указанного значения поля tim указанной временной метке. В при­веденном примере обратите внимание на совпадение составляющих секунд и миллисекунд двух значений (выделено жирным шриф­том). В изучаемой нами системе отношение между значениями вре­мени очень просто: каждое значение поля tim - это просто количест­во микросекунд, прошедших с момента начала эры UNIX (00:00:00 UTC - 1 января 1970). В примере 6.10 приведена программа, кото­рая служит мне инструментом для преобразования значений tim в системное время и обратно.
Рассмотрим простой пример файла трассировки, начальные строки которого содержат данные о событиях, которые произошли до момен­та начала сбора данных:
Нелегко понять, что происходит, если не преобразовать значения вре­мени к сопоставимому формату. Возьмем из примера 6.10 программу для преобразования значения tim в моей Linux-системе в более удобо­читаемое значение абсолютного времени и увидим, что вызов исполне­ния завершился только через 2,025881 секунды после включения трассировки:
Но фактическая продолжительность вызова исполнения составляет 30 секунд (e=30000000). То есть часть продолжительности этого вызова базы данных относится к периоду, предшествующему временной мет­ке, выведенной в начале файла трассировки. Я уже говорил, что эта временная метка не всегда соответствует тому моменту времени, в ко­торый на самом деле был установлен атрибут трассировки. Придется отдельно отслеживать время включения трассировки (назовем его t0). Это проще всего сделать, отметив время в поле tim при выполнении ко­манды на включение трассировки SQL.
Итак, вы определили, что в файле трассировки учтено избыточное вре­мя, и следующая задача состоит в том, чтобы избавиться от него. На рис. 6.7 показано, как это сделать. Здесь трассировка SQL включа­ется в момент t0, во время некоторого вызова разбора внутри долго вы­полняющегося блока PL/SQL. При этом часть продолжительности e вы­зова разбора относится к интересующему нас интервалу наблюдения, а другая его часть - к периоду времени, предшествующему t0. Лишнее время легко вычислить, т. к. значение t0 в единицах tim известно. Не вошедшее в период наблюдения время можно вычислить так:
Если первые несколько строк, переданные в файл трассировки, не со­держат значения tim, то можно вычислить значение для начала фай­ла, преобразовав начальное значение временной метки (в строке ***) в соответствующее значение tim, как было показано выше. Помните, что временная метка сопоставлена моменту завершения операции, ко­торая следует за данной строкой в файле трассировки. Задача сводится к ситуации, уже рассмотренной на рис. 6.7, в которой вам известны t, e, t0 (фактически и все промежуточные значения ela в случае, если длительность одного из событий ожидания также включает в себя t0).
Пропуск времени при отключении трассировки
При завершении сеанса, для которого была включена расширенная трассировка SQL, в файле трассировки будет учтено все время около момента завершения сеанса. Так, если сеанс отключает собственную трассировку командой ALTER SESSION SET EVENTS, в файле трассировки учитывается все время сеанса, прошедшее до момента выполнения этой команды. Если же трассировка отключается сторонним сеансом, то это отключение произойдет, скорее всего, в ходе выполнения собы­тия ожидания или вызова базы данных сеанса. В таком случае некото­рые нужные данные о сеансе могут отсутствовать в файле трассировки.
Например, трассировка указанного сеанса отключается в момент вре­мени tim=1043788733690992. Однако в конце файла трассировки содер­жится лишь следующее:
Обратите внимание на выделенную часть завершающего значения в по­ле tim: файл трассировки содержит сведения о том, что произошло до момента времени ...23,690992 (в секундах) и фактически на 4 микросе­кунды позже, но нет записей о том, что происходило между моментами ...23,690992 и ...33,690992. Не учтено ровно 10 секунд.
На рис. 6.8. показано, как сложилась такая ситуация. Трассировка SQL была выключена в момент t1, в ходе выполнения события ожида­ния z. Но ядро Oracle передает в файл трассировки строку события ожидания только по завершении этого события. Трассировка была вы­ключена раньше, чем завершилось событие ожидания, никаких дан­ных о нем в файле трассировки нет. Часть длительности события ожи­дания относится к периоду времени после t1, но та его часть, которая произошла до t1, остается неучтенной.

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

В данном случае вычислить пропущенное время просто, ведь значение t1 в единицах tim известно. Это делается по формуле:
Опять-таки проще всего отслеживать tx, пометив момент времени, ко­гда выполняется команда на отключение трассировки SQL. При от­ключении трассировки необходимо определить имя события, которое не было завершено на момент tx. Из стороннего сеанса это можно уз­нать посредством такой команды SQL:
Разработанный Hotsos сборщик данных Sparky выполняет подобный запрос непосредственно перед командой на включение и выключение трассировки. Если запрос не возвращает имени события, то все пропу­щенное время следует отнести к процессорному времени. Если же за­прос возвращает имя события, то по крайней мере некоторая часть пропущенного времени соответствует событию, имя которого возвра­тил запрос. При этом, как видно на рис. 6.8, некоторая часть пропу­щенного времени все равно может быть израсходована процессором.
Возможно, некоторая часть пропущенного времени израсходо­вана на выполнение инструкций ядра Oracle, для которых от­сутствуют средства измерения (подробно мы поговорим об этом в главе 7).
Может быть, удастся приблизительно определить, какую часть време­ни следует отнести на счет загрузки процессора, а какую - сопоста­вить событию ожидания. Однако наша практика показала, что в слу­чае, если запрос V$SESSION_WAIT возвращает имя события, сопоставле­ние всего значения этому событию будет хорошим приближением.
Наличие строк WAIT в конце файла трассировки несколько усложняет вычисление пропущенного времени, т. к. приходится осуществить еще одну операцию по отсчету времени. В данном случае вам придется получить значение t, отсчитывая время вперед от значения последнего поля tim файла через значения полей ela.

 



jAntivirus