Так, чиста мозгами пошуршать :-)

Дано : производится конверсия базы из американской кодировки в unicode (utf8).
То есть данные выгружаются, база дропается, пересоздается с новой кодировкой, данные загружаются, индексы строятся.

Две проблемки:
- таблица x не влезает в старый dbspace;
- индекс y тоже "нэ лiзе".

Ваши версии ?


В таком вот аксепте

aist-pskколичество битиков в символе американской и utf8 возможно разное.

Первое приходящее в голову, но неправильное решение :-).
Проблемы бы были и без перекодировки.

Выгружали unload-ом, индекс не фрагментированный, dbspace таблицы занят полностью и пришлось добавлять несколько раз, с индексом удалось разобраться без добавления диска :-)

еще идеи ? :-)

И таблица, и индекс живут каждый в своем выделенном dbspace, без "подселенцев".

zaietsВыбегалло
- таблица x не влезает в старый dbspace;

1. Как описывали - бубны вокруг эктентов, это решаемо.
2. Alter in place. Тоже решаемо, но геморройно.

Выбегалло
- индекс y тоже "нэ лiзе".

1. тоже зависит от начальных размеров эктента таблицы
2. fillfactor

индексы насколько я понял открепленные - здесь не должно быть трабл.
Тихої української ночі більше з голови нічого нЕ лізе.

Бинго !
Таки да, alter table in place в первом случае, и fillfactor - во втором. При том, что fillfactor стоял один и тот же на исходном и полученном серверах, но "за время пути собака могла подрасти" - реальный fillfactor на оригинале, после лет работы, был выше указанного.

GVF112GVFВыбегалло,

Как на счет компрессии .... помогает при использовании UTF.

С уважением,
Вадим Головский.

ну если кодировка изначально американская, то есть подавляющее большинство символов из первой половины ASCII - то какая компрессия ? Если где и промелькнет европейская буква в имени, которая в utf8 превратится в 2 байта, то ну очень редко.

Журавлев Денисоффтопик: а софт на чем на джаве (jdbc)?

Какой софт ? Всю конверсию делали dbaccess.
Или вопрос про фронтенд к базе и ETL примочки? Там зоопарк - Powerbuilder, java, perl, shell, по-моему даже куски PHP где-то имеются.

Журавлев ДенисВыбегалло
Или вопрос про фронтенд к базе и ETL примочки? Там зоопарк - Powerbuilder, java, perl, shell, по-моему даже куски PHP где-то имеются.
да про фронтенд. Мне поддержка юникода интересна. Powerbuilder он через одбс работает, там понятно и java тоже. А perl и php там юникод поддерживается, в смысле client_locale=xxx.utf ?

Powerbuilder, кстати, наша старая версия юникод не поддерживает. Будут мигрировать.
PHP, как интернетный язык, поддерживать обязан, но это не мой кусок, так что зуб не дам. С перлом сейчас разбираюсь.

GVF112GVFGVF112GVFВыбегалло,

Что показывает oncheck -pe, oncheck -pt ?

С уважением,
Вадим

Какой размер страницы, использовался в базе ?
Как увеличился размер записи в кодировке UNICODE ?



никак. Цитирую : "ну если кодировка изначально американская, то есть подавляющее большинство символов из первой половины ASCII..."

Oncheck -pe показывал то, что и должен был показывать - в оригинальной таблице типа 1000 страниц данных, в смигрированной - 2000.

GVF112GVFВыбегаллоGVF112GVFGVF112GVFВыбегалло,

Что показывает oncheck -pe, oncheck -pt ?

С уважением,
Вадим

Какой размер страницы, использовался в базе ?
Как увеличился размер записи в кодировке UNICODE ?



никак. Цитирую : "ну если кодировка изначально американская, то есть подавляющее большинство символов из первой половины ASCII..."

Oncheck -pe показывал то, что и должен был показывать - в оригинальной таблице типа 1000 страниц данных, в смигрированной - 2000.

1. Надеюсь, что CLIENT_LOCALE=DB_LOCALE=un_US.UTF8 ... :)
2. Хотелось бы сравнить отчеты - oncheck -pT (до и после миграции).
3. Можно сравнить дамп страниц с данными - oncheck -pD/pd (до и после миграции).
4. Проверить bug fix для сервера/клиента informix - UTF, onstat -d, tablespace и т.д.
http://www-01.ibm.com/support/docview.wss?rs=0&uid=swg27014361#11.50
5. Письмо в Support.

С уважением,
Вадим Головский.

естественно, CLIENT_LOCALE был установлен в en_us.8859-1 - мне ж надо было переконвертировать старую кодировку в utf8.

Разгадка уже приведена на предыдущей странице, поэтому можно обойтись без письма в саппорт.

P.S. Прежде чем бросаться сравнивать дампы страниц, стоит немного пошевелить мозгами. Как мне кажецца. Можно много времени сэкономить :-)

GVF112GVFВыбегалло,

P.S. Прежде чем бросаться сравнивать дампы страниц, стоит немного пошевелить мозгами. Как мне кажецца. Можно много времени сэкономить :-)

Мозгами нужно шевелить всегда.

Например,
- при установки переменных окружения среды -IFX_PAD_VARCHAR ... :)


Мимо кассы - независимо от значения IFX_PAD_VARCHAR, в файл выгружаются обрезанные данные.

GVF112GVF- планировании размеров таблиц ...

Вот без вас бы не догадались посчитать использованные страницы !

GVF112GVF- проверки конвертации кодовых страниц ... в UTF ... (наличие багов) ...

неприятности лучше переживать по мере их поступления. Особенно если вероятность мала.


GVF112GVF- и т.д.

Это особенно важно !

GVF112GVFПошевели -возможно, меньше вопросов будет в будущем ... ;)

С уважением,
Вадим.

И вам не хворать.

GVF112GVFВыбегалло,

Мимо кассы - независимо от значения IFX_PAD_VARCHAR, в файл выгружаются обрезанные данные.

А как загружаются? C дополнительными пробелами ?!

Я бы проверил дамп страниц с данными.
Если там все OK, тогда распределение экстентов (где, что и как расположено - data, index, tablespace tablespace, partition page for table).

Какая версия IDS? ILS ?

Пока больной дышит - у него есть надежда ... :) ... зри в корень и не хворай !

С уважением,
Вадим Головский.

Головоломка успешно решена юзером заец, читайте 9й пост сверху на первой странице.

GVF112GVFВыбегалло,

Ну это не серьезно.

Игорь, конечно молодец, что подкинул правильные идеи.
Я думаю, что для многих - это прописные истины (FAQ and so on).

С уважением,
Вадим.

Вадим, вы понимаете разницу между "задать вопрос на форуме" и "загадать головоломку" ?
Так вот, обратите внимание - у меня была именно головоломка. Вы же судоку решаете без привлечения Informix support (я надеюсь) ?