Помогите найти доводы для начальства

← →
Sergey13 © (2006-06-23 12:22) [40]

> [39] evvcom © (23.06.06 12:18)

Ну и что? Этот оператор устанавливает свойства транзакции, а не стартует ее. Вся сессия, по большому счету - "читающая транзакция", хотя мне лично тоже этот термин слух слегка режет 8-).

← →
Курдль © (2006-06-23 12:30) [41]

> Desdechado © (23.06.06 12:05) [37]
> Т.е. SELECT выполняется вне контекста транзакции?! А если
> он единственный запрос за все время работы с БД?

Кому какая разница, чего я там читаю? Для всех правила одинаковы.
Если я открыл в своей сессии транзакцию принудительно и что-то там прочитал, ничего в БД не изменив, - я получу абсолютно те же данные, что и просто по запросу. Другое дело, если я открыл транзакцию, чего-то в базе натворил, а потом читаю результаты. Вот тогда я действительно увижу уникальный срез данных, характерный только для моей сессии (с учетом моих не утвержденных commit-ом изменений).

> evvcom © (23.06.06 12:18) [39]

Согласен, что транзакция может быть настроена на определенный уровень изоляции. Но в случае с ораклом - надо иметь какую-то чрезвычайно нетривиальную задачу, чтобы этим воспользоваться.

← →
Desdechado © (2006-06-23 12:43) [42]

> я получу абсолютно те же данные, что и просто по запросу.
Я повторю вопрос: SELECT может выполняться вне контекста транзакции?!

← →
Sergey13 © (2006-06-23 12:49) [43]

> [42] Desdechado © (23.06.06 12:43)
> Я повторю вопрос: SELECT может выполняться вне контекста
> транзакции?!

Повторю ответ: вся сессия - одна большая транзакция, если нет коммитов/ролбеков. Если есть, то сессия - непересекающаяся последовательность транзакций.

← →
evvcom © (2006-06-23 12:55) [44]

> а не стартует ее

А я и не говорил, что транзакция стартуется. Я только хотел обратить внимание, что все-таки понятие "читающей транзакции" имеется. И еще, для чего же это все-таки? Приведу опять Тома Кайта:
Помимо четырех уровней изолированности транзакции, определенных в стандарте
SQL92, Oracle обеспечивает еще один уровень — транзакции только для чтения. Тран-
закция только для чтения эквивалентна при чтении уровню изолированности
REPEATABLE READ или SERIALIZABLE в SQL92. Такая транзакция видит только
изменения, зафиксированные на момент ее начала, но в этом режиме не разрешена
вставка, изменение и удаление данных (другие сеансы могут изменять данные, но тран-
закция только для чтения — нет). Используя этот режим, можно достичь уровней
REPEATABLE READ и SERIALIZABLE READ без чтения фантомов.

← →
Desdechado © (2006-06-23 13:12) [45]

Sergey13 © (23.06.06 12:49) [43]
Значит, нет. Следовательно, возможны читающие транзакции. Что подтверждает и цитата из Кайта.
Т.о. остается выяснить, если я не установил специальных параметров транзакции, и просто сделал 100 SELECT"ов, не отключившись от базы, то что, я заблокировал все эти данные?! Чтой-то не верится...
А если не заблокировал, то эту транзакцию я могу держать сколь угодно долго, и другим юзерам от этого плохо не будет. Собственно, с этого я и начал.

← →
Sergey13 © (2006-06-23 13:27) [46]

2[45] Desdechado © (23.06.06 13:12)
>Следовательно, возможны читающие транзакции.
Я бы вместо "читающие транзакции" сказал "ничего не меняющие сеансы". Ибо транзакцию, в моем понимании надо подтверждать (или отменять), а "ничегонедеоание" этого не требует.
Естественно они ничего не блокируют. В Оракле даже "писатели" не блокируют "читателей". Единственное - под сеанс выделены ресурсы сервера и пустопорожнее их удержание не есть особо хорошо, но это уже другая пестня.

← →
ZeroDivide © (2006-06-23 13:31) [47]

> Reindeer Moss Eater © (23.06.06 11:29) [29]
>
> Правильный ответ надо искать в логике работы с данными конкретной
> предметной области. а не среди множества усвоеных с опытом
> правил и аксиом.

