Добрый день

При попытке подключиться, пишет:
"wrong page type
page 0 is of wrong type (expected 3, found 1)."

Версия FB 2.1.1 (да я знаю, что это очень старая версия и я сам себе враг - у меня нет возможности мигрировать на более "свежую")
Windows 2012 R2 x64

Есть ли шанс это вылечить хоть каким-то способом? Стоит ли покупать FBFirstAID для этого? Или база умерла и проще восстановить утренний бекап и заставить пользователей повторить рабочий день?

Заранее спасибо за конструктивную помощь

AltHasp, пробовал. Любое подключение к БД дает такую ошибку

Dimitry Sibiryakov, т.е. только восстановление старого бекапа?
А совместимость БД при апгрейде нормальная?

Всем спасибо
Восстановили утреннюю базу
На выходных буду пытаться апдейтить сервер

kdv, спасибо
Утром ошибка повторилась. И опять с тем же текстом

Поставил 2.1.7 - идет восстановление БД (она больше 30Гиг)

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

kdv, принудительное прибитие процессов или "шутдаун" сервера могут к этому приводить? (у нас виртуалки и с дисками скорее всего проблем нет, но если там всякие кеши или "порванные" транзакции)

HEX редактором-то посмотреть не сложно. Было бы знать - куда смотреть и что там видеть :)

Dimitry Sibiryakov, gbak этой БД идет около 4 часов. В команде указан сетевой путь: (сервер):(путь к фалу)

Банальное копирование идет очень быстро, безусловно, но почему так долго делается gbak - не знаю

БД на MS SQL объемом около 72 Гиг из бекапа поднимается значительно быстрей.
Я подозревал, что это особенность работы gbak и FB

Сколько по вашему мнению должен идти рестор такой БД и куда стоит посмотреть? (мой ник не просто так придуман)

Ivan_Pisarevsky, подскажите, как правильней "убивать" зависшие подключения - я передам админам, чтобы настроили заббикс на корректную работу.

шутдаун сервера - имеется ввиду сервер Windows (знаю, что админы иногда грешат таким).

ну, вот такая системная ошибка начала появлться буквально в этом году. до этого на виртуалках все работало нормально


нет, ключая -SE нет - командные файлы остались от разработчиков, которые ушли громко хлопнув дверьми

kdv, куда смотреть? что может быть? копирование файлов таких объемов очень быстро идет. но вот бекап делается до 30 минут, а восстановление около 4 часов

Ivan_Pisarevsky, спасибо за подсказку -SE - ускорение в 9 раз...

kdv, спасибо. Передам админам - пусть "курят"

Проблема не решилась

Версия 2.1.7
Восстановил из бекапа базу
Минут через 20 та же проблема - при попытке подключиться начинает писать, что сервер не отвечает. На сервере 100500 процессов серверов.
У админов сработал автомат (не успел их предупредить) и они рубанули процессы и перегрузили службу ФБ
В результате та же ошибка с нулевой страницей.

Запустил восстановление. Куда смотреть, почему начинает "подвисать" БД и новые подключения отвергаются сервером?


UPD: есть отчеты, которые запускают за месяц и они формируются очень долго. не может ли там быть какая-то блокировка, которая "вешает" сервер.
Эта проблема началась вчера. В 22:00 была запущена база и всю ночь работала нормально - ночные смены работают по производству.
Но утром, когда подключился "офис", то в районе 10 утра все опять "зависло". Может офисные запросы на конец месяца (отчеты за июль, расчеты и т.п.) загружают сервер настолько, что админские системы распознают ее как "умершую" и убивают процессы. Что приводит к нарушение целостности БД?
Может где-то в конфиге можно настроить менее "эгоистичное" поведение для подключений?

Симонов Денис, что такое FW? (простите за глупые вопросы - я полный нуб в этом всем)

В log-файле перед "зависанием" появились вот такие записи:

"internal gds software consistency check (page in use during flush (210), file: cch.cpp line: 2975)"

и еще вот такая:

"page 1465957, page type 4 lock conversion denied (215)"

Симонов Денис,


Database "d:\MAINBASE.FDB"
Database header page information:
Flags 0
Checksum 12345
Generation 4758
Page size 16384
ODS version 11.1
Oldest transaction 3272
Oldest active 3273
Oldest snapshot 3273
Next transaction 4685
Bumped transaction 1
Sequence number 0
Next attachment ID 66
Implementation ID 16
Shadow count 0
Page buffers 2048
Next header page 0
Database dialect 1
Creation date Aug 5, 2020 15:32:49

Variable header data:
Sweep interval: 0
*END*

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

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

Ivan_Pisarevsky, вполне возможно, что там могут быть частые вставки и удаления (код очень "мудреный" с вложенностью больше 5 уровней вызовов хранимок). Если поставить принудительный сбор мусора - может помочь?

Basil A. Sidorov, данная опция сказывается на "скорострельности" при частых вставках?

Спасибо всем за помощь и участие

1. Выношу копию для "тяжелых" отчетов (проблема будет в обучении пользователей, чтобы они не забывали переходить)
2. Напрягаю админов по железу
3. Наверное, почищу немного базу, чтобы убрать старые записи, которые точно уже использоваться в оперативной работе не будут (база 2018 года была 21 гиг) - это может сказаться на скорости выполнения запросов