Ошибка сервера FB2.0 при изменении типа столбца на UTF8
Ошибка сервера FB2.0 при изменении типа столбца на UTF8
Всем привет. Всё-таки я пробился на этот форум несмотря на то что Google Mail пометил как спам письмо от kdv с активацией
Проблема такая. В горячо любимом мной сервере FireBird 2.0.0 я обнаружил ошибку, которая возникает после действий:
1) Создаем таблицу RL_DISCIPLINES с двумя полями:
CREATE TABLE RL_DISCIPLINES (
ID INTEGER NOT NULL,
DISCNAME_RUS CHAR(254) CHARACTER SET WIN1251 COLLATE WIN1251
);
вводим строк 20 данных в эту таблицу на русском языке.
2)
Потом вдруг решаем изменить тип данных столбца DISCNAME_RUS на CHAR(254) CHARACTER SET UTF8 COLLATE UNICODE
3) изменяем имя столбца на DISCNAME.
После этого БД работает нормально, но проблема заключается в следующих моментах:
1) Не проходит успешно Restore DataBase после его Backup при помощи IBExpert
2) Не проходит успешно Restore DataBase после его Backup при помощи утилиты gback.exe
3) После создания в этой таблице дополнительного поля
discname_utf8 типа CHARACTER SET UTF8 COLLATE UNICODE
при запуске запроса
insert into rl_disciplines(discname_utf8)
select
discname
from rl_disciplines
order by id
размер базы данных растет бесконечно, сервер уходит в бесконечный цикл, хотя и работает стабильно, не падает. Размер файла БД растет и растет и конца-края этому не видно.
сервер FireBird 2.0.0 установлен в архитектуре SuperServer под операционной системой Windows 2000 Professinal SP4 RUS.
Цель: Необходимо цикл backup/restore database выполнить успешно.
Ниже приведен отрывок протокола сообщений утилиты gback при restore DB:
gbak: activating and creating deferred index FK_RL_INFRESOURCES_RESTYPE_ID
gbak: activating and creating deferred index FK_RL_DISCBYCHAIR_DISCID
gbak:cannot commit index FK_RL_DISCBYCHAIR_DISCID
gbak: ERROR:violation of FOREIGN KEY constraint "PK_RL_DISCIPLINES" on table "RL_DISCIPLINES"
gbak: ERROR: Foreign key reference target does not exist
gbak: committing metadata
gbak:finishing, closing, and going home
gbak:Database is not online due to failure to activate one or more indices.
gbak:Run gfix -online to bring database online without active indices.
когда же операцию восстановления БД из баккапа делаю в IBExpert, он сообщает:
bak:restoring data for table RL_DISCBYCHAIR
gbak: 27 records restored
IBE: Invalid token.
Malformed string.
gds_$send failed.
Вот: Malformed string !
Кстати, образ БД крохотный. 1 Mb.
Если что могу выслать. Никаких коммерческих секретов у меня нет
Проблема такая. В горячо любимом мной сервере FireBird 2.0.0 я обнаружил ошибку, которая возникает после действий:
1) Создаем таблицу RL_DISCIPLINES с двумя полями:
CREATE TABLE RL_DISCIPLINES (
ID INTEGER NOT NULL,
DISCNAME_RUS CHAR(254) CHARACTER SET WIN1251 COLLATE WIN1251
);
вводим строк 20 данных в эту таблицу на русском языке.
2)
Потом вдруг решаем изменить тип данных столбца DISCNAME_RUS на CHAR(254) CHARACTER SET UTF8 COLLATE UNICODE
3) изменяем имя столбца на DISCNAME.
После этого БД работает нормально, но проблема заключается в следующих моментах:
1) Не проходит успешно Restore DataBase после его Backup при помощи IBExpert
2) Не проходит успешно Restore DataBase после его Backup при помощи утилиты gback.exe
3) После создания в этой таблице дополнительного поля
discname_utf8 типа CHARACTER SET UTF8 COLLATE UNICODE
при запуске запроса
insert into rl_disciplines(discname_utf8)
select
discname
from rl_disciplines
order by id
размер базы данных растет бесконечно, сервер уходит в бесконечный цикл, хотя и работает стабильно, не падает. Размер файла БД растет и растет и конца-края этому не видно.
сервер FireBird 2.0.0 установлен в архитектуре SuperServer под операционной системой Windows 2000 Professinal SP4 RUS.
Цель: Необходимо цикл backup/restore database выполнить успешно.
Ниже приведен отрывок протокола сообщений утилиты gback при restore DB:
gbak: activating and creating deferred index FK_RL_INFRESOURCES_RESTYPE_ID
gbak: activating and creating deferred index FK_RL_DISCBYCHAIR_DISCID
gbak:cannot commit index FK_RL_DISCBYCHAIR_DISCID
gbak: ERROR:violation of FOREIGN KEY constraint "PK_RL_DISCIPLINES" on table "RL_DISCIPLINES"
gbak: ERROR: Foreign key reference target does not exist
gbak: committing metadata
gbak:finishing, closing, and going home
gbak:Database is not online due to failure to activate one or more indices.
gbak:Run gfix -online to bring database online without active indices.
когда же операцию восстановления БД из баккапа делаю в IBExpert, он сообщает:
bak:restoring data for table RL_DISCBYCHAIR
gbak: 27 records restored
IBE: Invalid token.
Malformed string.
gds_$send failed.
Вот: Malformed string !
Кстати, образ БД крохотный. 1 Mb.
Если что могу выслать. Никаких коммерческих секретов у меня нет
нет такой версии. она уже давно снята с download.В горячо любимом мной сервере FireBird 2.0.0
кроме того, судя по вопросам, сомневаюсь, что сервер "горячо любимый", т.к. вопросы явно от начинающего.
каким именно образом?потом вдруг решаем изменить тип данных столбца
про IBExpert опустим, но ситуации с невосстановимым бэкапом указаны здесь:) Не проходит успешно Restore DataBase после его Backup при помощи IBExpert
www.ibase.ru/devinfo/db_repair.htm
при изменении типа столбца ПРЕДВАРИТЕЛЬНО надо проверить будут-ли читаться в этом типе УЖЕ ИМЕЮЩИЕСЯ ДАННЫЕ. Потому что изменение типа столбца данные не модифицирует.
Вы, очевидно, совсем новичок, если не знаете такой элементарной вещи. Да, insert into select может зациклиться.размер базы данных растет бесконечно, сервер уходит в бесконечный цикл
у Вас что, строковый столбец в 254 символа - первичный ключ???gbak: ERROR:violation of FOREIGN KEY constraint "PK_RL_DISCIPLINES" on table "RL_DISCIPLINES"
Последний раз редактировалось kdv 26 окт 2007, 13:50, всего редактировалось 1 раз.
Re: Ошибка сервера FB2.0 при изменении типа столбца на UTF8
А ты чего ожидал? От инсерта-то без ограничения видимости...fb.bird писал(а):при запуске запроса
insert into rl_disciplines(discname_utf8)
select
discname
from rl_disciplines
order by id
размер базы данных растет бесконечно
Тут как раз ничего удивительного, и багом не является. Читай в FAQ.
Дело в том, что я думаю, что при переходе на последнюю стабильную версию данная ошибка останется. К тому же я не из тех людей которые успевают всё время апгрейдить версию, в новой версии могут быть незнакомые ошибки ... я так полагаю.kdv писал(а):нет такой версии. она уже давно снята с download.
kdv писал(а): кроме того, судя по вопросам, сомневаюсь, что сервер "горячо любимый", т.к. вопросы явно от начинающего.
Где вопросы? Я пытаюсь сказать что существует ошибка.
потом вдруг решаем изменить тип данных столбца
В IBExpert в выпадающем контекстном меню есть кнопка Edit Field - там можно изменить тип столбца, а как Вы изменяете тип столбца ? Другим способом ? не доверяете IBExpert ?kdv писал(а):каким именно образом?
В статье рассматриваются случаи когда БД повреждена, а у меня же она не поврежденаkdv писал(а): про IBExpert опустим, но ситуации с невосстановимым бэкапом указаны здесь:
www.ibase.ru/devinfo/db_repair.htm
Данные прекрасно читаются.kdv писал(а): при изменении типа столбца ПРЕДВАРИТЕЛЬНО надо проверить будут-ли читаться в этом типе УЖЕ ИМЕЮЩИЕСЯ ДАННЫЕ. Потому что изменение типа столбца данные не модифицирует.
размер базы данных растет бесконечно, сервер уходит в бесконечный цикл
gbak: ERROR:violation of FOREIGN KEY constraint "PK_RL_DISCIPLINES" on table "RL_DISCIPLINES"
Нет. Данная таблица RL_DISCIPLINES - её идишник (ID) является внешним ключом (Foreign Key) для столбца DISCID таблицы RL_DISCBYCHAIR.kdv писал(а): у Вас что, строковый столбец в 254 символа - первичный ключ???
Последний раз редактировалось fb.bird 26 окт 2007, 20:22, всего редактировалось 9 раз.
Выслать на предмет доказательства существования проблемы.kdv писал(а): выслать на предмет чего?
Т.е. как это неверно ? Теперь уже и размер страницы БД нельзя выставлять равным 4096 байт ?kdv писал(а): Кстати, размер БД в 1мб также говорит о том, что похоже размер страницы БД выбран неверно.
Нельзя выбирать произвольно размер страницы БД ?
Если быть точным размер файла 1 011 712 байт.
В честь чего то, что insert into select может зациклиться, это нормально ?kdv писал(а): Вы, очевидно, совсем новичок, если не знаете такой элементарной вещи. Да, insert into select может зациклиться.
Я так понимаю сначала должна быть произведена выборка (select) данных из таблицы, а только затем начата вставка (insert).
Вы хотите сказать что вставка начинается тогда уже когда считаны первые строки данных чтение не произведено до конца а уже начата вставка ? И типа select будет читать данные произведенные вставкой записей из таблицы ?
Я Вас не понимаю.
Re: Ошибка сервера FB2.0 при изменении типа столбца на UTF8
Где insert без ограничения видимости ? Я конечно понимаю что запрос сделан неправильно, что такой запрос бесполезен, но мне непонятно то что сервер может уйти в бесконечный цикл.WildSery писал(а):А ты чего ожидал? От инсерта-то без ограничения видимости...fb.bird писал(а):при запуске запроса
insert into rl_disciplines(discname_utf8)
select
discname
from rl_disciplines
order by id
размер базы данных растет бесконечно
Тут как раз ничего удивительного, и багом не является. Читай в FAQ.
Вообще основная проблема в том, восстановление БД не проходит успешно.
какой именно проблемы. если с рестором - добро пожаловать в платный ремонт. Ссылку на документ, в котором объясняются похожие причины, дал.Выслать на предмет доказательства существования проблемы.
можно. 4к это нормально.Т.е. как это неверно ? Теперь уже и размер страницы БД нельзя выставлять равным 4096 байт ?
можно, но 1 и 2 к лучше не выбирать.Нельзя выбирать произвольно размер страницы БД ?
шут с ним.Если быть точным размер файла 1 011 712 байт.
если бы проблема касалась конкретного бага... Пока что не вижу ответов на вопрос по поводу как Вы модифицировали тип столбца, и почему не проверили столбец на конвертируемость данных в новый тип.
Итак. Резюмирую:
1. insert into select from - да, зацикливание, таково поведение InterBase/Firebird всех версий.
www.ibase.ru/ibfaq.htm#insinf
2. да, при изменении типа столбца данные столбца не конвертируются автоматически. Это стандартное поведение сервера. К чему может привести, описано тут:
http://www.ibase.ru/devinfo/db_repair.htm#col_alter
3
исправляйте проблему в исходных данных. В Вашем случае, мне кажется, проще не мучиться а пересоздать БД заново с нужными типами столбцов.Цель: Необходимо цикл backup/restore database выполнить успешно.
и дополнительно, еще раз обращаю внимание на 2.0.0:
www.ibase.ru/devinfo/allversions.htm
www.ibase.ru/devinfo/allversions.htm
еще один невнимательный читатель. в части статьи, описывающей невосстановимый бэкап, как раз и написано про случаи, когда повреждена ЛОГИЧЕСКАЯ структура БД, а не физическая. Пусть даже с Вашей точки зрения БД не повреждена, но ведь ее рестор не проходит, а значит логическое повреждение ЕСТЬ. рестор может восстановить только логически целостные данные.В статье рассматриваются случаи когда БД повреждена, а у меня же она не повреждена
В общем, дальше неинтересно обсуждать, пока Вы не
1. установите FB 2.03
2. будете менять типы данных корректно, средствами сервера, а не абы как.
Спасибо, почитал.kdv писал(а): какой именно проблемы. если с рестором ...
Ссылку на документ, в котором объясняются похожие причины, дал.
Спасибо большое за помощь, я так и сделал. Помогло.kdv писал(а):В Вашем случае, мне кажется, проще не мучиться а пересоздать БД заново с нужными типами столбцов.