Потеря данных при репликации, IB 7.5

Сообщение **kdv** » 23 авг 2007, 21:11

иногда shit все-таки happens:

ну... с другой стороны, кто вообще делает шатдаун, и кто делает шатдаун при работе пользователей...

Merlin · Сообщение **Merlin** » 23 авг 2007, 21:22

kdv писал(а):
иногда shit все-таки happens:
ну... с другой стороны, кто вообще делает шатдаун, и кто делает шатдаун при работе пользователей...

Йааа делайууу... Всю жись... Но на классике

dimitr · Сообщение **dimitr** » 23 авг 2007, 21:30

Merlin писал(а):Йааа делайууу... Всю жись... Но на классике

на классике нет такого понятия, как шатдаун сервера :-) kill не в счет :-)

Merlin · Сообщение **Merlin** » 23 авг 2007, 22:00

dimitr писал(а):
Merlin писал(а):Йааа делайууу... Всю жись... Но на классике
на классике нет такого понятия, как шатдаун сервера kill не в счет

А вы тут не про шатдаун базы разве? Тады ой

stix-s · Сообщение **stix-s** » 24 авг 2007, 06:25

WildSery писал(а):Нет, это я тебя не понял. Зачем на insert/update - то снэпшот?
А вот на чтение данных для отчёта - как раз снэпшот, а то такого насчитает...
Или мы друга друг непонимай?

понимай, понимай

На Insert/Update/(Delete) данные грузятся в не data-aware компоненты, по кнопке "Записать" стартует

write
nowait
concurrency

и сразу завершается
При успехе - коммит, при ошибке-откат.
В свое время думал, что выгоднее concurrency или read committed, особой разницы для себя в данном случае не нашел и оставил SNAPSHOT
На чтение в data-aware пользуется

read
nowait
rec_version
read_committed

Одна на всех и живет до завершения приложения
для отчетов - SNAPSHOT
ЗЫ
Мои извинения автору топа за отклонение от темы

Merlin · Сообщение **Merlin** » 24 авг 2007, 12:55

stix-s писал(а): понимай, понимай
На Insert/Update/(Delete) данные грузятся в не data-aware компоненты, по кнопке "Записать" стартует
write
nowait
concurrency
и сразу завершается
При успехе - коммит, при ошибке-откат.

А в такой постановке вопроса апсалютна по барабану какая транзакция, хоть consistency. Всё равно во временном промежутке с тех пор, как данные грузятся в не data-aware компоненты, и до старта пишущей транзакции по кнопке "Записать" их имели во всяких извращённых формах все кому не лень и там дааавно уже не то, что грузилось в не data-aware компоненты. Вот если бы снапшот-транзакция стартовала и затем сама грузила в не data-aware компоненты - тады другое дело. Статейки таки надо читать, а не просматривать по диагонали, сто репьёв в задницу их писателям

stix-s · Сообщение **stix-s** » 24 авг 2007, 14:59

Merlin писал(а): А в такой постановке вопроса апсалютна по барабану какая транзакция, хоть consistency. Всё равно во временном промежутке с тех пор, как данные грузятся в не data-aware компоненты, и до старта пишущей транзакции по кнопке "Записать" их имели во всяких извращённых формах все кому не лень и там дааавно уже не то, что грузилось в не data-aware компоненты. Вот если бы снапшот-транзакция стартовала и затем сама грузила в не data-aware компоненты - тады другое дело. Статейки таки надо читать, а не просматривать по диагонали, сто репьёв в задницу их писателям

Ну хорошо, стартовали SNAPSHOT, пока там юзверь репу чесал -

их имели во всяких извращённых формах все кому не лень

- получит при записи юзверь отлуп, но он чел настойчивый, снова к этой записи полез, снова ее поимели - чем вариант лучше?

Kabaev Sergey

Вопрос, возможно относящийся к топику. Кто-нибудь сталкивался с cитуацией, когда SWEEP не успевает выполняться? Т.е. поток занимающийся сборкой мусора не успевает выполнять свою работу и таблицы обрастают множеством дельта-пакетов ( я ж так понимаю, что IB в случае изменения записи в качестве новой версии записи хранит не "снимок" нового состояния записи, а некий дельта-пакет описывающий внесенные изменения относительно исходной версии).

Как это может проявляться на работе базы теоритически?
Кто-нибудь сталкивался с такой ситуацией в реале?

Merlin · Сообщение **Merlin** » 24 авг 2007, 15:49

Kabaev Sergey писал(а):Вопрос, возможно относящийся к топику. Кто-нибудь сталкивался с cитуацией, когда SWEEP не успевает выполняться?

SWEEP<>GARBAGE COLLECTION!!!
SWEEP<>GARBAGE COLLECTION!!!
SWEEP<>GARBAGE COLLECTION!!!
SWEEP<>GARBAGE COLLECTION!!!
SWEEP<>GARBAGE COLLECTION!!!
SWEEP<>GARBAGE COLLECTION!!!
SWEEP<>GARBAGE COLLECTION!!!
SWEEP<>GARBAGE COLLECTION!!!

В общем - на www.ibase.ru и читать, читать, читать...

Merlin · Сообщение **Merlin** » 24 авг 2007, 15:52

stix-s писал(а): Ну хорошо, стартовали SNAPSHOT, пока там юзверь репу чесал -
их имели во всяких извращённых формах все кому не лень
- получит при записи юзверь отлуп, но он чел настойчивый, снова к этой записи полез, снова ее поимели - чем вариант лучше?

