Для поддержания целостности данных все системы управления базами данных (РСУБД) применяют блокировки данных. Например, когда один редактор начинает обновление строк, эти строки блокируются, чтобы предотвратить их изменение другим редактором. По завершении транзакции блокировка прекращается.
Каждая СУБД использует блокировки и интерпретирует уровни изоляции по-разному. Поэтому вам нужно изучить модель поведения каждой СУБД, чтобы определить, на каком уровне вам нужно установить блокировки, как лучше установить уровни изоляции и как избежать появления простоев при блокировке и взаимоблокировок (тупиков).См. также Более подробно см. в документации по своей СУБД.
Кроме того, ArcGIS работает со всеми СУБД по-разному. В результате, возможные проблемы конкурентного использования при выполнении неверсионного редактирования слегка отличаются в различных РСУБД. В данном разделе приводится краткая информация о том, каким образом параллелизм и блокировки используются в ArcGIS, но блокировка базы данных является очень сложной темой.
ArcGIS и уровни изоляции
При редактировании базы геоданных Oracle, DB2 или Informix в неверсионном сеансе редактирования, ArcGIS не изменяет режим работы этой среды путем установки уровня изоляции. Вместо этого используется текущий уровень изоляции, установленный в СУБД. В результате, вы можете установить для изоляции любой уровень и установить опцию использования этого уровня при выполнении редактирований в неверсионной сессии редактирования.
Начиная с версии ArcGIS 10.4, для баз геоданных на SQL Server необходимо, чтобы опциям базы данных SQL Server READ_COMMITTED_SNAPSHOT и ALLOW_SNAPSHOT_ISOLATION было присвоено значение ON. При редактировании базы геоданных SQL Server в неверсионном сеансе редактирования, ArcGIS для транзакций задает уровень изоляции READ COMMITTED.
В последующих разделах описываются возможные проблемы с явлением параллелизма, которые могут возникнуть при стандартных условиях. Пока не будет указано иное, в данных разделах подразумевается, что в используемой СУБД для уровня изоляции по умолчанию установлено COMMITTED READ или эквивалент этого значения.
Oracle
Редакторы блокируют редакторов: при выполнении операции редактирования одного пространственного объекта или группы объектов, например при их перемещении или изменении их атрибутов, СУБД блокирует строки их таблиц. Объекты будут заблокированы до тех пор, пока вы не сохранитесь или не завершите сессию редактирования, не сохраняясь. Соответственно, любой редактируемый пространственный объект или запись остается заблокированным на протяжении всего сеанса редактирования.
Когда два пользователя пытаются редактировать один и тот же объект в одно и то же время, объект блокируется, когда первый редактор завершает операцию. Эта блокировка будет удерживаться, даже если этот редактор начал работать с другими объектами. Объекты будут заблокированы до тех пор, пока редактор не сохранит изменения или не завершит сеанс редактирования, без сохранения, что приведет к отмене всех изменений в этом сеансе.
Пока этот объект будет заблокирован, второй редактор пытается изменить его. Сеанс второго пользователя ArcMap ожидает отмены блокировки, отображая значок песочных часов, это означает, что в сеансе выполняется действие. Песочные часы будут продолжать отображаться до тех пор, пока блокировка не будет снята, пока первый редактор не сохранит изменения (закрепление изменений в базе данных) или закончит сеанс редактирования без сохранения (отмена изменений). В этом момент второй редактор может начать редактировать таблицу. (Обратите внимание, что изменения, внесенные вторым редактором, могут перезаписать изменения первого.)
Такая проблема с блокировками также может возникнуть между двумя редакторами в следующих случаях:
- Оба редактора одновременно вносят изменения.
- Каждый из редакторов изменил записи в своем текущем сеансе.
- Каждый из редакторов пытается изменить запись, уже измененную другим пользователем.
У первого редактора, который пытается изменить заблокированную строку, будут отображены песочные часы, поскольку его сеанс ArcMap ожидает снятия блокировки. Как только второй редактор попытается изменить строку, заблокированную первым редактором, возникнет ситуация, которая известна как взаимоблокировка, при которой оба пользователи заблокировали друг друга. СУБД выведет для одного из них сообщение о необходимости в произведении отката транзакций, чтобы другой пользователь смог продолжить работу. Редактор, транзакции которого были отменены, должен повторно внести все изменения, сделанные после последнего сохранения.
Редакторы не блокируют пользователей: Редакторы, производящие запись в базу данных, не мешают другим пользователям считывать те же самые данные, независимо от уровня изоляции. У пользователей или приложений, которые считывают заблокированные данные, они выглядит так же, как и до начала выполнения текущей транзакции.
Пользователи не блокируют редакторов: Пользователи или приложения, производящие чтение базы данных, не могут помешать другим пользователям изменять те же самые данные на любом уровне изоляции.
DB2 и Informix
Редакторы блокируют редакторов: в DB2 и Informix редакторы блокируют редакторов почти так же, как это происходит в Oracle. Для получения более подробной информации обратитесь к разделу по Oracle.
Редакторы блокируют пользователей: В DB2 и Informix редакторы запрещают другим пользователям или приложениям считывать те же самые данные на любом уровне изоляции выше UNCOMMITTED READ. На этих более высоких уровнях изоляции выполнение блокировки данных до момента сохранения редактирований или момента их отката может вызывать проблемы: пока вы работаете в сеансе редактирования, никто кроме вас не сможет считать данные, которые вы редактируете. Это может вызвать появление следующих ситуаций:
- Если вы добавите тот же слой в ArcMap, вы увидите песочные часы, и этот слой не будет отображен до тех пор, пока блокировки не будут сняты.
- Если вы пытаетесь панорамировать редактируемые данные, ArcMap будет ожидать снятия блокировки.
- Если вы идентифицируете заблокированный объект, то будут отображены песочные часы, и никакая информация не будет возвращена до снятия блокировки.
иПользователи блокируют редакторов: в СУБД DB2 и Informix пользователи могут запретить другим пользователям изменять те же самые данные на любом уровне изоляции выше UNCOMMITTED READ. Однако на практике вы редко когда сможете заметить это в ArcGIS, поскольку устанавливаемая при чтении данных блокировка строки длится очень малое время: к тому времени, когда данные будут отображены, блокировка уже будет снята. Пользователи, считывающие данные, по-настоящему смогут заблокировать редакторов в приложении, которое откроет курсор в СУБД, извлечет одну строку за раз и затем проведет итерацию через выборку, обрабатывая данные. В этом случае DB2 и Informix будут запрашивать и удерживать блокировки, когда будет происходить процесс обработки выборки.
PostgreSQL
Редакторы блокируют редакторов: в PostgreSQL невозможно обновить запись до тех пор, пока транзакция, которая первая внесла изменения, не будет отправлена в базу данных или отменена. Если два редактора одновременно пытаются обновить или удалить один и тот же пространственный объект, первый из них блокирует обновление этой записи. Другие редакторы не могут редактировать эту запись до тех пор, пока первый либо не сохранит изменения (т.е. отправит изменения в базу данных) или не выйдет из сеанса редактирования без сохранения изменений (т.е. отменит все изменения своего сеанса редактирования).
Пока этот объект заблокирован, второй редактор пытается изменить его. Сеанс второго пользователя ArcMap ожидает отмены блокировки, отображая значок песочных часов; это означает, что в сеансе выполняется действие. Песочные часы будут оставаться на экране, пока первый редактор не сохранит свои изменения (закрепит их в базе данных) или не завершит сеанс редактирования без сохранения (отменит редактирование). В этом момент второй редактор может начать редактировать таблицу. (Обратите внимание, что изменения, внесенные вторым редактором, могут перезаписать изменения первого.)
Редакторы не блокируют пользователей: если вы используете в PostgreSQL мультиверсионный контроль общего доступа (MVCC), который установлен по умолчанию и является рекомендуемым для баз данных, транзакции записи в базу данных, не блокируют доступ для чтения остальным пользователям. Это верно при использовании уровня изоляции по умолчанию READ COMMITTED в базе данных или установке уровня изоляции SERIALIZABLE.
Пользователи не блокируют редакторов: независимо от того, какой уровень изоляции установлен для базы данных, пользователи не блокируют данные.
SQL Server
Начиная с версии ArcGIS 10.4, для баз геоданных на SQL Server необходимо, чтобы опциям базы данных SQL Server READ_COMMITTED_SNAPSHOT и ALLOW_SNAPSHOT_ISOLATION было присвоено значение ON, а ArcGIS использовал для транзакций уровень изоляции READ COMMITTED. Для получения более подробной информации об уровне изоляции READ COMMITTED см. документацию по SQL Server.
Редакторы блокируют редакторов: Редакторы блокируют редакторов в SQL Server так же, как это происходит в Oracle.
Редакторы не блокируют пользователей: Пользователи получают закрепленную версию строки, существующую на момент начала транзакции.
Пользователи не блокируют редакторов: Когда транзакции, работающие с изолированной на базе версии строкой, считывают данные, операциям чтения не требуется блокировка данных, поэтому редакторы не блокируются. Также это сокращает количество блокировок и минимизирует возможность перерасхода ресурсов блокировки. Изоляция уровня Read committed с использованием версий строк и изоляция Snapshot созданы для обеспечения целостности чтения версионных данных на уровне статуса или транзакции.
Предотвращение проблем многопользовательского доступа
Можно снизить возможность возникновения проблем многопользовательского доступа, следуя этим рекомендациям:
Разработка приложений и рабочих процессов с подразумевающейся блокировкой
Необходимость ожидания, пока отпустится блокировка, часто является результатом плохо разработанных приложений или рабочих процессов. При разработке надо убедиться, что блокировка запрашивается, когда она действительно нужна. Вы можете добиться этого путем создания стандартов последовательности обновления по всем таблицам. Это должно помочь вам избежать появления взаимоблокировок (или тупиков). Чтобы сократить количество удерживаемых блокировок, лучше всего сделать так, чтобы любые запросы на изменение данных применялись в конце единицы логики приложения или рабочего процесса, выполняющего транзакцию.
Установите необходимый уровень изоляции (Oracle, DB2, Informix)
Уровень изоляции влияет на время, которое транзакция будет блокировать данные. Чем выше уровень изоляции, тем дольше транзакция будет удерживать блокировку. Чем дольше транзакция удерживает блокировку, тем сильнее она увеличивает целостность данных, но за счет увеличения конкурентного использования. Если это приемлемо для ваших целей, вы можете сократить уровень изоляции.
Регистрация данных как версионных
Улучшение многопользовательского доступа с помощью регистрации данных в качестве версионных. Если вы обрабатываете данные с помощью сторонних приложений, рассмотрите возможность регистрации данных как версионных с опцией перемещения изменений в таблицу базы. Это позволит сторонним приложениям видеть изменения, применяющиеся в версии базы геоданных Default, а также добавит приложениям ArcGIS и ArcObjects, которые иначе испытывали бы трудности при многопользовательском доступе, возможность редактирования и управления версиями данных. Когда редактор изменяет версионную таблицу, блокировка не используется, что позволяет редактировать данные в полной изоляции от других пользователей.