Может ли запрос с уровнем изоляции READ UNCOMMITTED вызвать блокировки таблиц, к которым он обращается?
Моему приложению требуется пакетная обработка 10M строк, результат сложного SQL-запроса, объединяющего таблицы.
Я планирую повторять набор результатов, читая по сто за одну итерацию.
Чтобы запустить это на занятой производственной базе данных OLTP и избежать блокировок, я решил запросить с уровнем изоляции READ UNCOMMITTED.
Будет ли это убрать запрос из любой записи в БД? избегать каких-либо блокировок строк / таблиц?
Моя главная проблема - мой запрос, блокирующий любую другую деятельность с БД, я гораздо меньше беспокоюсь об обратном.
Примечания стороны:
1. Я буду читать исторические данные, поэтому я вряд ли увижу незафиксированные данные. Это нормально, если я сделаю.
2. Процесс итерации может занять несколько часов. Соединение с БД останется открытым через этот процесс.
3. У меня будет максимум два таких одновременных экземпляра.
4. Я могу терпеть двойные ряды. (по продукту прочитано незафиксировано).
5. DB2 является целевой БД, но я хочу решение, которое подходит и для других поставщиков БД.
6. Поможет ли уровень изоляции моментальных снимков очистить память сервера?
3 ответа
Мой ответ относится к SQL Server.
Блокировка чтения зафиксированных выпусков после прочтения каждой строки (приблизительно). Блокировка, вероятно, не ваша проблема.
Я рекомендую вам использовать более безопасный READ COMMITTED, Еще лучше, используйте изоляцию снимка. Это устраняет много проблем с блокировкой. Есть и недостатки, так что лучше почитать об этом.
Моя главная проблема - мой запрос, блокирующий любую другую деятельность в БД
Изоляция моментального снимка устраняет все проблемы с блокировкой для транзакций только для чтения. Никакой блокировки в любом случае, полная согласованность данных. Помните, что длительные транзакции могут привести к заполнению TempDB версиями снимков.
Соединение с БД останется открытым через этот процесс.
Это проблема, потому что сбой в сети, развертывание приложения или зеркальное переключение при сбое убило бы ваш пакетный процесс.
Имейте в виду, что чтение без фиксации может привести к тому, что запросы время от времени будут терпеть неудачу. Вам нужно повторить логику или терпеть неудачные задания.
Вы действительно сталкивались с реальными блокировками при чтении?
Насколько я понимаю, единственная причина, по которой READ UNCOMMITED существовала в стандарте SQL, состояла в том, чтобы разрешить неблокирующее чтение. Поэтому я не знаю DB2, но ставлю вслепую, что она не блокирует данные во время чтения в режиме READ UNCOMMITED. Однако большинство современных систем RDBMS вообще не блокируют данные во время чтения (*). Поэтому READ UNCOMMITED либо недоступен (например, в Oracle), либо незаметно повышен до READ COMMITED (PostgreSQL).
Если вы можете свободно выбирать движок, либо проверьте обработку уровня изоляции транзакций DB2, либо перейдите к Oracle / PostgreSQL / other.
(*) Точнее, они не только блокируют данные. Некоторые общие блокировки могут быть размещены в запрашиваемых таблицах, поэтому никакой DDL не изменяет их во время чтения.
В sql server Уровень изоляции транзакции Чтение незафиксировано, без блокировки таблицы.