Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 10 11 12 13 14 [15] 16 17 18 19 .. 25   вперед  Ctrl
 Re: Нужна помощь  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
Кудряшка
Мое персональное скромное мнение по теме дискуссии: если в транзакции возникла ошибка - ее надо откатить и точка.

Угу. Вот идёт, например, ETL на скромный такой 1'000'000 записей. На 990'000-й возникла ошибка - надо всё нахрен откатить, и точка.

Кудряшка
Игнорировать выполнение "update T2" при возникновении ошибки - зло

Если это единственный метод обработки ошибок, который Вы знаете...
26 май 09, 10:46    [7226880]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Кудряшка
Member

Откуда: Сидней
Сообщений: 2219
SergSuper
Кудряшка

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

... и обрабатывать ошибку на клиенте?


Давайте определимся в такой штуке:
- ошибка - это одно
- транзакция и ее откат - это другое

Ошибку на кленте можете обрабатывать как хотите, хоть фиалками украсьте и выдавайте пользовятелю на экран.
А насчет транзакции - лично я предпочитаю откатить как только возникла ошибка.
Чем короче транзакция, тем мне спокойнее.
26 май 09, 11:05    [7227062]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Кудряшка
Member

Откуда: Сидней
Сообщений: 2219
[quot softwarer]Угу. Вот идёт, например, ETL на скромный такой 1'000'000 записей. На 990'000-й возникла ошибка - надо всё нахрен откатить, и точка.

Я в шоке.
Если они в одной транзакции - ДА! откатить!
Или не помещайте этот мильйон в одну транзакцию!
8-|
26 май 09, 11:08    [7227085]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Кудряшка
Member

Откуда: Сидней
Сообщений: 2219
softwarer
Кудряшка
Игнорировать выполнение "update T2" при возникновении ошибки - зло
Если это единственный метод обработки ошибок, который Вы знаете...


напишите запрос так, чтобы он не глючил. И чтобы быть уверенным, что если он глюкнул - значит что-то НЕ ТАК...
26 май 09, 11:11    [7227112]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
Кудряшка
Игнорирование ошибок чем-то похоже на "как бы самих себя обмануть".
Интересно, а кто тут предлагал ошибки игнорировать? По-моеому, слово "игнорировать" впервые в вашем посте появилось.

Кудряшка
Вы случайно не разработчик 1С?...

Любопытное предположение. Но должен вас огорчить.
26 май 09, 11:24    [7227216]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Кудряшка
Member

Откуда: Сидней
Сообщений: 2219
Bogdanov Andrey
Интересно, а кто тут предлагал ошибки игнорировать? По-моеому, слово "игнорировать" впервые в вашем посте появилось.


Тут завучало нечто подобное "если возникла ошибка в запросе в транзакции - все равно можносделать COMMIT" - это по сути, проигнорировать.
26 май 09, 12:31    [7227782]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
Кудряшка
А насчет транзакции - лично я предпочитаю откатить как только возникла ошибка.
Чем короче транзакция, тем мне спокойнее.

А насчёт больных - лично я предпочитаю прирезать как только пришёл с симптомами. Чем короче лечение, тем мне спокойнее. (c)

Кудряшка
Я в шоке.

Это неудивительно.

Кудряшка
Если они в одной транзакции - ДА! откатить!
Или не помещайте этот мильйон в одну транзакцию!

Угу. А потом и появляются режимы типа "база после сбоя потеряла закоммиченные данные", потому что иначе труба производительности.

Кудряшка
напишите запрос так, чтобы он не глючил. И чтобы быть уверенным, что если он глюкнул - значит что-то НЕ ТАК...

Умница. В точку. В самом деле что-то не так. Сработала защита целостности, например, не дала загрузить дубль. В этом случае надо разобраться с тем, кто прислал из внешнего источника этот миллион строк. И разобраться в то время, когда 999'999 строк будут лежать в базе и доступны пользователям, а "неправильная" - тоже лежать в базе, и тоже доступна, но с флагом ошибки.
26 май 09, 12:40    [7227859]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
martin_bishop
Member

Откуда:
Сообщений: 82
MasterZiv

-- это постулируемый *тобою* общий подход, или кем-то до тебя в треде ?


Нескольких единомышленников в этом треде и мой, в частности.
А мне говорит опыт работы с VLDB и распределёнными вычислениями.

Но оппоненты по-прежнему друг друга не слышат ...

