Здравствуйте, Gt_, Вы писали:


КДВ>>например:
КДВ>>read write
КДВ>>consistency
КДВ>>nowait

КДВ>>или
КДВ>>read write
КДВ>>concurrency
КДВ>>nowait

КДВ>>оба случая — уровень изолированности snapshot.

Gt_>и какое отношение к спору имеет snapshot ? речь шла о READ COMMITTED. я не пойму — вы тоже утверждаете, что с помощью неких параметров Read committed транзакции можно получать консистентный набор ?? (в том топике эфект неконсистентного набора вы упорно называете "неатомарным" )

[ Осторожно, чтобы не было стыдно за сказанную глупость ]

Выборка множества с уровнем изоляции read-commited вполне может вернуть записи, которые были "из вне" изменены и закоммичены после fetch. Это, да. Я даже помнится "бутылку пива" выиграл поэтому поводу ... в 99 году.

В целом это не так и страшно. Неприятно, но не страшно. Потому что одним запросом, как правило, дело не обходится. А что бы второе множество было согласовано с первым — нужно повышать уровень изоляции.

Gt_>не понял при чем тут cursor stability, но сразу вопрос — что на IL snapshot "insert into table1 select * from table1" не зациклится !?

Зациклится. Не знаю как щас (и даже лень проверять) — но раньше циклил на ура

Вот. Но все это теоритические изыски (цель которых — попрыгать на известных багах сервера) и кои совершенно не мешают эксплуатации FB

КД>Выборка множества с уровнем изоляции read-commited вполне может вернуть записи, которые были "из вне" изменены и закоммичены после fetch. Это, да. Я даже помнится "бутылку пива" выиграл поэтому поводу ... в 99 году.

ну наконец-то, может вы сможете донести эту нехитрую мысль клиническому тормозу Alex.Che ? или там совсем клиника ?

КД>В целом это не так и страшно. Неприятно, но не страшно. Потому что одним запросом, как правило, дело не обходится. А что бы второе множество было согласовано с первым — нужно повышать уровень изоляции.

на сколько мне известно IB и его клоны это единственные из версионников которые на READ COMMITTED не способны получить консистентный набор: oracle, mysql/innodb, mssql/read_committed_snapshot зафетчат те строки какие находились на момент запроса, кладя болт на то что со строкаими произошло после запроса (вот про postgres не вкурсе).

КД>Зациклится. Не знаю как щас (и даже лень проверять) — но раньше циклил на ура
ну правильно. баг с cursor stability от уровня изолированости никак не зависит.

ЗЫ. разобравшись с read committed можем наконец вернутся к "Более дебильной реализации" которую вы "не встречал." ?

Gt_

Здравствуйте, Gt_, Вы писали:

КД>>Выборка множества с уровнем изоляции read-commited вполне может вернуть записи, которые были "из вне" изменены и закоммичены после fetch. Это, да. Я даже помнится "бутылку пива" выиграл поэтому поводу ... в 99 году.

Gt_>ну наконец-то, может вы сможете донести эту нехитрую мысль клиническому тормозу Alex.Che ? или там совсем клиника ?

Данунах (уж прости меня) — это не я и не он(?) начал все валить в одну кучу. Как я уже писал — мне всегда было ... на уровень изоляции read-commited.

Gt_>ЗЫ. разобравшись с read committed можем наконец вернутся к "Более дебильной реализации" которую вы "не встречал." ?

Это не ко мне

Все что я хотел узнать в этой ветке — так это про параллельные транзакции в одном коннекте

Но как только просил конкретных примеров — все прячутся

КД>Но как только просил конкретных примеров — все прячутся
да пожалуйте:

Using Autonomous Triggers

Among other things, you can use database triggers to log events transparently. Suppose you want to track all inserts into a table, even those that roll back. In Example 6-47, you use a trigger to insert duplicate rows into a shadow table. Because it is autonomous, the trigger can commit changes to the shadow table whether or not you commit changes to the main table.

Example 6-47 Using Autonomous Triggers

CREATE TABLE emp_audit ( emp_audit_id NUMBER(6), up_date DATE,
                         new_sal NUMBER(8,2), old_sal NUMBER(8,2) );

-- create an autonomous trigger that inserts into the audit table before
-- each update of salary in the employees table
CREATE OR REPLACE TRIGGER audit_sal
   BEFORE UPDATE OF salary ON employees FOR EACH ROW
DECLARE 
   PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
  INSERT INTO emp_audit VALUES( :old.employee_id, SYSDATE, 
                                :new.salary, :old.salary );
  COMMIT;
