DeepEdit!

Сканирование индекса является излюбленным приемом операторов SQL, так как при этом выполняется намного меньше операций ввода/вывода, чем при сканировании полной таблицы, и таким образом работа идет быстрее.

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

запросом, должны не превышать стоимости полного сканирования таблицы. Если при сканировании индекса выполняется больше операций ввода/вывода, чем при полном сканировании таблицы, оно скорее нанесет вред производите­льности, чем пользу. Если выбираемые строки разбросаны по многочисленным блокам таблицы, которые не кластеризованы или не расположены следом друг за другом, то использование при выполнении запроса индекса приводит к его неоптимальному выполнению (даже в тех случаях, когда число обрабатываемых строк не превышает 1:VI), Это связано с чрезмерно большим количеством гене­рируемых при этом операций ввода/вывода. Такой избыток операций вво­да/вывода может потенциально перенапрячь подсистему памяти. А это делает более предпочтительным выполнение сканирования полной таблицы. Если рассматриваемая таблица имеет значительные размеры (определение то го, что такое "значительные размеры" мы оставляем за пользователями), можно даже посоветовать рассмотреть вопрос о ее параллельном сканировании.

а

рузья, жители космоса и Земли и трудоголики АБД, раскройте ваши уши. зольте нам быть вашими психиатрами по настройке (которые в некоторых частях света известны как сократители настройки) и выслушайте нас. Мы обе­щаем, что в конце нашего сеанса вы будете чувствовать себя намного лучше и

уйдете домой с чувством значительного облегчения. Ваши близкие даже будут

удивлены вашим гордым видом. Если же этого не случилось, прочтите данную главу еще раз.

Знаете ли вы, что 80% проблем с производительностью настраиваемой системы не имеет ничего общего с конфигурацией используемой базы данных Oracle?

Итак, если принять, что значительная часть наших проблем с производитель­ностью связана с SQL, то для нас очень важно рассказать об SQL и вопросах на­стройки приложений.

В большинстве сред в наследство АБД достаются чьи-то неудачные опыты в программировании или плохой дизайн подсистемы ввода/вывода, и ему прихо­дится либо смириться и жить со всем этим, либо искать другую работу. Самое плохое в том, что все эти игры с наследованием чужой работы никак не уйдут в прошлое. У нас даже есть для этого специальный термин: SQL с обратной сторо­ны Луны.

Чтобы еще больше запутать все, кто-то начинает льстить вам, награждая вас титулами эксперта, гуру или говоря легкомысленные фразы вроде: "Не могли бы вы взмахнуть своей магической палочкой АБД?" или "Она богиня" (кстати, где мы слышали раньше весь этот вздор?) и т. д. Не забивайте всем этим голову, чтобы не потерять ощущения притяжения Земли. Пожалуйста, не заставляйте краснеть сэра Исаака Ньютона с его тремя законами механики!

В широком смысле совершенно естественно, что люди часто просто умоля­ют вас выполнить работу мусорщика SQL. Попросту говоря, вам приходится

убирать ... , ну, сами знаете что! И чем больше вы убираете, чем лучше делаете

это, тем больше "добра" вам достается. Ваша жизнь становится похожей на цикл PL/SQL, в котором забыли поставить условие выхода из него.

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

Прим пер.) 

остается в прошлом. Да, вы тот самый избранный, кому доверено ис­правлять и разрешать все вопросы с производительностью, возникающие в ва­шей среде, даже если вы не представляете, что с ними делать. И по прошествии многих лет вы продолжаете извлекать из своего арсенала ужасных историй ка­кие-нибудь 

SQL из склепа 

(здесь и далее авторы иронизируют над нашумевшими теле- и мультсериалами "Байки из склепа". - 

Прим. пер.) 

и рассказывать их всем новичкам. Из этого могла бы получиться увлекательная книга! Есть смысл даже задуматься над созданием телесериала. Ну ладно, пора вернуться немного назад и поговорить с нашим редактором по приобретениям!

На следующий день после разговора с редактором настройка операторов SQL выходит на первое место по значению для здоровья и производительности нашей системы. Никакая настройка базы данных не дает нам такого количества преимуществ и выгод, как хороший оператор SQL. Мы говорим о потенциальном росте производительности буквально на несколько порядков. Никакая книга о настройке базы данных (включая и нашу), никакой эксперт (безотносительно к тому, сколько лет он настраивает базы данных Oracle) не могут обеспечить тако­го роста производительности. Вспомните, что 80% ваших проблем с производи­тельностью имеют своей причиной плохо спроектированные или плохо реализованные операторы SQL. Это ведь должно что-то значить для нас?

Теперь попробуем определить наши ожидания. Говоря о настройке приложе­ний, мы вовсе не имеем в виду подробности программирования SQL, мы подра­зумеваем те проблемы, с которыми приходится сталкиваться большинству АБД при рассмотрении проблем приложения. Однако если вы желаете изучить тон­кости программирования для SQL, мы рекомендуем три книги, в которых мож­но найти практически все, что вам потребуется.

Книги, которые мы предлагаем для знакомства с настройкой приложений (заметим, что порядок их расположения произволен и не отражает их качества или наших пристрастий): 1. EyalAronoff, Kevin Loney. 

Advanced Oracle Tuningand Administration. 

2. Guy Harrison. 

Oracle SQL High Performance Tuning.!. 

Peter Corrigan, Mark Gurry. 

Oracle Performance Tuning.

Наша основная задача в этой главе состояла в том, чтобы подготовить чита­телей к пониманию тех вопросов, которые, как мы знаем, являются для них очень важными и предлагают им подсказки для облегчения составления опти­мальных операторов SQL. Первое правило для того, чтобы выиграть сраже­ние, - знай своего врага. Именно в этом и состоит наша цель: как можно больше рассказать о главном противнике производительности - плохих операторах SQL. Как только мы узнаем, кто является врагом в нашей среде, сразу появляет­ся много новых возможностей построить собственный план битвы с ним.

Иногда плохие операторы SQL являются результатом неудачной модели данных. В таком случае нужно сперва разобраться с проблемами модели.