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

WildSery · Сообщение **WildSery** » 21 авг 2007, 15:14

Kabaev Sergey писал(а):Опять поправка - HT пробовали отключать, сервер перестал успевать обрабатывать запросы. Да и я не вижу смысла его гасить - у нас много процессорный сервер, в докумнтации на здешнем сайте сказано, что IB 7.5 SuperServer этот режим нормально поддерживает.

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

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

Опять поправка - HT пробовали отключать, сервер перестал успевать обрабатывать запросы. Да и я не вижу смысла его гасить - у нас много процессорный сервер, в докумнтации на здешнем сайте сказано, что IB 7.5 SuperServer этот режим нормально поддерживает.

прочитайте www.ibase.ru/devinfo/ht.htm

то что у вас "проседает" сервер при выключении HT, скорее всего означает что есть какое-то очень кривое железо, откуда и лезут проблемы. Разница при ht не может быть больше 15-ти % по определению. Потому что серверу нужен ДИСК, а не процессор, тем более с какой то "десктопной HT".

Kabaev Sergey

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

Но проблема не только в этом. Ведь мы имеем дел с только что отресторенной базой. Т.е. в ней теоретически все битые индексы, данные и метаданные должны быть заведомо верны, при условии что restore выполнился без ошибок. Мы же имеем другую картину. Restore действительно отработал без ошибок, но индекс в свежеподнятой базе или поврежден и вообще отсутствует. Т.е. мы имеем дело с ошибкой, которую штатное средство Interbase не отлавливает.

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

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

Kabaev Sergey писал(а): Но проблема не только в этом. Ведь мы имеем дел с только что отресторенной базой. Т.е. в ней теоретически все битые индексы, данные и метаданные должны быть заведомо верны, при условии что restore выполнился без ошибок.

Напоминаю:

Kabaev Sergey писал(а): 1 Насколько я понял со слов того человека, который поднимал базу restore закончилось без ошибок.

Я не фанат Borland InterBase, но сдаётся мне, что рестор таки завершился чем-то вроде

Exiting before completition due to error:
Cannot restore index RDB$FOREIGN...

Посему там в худшем случае вообще полбазы, а в лучшем просто куча неактивизированных индексов.

Kabaev Sergey писал(а): Мы же имеем другую картину. Restore действительно отработал без ошибок, но индекс в свежеподнятой базе или поврежден и вообще отсутствует.
Т.е. мы имеем дело с ошибкой, которую штатное средство Interbase не отлавливает.

Мужики тут сумлеваются. При всём нефанатстве по отношению к IB. Ибо этого не может быть потому что не может быть никогда. В IB режим рестора по умолчанию сделали таки где-то в районе 6.5 с игнорированием некоторых нарушений, не помню точно каких (в отличие от FB), но warning-и просто обязаны быть, в Борланде всётки не круглые идиоты работают. Кстати, проверить наличие неактивных индексов - минутное дело.

Kabaev Sergey писал(а): Свалить эту ошибку на железо я тоже не могу, т.к. рабочая база и тестовая находятся на двух разных серверах и в обоих базах идут ошибки. Ели они из-за железа, то у нас оба сервера кривые, что маловероятно.

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

dimitr · Сообщение **dimitr** » 22 авг 2007, 10:38

Merlin писал(а):но warning-и просто обязаны быть

я бы не поставил на это свою зарплату...

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

dimitr писал(а):
Merlin писал(а):но warning-и просто обязаны быть
я бы не поставил на это свою зарплату...

Ты чё, серьёзно? Не, ну насчёт нарушения какого-нибудь not null я вполне готов поверить, но референсных - это чересчур

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

Kabaev Sergey

Cообщений типа Exiting before completition due to error: ... Cannot restore index RDB$FOREIGN... не было. Привести точный текст выведенного при окончании restore сообщения я не могу, т.к. отчет выводился на экран. Соответственно, я могу только ссылаться на слова "того человека, который делал backup/restore". Но у меня нет оснований ему не доверять. Он достаточно квалифицирован, чтобы отличить "Exiting before completition due to error" от "restore completed"