Я хочу перефразировать гипотетически пример, на который намекал (боюсь ошибиться, но вроде Bogdanov Andrey или DBA-шник):

-- T1 - таблица обычная, T2 - с "умным" триггером

INSERT T1(A) VALUES('Attempt');
select @er=@@error, @rc=@@rowcount, @message='INSERT T1(A) faild!'
if @er <> 0 goto to_try_another_way_T1

INSERT T2(A) VALUES('Attempt');
select @er=@@error, @rc=@@rowcount, @message='INSERT T2(A) faild!'
if @er <> 0 goto to_try_another_way_T2


В данном случае с виду одинаковые инсёрты будут вести себя по-разному.
Не думаю что это правильно.

Вы, MasterZiv, сами писали, что мой подход характерен для вложенных транзакций.

Но вложенные транзакции, в свою очередь, характерны для больших БД и сложной, ветвистой логики.

А не может ли статься, что в небольших линейных базах Ваш подход не то, чтобы "приемлем", а просто "прокатывает". Но начинает "буксовать", когда база (точнее её бизнес-логика) перестаёт быть линейной, И когда количество разработчиков БД становится отличным от нуля?
26 май 09, 12:56    [7228002]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
martin_bishop
Member

Откуда:
Сообщений: 82
Кудряшка

Тут завучало нечто подобное "если возникла ошибка в запросе в транзакции - все равно можносделать COMMIT" - это по сути, проигнорировать.


Ответ неверный. Вы вычёркиваете такую возможность:

Одна из операций не прошла.
Грустно, конечно, но не смертельно.
Отсылаем уведомление источнику данных, что они "зашли" с ошибкой и своему админу.
Остальные, валидные данные - показываем клиентам (например "read only")

Сценариев, когда "Можно принять с оговорками"
(и не проигнорировать, а принять меры, но "За пределами" этой транзакции)
масса. Но Вы, похоже, не знаете ни одного ...
26 май 09, 13:09    [7228090]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
martin_bishop
Member

Откуда:
Сообщений: 82
Спасибо этой ветке.
Наконец-то я сам для себя лаконично сформулировал свой опыт, принципы и мысли:

Транзакции бывают двух типов:
- которые принимаюися безоговорочно (или не принимаются вовсе).
Для таких тр-ций реакция на ошибку находится внутри транзакции.

- которые могут быть приняты "с оговорками" (при определённых условиях).
Для таких тр-ций реакция на ошибку может находиться (но необязательно) снаружи транзакции.


Тогда назовём их:
- Жёсткая транзакция
- Транзакция с оговоркой

Тогда с учётом вышесказанного:

Приверженец отката транзакции на самом нижнем уровне (не обязательно в триггере)
отказывает Мастеру транзакции в праве запускать транзакцию с оговоркой
26 май 09, 13:30    [7228271]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Senya_L
Member

Откуда: Москва
Сообщений: 5381
martin_bishop
Кудряшка

Тут завучало нечто подобное "если возникла ошибка в запросе в транзакции - все равно можносделать COMMIT" - это по сути, проигнорировать.


Ответ неверный. Вы вычёркиваете такую возможность:

Одна из операций не прошла.
Грустно, конечно, но не смертельно.
Отсылаем уведомление источнику данных, что они "зашли" с ошибкой и своему админу.
Остальные, валидные данные - показываем клиентам (например "read only")

Сценариев, когда "Можно принять с оговорками"
(и не проигнорировать, а принять меры, но "За пределами" этой транзакции)
масса. Но Вы, похоже, не знаете ни одного ...
Действительно, зачем придумали эти ACID? :) На все ситуёвины непридвиденные затычку найдем.
26 май 09, 13:36    [7228325]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
Кудряшка
Тут завучало нечто подобное "если возникла ошибка в запросе в транзакции - все равно можносделать COMMIT" - это по сути, проигнорировать.

Странная у вас суть. Проигнорировать - это не предпринять никаких действий. А обработать ошибку, выполнить какие-то осмысленные логические действия и сделать, если надо commit - это совсем не "проигнорировать".
Приведу небольшой пример (естественно, его можно реализовать и по-другому). Пример утрированный, но...
В рамках одной транзакции необходимо создать приходную накладную и модифицировать остатки товара. Если товар - новый, то остатка по нему нет и необходимо его создать.
Проблема в том, что одновременно накладные заводятся разными пользователями и может так случиться, что обе будут содержать один и тот же новый товар. Простое решение проблемы - попытаться сделать insert и, получив, сообщение о том, что такая запись уже существует выполнить update. После чего успешно завершить транзакцию. Проверить наличие записи перед вставкой можно (и нужно), но гарантированного результата не даст, так как мы находимся в условиях одновременной работы сотни пользователей.
26 май 09, 13:38    [7228348]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
martin_bishop
Member