END;
/
-- update the salary of an employee, and then commit the insert
UPDATE employees SET salary = salary * 1.05 WHERE employee_id = 115;
COMMIT;

-- update another salary, then roll back the update
UPDATE employees SET salary = salary * 1.05 WHERE employee_id = 116;
ROLLBACK;

-- show that both committed and rolled-back updates add rows to audit table
SELECT * FROM emp_audit WHERE emp_audit_id = 115 OR emp_audit_id = 116;

Здравствуйте, Gt_, Вы писали:

КД>>Но как только просил конкретных примеров — все прячутся
Gt_>да пожалуйте:

Gt_>Using Autonomous Triggers

Спасибо, но интересовали независимые транзакции на уровне клиента.

Я несколько раз описывал что именно. Последний раз Sinclair-у, кажется.

Здравствуйте, Gt_, Вы писали:

КДВ>>оба случая — уровень изолированности snapshot.

Gt_>и какое отношение к спору имеет snapshot ? речь шла о READ COMMITTED. я не пойму — вы тоже утверждаете, что с помощью неких параметров Read committed транзакции можно получать консистентный набор ?? (в том топике эфект неконсистентного набора вы упорно называете "неатомарным" )

snapshot конечно никакого отношения к делу не имеет. да, неконсистентный набор я называю неатомарным, что в принципе
одно и то же. Насчет возможности атомарного, или консистентного набора в RC, я не утверждаю, потому
что в IB/FB это невозможно. Вернее, возможно, с оговорками, и в случае когда в плане запроса
есть конструкция SORT.

Gt_>аргументация чАго ? что RC в IB/FB способен получить консистентный набор ? что RC в oracle на это не способен ? я не понимаю что вы своей аргументацией хотите сказать ...

типичное передергивание
а) я про Оракл ничего не хочу сказать. у него запросы консистентные в RC, и пусть
б) аргументацию я последовательно изложил в упомянутом топике на sql.ru
могу повторить еще раз. в IB/FB в уровне изолированности RC можно получить консистентный набор для Select
только если на время select перевести уровень изолированности в snapshot.
Надеюсь, понятно, почему? Если нет, отвечу — в IB/FB нет блокировок по чтению. есть версионность.
Также, сам по себе read committed предполагает нестабильность результатов отдельных select.
это стандартно. Следовательно, если разные select относительно друг друга нестабильны, то это
нормально. А если сам select нестабилен в RC — это ненормально? Так вот, ненормальность можно
исправить выполнением запроса в "микро-snapshot", если позволите такой термин.
Отсюда я делаю вывод, что подобная функциональность хоть и возможна, но не нужна.
Потому что RC не предназначен для "стабильности" как уровень изолированности non-repeatable read.

Gt_>не понял при чем тут cursor stability, но сразу вопрос — что на IL snapshot "insert into table1 select * from table1" не зациклится !?

понятно. то есть Вы, это еще один маньяк, который приколебался к этому пресловутому insert into select,
который в свою очередь к уровню изолированности никакого отношения не имеет, потому что выполняется
в одной транзакции, т.е. видит свои же данные. Как бороться с ЭТИМ — давно известно.
Фатальным это не является. считайте это implementation defined. И еще раз подчеркну — это
не относится к уровням изолированности транзакций вообще никаким боком.

КДВ>>тут непонятно, почему база осталась corrupted, если бэкап был восстановлен.

Gt_>бэкап делался до прогона теста, т.е. на него еще нужно накатить лог.

ну если так... А если выдернуть диск с логом? Впрочем, это уже обсуждали в "сравнении СУБД",
в отношении Оракла и MS SQL.
Относительно IB/FB могу сказать, что в них восстановить базу можно либо до уровня
последнего бэкапа, либо до уровня последнего инкрементного бэкапа в FB 2 или до уровня
последнего архивированного журнала в IB 2007. Что в принципе одно и то же.
И конечно, так как из лога журналов, здесь состояние базы не восстановить, ни в IB ни в FB.

Здравствуйте, Кузьменко Д.В., Вы писали:

КДВ>ссылкой на документ, в котором написано про миниоткаты в RC в Оракле.
Например здесь:
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:11504247549852

КДВ>я поискал на techdocs, ничего похожего не нашел.
Если я правильно помню, то в доках этого нет, заставили Кайта проговориться, так поведение-то сервера надо объяснять. В связи с тем, что реализация кривая, оракл тщательно обходит этоу особенность в своей документации (но это уже совсем оффтопик). Хотя зачем искать, когда это довольно просто проверяется.
Вообще разборки по оракловской реализации RC, только на этом форуме, отгремели еще года четыре назад.

