Ошибка Репликатора

Корзина

Ваша корзина пуста

Выберите в каталоге интересующий товар и нажмите кнопку "В корзину"

В каталог

Избранное

Ваш список избранных товаров пуст

Отложенные товары

Ваш список отложенных товаров пуст

8-800-333-66-70

Ваш город:

Определение

Ошибка Репликатора

Пивоваров Алексей Викторович 19.03.2014 21:33:37

Здравствуйте!

Ситуация такова, что при выполнении ежедневной репликации на финальном этапе (Restore) Репликатор выдает ошибку,
наблюдали это еще на версии 2.6.2.124, при обновлении до 3.6.2.127 ничего не изменилось.

В логах Репликатора имеется такое:

19.03.2014 15:58:31 :: Все OK
19.03.2014 15:58:31 :: BackUp завершен переходим к Restore.
19.03.2014 15:58:31 :: Запускаем процесс восстановления... Это может занять несколько минут...
19.03.2014 15:58:31 :: Строка для выполнения : C:\Program Files\Firebird\Firebird_2_5\bin\gbak.exe -R -P 4096 -user SYSDBA -password masterkey D:\REPL-ARCHIVE\BR_20140319_15-58PRTX_DB.gbk 192.168.1.250:c:\sokrat\pritok-3.6\data\tmp_prtx_db.fdb
19.03.2014 15:59:02 :: Завершен процесс восстановления.
19.03.2014 15:59:02 :: Проверяем на наличие ошибок.
19.03.2014 15:59:02 :: Все OK
19.03.2014 15:59:02 :: Удаляем файл резервной копии. (лишний)
19.03.2014 15:59:02 :: файл удален
19.03.2014 15:59:02 :: Посылаем сообщение на AP-монитор.
19.03.2014 15:59:02 :: Послали сообщение на AP-монитор ResultCode=1
19.03.2014 15:59:03 :: ОШИБКА! Пришел ответ от APMonitor'а , ОШИБКА! он не заменил БД
19.03.2014 15:59:03 :: APmonitor ответил, продолжаем выходим.
19.03.2014 15:59:03 :: Процесс BackUp/Restore завершен c ошибками.
19.03.2014 15:59:03 :: Большая вероятность, что потребуется вмешательство администратора.
19.03.2014 15:59:03 :: Посылаем сообщение о разрешении соединений.
19.03.2014 15:59:06 :: Процесс BackUp/Restore длился: 0:01:01
19.03.2014 15:59:06 :: BackUp/Restore по заказу завершена

В логах АРМонитора следующее:

15:59:03:101::: Текущие cоединения :
15:59:03:101::: Переводим БД в режим off-line
15:59:03:101::: Строка для выполнения: C:\Program Files\Firebird\Firebird_2_5\bin\gfix.exe -shut -force 0 -user "SYSDBA" -password "masterkey" OPS-SERVER:c:\sokrat\pritok-3.6\data\prtx_db.fdb
15:59:03:367::: ОШИБКА! Не смогли перевести главную БД в режим off-line. ExitCode=1

Писали по этому поводу в техподдержку, ответили, что скорее всего файл БД занят каким-то процессом, что логично.
Вопрос только в том - каким? Потому что ничего нового уже несколько лет на сервер не устанавливали, а эта ошибка проявилась в конце января 2014, до этого все было отлично.

Кто-нибудь еще сталкивался с подобным? Куда копать?

Спасибо.

Скалецкий Игорь 20.03.2014 02:01:34

Причин может быть несколько. Рекомендации: 1. В контрольной панели системы вместо имени компьютера прописать IP адрес. 2. Проверить пути к Firebird в настройках Kernel, Monitor (настраивается в контрольной панели). 3. Проверить запущена ли служба АРМ Монитор. 4. Имя компьютера должно бать на латинице(попробуйте переименовать OPS-Server просто в Server). 5. Если Windows 7, то Контроль учетных записей должен быть отключен, так же рекомедуется отключить Брадмауэр. 6. Если все разных компьютерах, проверьте доступ к папке с базой.

Пивоваров Алексей Викторович 20.03.2014 03:47:02

