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

Тем не менее, разрабатывая пррыожение с учетом приведенной рекомендации, необходимо убедиться в том, что клиентский компьютер способен обработать все передаваемые ему данные. Ведь обычно именно серверные, а не клиентские компьютеры в большей степени приспособлены к обработке более крупных запросов. Кроме того, следует учитывать, что на сервер поступают запросы от многочисленных пользователей, а это означает, что серверный компьютер должен располагать достаточными ресурсами для успешного осуществления всех операций обработки данных, выполняемых сервером в интересах поддерживаемых пользователей. Таким образом, если применяется подход, предусматривающий передачу на серверный компьютер всех тех процедур обработки данных, с которыми не могут справляться клиентские компьютеры по причине нехватки ресурсов, то могут быть также исчерпаны ресурсы серверного компьютера, безусловно, при условии, что объем связанной с этим дополнительной нагрузки является весьма существенным. Поэтому лучше всего организовать работу в системе клиент/сервер , но так, чтобы в серверной части приложения формировались полные результирующие наборы, которые затем передавались бы в клиентскую часть, разумеется, с учетом того, чтобы эти результирующие наборы имели минимально возможный размер.

Применение денормализации

Этот раздел вполне можно было бы назвать и так: Почему не всегда следует безоглядно придерживаться правил , а речь в нем идет о правилах нормализации. Безусловно, без соблюдения правры нормализации данных было бы невозможно обеспечить целостность данных и достичь достаточно высокой производительности в среде OLTP. Но проблема состоит в том, что нормализация в основном способствует повышению характеристик обработки транзакций, но не все операции, выполняемые в базе данных OLTP, являются обязательно связанными с транзакциями. Ведь даже в системах OLTP приходится выполнять определенный объем работы, связанной с формированием отчетов (например, таких, которые содержат итоговые данные о транзакциях, проведенных в течение суток).

Причем зачастую достаточно лишь немного отступить от требований нормализации, скажем, ввести в таблицу всего лишь один дополнительный столбец, как появляется возможность исключить необходимость применения крупной операции соединения или даже такой операции соединения, которая охватывает несколько таблиц. Автор бьы свидетелем того, как добавление одного столбца позволрыо перейти от соединения девяти таблиц к соединению двух таблиц. Достигьгугое при этом сокращение объема выразрыось в том, что стала осуществляться обработка приблизительно 100 ООО строк вместо нескольких миллионов строк. Что же касается продолжительности запроса, то она сократилась от нескольких минут буквально до секунд.

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

строго обоснованно. Точно определите, какие цели должны быть достигнуты благодаря денормализации, и проведите предварительную проверку намеченных изменений, чтобы убедиться в том, что они действительно позволяют добиться предполагаемых результатов. Если же ожидания окажутся неоправданными, вы всегда сможете вернуться к применявшейся ранее схеме базы данных.

Процедуры технического сопровождения

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

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

Причем достаточно лишь проследить за дискуссиями в группах новостей или поговорить с теми, кто эксплуатирует одну и ту же систему в течение многих лет, чтобы убедиться в том, что во всех этих обсуждениях часто повторяется одинаковый сюжет: система, которая в свое время функционировала просто великолепно, со временем начинает работать все медленнее и медленнее, несмотря на то, что на протяжении всей истории ее эксплуатации не происходили какие-либо существенные изменения. Безусловно, замедление работы системы происходит на основании вполне объективных причин, например, в связи с увеличениям объемов хранимых данных и вытекающим из этого увеличением объемов обрабатываемых данных при выполнении запросов, но обусловленное этим снижение производительности, как правило, не должно быть столь существенным. Поэтому фактически наиболее важной причиной постепенного ухудшения производственных характеристик системы является то, что средства обеспечения высокой производительности, введенные в действие ко времени запуска системы, неизбежно перестают соответствовать текущим условиям ее эксплуатации. В частности, со временем изменяется состав приложений, применяемых для доступа к системе, становятся другими данные, к которым происходит доступ в операциях обработки данных, а то сочетание факторов, которые в свое время обеспечивало достижение наивысшей производительности, перестает быть действенным.

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

Качественная организация хранимых процедур

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

Применение непродолжительных транзакций

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

Использование наименее ограничительного уровня изоляции транзакций из всех возможных

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

Дополнительную информацию об уровнях изоляции транзакций и о блокировках см. в главе 12.

Применение в случае необходимости нескольких решений

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