Откуда:
Сообщений: 82
И ещё короче:

Бывают 2 типа транзакций:
- Транзакция с немедленной реакцией;
- Транзакция с отложенной реакцией.
26 май 09, 13:45    [7228418]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
martin_bishop
Member

Откуда:
Сообщений: 82
Подчёркиваю, не "проигнорированная" транзакция,
а "отложенная реакция"

Например на тот момент, когда админ прийдёт на работу и прочтёт письма.
И решит:
- показать юзеру то, что смогло заехать, а посылавшим данные написать запрос на перепосылку того, что не заехало,
- или дропнуть весь пакет, но тоже написать запрос на перепосылку (теперь уже всего пакета)
26 май 09, 13:54    [7228508]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

martin_bishop wrote:

> Вы, *MasterZiv*, сами писали, что мой подход характерен для вложенных
> транзакций.
>

Где ? Не, я не писал. Для РАЗНЫХ транзакций разный подход.

Но, впрочем, я согласен, что чем больше транзакция, тем более оправдан
подход с хотя бы частичной её обработкой (т.е. "твой").

> Но вложенные транзакции, в свою очередь, характерны для больших БД и
> сложной, ветвистой логики.

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

> А не может ли статься, что в небольших линейных базах Ваш подход не то,
> чтобы "приемлем", а просто "прокатывает".

Так если он "прокатывает", то другого и не нужно.

Но начинает "буксовать", когда
> база (точнее её бизнес-логика) перестаёт быть линейной, И когда
> количество разработчиков БД становится отличным от нуля?

Кол-во разработчиков-то тут при чём ?

В общем, ещё раз. Ваш спор уже проспорен по нескольку раз.
Есть разные СУБД, в них есть разные модели вложенных транзакций.
Единой стандартной фактически нет. И, соответственно, в разных СУБД
либо можно использовать только один вариант, либо оба (а может быть и
только другой, не знаю). И второй аспект - разной сложности логика
транзакций и разная логика, когда-то лучше использовать один подход,
когда -то -- другой. Я лично -- за откатывать безусловно всю транзакцию,
но это в общем только потому, что я -- за маленькие транзакции. Но это
не значит, что "ваш" способ "не прокатывает".

Posted via ActualForum NNTP Server 1.4

26 май 09, 14:22    [7228739]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Кудряшка
Member

Откуда: Сидней
Сообщений: 2219
Все молодцы. Возьмите с полки пирожок.
(я ушла, пока!)
26 май 09, 14:23    [7228744]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Senya_L wrote:

> Действительно, зачем придумали эти ACID? :) На все ситуёвины
> непридвиденные затычку найдем.

Я хочу справедливости ради отметить, что как только придумали
ACID, так сразу же и придумали, как нарушать это A в этой абривиатуре,
а именно - многооператорные транзакции. Потому, что атомарность
транзакции рассматриваться должа в области определения приложения,
это ему, приложению, известно, где должны проходить границы атомарности.
И именно поэтому допустимы оба подхода. Если приложение считает, что
можно скоммитить 3 записи из 4, корректно отменив при этом 1 запись,
это -- его право. Потому что СУБД вообще-то не просто так в вакууме
существуют, а для написания этих самых приложений.

Posted via ActualForum NNTP Server 1.4

26 май 09, 14:28    [7228785]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Кудряшка
Member

Откуда: Сидней
Сообщений: 2219
Bogdanov Andrey

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


Выделенное - фигню Вы написали.
(не сделжалась и решила вернуться)
26 май 09, 14:32    [7228830]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Senya_L
Member

Откуда: Москва
Сообщений: 5381
MasterZiv,

Вот как раз такие случаи, когда коммитится часть пересланных данных усложняет сильно логику этих самых приложений. Принцип "все-или-ничего" проще, как не крути :)
26 май 09, 14:37    [7228871]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Кудряшка
Member

Откуда: Сидней
Сообщений: 2219
softwarer
Умница. В точку. В самом деле что-то не так. Сработала защита целостности, например, не дала загрузить дубль. В этом случае надо разобраться с тем, кто прислал из внешнего источника этот миллион строк. И разобраться в то время, когда 999'999 строк будут лежать в базе и доступны пользователям, а "неправильная" - тоже лежать в базе, и тоже доступна, но с флагом ошибки.


