База, созданная IB 6.5, возможно ли?
Модераторы: kdv, Alexey Kovyazin
База, созданная IB 6.5, возможно ли?
Сменить сервер на FireBird 1.5? Т.е. без backup/restore? Базу не поломаю?
Re: База, созданная IB 6.5, возможно ли?
Имхо обязательно поломаешь. FB и IB разветвились именно в этой точке, в том числе по нумерации ODS. Ну и кроме того, там уже различия по синтаксису есть.Дмитрий писал(а):Сменить сервер на FireBird 1.5? Т.е. без backup/restore? Базу не поломаю?
-
Alexx
Нет, линия IB6.0x - FB-0.9x - FB1.0.x - FB1.5.x непрерывыная, там minor изменения ODS, которые выполняются следующим сервером в момент первого открытия базы предыдущей версии. Также как IB6.0.x - IB6.5 - IB7.x. Вот downgrade в обоих линиях требует бакапа gbak-ом более старой версии под сервером более новой и restore на своём. И не рекомендуются прыжки через одну и более версий ни вперёд ни назад. Но я от греха всегда делаю b/r.Alexx писал(а):Упс!
А если я с ФБ 1.0.0.338 на 1.5.1 перепрыгнул без бакап-рестора (вернее - без рестора) - тоже сюрпризов ждать?
Хотя щас вроде база нормально себя ведет уж месяц как... (правда я в структуру БД еще пока никаких изменений не вносил...)
www.ibase.ru/devinfo/prevver.htm
кстати, обновил, добавил про 7.5. Однако как и все, написанное ранее и подвергающееся длительным правкам-дополнениям, стало выглядеть удручающе. Впечатление такое, что надо бы это переписать целиком...
В общем, если есть советы на эту тему - пишите...
кстати, обновил, добавил про 7.5. Однако как и все, написанное ранее и подвергающееся длительным правкам-дополнениям, стало выглядеть удручающе. Впечатление такое, что надо бы это переписать целиком...
В общем, если есть советы на эту тему - пишите...
неправильно понял. напрямую можно. НО. если не сделать бэкап, нельзя будет откатиться назад.
В любом случае с бэкапом или без может вылезти кривизна, если использовались фишки 6.5, в частности ROWS в хранимых процедурах и триггерах (FB этого не понимает, ему FIRST надо).
ну и потом, вообще, лучше когда сервер работает с родной, созаднной им самим, пусть одним и тем же ODS.
В любом случае с бэкапом или без может вылезти кривизна, если использовались фишки 6.5, в частности ROWS в хранимых процедурах и триггерах (FB этого не понимает, ему FIRST надо).
ну и потом, вообще, лучше когда сервер работает с родной, созаднной им самим, пусть одним и тем же ODS.
Що?!!! Это 386-й что ли? В рестор ещё поверю если база за 10 гигов да индексов за 2 тыщи. Или индексы по полям, содержащим исключительно "Да" и "Нет"Дмитрий писал(а):Дело в том, что есть желание посмотреть, как будет работать FB Classic Server на многопроцессорном сервере, backup идет примерно 4 часа, а restore идет примерно 8 часов. Вот в чем прблема.
А вот бакапиться такая база должна минут за 40. Если не забыть -g gbak-у сказать.И правильно делаешь. Верняк сходу не будет, несколько дней придётся покувыркаться. А то и пару недель при таком объёме, там поди и процедур с триггерами хватает и приложение не маленькое. Пока IB-only фички заменишь на FB аналоги, пока с ambigious queries разберёшься, пока с некорректными group by - order by...Дмитрий писал(а):13 Гб . Рисковать боюсь. Вдруг на ФБ работать не будет. Я потом на ИБ уже просто так не вернусь.Кстати, каков размер базы?
IB75 дружит с HT. только HT вообще то надо выключать.
www.ibase.ru/devinfo/ht.htm
вообще HT предназначена для рабочих станций. на сервере HT вообще незачем. Смысл? Докажите мне обратное, после прочтения указанной статьи.
www.ibase.ru/devinfo/ht.htm
вообще HT предназначена для рабочих станций. на сервере HT вообще незачем. Смысл? Докажите мне обратное, после прочтения указанной статьи.
-
Alexx
Прямо вот так вот фактами пока не докажу.kdv писал(а):вообще HT предназначена для рабочих станций. на сервере HT вообще незачем. Смысл? Докажите мне обратное, после прочтения указанной статьи.
Но считаю, что нужно действительно смотреть по конкретному сочетанию задачи и железа. Один из доводов (№1), что загрузка процов под 100% достигается тока на вычислительных приложениях - не совсем верен.
У меня отнюдь не вычислительное приложение, однако с нынешним уровнем использования БД, работающей под CS (ФБ 1.5.1), при выключенном НТ, (после прочтения указанной статьи) загрузка процов часто бывает 95-98%, а иногда - ненадолго зашкаливает. Если нагрузка еще возрастет и зашкаливание будет более частым, то разнесение процессов по 4 (пусть даже 2 из кот. и являются виртуальными) процессоров вполне может ускорить работу, даже и при большей нагрузки на процессорную шину.
"Полевые испытания" проведу как тока подкинут нагрузки на БД...