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

Kabaev Sergey

B/R не проходит, валится на restore.

Нашел в настройках коннекта диалект подключения. Он тоже SQL 3.

SELECT BEID FROM T_BENTITY WHERE BEID+0=2072261010057931 только что выполнил. Результат пустой. База данных была два раза перезапущена, видимо после этого запись по какой-то причине пропала.

В-общем мы сейчас вообще думаем отказаться от ведения Оперативной и Аналитческой базы и уйти полностью на Аналитическую. Если Аналитика будет и дальше сыпаться, то, наверное, будем переползать на MS SQL.

WildSery · Сообщение **WildSery** » 20 авг 2007, 11:02

Kabaev Sergey писал(а):B/R не проходит, валится на restore.

На чём конкретно валится? Смотри в лог или покажи кусочек.

Kabaev Sergey писал(а):Если Аналитика будет и дальше сыпаться, то, наверное, будем переползать на MS SQL.

Работа со сломанной базой - замечательный инструмент убеждения начальства в необходимости смены сервера.
Мне вот интересно, что за продукт такой, которому пофиг, с FB или MSSQL работать? Или расчёт на то, что и софт переписывать придётся, а следовательно, и деньги будут под это дело выделяться?

Kabaev Sergey

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

1 Делаем запрос по связке таблиц A и B. Запрос с использованием плана.
2 Interbase выдает ошибку
Invalid token.
invalid request BLR at offset 147.
и что в плане не может использоваться индекс, кторый относится к третьей таблице C, вообще не упоминающейся в запросе.
3. Пердположили, что при восстановлении базы был поврежен этот индекс и пересоздали его.
4. После чего таблица С вообще исчезла.

Я так понимаю, что там и таблицы с метаданными повреждены.

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

Dimitry Sibiryakov

Парень, у тебя бьется база. Серьезно бьется. Шансов, что виновата птичка весьма немного, так что тебе следует проверить следующие вещи:
1) Force Writes = ON
2) БД имеет расширение fdb или системное восстановление отключено для диска с базой
3) БД внесена в игнор-лист антивирусов
4) ОЗУ работает устойчиво.

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

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

Kabaev Sergey писал(а):Я так понимаю, что там и таблицы с метаданными повреждены.

Таблицы с метаданными не могут быть повреждены просто так, потому как заново создаются при ресторе.
На твоём месте я бы попробовал эту базу отресторить и поглядеть на другом компьютере.

Kabaev Sergey

WildSery писал(а):Таблицы с метаданными не могут быть повреждены просто так, потому как заново создаются при ресторе.
На твоём месте я бы попробовал эту базу отресторить и поглядеть на другом компьютере.

Так и было сделано - база была отресторена на другом сервере. Именно в ней пошли странные сообщения.

Kabaev Sergey

Dimitry Sibiryakov писал(а):1) Force Writes = ON
2) БД имеет расширение fdb или системное восстановление отключено для диска с базой
3) БД внесена в игнор-лист антивирусов
4) ОЗУ работает устойчиво.

Force Writes = ON
Расширение файла базы .ib
Антивирусов на сервере нет.
ОЗУ - думаю, что работает устойчиво. Вроде целый отдел за ними следит.

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

Всё страньше и страньше. Мой телепатор скрипит уже.
Ты утверждаешь, что просто запросом к базе ты получаешь "invalid request BLR at offset 147"?
И уже назрел вопрос - каким инструментом ты лазишь в базу?

Kabaev Sergey

Ну да. Вот такой запрос есть в коде одной из программ работающих с Аналитикой:

select t_prod.*, t_bentity.bstateid
from t_prod, t_bentity
where t_bentity.beid = t_prod.beid
plan sort ( join (
t_prod natural,
t_bentity index (i_bentity_beid_bstateid)))
order by prodnumber

Вот такой ответ был получен от сервера при выполнении prepare:

Invalid token.
invalid request BLR at offset 147.
there is no index RDB$FOREIGN_T_POSTINGPLAN1 for table T_POSTINGPLAN.

Потом, кода дошел до этой ошибки под отладчиком, пытался выполнить запрос из IB Expert, получил то же сообщение.

Основной инструмент для работы с базой - IB Expert, версия одна из последних. Для backup/restore использовались штатные средства IB 7.5

PS Еще одна деталь, не знаю важная или нет.
Когда поднимали эту тестовую копию базы, ее сделали с одним отличием - файл базы данных был разбит на 5 файлов. Боевая база же у нас в двух файлах.

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

Kabaev Sergey писал(а):PS Еще одна деталь, не знаю важная или нет.
Когда поднимали эту тестовую копию базы, ее сделали с одним отличием - файл базы данных был разбит на 5 файлов. Боевая база же у нас в двух файлах.

Есть какой-то смысл в разбиении базы?
Вполне может быть, что вы в кусочках запутались, потому как ссылки внутри по абсолютному пути указываются.

Kabaev Sergey

У нас как раз была версия, что IB не переварил большой файл.

Почему попробовали - предыдущая версия нашей системы два года до этого работала с меньшими объемами данных безо всяких проблем. Объем базы был около двух гигов.

hvlad · Сообщение **hvlad** » 21 авг 2007, 11:49

Kabaev Sergey писал(а):Ну да. Вот такой запрос есть в коде одной из программ работающих с Аналитикой:

select t_prod.*, t_bentity.bstateid
from t_prod, t_bentity
where t_bentity.beid = t_prod.beid
plan sort ( join (
t_prod natural,
t_bentity index (i_bentity_beid_bstateid)))
order by prodnumber

Вот такой ответ был получен от сервера при выполнении prepare:

Invalid token.
invalid request BLR at offset 147.
there is no index RDB$FOREIGN_T_POSTINGPLAN1 for table T_POSTINGPLAN.

А тот же запрос без plan ?

Kabaev Sergey писал(а):PS Еще одна деталь, не знаю важная или нет.
Когда поднимали эту тестовую копию базы, ее сделали с одним отличием - файл базы данных был разбит на 5 файлов. Боевая база же у нас в двух файлах.

Это абсолютно не нужно, но с этой ошибкой не связано

Kabaev Sergey

hvlad писал(а):А тот же запрос без plan ?

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

Dimitry Sibiryakov

HT отключать не пробовали? FB2 устанавливать пробовали?

Дело в том, что IB наплевать на неправильные планы, а вот FB их есть отказывается. Так что проверь на всякий случай, что ты используешь базу с соответствующим сервером.

Kabaev Sergey

HT не отключали, на FB базу не пробовали.

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

Kabaev Sergey писал(а):Ну да. Вот такой запрос есть в коде одной из программ работающих с Аналитикой:

select t_prod.*, t_bentity.bstateid
from t_prod, t_bentity
where t_bentity.beid = t_prod.beid
plan sort ( join (
t_prod natural,
t_bentity index (i_bentity_beid_bstateid)))
order by prodnumber

Вот такой ответ был получен от сервера при выполнении prepare:

Invalid token.
invalid request BLR at offset 147.
there is no index RDB$FOREIGN_T_POSTINGPLAN1 for table T_POSTINGPLAN.

Вчера у меня телепатор отказался наглухо работать по причине жосткого бодуна, сегодня я уже опять бОльшей частью в этом мире. Наводящие вопросы:
1. Что на экран вывелось по завершении рестора, читать не пробовали?
2. Наличие индекса и его активность проверяли?
3. Ну, и в каких триггерах или вызываемых ими процедурах в явном плане задействован этот индекс? Не обязательно именно от этих двух таблиц, от упомянутых в их триггерах таблиц тоже. И в их, и в их, и в их... На препаре поднимается ВСЁ связанное с таблицами, во всяком случае, для проверки прав доступа, неважно что селект.

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

Kabaev Sergey писал(а):HT не отключали

Очень зря.

Kabaev Sergey

WildSery писал(а):
Kabaev Sergey писал(а):HT не отключали
Очень зря.

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

Kabaev Sergey

Merlin писал(а):1. Что на экран вывелось по завершении рестора, читать не пробовали?
2. Наличие индекса и его активность проверяли?
3. Ну, и в каких триггерах или вызываемых ими процедурах в явном плане задействован этот индекс? Не обязательно именно от этих двух таблиц, от упомянутых в их триггерах таблиц тоже. И в их, и в их, и в их... На препаре поднимается ВСЁ связанное с таблицами, во всяком случае, для проверки прав доступа, неважно что селект.

1 Насколько я понял со слов того человека, который поднимал базу restore закончилось без ошибок.
2. Индекса в момент возникновения ошибки в базе не было.
3. Где это индекс использован? - в одной из view в базе. Плюс, возможно, в коде запросов на рабочих местах.

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

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

Kabaev Sergey писал(а): Но данный индекс не так важен. В поднятой базе было несколько подобных ошибок с другими запросами,другими ключами и таблицами. Общее в запросах было только то, что IB пытался использовать в запросе индексы для совершенно левых таблиц, не упоминаемых в запросе.

Я, конечно, именно за IB-то не слежу давно, но повторяю ышо раз: скорей всего это только кажется, что таблицы не упоминаемые. При любом обращении к таблице отслеживаются все её зависимости, в том числе опосредованные. Где-то в триггерных цепочках от "упоминаемых" идёт упоминание этих "левых" таблиц и индексов.