WildSery · Сообщение **WildSery** » 22 авг 2007, 15:34

Тебе как раз и намекнули на то, что могло быть не "Exiting...due to error", а как раз
"Warning: ...
Restore completed"

Kabaev Sergey

Возможно. Я сейчас сам пытаюсь поднять базу на локальной машине, с выводом отчета в файл. Буду изучать.

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

Kabaev Sergey писал(а):Возможно. Я сейчас сам пытаюсь поднять базу на локальной машине, с выводом отчета в файл. Буду изучать.

В Operations Guide загляни. Что-то меня dimitr смутил насчёт ворнингов. Дело в том, что в IB сначала, а в FB до сих пор при любой ошибке на ресторе вылетает птица обломинго. По умолчанию, чтобы изумлённый админ сразу же стал крутить gbak-у я... то есть опции с целью вытащить что вытаскивается, продиагностировать базу и починить как можно ближе по времени к возникновению неприятностей, не давая им накопиться. Но начиная с какой-то версии уже этого века в IB сделали наоборот - ресторится что ресторится, а для диагностики отказами надо включать ключики. Так что ключики модернового gbak-а от IB могут существенно отличаться от того, к чему привык и я и большинство из присутствующих. Я считал и считаю это решение идиотизмом - прямой путь как раз к той ситуации, которая, похоже, сложилась у вас - админ спит, служба идёт, бакапы бакапятся, ресторы ресторятся, а что там уже может и не база вовсе, никто и не догадывается.

Kabaev Sergey

Вот что получилось:

gbak: finishing, closing, and going home

Но есть warining-и, вот фрагмент лога:

gbak: restoring trigger TG_GRADEPROD_DEL
gbak: restoring trigger TG_GRADEPROD_GENID
gbak: restoring trigger TG_GRADEPROD_UP
gbak: restoring trigger TG_GREPORT_UP
gbak: restoring trigger TG_KBACCOUNT_DEL
gbak: restoring privilege for user SYSDBA
gbak: WARNING: action cancelled by trigger (0) to preserve data integrity
gbak: WARNING: could not find table/procedure for GRANT
gbak: restoring privilege for user SYSDBA
gbak: WARNING: action cancelled by trigger (0) to preserve data integrity
gbak: WARNING: could not find table/procedure for GRANT
gbak: restoring privilege for user SYSDBA
gbak: WARNING: action cancelled by trigger (0) to preserve data integrity
gbak: WARNING: could not find table/procedure for GRANT
gbak: restoring privilege for user SYSDBA
gbak: WARNING: action cancelled by trigger (0) to preserve data integrity
gbak: WARNING: could not find table/procedure for GRANT
gbak: restoring privilege for user SYSDBA
gbak: WARNING: action cancelled by trigger (0) to preserve data integrity
gbak: WARNING: could not find table/procedure for GRANT

и далее еще примерно с десяток. Узнать бы что они значат? (Сделал b/r оперативной базы, там такие же сообщения в логе есть. )

Еще есть сообщения типа:

gbak: restoring index RDB$PRIMARY_T_SGCOND
gbak: do not recognize index attribute 12 -- continuing
gbak: restoring index RDB$FOREIGN_T_SGCOND4
gbak: do not recognize index attribute 12 -- continuing

но их можно списать на то, что на моей локальной машине стоит IB 7.1 , а на сервере IB 7.5. Backup делался новым gbak-ом.

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

Kabaev Sergey писал(а): но их можно списать на то, что на моей локальной машине стоит IB 7.1 , а на сервере IB 7.5. Backup делался новым gbak-ом.

Не можно, а нужно, что за доп экперименты с версиями?
Что мешает актуальной версией сделать?
ЗЫ я в шоке

Kabaev Sergey

Лицензии нет, чтоб на локальную машину поставить. Начиная с 7.5 IB привязывается к компу при установке, как я понял.

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

