Рассмотрим пример выходных данных
tkpro и
постараемся понять их различные компоненты. Выходные данные слегка сокращены для удобочитаемости:select A Id, A. Name, в. Name
from AUTHOR A, BOOK В
where A.Authored =
|
B.Book_Author_Id
|
||||||
and A.Authored
|
= 101
|
■
|
|||||
order by 1
|
3.Name;
|
||||||
call
|
count
|
cpu
|
elapsed
|
disk
|
query
|
current
|
rows
|
Parse
|
1
|
0,02
|
0,02
|
0
|
0
|
0
|
0
|
Execute
|
1
|
0,01
|
0,01
|
0
|
0
|
0
|
0
|
Fetch
|
27
|
0,24
|
0,36
|
1230
|
2342
|
0
|
399
|
Totals
|
29
|
0,27
|
0,39
|
1230
|
2342
|
0
|
399
|
Обсудим различные столбцы в выходных данных трассировки tkprof:
• Call Фаза обработки оператора SQL (фазы
define
иbind
также включены в фазу Parse).Count Количество вызовов/выполнений данной фазы.
CPU Реальное время использования CPU при выполнении фазы.
Elapse d Время ЦП (в секундах) плюс все время, потраченное на выполнение переключения контекстов операционной системой, обслуживание прерываний, выполнение ввода/вывода, ожидание ресурсов и т. д.
Disk Число блоков Oracle, прочитанных с диска (физический ввод/вывод) для данной фазы.
Query Число блоков Oracle, считанных из памяти в согласованном режиме.
• Current Число блоков Oracle, считанных из памяти в текущем режиме.
• Rows Число строк, обработанных в каждой фазе. Вы должны видеть значения для операторов
select
в фазе Fetch и для операцийinsert/update
в фазе выполнения.Заметим, что трудно обнаружить различие между столбцами Query и Current. С практической точки зрения нет реальной необходимости разделять логический ввод/вывод на два таких блока. На основании своего опыта мы
обычно суммируем их (Query и Current), чтобы прийти к суммарному логическому вводу/выводу для оператора SQL.
Как упоминалось в главе "Настройка приложения - вопросы, касающиеся АБД", окончательная цель любого оператора SQL заключается в возврате данных пользователю при наименьшем использовании системных ресурсов за разумный промежуток времени. Это означает, что для одних операций может требоваться больше операций ввода/вывода, а для других - больше ЦП. Не существует магических цифр процентного соотношения физического и логического ввода/вывода, поскольку такое соотношение зависит от природы и частоты настраиваемых операций (SQL). Основным моментом, о котором нельзя забывать в попытках настройки приложений, является время реакции системы и пропускная способность. Как уже говорилось, мы должны определить для нашей системы
события ожидания
и соответствующим образом настроить и систему, и приложение. В конечном счете именно пользователь определяет, какое количество ресурсов может и должен поглощать данный оператор SQL, и выдвигает требования ко времени реакции, частоте выполнения и нагрузке, налагаемой на систему.Если какой-то оператор SQL выполняет 1 млн физических операций ввода/вывода блоков, чтобы вернуть 100 строк, следует определить причину этого. Что-то здесь не складывается. На той же самой ноте мы должны задать вопрос о чрезмерном количестве логических операций ввода/вывода в операции (SQL). И хотя во всех учебниках говорится, что логический ввод/вывод, по крайней мере, в тысячу раз быстрее, чем физический вывод, отсюда не следует, что
(с точки зрения Oracle) логический ввод/вывод всегда лучше физического.
Ключевым фактором, рассматриваемым здесь, можно назвать число блоков,
которые приложение для того, чтобы вернуть данные пользователю.
которые приложение для того, чтобы вернуть данные пользователю.
Другим фактором является затраченное время, необходимое для возвращения пользователю набора строк. Следует определить, реально ли это число. Помните также, что применение индекса не всегда дает преимущества. Если из приведенных выше выводных данных трассировки удастся найти одну или несколько аномалий в операторе SQL, нужно будет переписать этот оператор, чтобы он использовал меньшее количество ресурсов и более оптимальные методы.
| < Предыдущая | Следующая > |
|---|
