ну... с другой стороны, кто вообще делает шатдаун, и кто делает шатдаун при работе пользователей...иногда shit все-таки happens:
Потеря данных при репликации, IB 7.5
понимай, понимайWildSery писал(а):Нет, это я тебя не понял. Зачем на insert/update - то снэпшот?
А вот на чтение данных для отчёта - как раз снэпшот, а то такого насчитает...
Или мы друга друг непонимай?
На Insert/Update/(Delete) данные грузятся в не data-aware компоненты, по кнопке "Записать" стартует
и сразу завершаетсяwrite
nowait
concurrency
При успехе - коммит, при ошибке-откат.
В свое время думал, что выгоднее concurrency или read committed, особой разницы для себя в данном случае не нашел и оставил SNAPSHOT
На чтение в data-aware пользуется
Одна на всех и живет до завершения приложенияread
nowait
rec_version
read_committed
для отчетов - SNAPSHOT
ЗЫ
Мои извинения автору топа за отклонение от темы
А в такой постановке вопроса апсалютна по барабану какая транзакция, хоть consistency. Всё равно во временном промежутке с тех пор, как данные грузятся в не data-aware компоненты, и до старта пишущей транзакции по кнопке "Записать" их имели во всяких извращённых формах все кому не лень и там дааавно уже не то, что грузилось в не data-aware компоненты. Вот если бы снапшот-транзакция стартовала и затем сама грузила в не data-aware компоненты - тады другое дело. Статейки таки надо читать, а не просматривать по диагонали, сто репьёв в задницу их писателямstix-s писал(а): понимай, понимай
На Insert/Update/(Delete) данные грузятся в не data-aware компоненты, по кнопке "Записать" стартуети сразу завершаетсяwrite
nowait
concurrency
При успехе - коммит, при ошибке-откат.
Ну хорошо, стартовали SNAPSHOT, пока там юзверь репу чесал -Merlin писал(а): А в такой постановке вопроса апсалютна по барабану какая транзакция, хоть consistency. Всё равно во временном промежутке с тех пор, как данные грузятся в не data-aware компоненты, и до старта пишущей транзакции по кнопке "Записать" их имели во всяких извращённых формах все кому не лень и там дааавно уже не то, что грузилось в не data-aware компоненты. Вот если бы снапшот-транзакция стартовала и затем сама грузила в не data-aware компоненты - тады другое дело. Статейки таки надо читать, а не просматривать по диагонали, сто репьёв в задницу их писателям
- получит при записи юзверь отлуп, но он чел настойчивый, снова к этой записи полез, снова ее поимели - чем вариант лучше?их имели во всяких извращённых формах все кому не лень
-
- Сообщения: 35
- Зарегистрирован: 16 авг 2007, 15:13
Вопрос, возможно относящийся к топику. Кто-нибудь сталкивался с cитуацией, когда SWEEP не успевает выполняться? Т.е. поток занимающийся сборкой мусора не успевает выполнять свою работу и таблицы обрастают множеством дельта-пакетов ( я ж так понимаю, что IB в случае изменения записи в качестве новой версии записи хранит не "снимок" нового состояния записи, а некий дельта-пакет описывающий внесенные изменения относительно исходной версии).
Как это может проявляться на работе базы теоритически?
Кто-нибудь сталкивался с такой ситуацией в реале?
Как это может проявляться на работе базы теоритически?
Кто-нибудь сталкивался с такой ситуацией в реале?
SWEEP<>GARBAGE COLLECTION!!!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!!!
В общем - на www.ibase.ru и читать, читать, читать...
Не, если один юзверь апдейтит МОЛОКО в СМЕТАНУ, а другой не глядя в ПРЕЗЕРВАТИВ и у обоих всё с песнями пролетает, и сметанщик об этом не подозревает - луччи и правильно, то нафиг тогда вообще транзакции, СУБД и всё такое...stix-s писал(а): Ну хорошо, стартовали SNAPSHOT, пока там юзверь репу чесал -- получит при записи юзверь отлуп, но он чел настойчивый, снова к этой записи полез, снова ее поимели - чем вариант лучше?их имели во всяких извращённых формах все кому не лень
слишком кардинально, у многих задач есть несколько путей решенияMerlin писал(а):
Не, если один юзверь апдейтит МОЛОКО в СМЕТАНУ, а другой не глядя в ПРЕЗЕРВАТИВ и у обоих всё с песнями пролетает, и сметанщик об этом не подозревает - луччи и правильно, то нафиг тогда вообще транзакции, СУБД и всё такое...
перестаньте делать из меня попугая. ЧИТАЙТЕ ХЕЛП К IBANALYST!!!Как это может проявляться на работе базы теоритически?
Кто-нибудь сталкивался с такой ситуацией в реале?
Если Вы не в состоянии открыть содержимое хелпа, то вот прямая ссылка на документ, который есть в хелпе:
www.ibase.ru/devinfo/summary.htm
и потом, казалось бы, при чем тут сборка мусора или sweep.
-
- Сообщения: 35
- Зарегистрирован: 16 авг 2007, 15:13
Я не делаю из Вас попугая, и неоднократно читал help.перестаньте делать из меня попугая. ЧИТАЙТЕ ХЕЛП К IBANALYST!!!
............
и потом, казалось бы, при чем тут сборка мусора или sweep.
В БД, с которой мы работаем появляются непонятные ошибки, в частности
а) данные в Аналитической базе - то пропадающие, то появляющиеся , то опять пропадающие после перезагрузки сервера.
б) неадекватное поведение IB при обрыве коннекта с Аналитической базой
в) данные в очереди репликации из Оперативной базы в Аналитику, которые иногда появляются не в течение 1-2 секунд после подтверждения породившей их транзакции, а с разрывом по времени в несколько часов.
Очень важное замечание - наша система в точно такой же конфигурации проработала два года БЕЗ подобных проблем и ошибок. Текущая версия системы отличается от старой только увеличением объема данных на один порядок, новым железом и версией IB.
Одно из моих предположений, что эти ошбки каким-либо образом связаны с ошибками процесса сборки мусора. На эту тему ничего в help-е нет. И вряд ли будет, потому что в helpe в основном описана штатная работа системы. Или инструментов для сбора данных о базе данных. Но в нём не описано, как могут проявляться сбои. Это как я понимаю требует уже хитрого анализа и об этом в help-ах не пишут, т.к. ручки устанут описывать все возможные сбои. Это могут знать только те, кто уже наступал на эти грабли, как я понимаю.
просто ситуация, описываемая тобой - похоже, ммммм, с одной стороны несколько необычна, так сказать (то видны записи, то нет, после перезагруза их ваще нет), с другой стороны:Kabaev Sergey писал(а):Я не делаю из Вас попугая, и неоднократно читал help.перестаньте делать из меня попугая. ЧИТАЙТЕ ХЕЛП К IBANALYST!!!
............
и потом, казалось бы, при чем тут сборка мусора или sweep.
симптомы ошибок в твоей БД похожи на общеизвестные, посему корифеи и нервничают
поэтому ошибки Борландов рассматриваются в самую последнюю очередь, тем более, что код они (Борланды) закрыли и шо там у них сейчас, никто не ведает (пардон - я не ведаю возможно другие в курсе)
никаких "таких" граблей нет. я склоняюсь к тому, что в вашем приложении безобразная работа с уровнями изолированности транзакций, и ничего более. Ну не бывает такого чтобы записи сохранились, а стали "видны через несколько часов". При чем тут сборка мусора? Вы вообще понимаете что такое "мусор"?Одно из моих предположений, что эти ошбки каким-либо образом связаны с ошибками процесса сборки мусора. На эту тему ничего в help-е нет. И вряд ли будет, потому что в helpe в основном описана штатная работа системы. Или инструментов для сбора данных о базе данных. Но в нём не описано, как могут проявляться сбои. Это как я понимаю требует уже хитрого анализа и об этом в help-ах не пишут, т.к. ручки устанут описывать все возможные сбои. Это могут знать только те, кто уже наступал на эти грабли, как я понимаю.
И, еще опять же, со стороны, не читали вы хелп к IBAnalyst. Потому что там написано, в каких случаях sweep не может собрать мусор, но не написано что это могло бы как-либо приводить к "видимости" или "невидимости" записей.
Расширение БД какое, на всякий случай? А то может gdb, плюс windows xp?
не вижу никаких "общеизвестных симптомов".симптомы ошибок в твоей БД похожи на общеизвестные, посему корифеи и нервничают
Сидел в выходные, пил пиво, чесал репу.Merlin писал(а): Не, если один юзверь апдейтит МОЛОКО в СМЕТАНУ, а другой не глядя в ПРЕЗЕРВАТИВ и у обоих всё с песнями пролетает, и сметанщик об этом не подозревает - луччи и правильно, то нафиг тогда вообще транзакции, СУБД и всё такое...
Если в разрезе про сметану и презервативы, то как бы в общем виде - ошибка пользователя, к сожалению на 100% не отгородишься, разве разбить товары на продуктовые и хоз, так сказать и не дать юзеру молоко в презервативы превращать
а вот если скажем два юзера по одному клиенту оплаты заводят или долги, которые суммировать надо, вот тут да ..........
В общем, спасибо за замечание, будем учесть
-
- Сообщения: 35
- Зарегистрирован: 16 авг 2007, 15:13