Как sql общается сразу со многими пользователями

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

UPDATE Salespeople

SET comm = comm * 2

WHERE sname LIKE 'R%';

и в это же время, Diane вводит такой запрос:

SELECT city, AVG (comm)

FROM Salespeople

GROUP BY city;

Может ли усредненное значение(AVG) Diane отазить изменения которые вы делаете в таблице? Не важно, будет это сделано или нет, а важно что бы были отражены или все или ни одно из значений комиссионных (comm) для которых выполнялись изменения. Любой промежуточный результат является случайным или непредсказуемым, для порядка в котором значения были изменены физически. Вывод запроса, не должен быть случайным и непредсказуемым.

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

Обработка одновременных транзакций называется - параллелизмом или сов-

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

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

_______________________________________________________

ПРИМЕЧАНИЕ: Термин "упорядочить", аналогичен общепринятому - "заказать", что в принципе более соответствует логике запроса, потому что с точки зрения пользователя, он именно "заказывает" информацию в базе данных, которая упорядочивает эту информацию в соответствии с "заказом". ________________________________________________________

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

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

• Тупик. Два пользователя могут попытаться выполнить дейст вия которые конфликтуют друг с другом. Например, если два пользователя попробуют изменить и значение внешнего ключа и значение родительского ключа одновременно.

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

ды COMMIT или ROLLBACK ).

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

На самом деле они осуществляют это управление вне SQL, даже если и воздействуют на процесс работы самой SQL.

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

Задержанные операции выстраиваюится в очередь и выполняются только когда блокировка снята ( некоторые инструменты блокировок дают вам возможность указывать NOWAIT, которая будет отклонять команду вместо того чтобы поставить ее в очередь, позволяя вам делать что-нибудь другое).

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

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