|
|
|
microsoft sql i oracle, всётаки на чём остановиться ?
|
|||
|---|---|---|---|
|
#18+
2 Violina Да недавно тут же говорилось про какой-то пример типа телеметрии, где надо часто получать выборки, а в то же время постоянно что-то в таблице меняется, и чтобы не держать блокировками используется dirty read. Тут фенька в том (как говорилось), что очень точные данные не нужны (к тому же они постоянно меняются), а нужен некий приблизительный образ текущего состояния, поэтому вот так и сделали. Просто не забывайте, что на RDBMS пишут не только Склад, Зарплата и т.п., где всё должно быть с точностью до копейки, а и другие задачи, где грязное чтение выручит. Я вообще за то, чтобы поменьше вводить искусственных ограничений (или вернее за возможность снять их, когда надо). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2003, 12:25:54 |
|
||
|
microsoft sql i oracle, всётаки на чём остановиться ?
|
|||
|---|---|---|---|
|
#18+
2 KonstN. Не знаю, что я не так пишу. Но я же и гворю что это ПЛОХО. В данном примере нельзя применять грязное чтение. НУжно только чтение закомиченных данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2003, 12:31:20 |
|
||
|
microsoft sql i oracle, всётаки на чём остановиться ?
|
|||
|---|---|---|---|
|
#18+
где надо часто получать выборки, а в то же время постоянно что-то в таблице меняется, и чтобы не держать блокировками используется dirty read. Я вообще за то, чтобы поменьше вводить искусственных ограничений (или вернее за возможность снять их, когда надо). Так я и имею ввиду что в Оракл получать выборки можно всегда , query ведь не блокируются. Для этого вводить dirty read нет необходимости. Нужно правильно настроить rollback segments. По поводу точности - точность примерно одинакова. В случае Oracle в отчете могут отсутствовать данные которые потом закомитили. При dirty read в отчете могут присутствовать данные которые потом были отменены. Так что зачем вводить нелогичную притянутую за волосы концепцию dirty read все еще не понятно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2003, 12:36:29 |
|
||
|
microsoft sql i oracle, всётаки на чём остановиться ?
|
|||
|---|---|---|---|
|
#18+
2 Violina согласен с тобой. Грязное чтение это черт знает что. Прочто на MS SQL некоторые вещи иначе не решить просто. Это ты на Oraclе пишешь select и не задумываешься что запись заблокирована. dirty read - это наружение понятие транзакционности. Их слова об ускорении -это от того что ( повторюсь) select на MS SQL будет ждать пока данные не отпустят. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2003, 12:44:46 |
|
||
|
microsoft sql i oracle, всётаки на чём остановиться ?
|
|||
|---|---|---|---|
|
#18+
2 Violina >Так я и имею ввиду что в Оракл получать выборки можно всегда, query ведь не блокируются. Тут ты немного заблуждаешься. На примере покажу. Предположим у тебя есть таблица с товарами и их ценами. Менеджер говорит "Поднимаем цены на 10%" Делаем Код: plaintext 1. , но commit не делаем. Теперь он приходит к другому программеру и говорит "Покажи-ка мне цены". Тот делает Код: plaintext 1. , и менеджер с удивлением видит первоначальные цены без поднятия цены. Вот что означает в Оракле возможность чтения данных, по которым делаются изменения без commit. Только после commitа изменения становятся доступны всем, а до этого все могут читать данные, которые были в базе до начала транзакции. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2003, 13:23:42 |
|
||
|
microsoft sql i oracle, всётаки на чём остановиться ?
|
|||
|---|---|---|---|
|
#18+
2 KonstN . Ну так это же и хорошо. Транзакция не зафиксирована. Втрой программер увидел все правильно. Можно не на прайсах объяснить а на документах. Подходт к тебе человек и говорит. Стать поддпись на документ. Ты ставишь, но коммит не делаешь. В это время другой человек печатет документы. 2 случая 1) Печатает без твоей подписи. 2) Печатает с твоей подписью. А ты подумал. Блин мне же 10 лет тюрмы светит если подпишу. И говоришь rollback. А документо уже распечатан. Результат - тебя посадили на 10 лет ). Вот тут-то и катит грязное чтение ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2003, 13:30:09 |
|
||
|
microsoft sql i oracle, всётаки на чём остановиться ?
|
|||
|---|---|---|---|
|
#18+
во нашел по теме: http://dbforums.com/arch/48/2002/5/392828 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2003, 13:30:12 |
|
||
|
microsoft sql i oracle, всётаки на чём остановиться ?
|
|||
|---|---|---|---|
|
#18+
А если например update Код: plaintext прошел только на половину к моменту окончания создания отчета. Куда можно будет пойти с таким отчетом?:-) Данная проблематика отражает и реальную дествительность. Например референту дали задания внести изменения в прайс лист в Exel. Она начала это делать. Ни одному здравомыслящему человеку не придет в голову требовать отчет по новым ценам пока она не закончит их изменения. Имеет место блокировка - референт скажет подождите немного, имейте терпение наконец! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2003, 13:42:16 |
|
||
|
microsoft sql i oracle, всётаки на чём остановиться ?
|
|||
|---|---|---|---|
|
#18+
Ребят, эта ветка изначально имела название для форума Сравнение СУБД. А теперь и по содержанию всё больше и больше скатывается :) 2 Violina >Так я и имею ввиду что в Оракл получать выборки можно всегда, query ведь не блокируются. Для этого вводить dirty read нет необходимости. Нужно правильно настроить rollback segments. Я писал в ответ на эту фразу. Ты написала здесь, что dirty read вводить нет необходимости, потому что Оракл читает данные и так. Но тут есть разница читает ли он изменённые незакомиченные данные (это и есть dirty read) или неизменённые, существовавшие до начала транзакции (как и делает Оракл). Ещё раз повторюсь - иногда, в редких случаях такая необходимость (читать грязные незакомиченные данные) существует, именно грязные, изменённые другим процессом. Бывает и всё тут :) 2 Работник Опять ты так... Я этот пример приводил для иллюстрации как Оракл выходит из положения неблокирования записей при изменении. Для тебя ещё раз повторю - базы бывают не только с деньгами и документами, но и просто с данными, для которых строгий коммит не всегда важен. Понятно? 2 Gt Хорошая ссылка "по теме" Это совсем не по теме. Это надо постить в Сравнение СУБД, да и то она мне на первый взгляд показалась топтанием MSSQL. Не надо его ругать - куча народа на нём работает, и всё у них хорошо, а от того, что он развивается, Оракл слабее не становится. Или становится? ;) 2 Violina >Данная проблематика отражает и реальную дествительность. Ты отражаешь здесь реальную действительность списка цен, но не более того. В настоящей реальной действительности бываю такие вещи, что и не снились Ораклу Ну если без шуток, то уровни изоляции транзакций утверждены ANSI, а там, я надеюсь, далеко не дураки. DIRTY READ имеет право на существование. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2003, 16:56:08 |
|
||
|
microsoft sql i oracle, всётаки на чём остановиться ?
|
|||
|---|---|---|---|
|
#18+
2 KonstN Вы писали: "Бывает и всё тут :)". Приведите хотя бы 1 пример (где используеться грязное чтение не по тому, что MS SQL данные блокирует а потому что так надо). Может я ошибаюсь, а вы меня на путь истиный наставите. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2003, 17:08:52 |
|
||
|
microsoft sql i oracle, всётаки на чём остановиться ?
|
|||
|---|---|---|---|
|
#18+
Но тут есть разница читает ли он изменённые незакомиченные данные (это и есть dirty read) или неизменённые, существовавшие до начала транзакции (как и делает Оракл). Измененые незакомиченные данные понятие растяжимое. Например пользователь выбрал набор данных и редактирует их в некой форме, и post еще не далал. Эти изменения тоже вроде как незакомиченные, но их не увидит даже dirty read, потому что база о них еще не знает. Так что если вдруг кому то понадобится видеть незакомиченные данные, dirty read не всегда сможет это обеспечить. Ну если без шуток, то уровни изоляции транзакций утверждены ANSI, а там, я надеюсь, далеко не дураки. Оракл концепторы вроде тоже не дураки, и то что в Оракл нету DIRTY READ приятно радует. DIRTY READ имеет право на существование. Да ладно, я не зато чтобы изничтожить DIRTY READ. Елси кто то с помощью него сможет решить насущные проблемы пожалуйста. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2003, 17:13:53 |
|
||
|
microsoft sql i oracle, всётаки на чём остановиться ?
|
|||
|---|---|---|---|
|
#18+
2 Работник Кто я такой, чтобы тебя на путь истинный наставлять? Предположим (внимание, я пишу "предположим"!) у нас есть данные, которые снимаются с температурных датчиков. Их достаточно много (несколько тысяч), поэтому запись происходит некоторое продолжительное время. Запись одного съёма происходит в одной транзакции (не берём в расчёт вариант, что каждая запись записывается в собственной транзакции). Тебе нужно как можно быстрее узнать, что в определённой области произошло нарушение заданного температурного режима. Один датчик может врать - вывод нужно делать по нескольким. Постоянно ходят селект-запросы на эту логику. В случае ораклового подхода ты не получишь свежих данных до тех пор пока они не будут закоммичены, а dirty read тебе позволит увидеть их сразу. Будут они отроллбачены или нет, в случае проблемы уже не имеет значения. Конечно, можно сказать, что пример не совсем для базы данных, но у меня нет времени долго придумывать хороший железобетонный пример. Надеюсь и этот достаточно хорош для понимания. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2003, 17:23:34 |
|
||
|
microsoft sql i oracle, всётаки на чём остановиться ?
|
|||
|---|---|---|---|
|
#18+
А вот это уже скорее задача для real time system. Отслеживать нарушения заданного температурного режима лучше не с помощью dirty read и вообще не путем чтения данных, которые кладутся в базу, а использовать систему нотификации. См. тему издевательство на Оракл В телекомах real-time у оракла только кажущийся. На самом деле до оракла работает в действительно реальном времени база коммутатора, которая периодически сбрасывает информацию в оракл/db2 etc. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2003, 17:37:23 |
|
||
|
microsoft sql i oracle, всётаки на чём остановиться ?
|
|||
|---|---|---|---|
|
#18+
Violina-a-a-a... Ещё раз повторяю. ========= Конечно, можно сказать, что пример не совсем для базы данных, но у меня нет времени долго придумывать хороший железобетонный пример. Надеюсь и этот достаточно хорош для понимания. ========= Идея в том, что нужно быстро прочесть данные, которые ложатся в рамках одной длительной транзакции (нельзя её побить на кусочки), и их закоммиченность не имеет значения. Хорош! Давай лучше про что-нибудь другое :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2003, 17:40:14 |
|
||
|
microsoft sql i oracle, всётаки на чём остановиться ?
|
|||
|---|---|---|---|
|
#18+
да пора прекращать. Всем спасибо за интересную дискусию! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2003, 17:54:24 |
|
||
|
microsoft sql i oracle, всётаки на чём остановиться ?
|
|||
|---|---|---|---|
|
#18+
Итог KonstN такой пример так и не придумал. Может его и нет? :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2003, 18:43:18 |
|
||
|
microsoft sql i oracle, всётаки на чём остановиться ?
|
|||
|---|---|---|---|
|
#18+
Работнику Мое скромное личное мнение если ты при открытии формы для редактирования данных начинаешь транзакцию то у тебя всегда будут проблемы с блокировками да и вообще будут проблемы. А ты не пробовал делать update через хранимые процедуры ???. То есть пользователь отредактировал данные и нажал ОК ты запустил транзакцию вызвал хранимую процедуру если все отработало без ошибок то commt иначе rollback и забыл за все проблемы сразу. И почему это гемморойный подход просвяти пожалуста почему??? я что-то не понимаю ??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.05.2003, 03:07:04 |
|
||
|
microsoft sql i oracle, всётаки на чём остановиться ?
|
|||
|---|---|---|---|
|
#18+
2 All Хотелось бы что бы разговор шел в конструктивном режиме. Ведь никто никого обидеть не хочет. Просто общаемся. Высказываем мыли в слух ( возможно не всегда верные) 2 andreym999 >Мое скромное личное мнение если ты при открытии формы для редактирования данных начинаешь транзакцию то у тебя всегда будут проблемы с блокировками да и вообще будут проблемы. Наверное не всегда. При открытии формы запись наверное блокировать не стоит, согласен. Но после того, как пользователь изменил хоть одно поле запись стоит заблокировать, что бы другие с ней не делали Update,Delete. Т.к select они всегда смогут сделать то проблем тут не вижу Пример: Пользователь открывает форму платежного поручения. Редактирует в нем наименование получателя. как только он начал редактировать наименование запись блокируеться и ничего с документом сделать нельзя. Вроде все верно. Нильзя его отправить в другой банк( вроде хорошо ) и т.д >А ты не пробовал делать update через хранимые процедуры ???. То есть пользователь отредактировал данные и нажал ОК ты запустил транзакцию вызвал хранимую процедуру если все отработало без ошибок то commt иначе rollback и забыл за все проблемы сразу. На мой взгляд такой подход плох по следйющей причине. Подняли мы форму , запись начали редактировать, но не заблокировали т.е другие с этой записью делают что хотят ( например update, delete) И когда пользователь нажмет кнопку процедура будет update уже другую запись ( так как ее могли поменять). пример: Пользователь открывает форму платежного поручения. Редактирует в нем наименование получателя. Запись не блокируеться. Другой пользователь отправляет этот документ в другой банк (он не знает ,что запись редактируеться). Когда первый закочил редактировать оказываеться, что уже поздно - документ ушел. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2003, 13:47:14 |
|
||
|
microsoft sql i oracle, всётаки на чём остановиться ?
|
|||
|---|---|---|---|
|
#18+
Работнику. Твой пример немного неккоректен. мне так кажется Если Ваша банковская система такое допустит то честно говоря я вам не завидую. У нас например(а я работаю в банке) документ (по памяти точно не помню) имеет статус введен,проведен, введен с ошибкой и есть еще что-то не помню. Так вот пока документ находится в со статусом введен, введен с ошибкой его можно редактировать, а если он проведен его уже редактировать нельзя. Надо сначала статус изменить. Документ может уйти только если он будет сначала верефицирован. "а мой взгляд такой подход плох по следйющей причине. Подняли мы форму , запись начали редактировать, но не заблокировали т.е другие с этой записью делают что хотят ( например update, delete) И когда пользователь нажмет кнопку процедура будет update уже другую запись ( так как ее могли поменять)." Можно добавить поле с флагом редактирование. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.05.2003, 23:44:53 |
|
||
|
microsoft sql i oracle, всётаки на чём остановиться ?
|
|||
|---|---|---|---|
|
#18+
> У нас например(а я работаю в банке) документ (по памяти точно не помню) имеет статус введен,проведен, введен с ошибкой и есть еще что-то не помню Думаю это не изменит ситуацию ( наличие статусов роли не играет) Вернемся еще раз к ситуации. Операционист набирает исходящее платежное поручение и при этом ошибаеться в наименовании получателя ( просто 2 буквы местами поменял). Через 5 минут он понимает это. Открывает тот же самый документ и начинает редактировать. В это время контролер верифицирует этот документ ( меняет ему статус на верифицирован) Отдел работы с коррсчетами отправляет этот документ( статус отправлен) А операционист только на этот момент завершил редактировани. На сервере выполнилась процедура. Пусть даже она ругнулась, что мол уже-то редактировать нельзя. ( Но когда он открывал форму редактировать можно было) Итог: Документ ушел неправильный. Хотя операционист хотел его сделать правильным. P.S А для исходящих нет возможности определить автоматически в общем случае правильно ли введен документ. Это только может сделать человек. Но не всегда он это сразу поймет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2003, 12:36:41 |
|
||
|
microsoft sql i oracle, всётаки на чём остановиться ?
|
|||
|---|---|---|---|
|
#18+
Я завтра посмотрю точно как это реализовано но помоему притянуто за уши Я писал что перед редактированием нужно изменить статус документа. Если хранимая процедкра при верификации не проверит текущий статус документа на момент апдейта то это проблема уже с логико у разработчиков. Но вообщем чтобы не лить воду завтра посмотрю и скажу точно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2003, 20:07:02 |
|
||
|
microsoft sql i oracle, всётаки на чём остановиться ?
|
|||
|---|---|---|---|
|
#18+
2 andreym999 Посмотри не используеться ли там механизм семафоров ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2003, 10:10:47 |
|
||
|
microsoft sql i oracle, всётаки на чём остановиться ?
|
|||
|---|---|---|---|
|
#18+
Посмотрел. Все очень просто могут два человека редактировать один документ. Кто последний тот и прав. ;) ;) ;). Если же начать редактирование документа а кто-то его проведет то при попытке апдейта будет облом -- сработает триггер. Вот так плохо ;) ;) ;). Но за все время эксплуатации системы пока таких проблем не возникало. Будем ждать ;) ;) ;). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2003, 10:51:45 |
|
||
|
microsoft sql i oracle, всётаки на чём остановиться ?
|
|||
|---|---|---|---|
|
#18+
2 andreym999 Не секрет если, что за система у вас стоит? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2003, 11:01:23 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=32156389&tid=1990206]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
206ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
68ms |
get tp. blocked users: |
2ms |
| others: | 206ms |
| total: | 520ms |

| 0 / 0 |