Kabaev Sergey писал(а):Лицензии нет, чтоб на локальную машину поставить. Начиная с 7.5 IB привязывается к компу при установке, как я понял.

а триал?
или я от жизни отстал?
у тя бэкап в новой версии, ты его ресторишь в старой ........

Kabaev Sergey

Дык, он у нас уже больше 90 дней.

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

Kabaev Sergey писал(а):Дык, он у нас уже больше 90 дней.

а переставить?

Kabaev Sergey

Не пробовал, но я полгаю, что IB скажет что-то наподобие "нефиг меня второй раз ставить". В-общем, когда контора нашу эту версию купила, и мы (программеры т.е.) пошли с вопросом к нашему главному - а типа нам бы тоже хорошо иметь свежую версию для отладки, то получили ответ - нефиг. Лицензий мало, на всех не хватит. Юзайте старую.

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

Kabaev Sergey писал(а):Вот что получилось:

gbak: WARNING: action cancelled by trigger (0) to preserve data integrity
gbak: WARNING: could not find table/procedure for GRANT
Узнать бы что они значат? (Сделал b/r оперативной базы, там такие же сообщения в логе есть. )

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

Kabaev Sergey писал(а): Еще есть сообщения типа:

gbak: restoring index RDB$PRIMARY_T_SGCOND
gbak: do not recognize index attribute 12 -- continuing
gbak: restoring index RDB$FOREIGN_T_SGCOND4
gbak: do not recognize index attribute 12 -- continuing

Тут ничего не скажу - ИБ-специфик.

Kabaev Sergey писал(а): но их можно списать на то, что на моей локальной машине стоит IB 7.1 , а на сервере IB 7.5. Backup делался новым gbak-ом.

Рестор тоже "новым" gbak-ом на "старом" сервере надо делать. Если такие ужимки и прыжки необходимы, полезная ссылка http://www.ibase.ru/devinfo/prevver.htm

Kabaev Sergey

Граждане , у нас тут странная ситуация.
Вчера данные в Аналитике были нормальные (грубо говоря отчет делался верно). Сегодня данные кривые показывает. Смотрим программу, генерирующую этот отчет, под отладчиком. Вытаскиваем запрос который готовит данные для отчета. Запускаем запрос в IB Expert . Данные нормальные. Тот же запрос из программы - данные неверные. Параметры запроса одинковые. Разница только в режиме открытия транзаций - в программе snapshot, в Experte - read comitted. Т.е. в read comitted транзакции чудес с данными нет. Так вот, у нас в системе стандартный режим работы транзакций как раз snapshot.
А после прочтения здешних статей у меня сложилось впечатление, что здешний народ использует в основном read comitted. Хотелось бы уточнить, кто какой режим транзакций предпочитает использовать? И не замечалось ли странностей при различных режимах на больших базах?

У меня по результатам всего нашего длинного обсуждения сложилось впечатление, что с проблемой подобной нашей (исчезания данных) никто не сталкивался. В это верится с трудом, т.к. не у нас же одних большая база на IB, и ничего особо уникального в нашей системе нет. Кроме, возможно, этих самых режимов. Не в этом ли дело?

stix-s · Сообщение **stix-s** » 23 авг 2007, 11:58

Kabaev Sergey писал(а): Т.е. в read comitted транзакции чудес с данными нет. Так вот, у нас в системе стандартный режим работы транзакций как раз snapshot.
А после прочтения здешних статей у меня сложилось впечатление, что здешний народ использует в основном read comitted. Хотелось бы уточнить, кто какой режим транзакций предпочитает использовать? И не замечалось ли странностей при различных режимах на больших базах?
Кроме, возможно, этих самов режимов. Не в этом ли дело?

У вас ИМХО застряла транзакция
http://ibase.ru/devinfo/mga.htm
и snapshot новых версий не видит
у себя для отчетов использую именно snapshot
для записи - короткие

Код: Выделить всё

write
nowait
concurrency

, а для чтения долгоживущую

Код: Выделить всё

read
nowait
rec_version
read_committed