Блокировки

Многопользовательский доступ

Производительность

Производительность – достаточно важный критерий оценки ИС. Разработчики SQL-серверов также достаточно много внимания уделяют росту производительности своих продуктов. Вообще рост производительности при использовании серверных СУБД достигается благодаря следующим факторам:

1) возможность функционировать на многопроцессорных системах;

2) использование многопоточности в рамках одного физического сервера;

3) использование сложных алгоритмов распределенных вычислений;

4) использование сложных алгоритмов оптимизации чтения/записи и извлечения данных;

5) как правило, для установки SQL-сервера выбирают наиболее мощный с вычислительной точки зрения компьютер.

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

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

Одним из самых больших достоинств серверов БД является возможность многопользовательского доступа к данным. Собственно, организовать многопользовательский доступ можно было и к xBase-данным, разместив файлы на файл-сервере и внеся некоторые коррективы в программное обеспечение.

Однако в серверных СУБД используется принципиально другой механизм. Они имеют интеллектуальное ядро, которое обрабатывает запросы, извлекает данные, формирует набор и отправляет его клиенту. Клиенты никогда не имеют непосредственного доступа к физическим данным на SQL-сервере.

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

Транзакции мы уже рассмотрели. Рассмотрим уровни изоляции и блокировки.

В многопользовательских клиент/серверных системах существует два подхода к управлению транзакциями --оптимистическая и пессимистическая блокировки.

Оптимистическая блокировка предполагает, что приложение явно не управляет блокировкой записей, рассчитывая на систему управления базами данных.

Пессимистическая блокировка подразумевает реализацию определенного типа блокировки самим приложением.

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

1) Минимизируйте время, которое транзакция находится в открытом состоянии. Это достигается ограничением SQL-кода в рамках одной транзакции.

2) Исключайте при разработке приложения блокировок во время простого просмотра записей. Блокируйте при вводе изменений только нужную запись.

3) Обеспечьте одинаковый порядок изменений и выборок данных таблиц для всех приложений. Это предотвратит так называемые взаимные блокировки.

Взаимные блокировки (deadlock) возникают, когда приложение А блокирует таблицу Т1 и пытается получить доступ к таблице Т2. В это же самое время приложение В блокирует таблицу Т2 и пытается получить доступ к таблице Т1. В этом состоянии таблицы Т1 и Т2 являются заблокированными, оба приложения ничего не выполняют ("зависают"). Тупиковая ситуация, которая требует вмешательства администратора SQL-сервера.

Рассмотрим еще несколько типов блокировок, знание механизма которых позволит вам создавать максимально отказоустойчивые системы.

Дата добавления: 2014-01-13