1 - давно IP-адреса
2 - у Firebird и монитора пути должны быть адекватные, ведь все предыдущие операции с БД происходят без проблем (проверим, конечно, но вряд ли это оно)
3 - служба точно запущена
4 - имя на латинице (тоже можно попробовать переименовать, НО до 24.01.2014 все ведь работало)
5 - Windows 2003 R2 Enterprise SP1, сервис брандмауэра остановлен, антивируса нет
6 - все операции происходят локально

Вся суть вопроса в том, что же такого невероятного могло случиться 25 января, что БД теперь постоянно занята?

Илюшин Иван 20.03.2014 09:26:17

1. индексирование данных на диске с БД должно быть отключено.
2. файл БД должен быть добавлен в исключения антивируса и брэндмауэра

Пивоваров Алексей Викторович 20.03.2014 14:08:33

1 - индексирование отключено
2 - от антивируса пока отказались, до этого был ESET NOD32, от брандмауэра тоже - даже сервис не запущен.

Пивоваров Алексей Викторович 20.03.2014 15:37:24

Переименовали сервер - без дефиса - ничего не изменилось.
Может надо в сервисе Firebird Server поставить галочку - взаимодействовать с рабочим столом или еще что-то где-то..?

Скалецкий Игорь 20.03.2014 16:07:52

А попробуйте следующее: остановите все службы ядро, монитор, репликатор, менеджер бд. Посмотрите в службах точно ли они остановлены. И просто перегрузите компьютер. Потом запустите все службы и проверьте запустились ли они. Такое подозрение, что Вы меняли версию программы и какие-то службы просто не работают либо запущены копии. Еще посмотрите в локальной сети нет-ли запущенного процесса (служба монитора) с обращением к рабочей базе. У нас однажды сосед по камере(инженер) игрался с разными базами и случайно запустил Службу Монитор на рабочую базу, потом неделю искал, что-же не работает. А NOD32 удален или просто отключен, если он был с брадмауэром, то все равно будет блокировать.

Пивоваров Алексей Викторович 20.03.2014 16:52:48

Службы останавливать через оснастку Windows Services или ярлыками из комплекта ПО Приток-А?

Потому что через ярлыки они удалятся. И, кстати, после перезапуска сервера автоматически не запускаются службы Ядро и Менеджер БД - приходится руками через ярлыки - удалять, а потом заново их создавать. Остальные службы - АРМонитор, Сервер служб, Репликатор и Pritok XDEV Server запускаются сами.

Process Explorer говорит, что файл БД занят только одним сервисом - fbserver.exe
По сети обращений к нему нету.

NOD32 удалили, но когда работал, то в исключения все было внесено.

Скалецкий Игорь 20.03.2014 18:06:44

Все таки рекомендую останавливать службы Ярлыками. При этом из служб они правильно удаляются. Перегружаем комп. и заново запускаем Службы Ярлыками. Далее рекомендую еще раз перегрузить комп. и теперь службы должны запуститься сами. У нас так. Еще вопрос Win2003 64 бит. Если да то еще раз проверьте пути к Firebird. А вообще можем созвониться (8652-28-27-41) или могу подключиться удаленно и посмотреть глазками может быстрее найду ошибку. Почему предлагаю, да потому что Сам знаю, что такое поломка базы,(не дай вам бог) и восстановление без резерва.

#10

Пивоваров Алексей Викторович 20.03.2014 19:20:37

Спасибо, будем пробовать по вашей инструкции =)
Windows x86, пути проверяли.

Резервные и архивные базы создаются по расписанию, единственное, если я правильно понимаю, сейчас у нас без Restore в рабочей БД накапливаются события, которые должны при Restore вычищаться из нее.

#11

Скалецкий Игорь 20.03.2014 19:26:33

Правильно понимаете. К тому-же размер базы увеличивается, при запросах скорость обработки снижается. И при большом размере базы(без Resore) может случиться крах. Рекомендую по возможности быстрее найти ошибку. Горький опыт: в ручную восстанавливал базу, более 600 объектов. Не очень то приятно провести несколько суток без отдыха.

#12