Абсолютно согласен. В IB/FB кусроры данных открываются и закрываются в контексте транзакции. В Oracle при Commit курсоры не закрываются, они либо читают последние подтвержденные изменения, либо читают последние неподтвержденные изменения в контексте автоматически открытой (Insert, Update, Delete) транзакции.

Ситуация:
Select <Редактирование пользователем> Update Commit
Вполне нормальная

А вот
Update <Редактирование пользователем> Update Commit
Действительно скушает память, но и только... На производительность это почти никак не повлияет.

← →
evvcom © (2006-06-23 13:45) [48]

> <Редактирование пользователем>

Это что такое? Чем отличается от Update? Не понял мысль.

← →
Sergey13 © (2006-06-23 13:50) [49]

> [48] evvcom © (23.06.06 13:45)
> > <Редактирование пользователем>
>
> Это что такое? Чем отличается от Update? Не понял мысль.

Это размышления пользователя - ту би, или, блин, нот ту би. 8-)

← →
Desdechado © (2006-06-23 14:14) [50]

Sergey13 © (23.06.06 13:27) [46]
> Я бы вместо "читающие транзакции" сказал "ничего не меняющие сеансы".
Т.е. я оказался прав. А проблемы только в разной терминологии.

> Ибо транзакцию, в моем понимании надо подтверждать (или отменять),
> а "ничегонедеоание" этого не требует.
А в моем: транзакция - это любое логически завершенное обращение к БД. Чтение - это не "ничегонеделание", это тоже обращение, т.е. транзакция.

← →
evvcom © (2006-06-23 14:18) [51]

> [50] Desdechado © (23.06.06 14:14)
> Т.е. я оказался прав.

Как говорил один великий лекарь,
Пациент скорее жив, чем мертв (с) Буратино
я скажу, что ты скорее прав, чем не прав. :)

← →
Sergey13 © (2006-06-23 14:28) [52]

2 [50] Desdechado © (23.06.06 14:14)
>А в моем: транзакция - это любое логически завершенное обращение к БД.
ИМХО, тут неправильно. Логин в БД - это тоже обращение к БД. Оно логически завершенное или нет?
Транзакция - это операция, переводящая нечто из одного согласованного состояния в другое согласованное. Если в неком процессе рассогласования нет как такового, то и транзакцией я бы этот процесс не назвал.

← →
Val © (2006-06-23 14:33) [53]

update mytable set myfield = 1
where myfield = 1
рассогласования нет как такового ;)

← →
Danilka © (2006-06-23 14:40) [54]

Из того-же Тома Кайта:
Основное назначение транзакций в базе данных — переводить ее из одного согласованного состояния в другое. При фиксации изменений в базе данных гарантируется сохранение либо всех изменений, либо ни одного. Более того, выполняются все правила и проверки, обеспечивающие целостность данных.
Транзакции базы данных обладают свойствами, сокращенно называемыми ACID
(Atomicity, Consistency, Isolation, Durability). Вот что означают эти свойства:
- Неделимость (Atomicity). Транзакция либо выполняется полностью, либо не выполняется.
- Согласованность (Consistency). Транзакция переводит базу данных из одного согласованного состояния в другое.
- Изолированность (Isolation). Результаты транзакции становятся доступны для других транзакций только после ее фиксации.
- Продолжительность (Durability). После фиксации транзакции изменения становятся постоянными.

А теперь вопрос: каким боком выделеное жирным имеет отношение к select-ам?
:)

← →
Danilka © (2006-06-23 14:44) [55]

точнее, наоборот, каким боком селекты имеют отношение к выделеному жирным. :)
вобщем, я считаю, что транзакции только на чтение - лишняя сущность, в подавляющем большинстве случаев.

← →
Sergey13 © (2006-06-23 14:45) [56]

2 [53] Val © (23.06.06 14:33)
>рассогласования нет как такового ;)
Его нет логически, по факту так сказать. Физически оно есть. Просто новое значение совпало со старым - частный случай.

← →
evvcom © (2006-06-23 14:47) [57]

> [54] Danilka © (23.06.06 14:40)

Я эту фразу и не стал цитировать, а прочел немного ниже и нашел [44]. Хотя если подумать, то Согласованность (Consistency) все же имеет отношение к селекту, которое и раскрывается в [44]

