Страница 1 из 1
IB 7.5 - вторая попытка.
Добавлено: 15 июл 2005, 22:35
Anton Glasunov
Завтра перевожу боевую БД на IB 7.5.1. Переход на 7.5.0 в феврале был не удачен, описание есть здесь, на b.p.i.general и на qc.borland.com. Пришлось откатиться на 7.1 SP2.
Страшно.
Добавлено: 16 июл 2005, 08:37
Лысый
Не бойся мы с тобой
и не забудь помолиться борланду

Добавлено: 20 июл 2005, 00:36
Anton Glasunov
Третьи сутки - полёт нормальный. Чур меня!
Первая ласточка
Добавлено: 21 июл 2005, 10:15
Anton Glasunov
Ночной validate -
MYSERVER (Server) Thu Jul 21 01:28:01 2005
Database: D:\DBPATH\DATABASENAME.GDB
Index RDB$FOREIGN218 is corrupt on page 1107386 in table TABLE1 (168)
........................
15 раз; page не меняется.
MYSERVER (Server) Thu Jul 21 01:32:58 2005
Database: D:\DBPATH\DATABASENAME.GDB
Index RDB$FOREIGN188 is corrupt on page 1095331 in table TABLE2 (320)
.......................
6 раз; page не меняется.
Этот день отличался от предыдущих небольшой правкой метаданных. - добавление поля в таблицу TABLE3 и правка 4-х SP.
Такое я себе позволял и на предыдущей версии IB без особых последствий.
В момент правки было 6 открытых коннектов и одна (read, read_commited) транзакция. sweep интервал выставлен в 0.
Sweep вызывается еженочно после shutdown и validate.
Имеется статистика, собранная через Server API и IBAnalyst в конце каждого дня. Я не вижу там ничего особенного.
Ночное тестовое восстановление с validation в норме.
FOREIGN KEY constraints для этих индексов перестроил(удалил/создал) только что. Без проблем.
Я в печали.
Добавлено: 26 июл 2005, 16:32
Anton Glasunov
Работает неделю и один день. Пока была только описанная беда с индексами. Сегодня было внесено некоторое количество изменений в метаданнные. Буду посмотреть.
Остаюсь на IB751
Добавлено: 05 авг 2005, 12:14
Anton Glasunov
Устойчивость приемлемая.
Кто-нибудь встречал сообщение об ошибке
DBSERVER (Server) Thu Aug 04 11:36:05 2005
Procedure scan (2) for ИМЯ_ПРОЦЕДУРЫ failed
Не нашел ни в документации, ни на сайте. Да, я её правил примерно в это время, но после того вполне штатно перекомпилировалась. И работает.
Добавлено: 05 авг 2005, 12:30
kdv
imho это как то связано с кэшем метаданных в отношении процедур, то есть с параметром reclaim.
проверьте
select tmp$state from tmp$databases
и
select rdb$procedure_cache, rdb$reclaim_interval
from rdb$database
по умолчанию вроде как 300 секунд указано.
p.s. если вдруг что, то убрать reclaim, то есть периодическую "сборку мусора" в кэше метаданных, можно
ALTER DATABASE SET NO RECLAIM INTERVAL
Добавлено: 23 авг 2005, 09:40
_so_
To Anton Glasunov.
Как IB 7.5.1 работает? Я сегодня на одной из рабочих баз запустил.
При восстановление потерялись данные в одной таблице как всегда (На эту тему сдесь я уже писал
http://forum.ibase.ru/phpBB2/viewtopic.php?t=121), но я уже к этому был готов.
Добавлено: 23 авг 2005, 12:09
kdv
но я уже к этому был готов
дык, это ж баг. а его исправлять надо....
Добавлено: 23 авг 2005, 18:17
Anton Glasunov
To Anton Glasunov.
Как IB 7.5.1 работает? Я сегодня на одной из рабочих баз запустил.
Работает (стучу по дереву)
Вот эта штука с индексами:
Ночной validate -
MYSERVER (Server) Thu Jul 21 01:28:01 2005
Database: D:\DBPATH\DATABASENAME.GDB
Index RDB$FOREIGN218 is corrupt on page 1107386 in table TABLE1 (168)
проявлялась еще раз, на других форейн индексах. После того, как последовательность ночных действий -
shutdown - validate - sweep - restart,
я измененил на
sweep - shutdown - validate - restart
появление ошибки в логе после validate прекратилось. Хотя "после того, не означает вследствие того".
С 5-го августа в логе нет ошибок кроме обычных 10054, в приемлемом количестве, с удаленных клиентов ODBC (тьфу(3р)).
В прошедшее воскресение увеличил размер страницы до 16K и размер кэша до 32K страниц. Сейчас жду что будет.
Такие дела.
Добавлено: 24 авг 2005, 09:26
_so_
Anton Glasunov писал(а):В прошедшее воскресение увеличил размер страницы до 16K и размер кэша до 32K страниц. Сейчас жду что будет.
Спасибо.
16K уже поставил давно при переходе на 7.5 (полгода назад) .
Тут кстати заметил чуть-чуть получше стал работать оптимизатор планов на некоторых запросах.