Пивоваров Алексей Викторович 20.03.2014 21:09:03

Увы и ах, не помогло... После второй перезагрузки сервера Ядро и Менеджер БД сами не запустились - только вручную через оснастку Windows Services.

Репликатор выдал ту же ошибку.

#13

Скалецкий Игорь 20.03.2014 21:26:22

Еще совет. Переписываем строчку выполнения после которой программа пишет "Не смогли перевести базу в Off-line", либо просто ее копируем из Loga, и выполняем вручную, можно в командной строке, а лучше создать отдельный bat. В итоге можно будет посмотреть параметры выполнения и почему не работает Restore.

#14

Скалецкий Игорь 22.03.2014 16:50:06

Уважаемый Алексей Викторович, как с базой? Нужна еще помощь? Если да то можете выложить полный Лог Репликатора и АРМонитора.

#15

Юлия Лефанова 24.03.2014 14:40:35

Цитата
Кто-нибудь еще сталкивался с подобным?

Да, давно правда.
Жаль что порядок действий из #2274 не помог. Проверьте всё -таки после остановки служб ярлыками, что в Services точно нет притоковских служб. И если вдруг окажутся, удалите через cmd sc_delete_Имя службы.
Файлы еще все лишние типа tmp_prtx_db.fdb и прочие, которых там быть не должно, из каталога с рабочей базой уберите. И интересно, когда службы остановлены, можете вы рабочую базу простым копированием в другое место перекинуть? Если база чем-то занята – не получится.

#16

Пивоваров Алексей Викторович 24.03.2014 16:23:21

Цитата
Скалецкий Игорь написал: Уважаемый Алексей Викторович, как с базой? Нужна еще помощь? Если да то можете выложить полный Лог Репликатора и АРМонитора.

Пока разбираемся. Похоже, что с 24 на 25 января кто-то из связки Репликатор-Firebird как-то криво отработал, следствием этого стал сабж. Будем еще проверять это.

#17

Сюкасев Сергей Владимирович 24.03.2014 16:25:40

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

#18

Орлов Павел, Разработчик 24.03.2014 16:26:21

Цитата
И интересно, когда службы остановлены, можете вы рабочую базу простым копированием в другое место перекинуть? Если база чем-то занята – не получится.

попробовать переместить. Скопировать получится.

#19

Сюкасев Сергей Владимирович 24.03.2014 16:27:33

Проще пытаться переименовать. Тогда точно не даст если занята.

#20

Орлов Павел, Разработчик 24.03.2014 16:45:31

Цитата
Сюкасев Сергей Владимирович написал: Проще пытаться переименовать. Тогда точно не даст если занята.

точно

#21

Пивоваров Алексей Викторович 27.03.2014 15:19:41

Доброго времени суток!

Ситуация с БД такова: никаким сторонним процессом она не занята.
Выяснилось, что если подсунуть в качестве рабочей базы ту, которая была создана в процессе репликации по расписанию 24 января 2014, то весь процесс резервирования проходит без ошибок.
Но если в качестве рабочей подсунуть ту, которая была создана в процессе Backup/Restore по расписанию, то выскакивает эта ошибка.

Что с этим можно сделать, чтобы всю базу не перебирать за два месяца последних?

#22

Пивоваров Алексей Викторович 27.03.2014 16:26:28

Спасибо.

Осталось только выяснить - кто ее поломал посреди ночи и вылечить!
Попробую сначала в техподдержку.

#23

Орлов Павел, Разработчик 27.03.2014 17:15:14

Цитата

Пивоваров Алексей Викторович написал:
Доброго времени суток!

Ситуация с БД такова: никаким сторонним процессом она не занята.

Выяснилось, что если подсунуть в качестве рабочей базы ту, которая была создана в процессе репликации по расписанию 24 января 2014, то весь процесс резервирования проходит без ошибок.

Но если в качестве рабочей подсунуть ту, которая была создана в процессе Backup/Restore по расписанию, то выскакивает эта ошибка.

Что с этим можно сделать, чтобы всю базу не перебирать за два месяца последних?

Отправляйте нам базу ту, которая "с ошибкой" . Проверим саму базу.