← →
Val © (2006-06-23 15:00) [58]

>[56] Sergey13 © (23.06.06 14:45)
Сергей, ради бога, я же пошутил..

← →
Sergey13 © (2006-06-23 15:03) [59]

> [58] Val © (23.06.06 15:00)

Да я тоже забыл смайлик вставить, в знак того, что понял это как шутку.
Исправляюсь. 8-)))))))))))))))

← →
ANB © (2006-06-23 15:11) [60]

Мне кажется информация из Тома Кайта касается не читающих транзакций, а уровня изоляции, с которым в оракле мало кто играет.
Таким образом ссылка на Тома Кайта в пользу существования читающих транзакций не корректна.
Если отбросить теоретическую шелуху, то транзакция в оракле начинается с первого изменения в БД и до коммита или роллбэка.
ситуация :
insert into Table1 <Пользователь ушел на обед> insert Table1 commit
приведет не только к съеданию ресурсов и разбуханию роллбэк сегмента (или чем его там в девятке заменили, но суть та же осталась), но и к блокировке на изменение таблицы Table1. Можете проверить сами. Читать, есно, из таблицы Table1 можно будет, но чтение будет идти из роллбэк сегмента (без учета добвленной записи), что тоже некузяво.

Задачу автора, если он ее нормально озвучит, наверняка можно решить без использования висячих транзакций. Правда, возможно понадобиться создать дополнительно временные таблицы.

← →
evvcom © (2006-06-23 15:18) [61]

> но и к блокировке на изменение таблицы Table1

Ну не так... :( Таблица не лочится. Лочатся только записи, которые апдейтятся. Соответственно с инсертом, вообще ничего не залочится, за исключением случая, если применяются пользовательские блокировки.

← →
ANB © (2006-06-23 15:31) [62]

> evvcom © (23.06.06 15:18) [61]

Блокировки возникают, если есть коллизия.

Например :

t1 (
ID, Name
)
на Name висит уникальный индекс.

Из первой сессии
insert into T1(ID, Name) values (1, "Вася");

Из второй сессии
insert into T1(ID, Name) values (2, "Петя"); -- пройдет
insert into T1(ID, Name) values (3, "Вася"); -- зависнет до коммита или роллбека в первой сессии.

Читаться будет при любом раскладе.

← →
Petr V. Abramov © (2006-06-23 15:32) [63]

set transaction read only - и имеем висячую транзакцию в статусе active, и до коммита/роллбэка DML вызовет ошибку
только вот зачем это надо - непонятно, потому как непонятно что вообще надо :)

← →
evvcom © (2006-06-23 15:40) [64]

> [62] ANB © (23.06.06 15:31)

Да, про такой случай запамятовал.

> [63] Petr V. Abramov © (23.06.06 15:32)

Сейчас выполнил:
set transaction read only; select * from dual;
никаких зависаний. Что имелось ввиду? И по Кайту вроде все понятно, для чего это.

Похоже, автора забили интеллектом или запугали.
А, может, он последовал совету запостить на sql.ru и отгрести тумаки :)

> evvcom © (23.06.06 15:47) [66]
а кто сказал, что я пытаюсь кого-то удивить :) просто народ 20 постов решал, бывают readonly транзакции, или нет :)

> [68] Petr V. Abramov © (23.06.06 15:56)

а....а.... Так вот это к чему :-)

> [67] Desdechado © (23.06.06 15:49)

Да, видимо, огрёб, унести не может. :)

readonly транзакции бывают.
других транзакций на чтение в орокле не бывает.
:)

Ну ка дай ссылочку на ветку . . .

не справился sql.ru, не оправдал высокое доверие :)

← →
Sergey Masloff (2006-06-23 19:40) [74]

Petr V. Abramov © (23.06.06 17:17) [73]
>не справился sql.ru, не оправдал высокое доверие :)
Кто б сомневался. А на самом деле никаких особых проблем с длительными транзакциями в оракле нет, так что сколько по бизнес-логике нужно столько и держать. Ситуации разные бывают, и на всякую ситуации свои механизмы. А легенды что хорошие транзакции-короткие транзакции оставим сторонникам религий и пользователям СУБД для которых это проблема ;-)

Помогите найти доводы для начальства Найти похожие ветки