Ошибка сервера FB2.0 при изменении типа столбца на UTF8

Access Violation, некорректное выполнение запросов или вызовов API, ошибки утилит командной строки, в общем все, что вам мешает работать

Модераторы: kdv, dimitr

Ответить
fb.bird
Сообщения: 13
Зарегистрирован: 26 окт 2007, 11:57

Ошибка сервера FB2.0 при изменении типа столбца на UTF8

Сообщение fb.bird » 26 окт 2007, 12:41

Всем привет. Всё-таки я пробился на этот форум несмотря на то что 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.
Если что могу выслать. Никаких коммерческих секретов у меня нет

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 26 окт 2007, 13:47

В горячо любимом мной сервере FireBird 2.0.0
нет такой версии. она уже давно снята с download.
кроме того, судя по вопросам, сомневаюсь, что сервер "горячо любимый", т.к. вопросы явно от начинающего.
потом вдруг решаем изменить тип данных столбца
каким именно образом?
) Не проходит успешно Restore DataBase после его Backup при помощи IBExpert
про IBExpert опустим, но ситуации с невосстановимым бэкапом указаны здесь:
www.ibase.ru/devinfo/db_repair.htm

при изменении типа столбца ПРЕДВАРИТЕЛЬНО надо проверить будут-ли читаться в этом типе УЖЕ ИМЕЮЩИЕСЯ ДАННЫЕ. Потому что изменение типа столбца данные не модифицирует.
размер базы данных растет бесконечно, сервер уходит в бесконечный цикл
Вы, очевидно, совсем новичок, если не знаете такой элементарной вещи. Да, insert into select может зациклиться.
gbak: ERROR:violation of FOREIGN KEY constraint "PK_RL_DISCIPLINES" on table "RL_DISCIPLINES"
у Вас что, строковый столбец в 254 символа - первичный ключ???
Последний раз редактировалось kdv 26 окт 2007, 13:50, всего редактировалось 1 раз.

WildSery
Заслуженный разработчик
Сообщения: 1738
Зарегистрирован: 05 июн 2006, 16:19

Re: Ошибка сервера FB2.0 при изменении типа столбца на UTF8

Сообщение WildSery » 26 окт 2007, 13:50

fb.bird писал(а):при запуске запроса
insert into rl_disciplines(discname_utf8)
select
discname
from rl_disciplines
order by id


размер базы данных растет бесконечно
А ты чего ожидал? От инсерта-то без ограничения видимости...
Тут как раз ничего удивительного, и багом не является. Читай в FAQ.

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 26 окт 2007, 13:52

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

fb.bird
Сообщения: 13
Зарегистрирован: 26 окт 2007, 11:57

Сообщение fb.bird » 26 окт 2007, 18:58

kdv писал(а):нет такой версии. она уже давно снята с download.
Дело в том, что я думаю, что при переходе на последнюю стабильную версию данная ошибка останется. К тому же я не из тех людей которые успевают всё время апгрейдить версию, в новой версии могут быть незнакомые ошибки ... я так полагаю.
kdv писал(а): кроме того, судя по вопросам, сомневаюсь, что сервер "горячо любимый", т.к. вопросы явно от начинающего.

Где вопросы? Я пытаюсь сказать что существует ошибка.
потом вдруг решаем изменить тип данных столбца
kdv писал(а):каким именно образом?
В IBExpert в выпадающем контекстном меню есть кнопка Edit Field - там можно изменить тип столбца, а как Вы изменяете тип столбца ? Другим способом ? не доверяете IBExpert ?
kdv писал(а): про IBExpert опустим, но ситуации с невосстановимым бэкапом указаны здесь:
www.ibase.ru/devinfo/db_repair.htm
В статье рассматриваются случаи когда БД повреждена, а у меня же она не повреждена
kdv писал(а): при изменении типа столбца ПРЕДВАРИТЕЛЬНО надо проверить будут-ли читаться в этом типе УЖЕ ИМЕЮЩИЕСЯ ДАННЫЕ. Потому что изменение типа столбца данные не модифицирует.
Данные прекрасно читаются.
размер базы данных растет бесконечно, сервер уходит в бесконечный цикл
gbak: ERROR:violation of FOREIGN KEY constraint "PK_RL_DISCIPLINES" on table "RL_DISCIPLINES"
kdv писал(а): у Вас что, строковый столбец в 254 символа - первичный ключ???
Нет. Данная таблица RL_DISCIPLINES - её идишник (ID) является внешним ключом (Foreign Key) для столбца DISCID таблицы RL_DISCBYCHAIR.
Последний раз редактировалось fb.bird 26 окт 2007, 20:22, всего редактировалось 9 раз.

fb.bird
Сообщения: 13
Зарегистрирован: 26 окт 2007, 11:57

Сообщение fb.bird » 26 окт 2007, 19:05

