|
Страница 3 из 25
2.2. SQL Server 2.2.1. Страничные Блокировки Для того, чтобы гарантировать целостность данных, архитектура SQL Server использует механизм блокировок страниц данных. Страница данных это набор записей, хранимых в некоторой области жесткого диска на сервере. Все страницы имеют один и тот-же размер, который определяется конфигурацией сервера и базы данных. В зависимости от длины записей и размера страницы, страница может содержать определенное количество записей. Записи в большинстве случаев добавляются в конец таблицы. Базовый размер страницы в SQL Server равен 2K, и это является минимальной единицей блокировкиl. Страничные блокировки требуют от разработчика глубоких знаний о конкурентной работе с данными и настройке кода для получения максимально конкурентного доступа. Страничная блокировка блокирует все записи или соответствующие ссылки в индексах, хранимые на одной странице. Например, если размер записи в таблице равен 100 байт, а размер ключа индекса равен 10 байт, то блокировка одной страницы данных и одной страницы индекса приведет к куммулятивному эффекту блокирования 18-ти записей и 180-ти ключей индекса. Когда происходит запись в таблицу, то для обеспечения целостности записи RDBMS блокирует страницу, на которой находится эта запись. Блокирование целой страницы намного быстрее блокирования отдельной записи, и требует намного меньше ресурсов сервера для управления блокировками. Вместе с тем, блокирование целой страницы, приводит к блокированию других пользователей от изменения данных на этой-же странице. В дополнение к блокированию страницы, на которой находится интересующая запись, SQL Server дополнительно блокирует предыдущу и следующую страницу (относительно блокируемой). Доступ к записям на блокированных страницах будет невозможен в течение действия блокировки. Блокирование может возникнуть во многих ситуациях. Наиболее частая причина блокировки - добавление записи или ее модификация. Кроме этого, использование курсоров клиентским приложением может также производить большое количество блокировок страниц. В таких ситуациях пользователь, всего-лишь просматривающий записи, блокирует других пользователей от внесения изменений на эти-же страницы до тех пор, пока не закроется курсор либо блокировка не переместится на другие страницы. То, что "читатель" записи блокирует страницу на которой эта запись находится, и ее смежные страницы, может привести к проблемам производительности для пользователей, которые нуждаются в доступе к данным на заблокированных страницах. Вместо того, чтобы сосредоточиться на разработке правил управления данными, разработчик вынужден описывать сложную обработку возможного возникновения конфликтов блокировок. Это увеличивает сложность приложения, и повышает стоимость разработки и сопровождения. 2.2.2. Блокировки Индексов Индексы SQL Server блокируются точно так-же, как и страницы данных соответствующих таблиц, однако эффект блокировки страницы индекса значительно шире. Записи в таблице хранятся в большинстве случаев в случайном порядке (исключение составляют кластерные индексы). Когда обновляется страница данных, то должен обновиться соответствующий индекс. Как и у таблиц, данные индексов хранятся на страницах. Для обновления страницы индекса, эта страница должна быть сначала заблокирована. Если данные в таблице распределены случайным образом, то блокировка страницы индекса приведет к блокировке большого количества страниц данных, поскольку страница индекса ссылается на большое количество страниц данных. Это значит что модификация одного ключевого значения на странице может заблокировать множество совершенно посторонних записей на страницах данных. Если для таблицы определено несколько индексов, то изменение одной записи приведет к лавинообразному росту блокировок страниц, не относящихся к странице где находится модифицируемая запись. В приложениях, работающих с большими объемами данных, это может сильно снизить производительность системы. 2.2.3. Блокировки Таблиц Целостностное представление базы данных иногда требует уровня изоляции "воспроизводимое чтение". "Воспроизводимое чтение" гарантирует неизменность видимых данных на время действия транзакции. Это очень важно в финансовых приложениях или при создании отчетов по большим объемам данных в то время как другие пользователи модифицируют записи. Для обеспечения целостного представления данных в Sybase или Microsoft SQL Server разработчик должен использовать блокировки таблиц. Блокировка таблицы вызывает полную блокировку, разделяемую, для обновления или исключительную [Shared, Update, or Exclusive]. Представьте себе свод баланса бухгалтером - пока свод не закончен, архитектура SQL Server требует чтобы разработчик полностью заблокировал таблицу на время свода. Кроме этого может потребоваться полное блокирование связанных таблиц. Более подробно эта тема обсуждается в секции 6.3. 2.2.4. Эскалация страничных блокировок в Блокировки Таблиц Длинные транзакции, затрагивающие большое количество записей, требуют большого количества страничных блокировок. Как только количество страничных блокировок достигает определенного предела, SQL Server автоматически включает полную блокировку таблицы. Назначение такого механизма в том, чтобы уменьшить работу RDBMS по управлению блокировками и обеспечению конкурентного использования данных, и чтобы предотвратить деградацию производительности. Естественно, что полная блокировка таблицы заблокирует другим пользователям доступ к этой таблицы. Эскалация может произойти как при обновлениях, так и при обычной выборке данных. Для того, чтобы обеспечить оптимальную производительность при многопользовательском доступе, администратор БД должен тщательно проанализировать структуры БД и алгоритмы клиентских приложений на пересекающиеся запросы по чтению и обновлению данных. После этого администратор должен определить уровень эскалации табличных блокировок чтобы сбалансировать управление большим количеством блокировок страниц и блокировку доступа при эскалации табличных блокировок. Разработчики приложений также должны понимать особенности страничных и табличных блокировок, и соответственно программировать обработку доступа при блокировках. Такие требования добавляют к приложениям дополнительную сложность кода, увеличивая стоимость разработки и сопровождения. 2.2.5. Варианты решения проблем Для того, чтобы обрабатывать множество ограничений механизма блокировок SQL Server, разработчики должны использовать множество решений для оптимизации баланса между конкурентным доступом и производительностью: - Использовать администратора БД, хорошо знакомого с SQL Server, для проведения анализа клиентских приложений, статистики базы данных и структур данных, чтобы установить оптимальное значение уровня эскалации табличных блокировок.
- Буферизировать данные локально (например использовать Cached Updates в BDE 3.x) для сокращения времени транзакции до минимума. В любом случае необходимо специально программировать обработку ситуаций, когда разные пользователи пытаются обновить одни и те-же записи.
- Использовать репликацию данных, над которыми может произоводиться длительная обработка (сложные отчеты). К сожалению, репликация в SQL Server является односторонней. Это ограничение часто делает невозможным использование репликации для более сложных задач. В Sybase, репликация производится при помощи отдельного продукта, называемого “Replication Server”.
- Использовать временные таблицы для пакетных обновлений данных. Это может вызвать другие проблемы, поскольку пользователи могут параллельно такому обновлению модифицировать данные в других таблицах, и данные во временной таблице станут неактуальными.
- Использовать HOLDLOCK для установления блокировки SHARE на выбранные элементы данных, чтобы предотвратить обновление этих данных другими пользователями. При большом количестве пользователей, возможно что другие пользователи будут пытаться обновить одни и те-же страницы данных или индексов. Множественные блокировки SHARE могут быть применены к одним и тем-же элементам чтобы блокировать обновления. При таком сценарии, другой пользователь получит deadlock и один из двух пользователей должен быть отключен для прекращения ситуации deadlock. Использование монопольных блокировок предотвратит deadlock, но и сделает невозможным просмотр заблокированных данных другими пользователями. Ненормальное завершение приложения может оставить неразрешенные блокировки до тех пор, пока сервер определит что связь с приложением оборвалась.
2.2.6. Операция Вставки в Microsoft SQL Server В Microsoft SQL Server 6.5 механизм блокировок улучшен по сравнению с версией 6.0 и Sybase SQL Server поддержкой блокировок на уровне записей при вставке. Это увеличивает производительность вставки записей, но никак не решает другие проблемы со страничными, индексными или табличными блокировками. Поэтому, независимо от версии, обновление данных в архитектуре SQL Server все-равно требует табличных или страничных блокировок для обеспечения целостности данных. |