12 вариант 2 (954078), страница 20

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 20)

• Язык SQL не предназначен для обработки файлов. Одну из наиболее распространенных ошибок в программировании SQL допускают люди, имеющие опыт работы по программированию с исполь­зованием средств обработки файлов, таких как BTRIEVE или ISAM. Разработчики программного обеспечения не должны забывать, что для соотношений главный/подробный нужно писать два от­дельных запроса: один запрос — к главной записи, а другой — к расшифровке этой записи. Это позволит избежать лишних непроизводительных затрат обработки, которые могут заметно снизить производительность прикладных программ.

• Настройка не решает проблемы некачественного проектирования. Это наиболее важное понятие при настройке приложений. Оно подчеркивает то, что знает любой, кто занимался разработкой систем, -лучше заранее устранить возможные ошибки, чем потом их исправлять. Не имеет значения, сколько создано индексов, насколько качественно оптимизированы запросы или сколько распределено кэшей и буферов, — если база данных плохо спроектирована, производительность всей системы будет низкой.

Это только общие рекомендации по настройке приложений. В каждом вычислительном центре суще­ствуют собственные конкретные проблемы, от которых зависит бесперебойная работа приложений. Чаще всего разработчикам приходится настраивать и корректировать свои программы без вмешательства DBA, Однако в связи с его подразумеваемой ответственностью DBA должен работать с персоналом разработки приложений над решением этих проблем.

Настройка производительности не всегда должна происходить на глобальном уровне — уровне базы дан­ных Теоретически основная часть настройки должна осуществляться на более низких масштабируемых уров­нях, где гораздо легче измерить влияние различных факторов на производительность. Непререкаемой истиной настройки и оптимизации базы данных является то, что настройка производительности — не колдовство или магия. Оптимизация базы данных не заставит плохо написанное приложение работать бы­стрее, это может относиться и к хорошо написанному приложению, хотя и встречается не так часто. Важно изучить, как база данных выполняет обработку на уровне приложений или SQL.

Для этой цели в Oracle предусмотрено инструментальное средство в форме EXPLAIN PLAN, которое позволяет DBA пропустить оператор SQL через оптимизатор Oracle и узнать, как этот оператор будет выполнен базой данных, то есть получить план выполнения. Это позволяет узнать, работает ли база данных согласно ожиданиям, например, использует ли она индекс таблицы, вместо того чтобы просматривать всю таблицу базы данных. Результаты, возвращаемые EXPLAIN PLAN, зависят от нескольких факторов. Они включают:

• Изменения в статистике во время работы базы данных под управлением стоимостного оптимизатора

• Использование подсказок HINTS во время работы с продукционным оптимизатором, которые за­ставляют запрос выбрать определенный план выполнения

• Добавление или удаление новых индексов на одной из таблиц в операторе SQL во время работы базы данных с продукционным оптимизатором

• Тонкие изменения в фразах WHERE или FROM оператора SELECT языка SQL во время работы базы данных с продукционным оптимизатором

• Наличие объектов базы данных с тем же именем, что и у объекта, на который производится ссылка в схеме пользователя, выполняющего запрос

Поэтому необходимо учитывать, что результаты EXPLAIN PLAN ни в коем случае не являются посто­янными и окончательными. DBA должен знать об изменениях, внесенных в объекты базы данных, напри­мер о новых индексах и о том, как быстро растут таблицы.

RDBMS Oracle использует EXPLAIN PLAN, сохраняя информацию о ходе выполнения запроса в таб­лице внутри схемы пользователя. Чтобы оператор EXPLAIN PLAN мог работать, эта таблица должна уже существовать. Для создания таблицы пользователь должен выполнить следующий сценарий. Безусловно, ем необходимо иметь привилегии CREATE TABLE и RESOURCE или привилегии квоты в своем табличном пространстве по умолчанию.

% svrmgri

SVRMGR> connect scott/tiger

Connected.

SVRMGR> @$ORACLE_HOME/rdbms/admin/utlxplan.sql

Statement Processed.