kdv писал(а): выслать на предмет чего?
Выслать на предмет доказательства существования проблемы.
kdv писал(а): Кстати, размер БД в 1мб также говорит о том, что похоже размер страницы БД выбран неверно.
Т.е. как это неверно ? Теперь уже и размер страницы БД нельзя выставлять равным 4096 байт ?
Нельзя выбирать произвольно размер страницы БД ?
Если быть точным размер файла 1 011 712 байт.

fb.bird
Сообщения: 13
Зарегистрирован: 26 окт 2007, 11:57

Сообщение fb.bird » 26 окт 2007, 19:17

kdv писал(а): Вы, очевидно, совсем новичок, если не знаете такой элементарной вещи. Да, insert into select может зациклиться.
В честь чего то, что insert into select может зациклиться, это нормально ?

Я так понимаю сначала должна быть произведена выборка (select) данных из таблицы, а только затем начата вставка (insert).
Вы хотите сказать что вставка начинается тогда уже когда считаны первые строки данных чтение не произведено до конца а уже начата вставка ? И типа select будет читать данные произведенные вставкой записей из таблицы ?
Я Вас не понимаю.

fb.bird
Сообщения: 13
Зарегистрирован: 26 окт 2007, 11:57

Re: Ошибка сервера FB2.0 при изменении типа столбца на UTF8

Сообщение fb.bird » 26 окт 2007, 19:19

WildSery писал(а):
fb.bird писал(а):при запуске запроса
insert into rl_disciplines(discname_utf8)
select
discname
from rl_disciplines
order by id


размер базы данных растет бесконечно
А ты чего ожидал? От инсерта-то без ограничения видимости...
Тут как раз ничего удивительного, и багом не является. Читай в FAQ.
Где insert без ограничения видимости ? Я конечно понимаю что запрос сделан неправильно, что такой запрос бесполезен, но мне непонятно то что сервер может уйти в бесконечный цикл.
Вообще основная проблема в том, восстановление БД не проходит успешно.

fb.bird
Сообщения: 13
Зарегистрирован: 26 окт 2007, 11:57

Сообщение fb.bird » 26 окт 2007, 19:25

kdv писал(а): кроме того, судя по вопросам, сомневаюсь, что сервер "горячо любимый", т.к. вопросы явно от начинающего.
Я вижу Вы не верите в любовь с первого раза. ((c) Задорнов)

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 26 окт 2007, 19:54

Выслать на предмет доказательства существования проблемы.
какой именно проблемы. если с рестором - добро пожаловать в платный ремонт. Ссылку на документ, в котором объясняются похожие причины, дал.
Т.е. как это неверно ? Теперь уже и размер страницы БД нельзя выставлять равным 4096 байт ?
можно. 4к это нормально.
Нельзя выбирать произвольно размер страницы БД ?
можно, но 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 выполнить успешно.
исправляйте проблему в исходных данных. В Вашем случае, мне кажется, проще не мучиться а пересоздать БД заново с нужными типами столбцов.

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 26 окт 2007, 19:57

и дополнительно, еще раз обращаю внимание на 2.0.0:
www.ibase.ru/devinfo/allversions.htm

dimitr
Разработчик Firebird
Сообщения: 888
Зарегистрирован: 26 окт 2004, 16:20

Сообщение dimitr » 26 окт 2007, 23:16

fb.bird писал(а):В IBExpert в выпадающем контекстном меню есть кнопка Edit Field - там можно изменить тип столбца, а как Вы изменяете тип столбца ? Другим способом ? не доверяете IBExpert ?
я доверяю только оператору ALTER TABLE. За отсебятину IBExpert'а пусть несут ответственность его авторы.

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 27 окт 2007, 00:35

В статье рассматриваются случаи когда БД повреждена, а у меня же она не повреждена
еще один невнимательный читатель. в части статьи, описывающей невосстановимый бэкап, как раз и написано про случаи, когда повреждена ЛОГИЧЕСКАЯ структура БД, а не физическая. Пусть даже с Вашей точки зрения БД не повреждена, но ведь ее рестор не проходит, а значит логическое повреждение ЕСТЬ. рестор может восстановить только логически целостные данные.

В общем, дальше неинтересно обсуждать, пока Вы не
1. установите FB 2.03
2. будете менять типы данных корректно, средствами сервера, а не абы как.

fb.bird
Сообщения: 13
Зарегистрирован: 26 окт 2007, 11:57

Сообщение fb.bird » 27 окт 2007, 11:46

kdv писал(а): какой именно проблемы. если с рестором ...
Ссылку на документ, в котором объясняются похожие причины, дал.
Спасибо, почитал.
kdv писал(а):В Вашем случае, мне кажется, проще не мучиться а пересоздать БД заново с нужными типами столбцов.
Спасибо большое за помощь, я так и сделал. Помогло.

Ответить