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

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

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

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

Знакомство с инструментальными средствами настройки индексов, входящими в состав приложения Database Tuning Advisor

Приложение Database Tuning Advisor предназначено для замены приложения Index Tuning Wizard, которое впервые появилось в версии 7.0. Безусловно, с тех пор многое изменилось, и в приложение Database Tuning Advisor вошел более широкий набор инструментальных средств по сравнению с теми, которые касаются настройки индексов, но эти средства все еще остаются в нем основными.

Рекомендуем соблюдать исключительную осторожность при использовании автоматизированных инструментальных средств настройки по отношению к индексам. Особенно внимательно следует относиться к тому, какие индексы должны быть удалены по рекомендации этих средств. Данные рекомендации формируются с учетом рабочей нагрузки, наблюдаемой в настоящее время, но в нее могут не войти все те запросы, на которых основано функционирование системы. Внимательно ознакомьтесь с рекомендациями, выработанными программой, и еще раз проверьте, являются ли они обоснованными. Это особенно касается рекомендаций по удалению индексов; прежде чем ими воспользоваться, необходимо уточнить, для чего предназначен удаляемый индекс, и имеет ли смысл вьшолнение рекомендаций по его )Т1ичтожению. Дело в том, что иногда программа Database Tuning Advisor не обнаруживает, например, какие-то задачи по формированию отчетов, которые являются достаточно трудоемкими, но не эксплуатируется в тот момент, когда формируется файл с данными о рабочей нагрузке, на основании которого формируются рекомендации, касающиеся индексов.

Таблица 23.1. Рекомендации по использованию клиентских или серверных средств обработки данных

Средство обработки данных

Рекомендуемая область применения

Статические курсоры

Однонаправленные курсоры,

предназначенные только для чтения

Ситуации

holdlock

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

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

Ситуации holdlock связаны с применением транзакций, а все транзак-ционные операции выполняются гораздо лучше в серверной, а не в клиентской части приложения

Сопоставление средств клиентской и серверной обработки

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

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

В табл. 23.1 приведен краткий обзор некоторых рекомендацрш, которыми следует руководствоваться, принимая решение об использовании клиентской или серверной обработки.

Окончание табл. 23.1

данньпГ обработки Рекомендуемая область применения

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

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

Приложения, в кото- В таких приложениях целесообразно использовать средства ADO.NET. рых применяется В их состав входит превосходный набор инструментов, позволяющих значительный объем осуществлять однократную выборку данных с сервера (что способствует операции выборки уменьшению количества циклов обмена данными с сервером), после данных по критериям чего применяются операции выборки данных по критериям и происходит и (или) вторичной локальная сортировка с использованием машины ADO. Применение сортировки данных, выбранных по условию или отсортированных в СУБД SQL

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

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

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