#24

Пивоваров Алексей Викторович 27.03.2014 17:18:31

Написал уже в поддержку Русаковой Елене по адресу elena@sokrat.ru

#25

Русакова Елена, Техподдержка 27.03.2014 19:33:16

Первоначальная проверка показала, что репликатор на наших АРМах с Вашей БД отрабатывает корректно. Попробуем посмотреть детальнее. Отправьте, пожалуйста, полностью логи притока и репликатора за 23.01, 24.01 и за 25.01, + логи firebirdа с серверов, + системные логи серверов.

#26

Пивоваров Алексей Викторович 27.03.2014 20:54:47

Во-первых, логов за январь, к сожалению, не сохранилось, потому что не думали, что это будет так выглядеть.
Во-вторых, тест на виртуальной машине показал, что Репликатор отрабатываает без ошибок на той же базе, что была отправлена в техподдержку (от 27 марта).
В-третьих, будем пробовать подобные манипуляции на рабочем сервере, удачи нам! =)

#27

Скалецкий Игорь 27.03.2014 21:42:07

Здаётся Мне, что у Вас все таки где-то неправильные пути, либо IP адреса, либо Имя компьютера, либо порт АРМонитора заблокирован. Перечитайте еще раз советы выше и проверьте все настройки. УДАЧИ.

#28

Пивоваров Алексей Викторович 27.03.2014 22:03:18

Удалил старую установку ПО вместе с Firebird, перезагрузился, установил 127 версию заново, подсунул архивную БД от сегодняшнего числа, перезагрузился - заработало!

Пути, настройки, адреса и др. - ничего не менял. Жду с утра отработку по расписанию.

#29

Пивоваров Алексей Викторович 28.03.2014 13:09:06

По расписанию все отработало правильно.
Получается, что ситуация разрешилась полной переустановкой программы. Кто бы мог подумать =)

Всем спасибо за помощь!

#30

Скалецкий Игорь 28.03.2014 14:13:45

Чудесно, что у Вас все заработало. Удачи!!!!

#31

Орлов Павел, Разработчик 28.03.2014 15:47:26

Хорошо, что заработало! Жаль, что так и не выяснили в чем проблема. На протяжении всей истории много догадок. .. База нормальная, проверили.

#32

Пивоваров Алексей Викторович 28.03.2014 17:00:04

Цитата
Орлов Павел написал: Хорошо, что заработало! Жаль, что так и не выяснили в чем проблема. На протяжении всей истории много догадок. .. База нормальная, проверили.

Да, жаль.
А как проверить? Если только посчитать, все-ли на месте.

#33

Орлов Павел, Разработчик 29.03.2014 19:01:45

Проверили специальными инструментами СУБД целостность структуры, нарушение страниц и т.д. Данные, содержащиеся в БД, при таких проверках не интересуют.

#34

Пивоваров Алексей Викторович 31.03.2014 13:12:30

Теперь понятно, спасибо.

#35

Тимашов Александр Сергеевич 24.11.2014 22:07:51

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

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

#36

Тимашов Александр Сергеевич 24.11.2014 22:26:49

Вот только что подкинул временную базу созданную репликатором (которую он не смог установить взамен рабочей) - репликация заработала нормально.

#37

Скалецкий Игорь 24.11.2014 23:16:14

Уточните какая версия ПО пульта и операционной системы
А так же поспрашайте операторов, точно ни какого предупреждения, о том, что база несархивировалась не было.
У нас если были какие-то проблемы с базой, то после или в момент архивирование. появлялось окно Дословно не помню, но что то типа. "Архивирование прошло неудачно, требуется вмешательство администратора" и еще одно "Не хватает оперативной памяти для завершения операции".

#38

Воробьев Павел, Разработчик 25.11.2014 09:57:48

"работали на версии 2.6.2.124, при обновлении до 3.6.2.127..."
ЭХ... 3.6.3 уже год как лежит на ftp.

#39

Скалецкий Игорь 25.11.2014 15:21:46

Цитата
Воробьев Павел написал: "работали на версии 2.6.2.124, при обновлении до 3.6.2.127..." ЭХ... 3.6.3 уже год как лежит на ftp.

