Суть согласованности чтения такова: предположим, клиент откатывает свои изменения? Или предположим, что эти изменения потерпят неудачу из-за нарушения ограничения или сбоя системы?
До тех пор, пока клиент не подтвердит свои изменения, эти изменения не существуют. Любое решение, которое вы можете принять на основе фантомного чтения или грязного чтения, не будет более обоснованным, чем сценарий, который вы описываете. Действительно, они имеют меньшую юридическую силу, потому что изменения являются неполными и, следовательно, противоречивыми. Конкретный пример: если изменения клиента включают внесение депозита и снятие средств, насколько обоснованным будет ваше решение, если вы посмотрели счет, когда он внес депозит, но еще не снял деньги?
Другой пример: длительный пакетный процесс обновляет зарплату каждого сотрудника в организации. Если вы выполняете запрос на зарплату сотрудников, действительно ли вы хотите получить отчет, в котором будет показана половина сотрудников с обновленной зарплатой и половина с их старой зарплатой?
редактировать
Согласованность чтения достигается за счет использования информации в табличном пространстве UNDO (сегменты отката в более старой реализации). Когда сеанс читает данные из таблицы, которая изменяется другим сеансом, Oracle извлекает информацию UNDO, сгенерированную этим вторым сеансом, и заменяет ее измененными данными в наборе результатов, представленном первому сеансу.
Если сеанс чтения является длительным запросом, он может завершиться неудачей из-за пресловутого ORA-1555: snapshot too old
. Это означает, что экстент UNDO, в котором содержалась информация, необходимая для создания согласованного чтения, был перезаписан.
Блокировки не имеют никакого отношения к согласованности чтения. В Oracle пишет не блокировать чтения. Цель блокировок - предотвратить попытки других процессов изменить интересующие нас строки.