|
Страница 16 из 25
6.3. Типичный сценарий Представьте себе таблицу, в которой записи являются ежемесячными записями баланса счетов. По определению, сумма по всем записям должна быть равна нулю (т.е. сумма дебета должна быть равна сумме кредита). Представьте также, что в системе работают одновременно два пользователя - аналитик и оператор. Если аналитик решит запустить длительный отчет, например по всем периодам, то такой запрос должен будет прочитать все записи в таблице. Если аналитик начнет запрос, а в это время оператор выполнит обновление (помните, что сумма дебета и кредита должны равняться 0) самой верхней записи таблицы (которую запрос аналитика уже прочитал) и нескольких самых нижних записей (которые запрос аналитика еще не успел прочитать из-за длительности своего выполнения), то аналитик увидит только вторую часть транзакции оператора. Итог у аналитика не сойдется и запрос придется выполнять снова.
В большинстве случаев аналитику придется действительно повторить запрос (правда, тут еще надо догадаться - действительно-ли это не сошелся баланс или это произошло из-за вмешательства оператора). Но поскольку неизвестно, сколько на самом деле записей изменил оператор, да и сколько всего операторов работают в этот момент, единственным решением для аналитика может быть только административное - запретить всем операторам вводить данные до тех пор, пока аналитик не завершит формирование отчета. Еще более худшая ситуация может возникнуть, если отчет выполняется не по одной а по двум таблицам - главной и подчиненной. Большинство генераторов отчетов сначала собирают данные из подчиненных таблиц, а затем выполняют расчет по главной. Раздельное обновление данных в этих таблицах может привести к появлению полностью негодного отчета. Это недопустимо в базах данных, контролирующих научные данные реального времени или производственный процесс.
В архитектуре SQL Server, есть только один способ гарантировать целостность и воспроизводимость чтения - это блокировка всей таблицы. Блокировка такого типа блокирует доступ к таблице для других пользователей. В приведенном выше сценарии, SQL Server автоматически переведет страничные блокировки в блокировку всей таблицы. Однако блокировка таблицы не возникнет пока достаточное количество страниц не будет прочитано (уровень эскалации бликроовки). Так что вероятна ситуация, когда операторы, обновляющие данные, заблокируют возможность установки блокировки таблицы, и запрос аналитика "зависнет" в ожидании до бесконечности или просто не сможет выполниться. Разработчик должен знать особенности эскалации блокировок и вручную протестировать все ситуации. Возникновение полной блокировки таблицы в системах, работающих 24 часа в сутки, может быть очень труднодостижимо или вообще невозможно, поскольку такая блокировка приведет к блокировке всех остальных пользователей, работающих интерактивно и в реальном времени. Много разработчиков не имеют другого выбора кроме как выполнять подобные отчеты по расписанию, в часы наименьшей активности основной массы пользователей, и когда полная блокировка таблицы никому не помешает.
Разработчики должны также потратить много времени, разрабатывая систему управления блокировками, для того чтобы обеспечить работу программы при возникновении конфликтов блокировок. Часто состояние заблокированности не может быть определено пока пользователь не завершит транзакцию. Разработчики должны периодически пытаться сохранить транзакцию пока блокированные данные не станут доступными, либо писать сложные процедуры кэширования обновлений на клиентских машинах (для сокращения времени выполнения транзакции). Локальное кэширование данных вызывает много других проблем, например как следствие - большинство пользователей во время кэширования их обновлений видят неверную информацию в базе данных.
Сложность приложений, разрабатываемых в настоящее время, достаточно высока и без ограничений, накладываемых архитектурой SQL Server.
(Д.К. - в настоящее время фирма Sybase выпустила специальный продукт, позволяющий работать с DSS-транзакциями - Sybase IQ. Это специальный продукт, который предназначен для выполнения транзакций DSS только в режиме чтения (и фактически только по архивным, а не оперативным данным). Обновление такой БД в режиме OLTP практически невозможно из-за специально применяемых структур данных. Таким образом задачи OLTP и DSS у Sybase решаются при помощи двух отдельных продуктов - Sybase System 11 и Sybase IQ соответственно). |