Вот-вот, и я о том-же 3.6.3 надежней и больше функционала.

#40

Тимашов Александр Сергеевич 28.11.2014 19:26:11

Версия 3.6.2 (128) операционка ХР. Как раз перед обновлением на 3.6.3 решил проверить имеется ли база данных на случай ошибки обновления. А оказалось что репликации не производятся уже в течении почти месяца.... было очень неприятно.
Жду нового репликатора с оповещением.

#41

Скалецкий Игорь 28.11.2014 22:42:49

А еще что бы SMS на телефон начальника приходила

Еще раз поспрашайте операторов. Наши например окно с предупреждением просто закрывали и не кому не говорили. Пришлось в очередной раз проводить ликбез!!!

#42

Тимашов Александр Сергеевич 01.12.2014 13:59:29

Ну если я делаю репликацию и о том что репликатор не заменил базу данных узнаю из контрольной панели репликатора - это норма?
В АРМе при этом отображается что репликация завершена.

#43

Пивоваров Алексей Викторович 04.12.2014 20:23:23

Доброго времени суток!

Обновились до 3.6.3.121 на одном из серверов. Есть подозрение, что в настройках репликатора может слетать опция "Создавать архивные базы", но это только подозрение.

Нам СБ сообщает об ошибках и всплывающих красных окошках, если вдруг backup/restore не выполняется или что-то еще.

#44

Романов Иван Николаевич 25.12.2015 14:52:22

Здравствуйте, такая же проблема как и была указана изначально. База ни чем не занята (пробовал копировать никаких проблем), антивирусник удалял, вообще делал все что было предложено здесь ранее. Но ошибка точно такая же. При этом дата создания базы новая. Что то еще кроме переустановки может помочь? Версия по 3.6.3. (124) вин. XP sp3.

#45

Ершов Павел Андреевич, Техподдержка 25.12.2015 16:44:54

Обновитесь до 3.7.0 (123).

#46

Пивоваров Алексей Викторович 29.01.2016 14:52:11

День добрый!

Обновились до 3.7.0 (123) и непонятно - работает Репликатор или нет? (скриншот прилагается)

Прикрепленные файлы

post-00-49-88.png (151.26 КБ)

#47

Ершов Павел Андреевич, Техподдержка 01.02.2016 12:27:33

Репликатор и ядро на разных компьютерах?

#48

Пивоваров Алексей Викторович 01.02.2016 13:12:52

Цитата
Ершов Павел Андреевич написал: Репликатор и ядро на разных компьютерах?

Нет, все на одном.

Забавно! Вечером в пятницу ошибка была, в понедельник утром - все в порядке. Репликация проводилась по расписанию.

#49

Щеблыкин Игорь Александрович 16.02.2017 23:06:25

Здравствуйте, у меня тут тоже проблема с репликатором нарисовалась. Установил 18.10.2016 сборку 128 и начал выдавать ошибку репликатора, репликации не было по сей день, так как на основную работу АРМ это не влияло данную проблему не заметил, понадобилась история за тот срок когда репликатор не работал и тут я и сел, так как я не профессиональный пользователь в данной программе (пока что). 13.02.2017г. обновился до 129 сборки но проблема не решилась. Я так понимаю если скоро эту проблему не решить на меня рухнет база!!! помогите пожалуйста

#50 Скалецкий Игорь 17.02.2017 01:51:56 1. Посмотреть запущена ли служба АРМ Репликатор и АРМ Монитор 2. Проверить пути настроек программы Репликатора. 3. Нужно в логах репликатора(в папке Replikator, папки Logs и L) посмотреть какая ошибка. В частности присутствие строчки АРМ Монитор не смог заметить базу данных. 4. Желательно вообще обновиться до 3.7.1... Ну а если Вы не профессиональный пользователь программы, нужно срочно обратиться в службу поддержки по телефону(бесплатно) иначе, как Вы правильно подметили может случиться.... И будете базу в ручную переделывать.

Сиcтема охраны "Приток-А"

ПО Приток-А 3.6

Ошибка Репликатора