Согласованность чтения транзакций Oracle? - PullRequest
3 голосов
/ 24 апреля 2010

У меня проблема с пониманием согласованности чтения в базе данных (Oracle).

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

Ответы [ 3 ]

10 голосов
/ 24 апреля 2010

Суть согласованности чтения такова: предположим, клиент откатывает свои изменения? Или предположим, что эти изменения потерпят неудачу из-за нарушения ограничения или сбоя системы?

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

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

редактировать

Согласованность чтения достигается за счет использования информации в табличном пространстве UNDO (сегменты отката в более старой реализации). Когда сеанс читает данные из таблицы, которая изменяется другим сеансом, Oracle извлекает информацию UNDO, сгенерированную этим вторым сеансом, и заменяет ее измененными данными в наборе результатов, представленном первому сеансу.

Если сеанс чтения является длительным запросом, он может завершиться неудачей из-за пресловутого ORA-1555: snapshot too old. Это означает, что экстент UNDO, в котором содержалась информация, необходимая для создания согласованного чтения, был перезаписан.

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

1 голос
/ 25 апреля 2010

Для систем с большим количеством пользователей, где пользователи могут «удерживать» блокировку в течение длительного времени, обычно используется шаблон оптимистической автономной блокировки , т.е. используйте версию в ОБНОВЛЕНИИ ... ГДЕ заявление.

Вы можете использовать дату, идентификатор версии или что-то еще в качестве версии строки. Также можно использовать виртуальный столбец ORA_ROWSCN, но сначала вам нужно прочитать его.

0 голосов
/ 06 мая 2010

Когда запись заблокирована из-за изменений или явного оператора блокировки, в заголовок этого блока делается запись. Это называется ITL (список заинтересованных транзакций). Когда вы приходите, чтобы прочитать этот блок, ваша сессия видит это и знает, куда идти, чтобы получить согласованную по чтению копию из сегмента отката.

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