|
|
|
Converting 9.40FC6 -> 11.50FC1
|
|||
|---|---|---|---|
|
#18+
Коллеги, добрый день. При попытке миграции Informixa с версии 9.4 на 11.5 столкнулся со следующей проблемой: 13:01:23 IBM Informix Dynamic Server Started. 13:01:23 Requested shared memory segment size rounded from 930816KB to 950272KB 13:01:24 Segment locked: addr=10a000000, size=973078528 13:01:25 Event alarms enabled. ALARMPROG = '/opt/informix/Ifx1150FC1/etc/log_full.sh' 13:01:25 Booting Language <c> from module <> 13:01:25 Loading Module <CNULL> 13:01:25 Booting Language <builtin> from module <> 13:01:25 Loading Module <BUILTINNULL> 13:01:30 DR: DRAUTO is 0 (Off) 13:01:30 DR: ENCRYPT_HDR is 0 (HDR encryption Disabled) 13:01:30 Fast poll /dev/poll enabled. 13:01:30 IBM Informix Dynamic Server Version 11.50.FC1 Software Serial Number AAA#B000000 13:01:31 Conversion from version 9.40 Started 13:01:32 Checking partition header pages for needed free space 13:01:33 ERROR: Partition header page (Chunk 4 Offset 996926) does not have enough free space (Free count 4) 13:01:35 Checking for space in partition header pages failed 13:01:35 IBM Informix Dynamic Server Stopped. 13:01:35 mt_shm_remove: WARNING: may not have removed all/correct segments Подскажите как лечить? где капать? Заранее благодарен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2010, 13:18 |
|
||
|
Converting 9.40FC6 -> 11.50FC1
|
|||
|---|---|---|---|
|
#18+
думаю 4й чанк у вас еще до конвертации полностью заполнен. природа заполнения автору думаю понятна. Наиболее простой способ - перед конвертацией выявить таблицы размещенные в этом чанке и с помощью манипуляций с таблицей (alter fragment, drop|create) перенести одну или несколько таблиц(фрагментов) в другой чанк(пространство) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2010, 14:39 |
|
||
|
Converting 9.40FC6 -> 11.50FC1
|
|||
|---|---|---|---|
|
#18+
Чанк действительно заполнен, но есть и другой свободный в данном DBSpace. Не подскажете какой объем примерно нужно высвободить? Данный чанк 1000000 блоков по 2Кб. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2010, 14:46 |
|
||
|
Converting 9.40FC6 -> 11.50FC1
|
|||
|---|---|---|---|
|
#18+
думаю в пределах 1Мб будет достаточно. Посмотрите IBM Informix Migration Guide в Checking and Configuring Available Space данный момент описан. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2010, 15:10 |
|
||
|
Converting 9.40FC6 -> 11.50FC1
|
|||
|---|---|---|---|
|
#18+
knuckle, между делом: зачем на FC1? %( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2010, 21:17 |
|
||
|
Converting 9.40FC6 -> 11.50FC1
|
|||
|---|---|---|---|
|
#18+
Столкнулся с аналогичной проблемой. Подскажите, каким образом можно вынести таблицу из одного чанка в другой в рамках одного ДБспейса? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.08.2010, 19:23 |
|
||
|
Converting 9.40FC6 -> 11.50FC1
|
|||
|---|---|---|---|
|
#18+
AfixxСтолкнулся с аналогичной проблемой. Подскажите, каким образом можно вынести таблицу из одного чанка в другой в рамках одного ДБспейса? Действительно наиболее простой - таки извернуться с другим пространством: zaietsНаиболее простой способ - перед конвертацией выявить таблицы размещенные в этом чанке и с помощью манипуляций с таблицей (alter fragment, drop|create) перенести одну или несколько таблиц(фрагментов) в другой чанк( [другое] пространство) То бишь таки - в другое пространство. Более сложный способ - в пределах этого же пространства (теоретический, на практике не проверял ): 1. onstat-ом получить карту свободных мест пространства (чанков) 2. созданием фиктивных таблиц с начальным размером extent'ов забить пустые места в пространстве 3. onstat-ом получить перечень фиктивных таблиц в нужном чанке 4. дропнуть эти фиктивные таблицы 5. "с помощью манипуляций с таблицей (alter fragment, drop|create) перенести одну или несколько таблиц(фрагментов) в другой чанк" - она поместится только в этом чанке 6. дропнуть прочие фиктивные таблицы. П.С.: Выбегалло, оформляй как Головоломка-5 - может кто-то ещё вариант придумает :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.08.2010, 21:43 |
|
||
|
Converting 9.40FC6 -> 11.50FC1
|
|||
|---|---|---|---|
|
#18+
Получается проще создать "второй" DBSpace. Временно вынести туда нужные таблицы. Сконвертировать базу. Вернуть вынесенные таблицы обратно в "первый" DBSpace. "Второй" DBSpace удалить. Подскажите, какой командой можно узнать, что содержиться в определенном чанке? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.08.2010, 09:35 |
|
||
|
Converting 9.40FC6 -> 11.50FC1
|
|||
|---|---|---|---|
|
#18+
oncheck -pe В принципе можно проще: 1. выгрузить таблицу 2. удалить таблицу 3. конвертировать 4. загрузить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.08.2010, 11:45 |
|
||
|
Converting 9.40FC6 -> 11.50FC1
|
|||
|---|---|---|---|
|
#18+
AfixxПодскажите, какой командой можно узнать, что содержиться в определенном чанке? Попробуйте этим запросом (правда, не знаю, как он будет работать на новых версиях) Надеюсь, что номер чанка вы знаете или сможете его легко найти. ----------------------------------------------------------- -- List objects on the chunk -- -- (список таблиц, индексов и др. объектов на указанном чанке) -- IDS 7.3+ 9.2+ -- -- V.Shulzhenko DBA Tools ----------------------------------------------------------- set isolation to dirty read; select dbsname[1,18] db_name ,tabname[1,18] tablespace ,owner[1,8] ,count(*) num_of_exts from systabnames tn, syschunks C, systabextents te where C.chknum = trunc((te.te_physaddr / 1048576)) and tn.partnum = te.te_partnum and C.chknum = -- set chunk number group by 1,2,3 order by 1,2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.08.2010, 14:00 |
|
||
|
Converting 9.40FC6 -> 11.50FC1
|
|||
|---|---|---|---|
|
#18+
zaietsoncheck -pe В принципе можно проще: 1. выгрузить таблицу 2. удалить таблицу 3. конвертировать 4. загрузить. Для новичков: ОСТОРОЖНО! Предварительная выгрузка схемы таблицы dbschema -d db -t tbl -ss не спасает. 1. Удаление таблицы ведёт к удалению всех внешних ключей не только от удаляемой таблицы, но и на неё 2. Удаление таблицы ведёт к удалению всех view и всех view завязанных на удаляемые view ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.08.2010, 18:19 |
|
||
|
Converting 9.40FC6 -> 11.50FC1
|
|||
|---|---|---|---|
|
#18+
Спасибо всем за помощь. Сегодня попробую. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2010, 09:27 |
|
||
|
Converting 9.40FC6 -> 11.50FC1
|
|||
|---|---|---|---|
|
#18+
АнатоЛой Предварительная выгрузка схемы таблицы dbschema -d db -t tbl -ss не спасает. 1. Удаление таблицы ведёт к удалению всех внешних ключей не только от удаляемой таблицы, но и на неё 2. Удаление таблицы ведёт к удалению всех view и всех view завязанных на удаляемые view Вместо dbschema я использую myschema из набора утилит от Кагеля. Она показывает не только входящие связи, но и исходящие. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2010, 10:03 |
|
||
|
Converting 9.40FC6 -> 11.50FC1
|
|||
|---|---|---|---|
|
#18+
victor16АнатоЛой Предварительная выгрузка схемы таблицы dbschema -d db -t tbl -ss не спасает. 1. Удаление таблицы ведёт к удалению всех внешних ключей не только от удаляемой таблицы, но и на неё 2. Удаление таблицы ведёт к удалению всех view и всех view завязанных на удаляемые view Вместо dbschema я использую myschema из набора утилит от Кагеля. Она показывает не только входящие связи, но и исходящие. Пасибо, с констрейнтами понятно. А для взглядов я когда-то писал ХП, которая возвращает список зависимых взглядов (рекурсивно по данным таблиц системного каталога). Для этого списка запускал потом dbschema и склеивал в скрипт, а после пересоздания таблицы прогонял этот скрипт через dbaccess... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2010, 12:41 |
|
||
|
Converting 9.40FC6 -> 11.50FC1
|
|||
|---|---|---|---|
|
#18+
Коллеги, приветствую. Спустя продолжительное время снова вернулся к вопросу конвертации. В прошлый раз так и не удалось дожать данный вопрос (см. первый пост). Последовал вашему совету и вынес часть таблиц из чанка. Но проблема не исчезла и даже не изменилась. Отслеживая содержимое в чанке, удаляя и вынося все что было можно, высвободил порядка 30%. Но при попытке конвертации информикс ругается на тоже самое место: 13:01:33 ERROR: Partition header page (Chunk 4 Offset 996926) does not have enough free space (Free count 4) 13:01:35 Checking for space in partition header pages failed Вот часть вывода результата вызова oncheck -pe Chunk Pathname Size Used Free 4 /opt/informix/chunks_IDS940FC6/data_2 1000000 636121 363879 ---xxx--- FREE 996272 560 workdbs:'informix'.TBLSpace 996832 100 FREE 996932 2952 ---xxx--- Пытаясь включить логику: офсет996832+100=996931 > 996926, понимаю что проблема где-то в workdbs:'informix'.TBLSpace С одной стороны вроде бы и дальше есть пустые блоки. Но до конца не представляю процесс конвертации. С другой стороны (Free count 4): значит начиная с блока 996930 по 996931 что-то есть. Подскажите, как понять что тут мешает? Заранее благодарен. АнатоЛойknuckle, между делом: зачем на FC1? %( За не имением другого. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2010, 19:52 |
|
||
|
Converting 9.40FC6 -> 11.50FC1
|
|||
|---|---|---|---|
|
#18+
knuckle, Какой у Вас размер базы данных ?! Нужно понимать, что конвертация - это всегда риск !!! Обычно, используется? когда нет других возможностей миграции на альтернативную платформу, серверную площадку, продуктивную систему и т.д. Самый надежный, но трудоемкий путь - использование утилит миграции (dbexport/dbimport, dbschema, and so on). Для быстрой загрузки данных могут использовать родные утилиты INFORMIX или программные продукты ETL - IBM DataStage, Informatica и т.д. В любом случае - это контролируемый и управляемый процесс !!! У Вас есть возможность маневра - оптимизации переноса данных, физического и логического планирования, утилизации собственных ресурсов и т.д. Прямая конвертация - не всегда возможна (из-за недостатока ресурсов), может привести к потере данных (затрагивает физические структуры данных) и т.д. Спрашивается, зачем Вам все это ??? ... :) Надеюсь, что Вы не тестер продуктов - IBM Informix. С уважением, Вадим Головский. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2010, 07:23 |
|
||
|
Converting 9.40FC6 -> 11.50FC1
|
|||
|---|---|---|---|
|
#18+
2GVF112GVF Нет я не тестер продуктов IBM :) Размер базы - порядка 120Гб Сейчас пытаюсь повести конвертацию на тестовой системе, которая 1 в 1 совпадает с боевой. Соотетственно полагаю, что если конвертация удастся на одной, то и на другой среде также пройдет успешно. Не хочется связываться с dbexport/dbimport из-за большого размера БД (большого кол-ва таблиц, критичных данных, Блоб-данных). Хотя после вашего поста начал больше склоняться к этому варианту. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2010, 14:13 |
|
||
|
Converting 9.40FC6 -> 11.50FC1
|
|||
|---|---|---|---|
|
#18+
Что дает запрос: select t.partnum,t.dbsname,t.owner,t.tabname,e.nextsiz from systabnames t, sysptnhdr e where t.tabname = 'TBLSpace' and t.partnum = e.partnum and t.dbsname ='ваше пространство' По поводу dbexport/dbimport - не самое оптимальное решение. У вас есть какие-то ограничение на время миграции? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2010, 14:37 |
|
||
|
Converting 9.40FC6 -> 11.50FC1
|
|||
|---|---|---|---|
|
#18+
На 9.40 вы с самого начала работаете или мигрировали с более ранней версии? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2010, 14:56 |
|
||
|
Converting 9.40FC6 -> 11.50FC1
|
|||
|---|---|---|---|
|
#18+
zaietsЧто дает запрос: select t.partnum,t.dbsname,t.owner,t.tabname,e.nextsiz from systabnames t, sysptnhdr e where t.tabname = 'TBLSpace' and t.partnum = e.partnum and t.dbsname ='ваше пространство' По поводу dbexport/dbimport - не самое оптимальное решение. У вас есть какие-то ограничение на время миграции? partnum 3145729 dbsname workdbs owner informix tabname TBLSpace nextsiz 1600 1 row(s) retrieved. ----- Миграцию нужно провести с минимальным простоем. Думаю нужно уложиться в сутки и при этом быть максимально увереным в успехе. Ранее была версия 7.10 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2010, 18:15 |
|
||
|
Converting 9.40FC6 -> 11.50FC1
|
|||
|---|---|---|---|
|
#18+
knuckle Миграцию нужно провести с минимальным простоем. Думаю нужно уложиться в сутки и при этом быть максимально увереным в успехе. Ранее была версия 7.10 Если вы в Киеве, могу нескромно предложить свои услуги по миграции. Если с 7.10 мигрировали на 9.40 то точно ли выполнили после миграции onmode -BC 2? Проверить можно по onstat -d, кстати - дайте его. Если возможен 1 день простоя, то можно и просто перелить данные. За это время если у вас не утраспарк3 и не ниагара все перельется без проблем и вы будете со 100% гарантией что с данными все ОК. Такой же гарантии что все будет работать нормально - никто не даст :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2010, 18:30 |
|
||
|
Converting 9.40FC6 -> 11.50FC1
|
|||
|---|---|---|---|
|
#18+
Я когда то с семерки на 9 переносил базу в 500 + Гб. Гланое распаралелить правильно , перенос данных и постройку индексов. http://www.sql.ru/forum/actualthread.aspx?tid=124199#981754 Потом ее по моим скриптам также переносили уже без меня с платформы на платформу. Единственное, что там не учтено , у меня небыло ЛОБов. Работы на подготовку без лобов 2-3 дня, Тестирование скорости оценка даунтайма тоже 2-3. Вобщем работы на неделю с перекурами. Сам 120 Гб перенос на современном железе думаю можно уложить в 10-12 часов , это даже с запасом на непредвиденности. Можно размазать перенос неделю по пару часов поночам , если приложение будет(сможет) работать с алиасами из другого сервера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2010, 21:26 |
|
||
|
Converting 9.40FC6 -> 11.50FC1
|
|||
|---|---|---|---|
|
#18+
А UPDATE STATISTICS после всех удалений и переносов не спасет отца русской демократии? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.09.2010, 20:01 |
|
||
|
Converting 9.40FC6 -> 11.50FC1
|
|||
|---|---|---|---|
|
#18+
zaiets, нет я в Москве. onmode -BC 1 --- -bash-3.00$ onstat -d IBM Informix Dynamic Server Version 9.40.FC6 -- On-Line -- Up 13 days 16:24:13 -- 2965504 Kbytes Dbspaces address number flags fchunk nchunks flags owner name 142190e58 1 0x20001 1 1 N informix rootdbs 14324e820 2 0x42005 2 1 NDTB informix temp_dbs 14324e9a0 3 0x60001 3 6 N B informix workdbs 14324eb20 4 0x20001 6 1 N informix idx_dbs 14324eca0 5 0x20001 7 1 N informix log_dbs 14324ee20 6 0x20001 13 1 N informix workdbs2 14324f028 7 0x60011 9 1 N BB informix blobs_2 14324f1a8 8 0x28001 10 1 N S informix sblobs 8 active, 2047 maximum Note: For BLOB chunks, the number of free pages shown is out of date. Run 'onstat -d update' for current stats. Chunks address chunk/dbs offset size free bpages flags pathname 142191028 1 1 5 1000000 835893 PO-- /opt/informix/chunks_IDS940FC6/root_chunk 14324d4a0 2 2 5 11000000 0 PD-B /opt/informix/chunks_IDS940FC6/temp 14324d638 3 3 5 1000000 109483 PO-- /opt/informix/chunks_IDS940FC6/data_1 14324d7d0 4 3 5 1000000 364011 PO-- /opt/informix/chunks_IDS940FC6/data_2 14324d968 5 3 5 1000000 134396 PO-- /opt/informix/chunks_IDS940FC6/data_3 14324db00 6 4 5 1000000 569667 PO-- /opt/informix/chunks_IDS940FC6/idx_sp 14324dc98 7 5 5 900000 152427 PO-- /opt/informix/chunks_IDS940FC6/logs_sp 14324de30 8 3 100 24999500 3726090 PO-B /opt/informix/chunks_IDS940FC6/data_5 14324e028 9 7 5 11000000 ~2750000 2750000 POBB /opt/informix/chunks_IDS940FC6/blob_2 14324e1c0 10 8 5 1000000 932620 932620 POS- /opt/informix/chunks_IDS940FC6/smartB Metadata 67327 50099 67327 14324e358 11 3 5 14999990 1898401 PO-B /opt/informix/chunks_IDS940FC6/data_4 14324e4f0 12 3 100 24999500 17376706 PO-B /opt/informix/chunks_IDS940FC6/data_6 14324e688 13 6 5 1000000 880979 PO-- /opt/informix/chunks_IDS940FC6/data_dbs2 13 active, 32766 maximum Expanded chunk capacity mode: enabled -- А если dbexport/dbimport не оптимальное решение? Не посоветуете ли другой способ? -- sysmaster, UPDATE STATISTICS не помог. Начал капать в сторону Миграции данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2010, 18:00 |
|
||
|
Converting 9.40FC6 -> 11.50FC1
|
|||
|---|---|---|---|
|
#18+
По поводу dbexport/dbimport - операторы выполняются в 1 поток, поэтому и медленно. Сам принцип onstat- описал выше - распараллелить. БД небольшая при достаточном наличие ресурсов и продуманном выполнении в сутки вы вложитесь. Если есть заинтересованность - многие из форума могут вам выполнить работы по переходу, чтобы вам не наступать на уже пройденные другими грабли. По поводу конвертации - я бы попробовал еще такую последовательность: 1. onmode -BC 2 ( в старый формат конвертировать думаю уже не нужно :) ) 2. Migr to 10.00 (не факт что поможет но попробовать думаю следует) 3. Migr to 11.50 Четвертый чанк у вас в старом формате, вполне возможно что onmode -BC 2 решит проблему. Хотя по старому формату (вернее на IDS до 9.40) TBlspace размещались если не ошибаюсь токо в корневом чанке. У вас же размещены и во 2м чанке пространства. Кроме того, нужно еще посмотреть сколько таблиц и индексов у вас в пространстве workdbs. Если их относительно много (точно сказать сколько это много не могу) попробовать попереносить мелкие таблицы и индексы в другое пространство. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2010, 15:58 |
|
||
|
|
start [/forum/topic.php?fid=44&tid=1607298]: |
0ms |
get settings: |
26ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
44ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
529ms |
get tp. blocked users: |
1ms |
| others: | 290ms |
| total: | 927ms |
| 0 / 0 |