Примечание: Потрудитесь сменить тон, а то несолидно.

Что хотелось бы сказать: Я согласна, что 999'999 должны в базу попасть. Только я в упор не понимаю зачем при этом весь миль0н в одной транзакции, когда по СУТИ каждый инсерт, если он прошел удачно и без ошибок, принимается(коммит) независимо от других.
Т.е. посмотрим с другого бока: 1 инсерт прошел, 999'999 обрубились (почему-то). Ну один, так один, согласно логике.

ЗАЧЕМ весь миллион помещать в одну общую транзакцию? Обьясните...
26 май 09, 14:45    [7228934]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
martin_bishop
Member

Откуда:
Сообщений: 82
To MasterZiv: спасибо за ответ.

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

А в длинных транзакциях отложенность решения зачастую - единственный спозоб незалочить ресурс в тот момент, когда, например человек начал операцию и тут же погнался за котом, который стянул со стола колбасу. Не факт, что человек его быстро настигнет и скоро прийдёт продолжать-заканчивать свою транзакцию.
Я имею ввиду бизнес-транзакции, откуда я и позаимствовал мысль с отложенным решением.
И стал применять в длинных (или коротких логически, но тажеловесных) транзакциях.
Потому что, зачастую, дешевле отказаться от 9 999 999 999 строк прямым truncate или drop в предварительном хранилище, чем роллбэчить эту колбасу.

To Кудряшка
Всё в одной тр-ции - нет траты на открыть-закрыть, но тяжёлый откат и большой лог.
каждая строка в своей тр-ции - много открыть-закрыть, но короткий лог.

Если в тр-ционных скобках только инсёрты в одну таблицу, то можно и без тр-ции, конечно.
Но если на каждую вставленную строку происходят действия ещё где-то,
то ответ не очевиден.
Иногда приходится разбивать тр-цию на пакеты,
иногда - лить рядом с проверками, а после склеивать партицию с тем, что уже есть или отказаться от всей заливки
26 май 09, 15:00    [7229072]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Кудряшка
Member

Откуда: Сидней
Сообщений: 2219
martin_bishop

To Кудряшка
Всё в одной тр-ции - нет траты на открыть-закрыть, но тяжёлый откат и большой лог.
каждая строка в своей тр-ции - много открыть-закрыть, но короткий лог.


причем тут лог, открывать/закрывать... ???
если N манипулаций с данными не рассматриваются как одна цельная операция, они не должны быть в одной транзакции
26 май 09, 15:05    [7229122]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
Кудряшка
Выделенное - фигню Вы написали.
Ну вот и Вы перешли на так непонравившися Вам метод ведения дискуссии Эталоном Этаноловичем. Могу прцитировать Вас же из соседнего топика:
Ваше высокопарное "чушь" и "пурга" - лично для меня не аргумент.
26 май 09, 15:05    [7229127]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Кудряшка
martin_bishop

To Кудряшка
Всё в одной тр-ции - нет траты на открыть-закрыть, но тяжёлый откат и большой лог.
каждая строка в своей тр-ции - много открыть-закрыть, но короткий лог.


причем тут лог, открывать/закрывать... ???


А вы попробуйте залить (скажем в Oracle) 1000000 записей с транзакциями по 1000 записей,
а потом туда же с autocommit-ом. И сразу все станет ясно.

Кстати, тут периодически вложенные транзакии поминали
Почем траву брали товарищи ??? (вложенные транзакции из известных мне есть только в BDB)
26 май 09, 15:13    [7229225]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Кудряшка
Member

Откуда: Сидней
Сообщений: 2219
Gluk (Kazan)
Кудряшка
martin_bishop

To Кудряшка
Всё в одной тр-ции - нет траты на открыть-закрыть, но тяжёлый откат и большой лог.
каждая строка в своей тр-ции - много открыть-закрыть, но короткий лог.


причем тут лог, открывать/закрывать... ???


А вы попробуйте залить (скажем в Oracle) 1000000 записей с транзакциями по 1000 записей,
а потом туда же с autocommit-ом. И сразу все станет ясно.


Я для конкретного примера за то, чтобы транзакции были по одной записи:)
(это вариант с autocommit-ом ?)
26 май 09, 15:22    [7229306]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 10 11 12 13 14 [15] 16 17 18 19 .. 25   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить