Задам тут 2 вопроса. Потому как после первой проблемы возникла вторая...
1. Все началось с того что в базу перестали записываться данные. Данные
это тупо одно текстовое поле и один маленько-большой БЛОБ (от 1 кб до 3
Мб обычно). Просто ТУПО перестали записываться данные. Программа которая
все
При ресторе после строк
gbak: restoring data for table STORE
gbak:1 records restored
выскакивает ошибка:
Initialisation failure.
Arithmetic exception, numeric overflow or string truncation
Похоже на ошибку в данных, но в той таблице, на которую идет ругань
метаданные не менялись лет
"Андрей Кручинин" ...
Задам тут 2 вопроса. Потому как после первой проблемы возникла вторая...
1. Все началось с того что в базу перестали записываться данные. Данные это тупо одно текстовое поле и один маленько-большой БЛОБ
(от 1 кб до 3 Мб обычно). Просто ТУПО перестали записываться данные. П
объем базы был около 37 Гб.
Как-то у меня сразу глаз за эту цифру зацепился. Какое-то было ограничение
именно с такой цифрой.
09.12.2010 21:01, Oleg Matveyev пишет:
объем базы был около 37 Гб.
Как-то у меня сразу глаз за эту цифру зацепился. Какое-то было
ограничение именно с такой цифрой.
Потому и написал сразу, мало ли ...
--
Андрей Кручинин
www.med-zakaz.ru
Для особо извращенных - http://мед-заказ.рф :-)
"Oleg Matveyev" ...
объем базы был около 37 Гб.
Как-то у меня сразу глаз за эту цифру зацепился. Какое-то было ограничение
именно с такой цифрой.
Это ограничение на размер одной таблицы в ОДС младше 11
--
Хорсун Влад
09.12.2010 22:19, Dmitry Yemanov пишет:
RDB$ADMIN -> владелец SYSDBA.
Причем тут владелец? Значение RDB$SYSTEM_FLAG чему равно?
4
Это в БД до "я ее через embedded прогнал через b/r", или
уже после ?
Влад
Но интересен вопрос плана - откуда могло вылезти в принципе?
Мне тоже это интересно. Если говорить о "в принципе", то
gbak до версии 2.5 не знает о существовании системных ролей,
и пишет в бекап все роли.
--
Хорсун Влад
В письме от Thu, 09 Dec 2010 23:35:18 +0300, Vlad Khorsun
сообщал:
Как-то у меня сразу глаз за эту цифру зацепился. Какое-то было
ограничение именно с такой цифрой.
Это ограничение на размер одной таблицы в ОДС младше 11
Начало топика ("Все началось с того что в базу перестали записы
"Arioch" ...
В письме от Thu, 09 Dec 2010 23:35:18 +0300, Vlad Khorsun
Как-то у меня сразу глаз за эту цифру зацепился. Какое-то было ограничение
именно с такой цифрой.
Это ограничение на размер одной таблицы в ОДС младше 11
Начало топика ("Все началось с того что в базу перестали запи
Hello, Oleg!
Oleg Matveyev wrote:
объем базы был около 37 Гб.
Как-то у меня сразу глаз за эту цифру зацепился. Какое-то было
ограничение именно с такой цифрой.
макс. размер таблицы до ODS 11 (FB).
Так как тут FB 2.x, то не канает.
--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
В письме от Tue, 14 Dec 2010 16:00:43 +0300, Dmitri Kuzmenko
сообщал:
макс. размер таблицы до ODS 11 (FB).
Так как тут FB 2.x, то не канает.
Не должно канать. Но мало ли какой у него мог ODS случиться...
--
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/
15.12.2010 12:52, Arioch пишет:
макс. размер таблицы до ODS 11 (FB).
Так как тут FB 2.x, то не канает.
Не должно канать. Но мало ли какой у него мог ODS случиться...
Цитата из ПЕРВОГО сообщения: "База переводилась под 2.5 через b/r"
Konstantin R. Beliaev wrote:
И если нет, то как бы найти строку с этой самой ошибкой?
select count(FieldX) отрабатывает нормально.
select * и отфетчить все строки.
--
Дмитрий Еманов
Dmitry Yemanov wrote:
select * и отфетчить все строки.
Проходит нормально...
On Tue, 06 Feb 2007 11:45:46 +0300, Konstantin R. Beliaev <[EMAIL PROTECTED]>
wrote:
>> select * и отфетчить все строки.
>>
> Проходит нормально...
Возможно, на момент бэкапа было "ненормально"?
Попробуй сейчас сделать бэкап с контрольным рестором.
--
Сергей Смирнов.
WildSery wrote:
Возможно, на момент бэкапа было "ненормально"?
Попробуй сейчас сделать бэкап с контрольным рестором.
Ошибка стабильно повторяется.
Переслали бэкап мне, получил другую ошибку:
gbak: cannot commit index RDB$FOREIGN29
gbak: ERROR: violation of FOREIGN KEY constraint "INTEG_62" on
А, собака! разобрался!
В Storenames были NOTNULL поля с null-ами. Они не отресторились и
ссылающаяся таблица обругала их отсутствие.
Правда так и не понял: это бэкап пропускал такие записи или рестор их
выкидывал.
Бэкап под IB 4.0, за ним раньше выкидывания записей не замечалось.
Рестор под FB
Konstantin R. Beliaev wrote:
Правда так и не понял: это бэкап пропускал такие записи или рестор их
выкидывал.
Понял: выкидывал рестор, об этом есть записи в логе.
Интересно, если бы не ФК, в самом конце рестора мне бы выскочило
сообщение об ошибках?
Hello, Konstantin!
Konstantin R. Beliaev wrote:
Понял: выкидывал рестор, об этом есть записи в логе.
Интересно, если бы не ФК, в самом конце рестора мне бы выскочило
сообщение об ошибках?
нет. здесь все ОК, кроме сообщения об ошибке. при построении FK
если в детали есть записи которых нет в
Dmitri Kuzmenko wrote:
нет. здесь все ОК, кроме сообщения об ошибке. при построении FK
если в детали есть записи которых нет в мастере (логически
или физически поврежденная БД), выдается вот такое
сообщение. Лечится так:
1. поскольку это проблема создания индексов, база ресторится
целиком.
2. а
Dmitry Yemanov wrote:
Достаточно до релиза 2.0.0 (билд 12748), но лучше конечно же поновее.
Все отресторилось, спасибо.
22 matches
Mail list logo