Не, если один юзверь апдейтит МОЛОКО в СМЕТАНУ, а другой не глядя в ПРЕЗЕРВАТИВ и у обоих всё с песнями пролетает, и сметанщик об этом не подозревает - луччи и правильно, то нафиг тогда вообще транзакции, СУБД и всё такое...

stix-s · Сообщение **stix-s** » 24 авг 2007, 15:57

Merlin писал(а):
Не, если один юзверь апдейтит МОЛОКО в СМЕТАНУ, а другой не глядя в ПРЕЗЕРВАТИВ и у обоих всё с песнями пролетает, и сметанщик об этом не подозревает - луччи и правильно, то нафиг тогда вообще транзакции, СУБД и всё такое...

слишком кардинально, у многих задач есть несколько путей решения

Сообщение **kdv** » 24 авг 2007, 16:14

Как это может проявляться на работе базы теоритически?
Кто-нибудь сталкивался с такой ситуацией в реале?

перестаньте делать из меня попугая. ЧИТАЙТЕ ХЕЛП К IBANALYST!!!
Если Вы не в состоянии открыть содержимое хелпа, то вот прямая ссылка на документ, который есть в хелпе:
www.ibase.ru/devinfo/summary.htm

и потом, казалось бы, при чем тут сборка мусора или sweep.

Kabaev Sergey

перестаньте делать из меня попугая. ЧИТАЙТЕ ХЕЛП К IBANALYST!!!
............
и потом, казалось бы, при чем тут сборка мусора или sweep.

Я не делаю из Вас попугая, и неоднократно читал help.

В БД, с которой мы работаем появляются непонятные ошибки, в частности
а) данные в Аналитической базе - то пропадающие, то появляющиеся , то опять пропадающие после перезагрузки сервера.
б) неадекватное поведение IB при обрыве коннекта с Аналитической базой
в) данные в очереди репликации из Оперативной базы в Аналитику, которые иногда появляются не в течение 1-2 секунд после подтверждения породившей их транзакции, а с разрывом по времени в несколько часов.

Очень важное замечание - наша система в точно такой же конфигурации проработала два года БЕЗ подобных проблем и ошибок. Текущая версия системы отличается от старой только увеличением объема данных на один порядок, новым железом и версией IB.

Одно из моих предположений, что эти ошбки каким-либо образом связаны с ошибками процесса сборки мусора. На эту тему ничего в help-е нет. И вряд ли будет, потому что в helpe в основном описана штатная работа системы. Или инструментов для сбора данных о базе данных. Но в нём не описано, как могут проявляться сбои. Это как я понимаю требует уже хитрого анализа и об этом в help-ах не пишут, т.к. ручки устанут описывать все возможные сбои. Это могут знать только те, кто уже наступал на эти грабли, как я понимаю.

stix-s · Сообщение **stix-s** » 24 авг 2007, 19:19

Kabaev Sergey писал(а):
перестаньте делать из меня попугая. ЧИТАЙТЕ ХЕЛП К IBANALYST!!!
............
и потом, казалось бы, при чем тут сборка мусора или sweep.
Я не делаю из Вас попугая, и неоднократно читал help.

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

возможно другие в курсе)

Сообщение **kdv** » 25 авг 2007, 22:18

Одно из моих предположений, что эти ошбки каким-либо образом связаны с ошибками процесса сборки мусора. На эту тему ничего в help-е нет. И вряд ли будет, потому что в helpe в основном описана штатная работа системы. Или инструментов для сбора данных о базе данных. Но в нём не описано, как могут проявляться сбои. Это как я понимаю требует уже хитрого анализа и об этом в help-ах не пишут, т.к. ручки устанут описывать все возможные сбои. Это могут знать только те, кто уже наступал на эти грабли, как я понимаю.

никаких "таких" граблей нет. я склоняюсь к тому, что в вашем приложении безобразная работа с уровнями изолированности транзакций, и ничего более. Ну не бывает такого чтобы записи сохранились, а стали "видны через несколько часов". При чем тут сборка мусора? Вы вообще понимаете что такое "мусор"?
И, еще опять же, со стороны, не читали вы хелп к IBAnalyst. Потому что там написано, в каких случаях sweep не может собрать мусор, но не написано что это могло бы как-либо приводить к "видимости" или "невидимости" записей.

Расширение БД какое, на всякий случай? А то может gdb, плюс windows xp?

симптомы ошибок в твоей БД похожи на общеизвестные, посему корифеи и нервничают

не вижу никаких "общеизвестных симптомов".

stix-s · Сообщение **stix-s** » 26 авг 2007, 13:19

kdv писал(а): не вижу никаких "общеизвестных симптомов".

Пардон, неправильно выразился

я имел в виду высказанное предположение о корректности работы клиентского приложения

stix-s · Сообщение **stix-s** » 27 авг 2007, 14:43

Merlin писал(а): Не, если один юзверь апдейтит МОЛОКО в СМЕТАНУ, а другой не глядя в ПРЕЗЕРВАТИВ и у обоих всё с песнями пролетает, и сметанщик об этом не подозревает - луччи и правильно, то нафиг тогда вообще транзакции, СУБД и всё такое...

Сидел в выходные, пил пиво, чесал репу.
Если в разрезе про сметану и презервативы, то как бы в общем виде - ошибка пользователя, к сожалению на 100% не отгородишься, разве разбить товары на продуктовые и хоз, так сказать и не дать юзеру молоко в презервативы превращать

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

stix-s · Сообщение **stix-s** » 31 авг 2007, 05:55

Интересно, автор решил проблему?

Kabaev Sergey

Нет. Сейчас переходим на off-line репликацию + откатываемся на IB 7.1