Re: Ошибка при добавл ении CHECK в таблицу

2010-07-23 Пенетрантность Dmitry Yemanov

24.07.2010 3:02, Andrei пишет:


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


Тогда уж удалить все чеки и пересоздать их. После удаления проверить, 
чтобы rdb$check_constraints была пустой.



в процессе апгрейда gbak-ом с Yaffil на 2.5 такой поломки не
может произойти?


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


Если базы с яффила сохранились, то можно посмотреть, в каком состоянии 
там были системные таблицы до переезда.



Дмитрий



Re: Ошибка при добавлении CHECK в таблицу

2010-07-23 Пенетрантность Yurij
On Jul 24, 2:02 am, Andrei  wrote:
> и у меня уже не одна такая база :(
> очень надеюсь, что среди баз размером 25-40 Гб таких
> битых не окажется. Так как пересоздание их через скрипт
> мягко говоря не реально.

А вот, кстати, откуда такая религия, что пересоздать эти базы через
скрипт нереально?

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

Re: Ошибка при добавлении CHECK в таблицу

2010-07-23 Пенетрантность Andrei

и у меня уже не одна такая база :(

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

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

в процессе апгрейда gbak-ом с Yaffil на 2.5 такой поломки не
может произойти?

Re: Странное поведени е птицы

2010-07-23 Пенетрантность Dmitri Kuzmenko

Hello, Konstantin!

Konstantin R. Beliaev wrote:


Это вот это?
Average version length: 61.82, total versions: 40104, max versions: 1
В нескольких таблицах есть подобное количество версий, но max versions 
больше 1 не поднимается.


обычно это означает результат удаления. Особенно если размер
записи меньше размера версии.


   no reserve зачем поставил ?

Я его не ставил :-
Вот строчка тестового рестора из скрипта в отдельный каталог:
gbak %BFILE% %RFILE% -replace_database -o -v -y %RLOG%


да пох. значит когда-то поставил, и теперь этот флаг кочует при BR.
Я вообще удивляюсь обширности знаний - много же разных флагов остаются 
неизменными при B/R - размер страницы, свип интервал, FW, и в частности 
no reserve.



Как его теперь отключить-то?


use gfix, Luke.

--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34




Re: Ошибка при добавл ении CHECK в таблицу

2010-07-23 Пенетрантность Dmitry Yemanov

23.07.2010 18:28, Sergey Mereutsa пишет:


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


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



Дмитрий



Re[2]: Ошибка при добавлении CHECK в таблицу

2010-07-23 Пенетрантность Sergey Mereutsa
Привет!

> У тебя в системных таблицах какой-то ужас. Два разных чека на разных 

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


-- 
Best regards,
 Sergeymailto:gebele...@gmail.com




Re: Ошибка при добавл ении CHECK в таблицу

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


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



Дмитрий



Re: Странное поведени е птицы

2010-07-23 Пенетрантность Konstantin R. Beliaev

Vlad Khorsun wrote:


   Кол-во бекверсий и длины их цепочек.


Это вот это?
Average version length: 61.82, total versions: 40104, max versions: 1
В нескольких таблицах есть подобное количество версий, но max versions 
больше 1 не поднимается.



   no reserve зачем поставил ?


Я его не ставил :-
Вот строчка тестового рестора из скрипта в отдельный каталог:
gbak %BFILE% %RFILE% -replace_database -o -v -y %RLOG%
Время от времени я руками подменяю рабочую базу отресторенной.
Разве что когда-то давно поставил и он запоминается в файле бэкапа?
Как его теперь отключить-то?



Re: Скорость инсертов

2010-07-23 Пенетрантность Khorsun Vlad

"Tonal" ...

07.07.2010 14:32, Vlad Khorsun пишет:

Наткнулся на странную вещь: при массовой загрузки данных в базу скорость
последовательности инсертов уменьшается на 1/6 если все они в одной
транзакции.

...

На обоих таблицах триггера генерят ID и VERS и бросают EVENT:

   А если без EVENT ?

Да, при отключении триггера скорость остаётся постоянной.

А в чём прикол? Вроде EVENT-ы это простые счётчики. В любом случае после
комита бросится только 2 штуки, откуда такое замедление?


   Внутренняя очередь с отложенными до коммита заданиями (DFW) используется
криво - каждый раз POST_EVENT добавляет туда новый элемент, а не увеличивает
счётчик для имеющегося. Соответственно к коммиту мы имеем гигантскую очередь
из одинаковых ивентов. Напишешь трекеру ?

--
Хорсун Влад