После создания этой таблицы можно выработать EXPLAIN PLAN из запроса, предварив этот запрос командой на выполнение EXPLAIN PLAN. Следующий сценарий показывает, как оформить запрос для EXPLAIN PLAN:

CONNECT /

EXPLAIN PLAN

SET STATEMENT_ID = 'QUERY1’

INTO PLAN_TABLE FOR

SELECT O.ORDER_DATE, O.ORDERNO, O.PARTNO, P.PART_DESC, O.QTY

FROM ORDER 0, PART P

WHERE O.PARTNO = P.PARTNO

Обратите внимание на фразы SET STATEMENT и INTO в EXPLAIN PLAN. Значение SET STATEMENT

используется для обеспечения уникальности результатов этого выполнения EXPLAIN PLAN, записанных в таблице; оно может представлять собой практически любую строку длиной до 30 символов. С другой сто­роны, указав таблицу в фразе INTO, вы сообщаете EXPLAIN PLAN, куда поместить информацию о вы­полнении запроса. В предыдущем примере текущее выполнение запроса обозначено как QUERY1, а его информация записана в таблицу PLAN_TABLE.

Теперь, когда EXPLAIN PLAN загрузил таблицу информацией, возникает очевидный вопрос — ка выбрать и интерпретировать полученную информацию. В Oracle предусмотрен сценарий, описанный в ру­ководстве Oracle8 Server Utilities Guide, который отображает информацию в древовидной форме. Он выглядит следующим образом:

SELECT LPADC ', 2* (LEVEL-1))||operation||' '|1

options, object_name "QUERY PLAN"

FROM plan_table

START WITH id = 0 AND statement_id = 'QUERY1'

CONNECT BY PRIOR id = parent_id

После выполнения запроса SQL через EXPLAIN PLAN будет получен псевдограф, аналогичный ни-1 жеприведенному:

Рассматривая эту выходную информацию, важно учитывать, что все операции, о которых сообщает FXPLAIN PLAN, по существу, представляют собой комбинации "операция/опция". Обсудить все эти ком­бинации или допустимые интерпретации сценариев EXPLAIN PLAN не представляется возможным. Как и во многих областях информационной индустрии, особенно в области реляционных баз данных, единствен­ным настоящим учителем является опыт. Ниже приведены наиболее распространенные пары "операция/ опция", возвращаемые при выполнении операторов EXPLAIN PLAN.

В базе данных, в которой часто происходят (и ожидаются) полные просмотры таблицы, можно откорректировать параметр DBJUE_MULTIBLOCK_READ_COUNT в файле параметров INIT.ORA для обеспечения единовременного чтения большего числа блоков. Значение по умолчанию для этого параметра — восемь блоков.

EXPLAIN PLAN — мощное инструментальное средство для разработчиков программ, поскольку оно позволяет проверить правильность настройки запросов. Безусловно, изменения, внесенные в объекты базы

данных, могут неблагоприятно воздействовать на результаты EXPLAIN PLAN, но эти результаты полез­ны при определении потерь производительности в приложении.

Утилиты SQL*Trace и TKPROF

Средства Oracle SQL'Trace и EXPLAIN PLAN аналогичны в том, что они оба используются для на­стройки производительности на уровне приложения и показывают, в какой форме RDBMS Oracle выпол­няет запрос. В отличие от оператора EXPLAIN PLAN, который просто показывает, какой способ выполнения запроса выбирает оптимизатор базы данных для получения указанной информации, утилита SQL*Trace отображает количественные показатели выполнения SQL. SQL*Trace показывает не только план выполнения, но и такие показатели, как ресурсы процессоров и дисков. Ее результаты часто рассматри­вают как низкоуровневое представление способа выполнения запроса базы данных, поскольку она пока­зывает коэффициенты на уровне операционной системы и RDBMS.

Для использования SQL*Trace необходимо вначале установить некоторые параметры в файле параметров INIT.ORA:

MAX_DUMP_FILE_SIZE Обозначает максимальный размер файла, вырабатываемого Oracle. Это

значение представляет собой число блоков операционной системы „ (они могут отличаться по размеру от блоков базы данных). Ц

Характеристики

Список файлов домашнего задания