|
|
|
работа с SQL / DAO
|
|||
|---|---|---|---|
|
#18+
Alexey TominА как же тогда можно простым select'ом получить "snapshot too old"? Так это как раз следствие отсутствия транзакции - данные, которые захотели прочитать, вовремя не заблокировали и они утекли из базы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.06.2014, 10:41 |
|
||
|
работа с SQL / DAO
|
|||
|---|---|---|---|
|
#18+
Сергей АрсеньевAlexey TominА как же тогда можно простым select'ом получить "snapshot too old"? Так это как раз следствие отсутствия транзакции - данные, которые захотели прочитать, вовремя не заблокировали и они утекли из базы. Категорически не согласен. При старте (неявной) транзакции она запрещает удалять из сегмента старых данных. Если во время выполнения select'а было слишком много изменений (а все данные держатся- вдруг наш select до них дойдёт?)- вылезает ошибка. Иначе мы не могли б получить согласованное чтение данных ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.06.2014, 14:18 |
|
||
|
работа с SQL / DAO
|
|||
|---|---|---|---|
|
#18+
Alexey TominPetro123пропущено... вот это НЕобязательно, т.к. сервер САМ стартует транзакцию (неявно) на ИЗМЕНЕНИЕ данных. Во-первых, он так же стартует транзакцию на чтение данных. Тот же Оракл- сам. А некоторые сервера хотят этого от клиента явно (и завершать- тоже явно, даже на чтение). давайте ближе к практике Господа. И не ругаться словами "сегмент". - если не было Commit с клиента на запрос модификации, то изменения не произойдут (сабж) - если не было START TRANSACTION с клиента на запрос чтения, то ничего "страшного не произойдёт". Мы получим данные. Так? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.06.2014, 15:09 |
|
||
|
работа с SQL / DAO
|
|||
|---|---|---|---|
|
#18+
Alexey TominИначе мы не могли б получить согласованное чтение данных Oracle получает их иначе. Поскольку он версионник, то он хранит не сами данные, а их состояние на определенные моменты времени (снимки). Выбрав любой момент времени (на который ему хватит сегмента отката) можно прочитать это состояние, для этого транзакция не нужна. Он же пишет, что снимок устарел, а не транзакция. Транзакция нужна либо для атомарности изменений, либо как один из механизмов для согласованного чтения нескольких запросов. Поэтому она и не создается вплоть до момента начала изменений или явного старта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.06.2014, 18:07 |
|
||
|
работа с SQL / DAO
|
|||
|---|---|---|---|
|
#18+
Сергей АрсеньевAlexey TominИначе мы не могли б получить согласованное чтение данных Oracle получает их иначе. Поскольку он версионник, то он хранит не сами данные, а их состояние на определенные моменты времени (снимки). Выбрав любой момент времени (на который ему хватит сегмента отката) можно прочитать это состояние, для этого транзакция не нужна. Он же пишет, что снимок устарел, а не транзакция. Транзакция нужна либо для атомарности изменений, либо как один из механизмов для согласованного чтения нескольких запросов. Поэтому она и не создается вплоть до момента начала изменений или явного старта. Непонятно. А если у меня стартовал один длинный select, и идет фетч, во время которого другая сессия успела изменить и закоммитить какую-то запись, которая попадает в мой запрос? Мой запрос ведь тоже будет выполняться в контексте некоей транзакции, чтобы обеспечить изолированность? Даже если я транзакцию явно не стартовал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.06.2014, 18:44 |
|
||
|
работа с SQL / DAO
|
|||
|---|---|---|---|
|
#18+
ДиезМой запрос ведь тоже будет выполняться в контексте некоей транзакции, чтобы обеспечить изолированность? Даже если я транзакцию явно не стартовал. IMHO. Не совсем, он будет выполнятся привязанным к моменту времени. Один запрос - одна операция. В Oracle он согласован сам по себе на какой-то момент времени. Транзакция это атомарная последовательность операций. Нужна (в Oracle) для изоляции запросов на уровнь serializable или для атомарности изменений на уровне read commited. Уровень изоляции snapshot, согласно SQL 92 для транзакий не описан. :) Он работает вне их. Просто анализ журнала, поскольку записи журнала неизменны (immutable), то транзакции, для обеспечения согласованности их чтения не нужны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.06.2014, 20:52 |
|
||
|
работа с SQL / DAO
|
|||
|---|---|---|---|
|
#18+
Сергей АрсеньевДиезМой запрос ведь тоже будет выполняться в контексте некоей транзакции, чтобы обеспечить изолированность? Даже если я транзакцию явно не стартовал. IMHO. Не совсем, он будет выполнятся привязанным к моменту времени. Один запрос - одна операция. В Oracle он согласован сам по себе на какой-то момент времени. Транзакция это атомарная последовательность операций. Нужна (в Oracle) для изоляции запросов на уровнь serializable или для атомарности изменений на уровне read commited. Уровень изоляции snapshot, согласно SQL 92 для транзакий не описан. :) Он работает вне их. Просто анализ журнала, поскольку записи журнала неизменны (immutable), то транзакции, для обеспечения согласованности их чтения не нужны. Isolation - это один из признаков модели ACID. Как может уровень изоляции snapshot существовать все транзакции, если уровень изоляции - это свойство транзакции? :) Это я к тому, что любой запрос к реляционной СУБД (в т.ч. Oracle) выполняется в рамках транзакции. Если клиент явно ее не стартует, значит это делает драйвер. При любой архитектуре СУБД. Также и с закрытием транзакции: не закрыл сам - драйвер сделает commit или rollback исходя из личных предпочтений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.06.2014, 23:18 |
|
||
|
работа с SQL / DAO
|
|||
|---|---|---|---|
|
#18+
[quot Диез]Сергей АрсеньевIsolation - это один из признаков модели ACID. Как может уровень изоляции snapshot существовать все транзакции, если уровень изоляции - это свойство транзакции? :) Еще раз повторю - такого уровня изоляции нет согласно SQL 92. Snapshot делается не за счет транзакции, а наоборот транзакция может использовать снимки. Для обычного запроса Oracle достаточно снимка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2014, 09:28 |
|
||
|
работа с SQL / DAO
|
|||
|---|---|---|---|
|
#18+
[quot Сергей Арсеньев]Диезпропущено... Еще раз повторю - такого уровня изоляции нет согласно SQL 92. Snapshot делается не за счет транзакции, а наоборот транзакция может использовать снимки. Для обычного запроса Oracle достаточно снимка. Всё, теперь понятно :) Я транзакцию понимаю в логическом смысле - как общий принцип обеспечения целостности данных. Вы говорите про внутренний механизм Oracle, связанный с записью в файлы. Оказывается, на форуме Оракла эти баталии идут давно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2014, 12:42 |
|
||
|
работа с SQL / DAO
|
|||
|---|---|---|---|
|
#18+
[quot Диез]Сергей АрсеньевВсё, теперь понятно :) Я транзакцию понимаю в логическом смысле - как общий принцип обеспечения целостности данных. IMHO. Транзакция это атомарная последовательность операций. Это один из способов обеспечения целостности данных. Для неизменяемых объектов она не требуется. С ними можно делать все что угодно (чтение) в произвольном порядке - их согласованность не нарушится. Что и используют версионники, работая с данными, какие были на какой-то момент времени. Фиксация атомарной последовательности им нужна, в основном, для согласованного изменения актуальных данных (ну или для фиксации момента времени по умолчанию). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2014, 15:40 |
|
||
|
работа с SQL / DAO
|
|||
|---|---|---|---|
|
#18+
Сергей Арсеньев Так это как раз следствие отсутствия транзакции - данные, которые захотели прочитать, вовремя не заблокировали и они утекли из базы."Snapshot to old" это комбинация из "оптимистичная фиксация" и "слишком долгая транзакция". А совсем не то, что вы написАли. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2014, 17:00 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=38666966&tid=2127068]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
152ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
46ms |
get tp. blocked users: |
2ms |
| others: | 248ms |
| total: | 489ms |

| 0 / 0 |