КДВ>не знаю.
Ну а что тогда?

КДВ>Вы заявили, что Вы знаете версионность лучше меня.
Исключительно в ответ на попытки обвинииь меня в том, что я знаю ее хуже, равно как и другие способы работы планировщиков БД.

КДВ>IB/FB Вы не знаете, а следовательно никак не можете составить ПОЛНУЮ картину по реализации версионности в СУБД.
ПОЛНОЙ картины не знает никто. А дял того чтобы понять, что может, что не может и причем тут вообще версионность — достаточно нескольких не самых новых учебников и пары лет практики.

КДВ>Это муть голубая.
Не нравится — не ешь.

Здравствуйте, Alex.Che, Вы писали:

AC>Иван,
Нда. Вот уж не думал, что меня с "этим" перепутают, зачем людей-то по себе судить?... (
Обычно я для ахинеи использую другой ник, но Alex.Che уже к сожалению знаят, приходится воздерживаться...

AC>ты сперва почитай таки доку, ссылку на которую тебе дали, а потом приходи, будем обсуждать нюансы
AC>IL RC в FB, и его отличия от Oracle с его "миниоткатами". До тех пор, пока не прочитаешь
Если имеется ввиду ссылочка на Critique of ANSI SQL isolation levels, то вот лично я (IB, Merle) ее читал еще в 99-м или 98. Самое забавное в том, что первый русский перевод этой классичской статьи (который был опубликован на osp) был настолько крив, что полностью искажал смысл. В вашу версию перевода я даже не заглядывал, но будьте аккуратнее, прочитайте все-таки оригинал..

Здравствуйте, Alex.Che, Вы писали:

AC>Вань, мужики в поле пашут.
Ну вот и паши...

AC>Напоминаю, речь идёт о твоих инсинуациях на тему:
Это не инсинуации — это разжевывание элементарных вещей.

AC>А то всё фантазии какие-то, полунамёки...
Никаких полунамеков. Я все очень четко описал, как для самых маленьких. Оракл выполняет откат одного запроса, при изменении данных в предикате, а FB — нет.

AC>Вот она.
По этой ссылке нет упоминания о том, что FB выполняет откат зпроса при изменении данных в предикате в RC.
Следовательно, у Оракла RC согласованнее. Возражения есть?

Здравствуйте, SP_, Вы писали:

SP_>Хм, а кто мне запретит абсолютно аналогичным способом "нарушать изолированность" использую 2 разных соединения?
Это клиника. Я тут с кем вообще разговариваю? Сколько раз надо повторить, что никто не запретить, но так делать все равно не надо?
Что дело не в том из скольких коннектов это делается, а в том, что так в любом случае делать нельзя.

SP_>Имея схему "один коннект — много транзакций" всегда можно применять ее как "один коннект — одна транзакция".
Можно. Но нет смысла. Там где просто можно — это сложнее, а в остальных случаях — не стоит этим заниматься.

SP_> FB попросту более гибок.
Предоставляет больше способов прострелить себе ногу?

SP_>Навскидку, при ограничении числа одновременных коннектов(например купленных по лицензии) к БД.
Нет слов..

Здравствуйте, SmlMouse, Вы писали:

SM>Да? Честно-честно? А если всё-таки немного подумать?
А ты еще не думал? Ну попробуй...

SM>Данные существовали до старта T1
И кто помешает их поменять?

SM>Итак, некомпетентность твою я уже увидел.
Это ты просто свою продемонстрировал.

SM>Уходим от твета?
Призываем к ответу.

SM>Слив защитан
Сломался?

Здравствуйте, IB, Вы писали:

IB>Здравствуйте, Пацак, Вы писали:

П>> Бороться со святой верой не намерен — это личное дело каждого верующего.
IB>Ок, верьте..

П>>...тем более когда оппонент постоянно переводит тему.
IB>Я не меняю, это вы за темой не следите.
IB>Ты в чем-то не согласен с процитированным текстом?


П>> Теперь вот потоки еще зачем-то приплел,
IB>Я приплел?! Ребята, у вас какая-то фатальная проблема с отслеживанием хода дискуссии...

П>> В общем нафиг такой спор, хочешь считать всех программистов firebird тупорылыми придурками,
IB>Ну, к тому чтобы сформировалось такое мнение, в этом топике было приложено очень много усилий..

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