ReSQL.ru
     
powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Informix [игнор отключен] [закрыт для гостей] / Миграция с 9.5 на 11.50
25 сообщений из 54, страница 1 из 3
  1  все
Миграция с 9.5 на 11.50
    #36980477
andjeo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andjeo
Участник
Доброй ночи!
Форумчане, подскажите, пожалуйста.

Стоит задача смигрировать БД объемом примерно 250 Гб с Win2k3 на RHEL 5.5.

После прочтения форума мной был выбран способ миграции, описанный тут: http://www.sql.ru/faq/faq_topic.aspx?fid=588
На новом сервере создана dbschema, чанки, дбспейсы. Загрузка данных осуществляется по сети без файрволлов и прочего.

Все бы ничего, но скорость переноса данных просто угнетает.
Пробовал и параллельно грузить несколько таблиц, и грузить таблицы последовательно. Никак не могу получить результат, приемлемый для миграции боевой системы.

Последовательная загрузка заняла около 22 часов и была мной остановлена, т.к. за это время даже не начали переноситься самые крупные таблицы (от 20 до 46 Гб)

Пробовал играться параметрами RA_PAGES. Стало веселее, но все равно не фонтан.

Подскажите, куда можно еще копать?
Время, отведенное на миграцию, это суббота с 7 утра до вечера воскресенья.

Onconfig смогу показать в понедельник.
...
Рейтинг: 0 / 0
27.11.2010, 00:12
| Ответить | Цитировать | Написать  
Миграция с 9.5 на 11.50
    #36980711
Фотография Andron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andron
Участник
Линк который вы привели не открывается. Для существенного ускорения переноса данных рекомендую сделать так:

1. Оценить размеры исходных таблиц и сразу при создании новых таблиц создавать их с большим размером первоначальных экстентов, это ускорит заливку за счет того что место под данные будет уже выделено

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

3. Базу в которую будут заливаться данные перевести в нежурналируемый режим - это существенно повлияет на скорость загрузки

4. Для заливки создать журналы размером ~100 Мб, несколько десятков журналов такого размера, это сократит временные задержки при переключении журналов в процессе создания индексов (процесс создания индекса это журналируемая операция даже в нежурналируемой базе). После создания индексов вернуть требуемый размер журнала в базе. Размер физического журнала также сделать ~2 Гб, возможно не будет чекпоинтов по заполнению физ журнала при построении индексов на средних таблицах. Размер буферов лог. журнала и физ. журнала на время построения индексов сделать побольше, ~ 512 Килобайт.

5. Перед загрузкой проверить скорость сетевого соединения - сеть может быть узким местом.

6. Индексы после заливки данных создавать с включенным PDQ (настроить параметры DS)

7. Перед заливкой проверить что на новом сервере включено KAIO (если используются raw device). Если используются обычные файлы то включить в информиксе параметр DIRECT_IO = 1.

8. ReadAhead (параметр RA_PAGES) имеет значение не при заливке данных, а при операциях чтения, т.е. может помочь при создании индексов

9. Рекомендую для очень больших таблиц базы создать отдельный dbspace и буферный пул с большим размером страницы, например 8к или 16к. Это поможет устранить конкуренцию за буферный пул с остальными таблицами.

10. Пересмотреть схему некоторых таблиц - можно например сделать фрагментацию по дате, если в системе есть запросы с такими выборками это может ускорить такие запросы.

11. Кол-во cpu vp сделать равным кол-ву физ. процессоров, установить для них параметр noage, сконфигурировать отдельный сетевой процессор net

12. Установить повыше параметры LRU, чтобы данные при загрузке писались на диск из буферов большими порциями (чтобы преобладала запись во время чекпоинтов)

13. Не использовать журналируемую фс для чанков.

14. Для создания индексов по большим таблицам создать временное пространство размером пропорционально размеру самого большого индекса (прописать его в DBSPACETEMP перед запуском сервера), или сделать для сервера перед запуском переменную окружения export PSORT_DBTEMP в которую прописать путь на большой локальной ФС и выдать на ней права пользователю informix

15. Можно также включить параметры автонастройки LRU и AIO, но не включать параметр RTO_SERVER_RESTART

16. Размер буферного пула можно установить экспериментально, сделав тестовую заливку при разных значениях BUFFERPOOL

После того как зальете данные, можно будет перевести базу в журналируемый режим (если требуется).
...
Рейтинг: 0 / 0
27.11.2010, 13:15
| Ответить | Цитировать | Написать  
Миграция с 9.5 на 11.50
    #36980728
GVF112GVF
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GVF112GVF
Гость
andjeoДоброй ночи!
Форумчане, подскажите, пожалуйста.

Стоит задача смигрировать БД объемом примерно 250 Гб с Win2k3 на RHEL 5.5.

После прочтения форума мной был выбран способ миграции, описанный тут: http://www.sql.ru/faq/faq_topic.aspx?fid=588.
На новом сервере создана dbschema, чанки, дбспейсы. Загрузка данных осуществляется по сети без файрволлов и прочего.

Все бы ничего, но скорость переноса данных просто угнетает.
Пробовал и параллельно грузить несколько таблиц, и грузить таблицы последовательно. Никак не могу получить результат, приемлемый для миграции боевой системы.

Последовательная загрузка заняла около 22 часов и была мной остановлена, т.к. за это время даже не начали переноситься самые крупные таблицы (от 20 до 46 Гб)

Пробовал играться параметрами RA_PAGES. Стало веселее, но все равно не фонтан.

Подскажите, куда можно еще копать?
Время, отведенное на миграцию, это суббота с 7 утра до вечера воскресенья.

Onconfig смогу показать в понедельник.


Следует обратить внимание на режим журналирования транзакций для базы данных.
Для увеличения скорости загрузки, попробуйте перевести базу в режим - "no logging".

Можно рассмотреть несколько вариантов миграции:

1. Использовать возможности HPL или ETL (for example, IBM DataStage).
2. Использовать комбинированный режим для загрузки данных:
- INSERT .... SELECT - для небольших таблиц (или LOAD)
- HPL для больших таблиц.

При использовании HPL - следует обратить внимание на использование режимов быстрой выгрузки/загрузки данных и на параметры конфигурации HPL и сервера Informix в файле
ONCONFIG.

Следует помнить, что многие полезные утилиты есть на сайте WWW.IIUG.ORG
Software Repository Index - http://www.iiug.org/software/software_index.html

Например:
movetab - Allows moving tables between Informix instances without having to turn off logging

или ...

Get my dbcopy utility from the package utils2_ak from the IIUG Software
Repository, it will copy your table(s) for you and with the AWK scripts in
my package utils3_ak you can easily use dbschema or myschema to create a
dbcopy script to move the entire database in parallel using the mkdbcopy.awk
script. Dbcopy is several times faster than doing the copy in dbaccess and
safer than using dd and it does not require the sourcce server to be offline.
Art S. Kagel


Ну и помнить про следующий ресурс - Knowledge Collection: IBM Informix Dynamic Server (IDS) version 11.50 Migration

http://www-01.ibm.com/support/docview.wss?rs=630&context=SSGU8G&context=SSZ2HS&context=SSP6X2&context=SSVHPS&context=SSHPYE&dc=DB560&dc=DB520&uid=swg21260154&loc=en_US&cs=utf-8&lang=en

----------------
С уважением,
Вадим.
...
Рейтинг: 0 / 0
27.11.2010, 13:41
| Ответить | Цитировать | Написать  
Миграция с 9.5 на 11.50
    #36980741
andjeo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andjeo
Участник
AndronЛинк который вы привели не открывается. Для существенного ускорения переноса данных рекомендую сделать так:

1. Оценить размеры исходных таблиц и сразу при создании новых таблиц создавать их с большим размером первоначальных экстентов, это ускорит заливку за счет того что место под данные будет уже выделено

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

3. Базу в которую будут заливаться данные перевести в нежурналируемый режим - это существенно повлияет на скорость загрузки

4. Для заливки создать журналы размером ~100 Мб, несколько десятков журналов такого размера, это сократит временные задержки при переключении журналов в процессе создания индексов (процесс создания индекса это журналируемая операция даже в нежурналируемой базе). После создания индексов вернуть требуемый размер журнала в базе. Размер физического журнала также сделать ~2 Гб, возможно не будет чекпоинтов по заполнению физ журнала при построении индексов на средних таблицах. Размер буферов лог. журнала и физ. журнала на время построения индексов сделать побольше, ~ 512 Килобайт.

5. Перед загрузкой проверить скорость сетевого соединения - сеть может быть узким местом.



1. Сделано сразу же.

2. Индексы будут создаваться после прогрузки данных ( вторая часть dbschema)

3. Обе базы уже в no logging.

4. Журналы по 512 мб


6. Индексы после заливки данных создавать с включенным PDQ (настроить параметры DS)

7. Перед заливкой проверить что на новом сервере включено KAIO (если используются raw device). Если используются обычные файлы то включить в информиксе параметр DIRECT_IO = 1.



6. Уже включено.

7. Используются файлы, значение параметра скажу в понедельник. Если не стоит, то поставлю.

8. ReadAhead (параметр RA_PAGES) имеет значение не при заливке данных, а при операциях чтения, т.е. может помочь при создании индексов



8. Но при уставновке RA_PAGES=50000 скорость загрузки данных возросла....

9. Рекомендую для очень больших таблиц базы создать отдельный dbspace и буферный пул с большим размером страницы, например 8к или 16к. Это поможет устранить конкуренцию за буферный пул с остальными таблицами.


9. Уже сделано.


10. Пересмотреть схему некоторых таблиц - можно например сделать фрагментацию по дате, если в системе есть запросы с такими выборками это может ускорить такие запросы.


10. Уже сделано.


11. Кол-во cpu vp сделать равным кол-ву физ. процессоров, установить для них параметр noage, сконфигурировать отдельный сетевой процессор net


11. Сконфигурирую отдельно сетевой процессор.




13. Не использовать журналируемую фс для чанков.


13. Вот тут я пролетел. Использую ext3.


[/quot]
16. Размер буферного пула можно установить экспериментально, сделав тестовую заливку при разных значениях BUFFERPOOL
[/quot]

16. Уже пробовал играться значениями. Результат увижу в понедельник.
...
Рейтинг: 0 / 0
27.11.2010, 13:51
| Ответить | Цитировать | Написать  
Миграция с 9.5 на 11.50
    #36982575
Фотография Daugava
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Daugava
Участник
AndronЛинк который вы привели не открывается.
Линк вроде как на здешний FAQ и открывается отлично. Другое дело, что в ФАК-е первой идет моя ссылка на UCDI, а Google изменил ссылки.
Собственно напомню, что в результате нескольких таких миграций, я склонился к мнению, что лучше HPL ничего нет. Впрочем, с тех пор прошло уже 8 или 9 лет.


вот куда была ссылка

Ценное в ней - скрипт по настройке таблиц для HPL-я.
Обращу внимение, что '8859-5' стоит поменять на вашу кодовую таблицу. Кроме того, скрипт не затрагивает вопросов загрузки данных в одну таблицу из нескольких файлов. Не знаю, насколько в современных версиях актуальна проблема 2Гб.


Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
#!/bin/sh
USAGE="$0 <unload source path> <database>"

if [ $# !=  2  ]
then
   echo $USAGE
   exit  2 
fi

UNLPATH=$ 1 
DATABASE=$ 2 
HOSTNAME=`hostname`
DBACCNOIGN= 1 
export DBACCNOIGN
OUTFILE=/tmp/outfile$$

dbaccess onpload> $OUTFILE  2 >& 1  <<!
begin;
delete from formats;
delete from device;
delete from formatitem;
delete from mapitem;
delete from maps;
delete from session;

insert into device
(name,
seq ,
type,
file,
blocksize  ,
devicesize,
lockflag  )
select t.tabname, 1 ,'FILE',
'$UNLPATH/'||trim(t.tabname),
 0 , 0 ,'N'
from $DATABASE:systables t
where tabid>= 99  and tabtype='T';

--For splited tables
insert into device
(name,
seq ,
type,
file,
blocksize  ,
devicesize,
lockflag  )
select t.tabname, 2 ,'FILE',
'$UNLPATH/'||trim(t.tabname)||'2',
 0 , 0 ,'N'
from $DATABASE:systables t
where tabname IN ('arch_history') and tabtype='T';
insert into device
(name,
seq ,
type,
file,
blocksize  ,
devicesize,
lockflag  )
select t.tabname, 3 ,'FILE',
'$UNLPATH/'||trim(t.tabname)||'3',
 0 , 0 ,'N'
from $DATABASE:systables t
where tabname IN ('arch_history') and tabtype='T';

insert into formats
select t.tabid, 0 ,t.tabname,'Delimited','Delimited','Intel',
'8859-5', 0 ,'','','newline','ASCII','|','ASCII','','','','','N'
from $DATABASE:systables t
where tabid>= 99  and tabtype='T';

insert into formatitem
select t.tabid,c.colno,c.colname, 1 , 0 , 0 , 0 , 0 ,''
from $DATABASE:systables t, $DATABASE:syscolumns c
where t.tabid>= 99  and tabtype='T' and c.tabid=t.tabid;

insert into mapitem
select t.tabid,c.colno,c.colname,c.colname
from $DATABASE:systables t, $DATABASE:syscolumns c
where t.tabid>= 99  and tabtype='T' and c.tabid=t.tabid;

insert into maps
select  0 ,t.tabid,t.tabname,'Record','$DATABASE',
'informix.'||trim(t.tabname),'',t.tabid,'N'
from $DATABASE:systables t
where t.tabid>= 99  and tabtype='T';

insert into session
select 'U','','N',t.tabid,t.tabname,' ',
'$INFORMIXSERVER',t.tabname,t.tabname,'$HOSTNAME',
'$DATABASE','','','','/tmp/'||trim(t.tabname)||'.rej',
'/tmp/'||trim(t.tabname)||'.log', 0 , 0 , 0 , 0 , 0 , 0 , 0 , 4 ,
 0 , 0 , 0 , 0 , 130 , 1 , 0 , 0 , 0 , 0 
from $DATABASE:systables t
where t.tabid>= 99  and tabtype='T';

commit;

unload to onpload.sh delimiter ';'
select 'onpload -j '||tabname||' -fl','date','echo '||tabname
from $DATABASE:systables
where tabid>= 99  and tabtype='T'

!

if [ $? -ne  0  ]; then
   cat $OUTFILE
   rm -f $OUTFILE
   exit  1 
fi
rm -f $OUTFILE
echo Run ./onpload.sh for HPL
...
Рейтинг: 0 / 0
29.11.2010, 09:53
| Ответить | Цитировать | Написать  
Миграция с 9.5 на 11.50
    #36982744
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
DaugavaAndronЛинк который вы привели не открывается.
Линк вроде как на здешний FAQ и открывается отлично.
я пофиксил, там точка лишняя была.



PS: на современном железе, 250 гиг должны заливаться, простым импортом часов за 8. В ширину канала 100 мбит должно упираться. Сколько памяти, дисков, отдано информиксу, какой пинг?
...
Рейтинг: 0 / 0
29.11.2010, 11:21
| Ответить | Цитировать | Написать  
Миграция с 9.5 на 11.50
    #36982830
andjeo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andjeo
Участник
Журавлев ДенисDaugavaпропущено...

Линк вроде как на здешний FAQ и открывается отлично.
я пофиксил, там точка лишняя была.



PS: на современном железе, 250 гиг должны заливаться, простым импортом часов за 8. В ширину канала 100 мбит должно упираться. Сколько памяти, дисков, отдано информиксу, какой пинг?


У меня только экспорт на старом сервере занимает 7.5 часов.

Импорт пробовал, но в данных попадаются иногда переносы строки, которые не все удаляются.
Импорт тоже шел долго.

На новом сервере информикс потребляет 18Гб оперативы, пинги в районе 0.316 ms.
На старом информикс потребляет около 1,4 Гб памяти, там виндовая машина.
Заставить его потреблять больше у меня не получилось =\
...
Рейтинг: 0 / 0
29.11.2010, 11:52
| Ответить | Цитировать | Написать  
Миграция с 9.5 на 11.50
    #36982887
Фотография Daugava
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Daugava
Участник
andjeoУ меня только экспорт на старом сервере занимает 7.5 часов.
Собственно, почему бы не выполнить все операции за 8 ? Импорт можно начатать до окончания экспорта.
У меня основное время уходило на построение индексов.
...
Рейтинг: 0 / 0
29.11.2010, 12:08
| Ответить | Цитировать | Написать  
Миграция с 9.5 на 11.50
    #36982895
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
andjeoУ меня только экспорт на старом сервере занимает 7.5 часов.
а если копировать файлы экспорта, на новый, сколько времени копируется?

andjeoИмпорт пробовал, но в данных попадаются иногда переносы строки, которы
е не все удаляются.О чем вы? Копировали по фтп без конвертации концов строк?


andjeoНа новом сервере информикс потребляет 18Гб оперативы, пинги в районе 0.316 ms.
а сколько дисков? смотрите во что упирается, onstat, top, sar
...
Рейтинг: 0 / 0
29.11.2010, 12:11
| Ответить | Цитировать | Написать  
Миграция с 9.5 на 11.50
    #36982906
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
Построение индексов ускоряем с помощью pdq и PSORT_NPROCS
...
Рейтинг: 0 / 0
29.11.2010, 12:15
| Ответить | Цитировать | Написать  
Миграция с 9.5 на 11.50
    #36983327
andjeo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andjeo
Участник
Журавлев ДенисandjeoУ меня только экспорт на старом сервере занимает 7.5 часов.
а если копировать файлы экспорта, на новый, сколько времени копируется?

andjeoИмпорт пробовал, но в данных попадаются иногда переносы строки, которы
е не все удаляются.О чем вы? Копировали по фтп без конвертации концов строк?


andjeoНа новом сервере информикс потребляет 18Гб оперативы, пинги в районе 0.316 ms.
а сколько дисков? смотрите во что упирается, onstat, top, sar

Дело не в концах строк. Переводы строки попадаются в самих дынных ( комментарии, введенные пользователями).

Копирование файлов экспорта занимает около 2 часов.

Top,sar ничего не дают. Не загружена машина.
...
Рейтинг: 0 / 0
29.11.2010, 14:22
| Ответить | Цитировать | Написать  
Миграция с 9.5 на 11.50
    #36983679
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
andjeoДело не в концах строк. Переводы строки попадаются в самих дынных ( комментарии, введенные пользователями).
так они экранированы будут в экспорте.

andjeoTop,sar ничего не дают. Не загружена машина.значит в диск.
...
Рейтинг: 0 / 0
29.11.2010, 15:35
| Ответить | Цитировать | Написать  
Миграция с 9.5 на 11.50
    #36983793
Фотография Daugava
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Daugava
Участник
Архивирование на лету должно снизить время на копирование бекапа.

Сейчас проверил, mkfifo есть в cygwin-е, сервера под винду меня правда нет, протестировать до конца не могу.

Для борьбы с CRLF-ами и другими спецсимволами в Char полях необходимо использовать ключик -X при экспорте и импорте.
...
Рейтинг: 0 / 0
29.11.2010, 16:03
| Ответить | Цитировать | Написать  
Миграция с 9.5 на 11.50
    #36984671
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vasilis
Участник
AndronДля существенного ускорения переноса данных рекомендую сделать так:

Хороший список.
Добавил в ФАК // http://www.sql.ru/faq/faq_topic.aspx?fid=588
...
Рейтинг: 0 / 0
29.11.2010, 21:37
| Ответить | Цитировать | Написать  
Миграция с 9.5 на 11.50
    #36984786
andjeo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andjeo
Участник
DaugavaandjeoУ меня только экспорт на старом сервере занимает 7.5 часов.
Собственно, почему бы не выполнить все операции за 8 ? Импорт можно начатать до окончания экспорта.
У меня основное время уходило на построение индексов.

Это как? Можно пример?
...
Рейтинг: 0 / 0
29.11.2010, 23:18
| Ответить | Цитировать | Написать  
Миграция с 9.5 на 11.50
    #36985241
Фотография Daugava
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Daugava
Участник
andjeoЭто как? Можно пример?

Собственно Вы же ссылались на ФАК, где первым идет "мой метод". Когда вставка осуществляется одновременно с чтением. Метод подходит для случаев, когда тонким местом является производительность старого сервера. Если производительность примерно равна, то создание индексов лучше производить после закачки данных.

Если узким местом является сеть, то dbexport (с ключиком -t) делается в fifo файл (mkfifo), который тут же сжимается (gzip) и перенаправляется на второй сервер (можно просто расшарить диск), где он разархивируется (gzip) опять таки в fifo и тут же стартует закачка (dbimport -t).
...
Рейтинг: 0 / 0
30.11.2010, 10:08
| Ответить | Цитировать | Написать  
Миграция с 9.5 на 11.50
    #36985286
andjeo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andjeo
Участник
DaugavaandjeoЭто как? Можно пример?

Собственно Вы же ссылались на ФАК, где первым идет "мой метод". Когда вставка осуществляется одновременно с чтением. Метод подходит для случаев, когда тонким местом является производительность старого сервера. Если производительность примерно равна, то создание индексов лучше производить после закачки данных.

Если узким местом является сеть, то dbexport (с ключиком -t) делается в fifo файл (mkfifo), который тут же сжимается (gzip) и перенаправляется на второй сервер (можно просто расшарить диск), где он разархивируется (gzip) опять таки в fifo и тут же стартует закачка (dbimport -t).


А если есть необходимость внести изменения в dbschema?
Тогда только дожидаться окончания экспорта?
...
Рейтинг: 0 / 0
30.11.2010, 10:21
| Ответить | Цитировать | Написать  
Миграция с 9.5 на 11.50
    #36985404
Фотография Daugava
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Daugava
Участник
Собственно я описал самый простой способ. Естественно можно использовать разные комбинации. По гугляйте на эту тему в groups.google.com, все проблемы давно решены.
Ничто не мешает сделать dbschema заранее, а потом просто выполнить скрипт типа такого для каждой таблицы, с обратной загрузкой на другой стороне.

sqlunload -d database -t table | gzip -9 > table.unl.gz




P.S. sqlunload - часть из пакета sqlcmd by Jonathan Leffler.
...
Рейтинг: 0 / 0
30.11.2010, 10:53
| Ответить | Цитировать | Написать  
Миграция с 9.5 на 11.50
    #36985445
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
про сеть: тут похоже 100мбит, но в серваках часто гигабитные адаптеры, поэтому я на время миграции если есть возможность соединяю прямым кабелем сервера между собой.
...
Рейтинг: 0 / 0
30.11.2010, 11:07
| Ответить | Цитировать | Написать  
Миграция с 9.5 на 11.50
    #36985934
zaiets
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zaiets
Гость
andjeoЖуравлев Дениспропущено...
а если копировать файлы экспорта, на новый, сколько времени копируется?

пропущено...
О чем вы? Копировали по фтп без конвертации концов строк?


пропущено...
а сколько дисков? смотрите во что упирается, onstat, top, sar

Дело не в концах строк. Переводы строки попадаются в самих дынных ( комментарии, введенные пользователями).

Копирование файлов экспорта занимает около 2 часов.

Top,sar ничего не дают. Не загружена машина.

А виндовая машина как загружена то?
Может весь тормоз как говорят в сети и в виндовой машине?
Также есть ньюанс с ключами - многие разработчики уникальные и первичные ключи создают
не по явно созданным индексам и даже бывают их(констрейнты) не именуют.
Если таковые есть - то в dbchema они попадают в оператор создания таблицы и вставка тогда получается в таблицу с индексами если эти констрейнты не отключать.

Ext3 - да, это не наше.
...
Рейтинг: 0 / 0
30.11.2010, 13:39
| Ответить | Цитировать | Написать  
Миграция с 9.5 на 11.50
    #36986126
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
zaietsExt3 - да, это не наше.так говорят только те, кто не ждал fsck 8 часов.
...
Рейтинг: 0 / 0
30.11.2010, 14:28
| Ответить | Цитировать | Написать  
Миграция с 9.5 на 11.50
    #36986948
zaiets
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zaiets
Гость
Журавлев ДенисzaietsExt3 - да, это не наше.так говорят только те, кто не ждал fsck 8 часов.

Да, действительно не ждал, люблю погеморроиться с немного другими проблемами.
Настраивали на "Raw", правда в 5 рхл уже не через raw а просто подсовывая тома
lvm информиксу 10 делали.
...
Рейтинг: 0 / 0
30.11.2010, 18:04
| Ответить | Цитировать | Написать  
Миграция с 9.5 на 11.50
    #36987149
andjeo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andjeo
Участник
Daugava Архивирование на лету должно снизить время на копирование бекапа.

Сейчас проверил, mkfifo есть в cygwin-е, сервера под винду меня правда нет, протестировать до конца не могу.

Для борьбы с CRLF-ами и другими спецсимволами в Char полях необходимо использовать ключик -X при экспорте и импорте.

После экспорта -X импорт не хочет понимать анлоады.
Ругается на то,что типа в анлоад файле больше столбцов чем в базе. Но количество столбцов совпадает и данные грузить вроде как начинает. Это нормально?..
...
Рейтинг: 0 / 0
30.11.2010, 19:23
| Ответить | Цитировать | Написать  
Миграция с 9.5 на 11.50
    #36987510
andjeo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andjeo
Участник
Возможен ли такой вариант:
1. Монтируем новый сервер как диск
2. Запускаем на старом сервере dbexport
3. На новом сервере, с некоторой задержкой, делаем load from,сохраняя порядок таблиц из экспорта

Зы: dbexport -X просто проигнорирует переносы строк и анлоад файлы будут загружаться нормально?или я не понимаю что то?
...
Рейтинг: 0 / 0
30.11.2010, 23:32
| Ответить | Цитировать | Написать  
Миграция с 9.5 на 11.50
    #36987516
bk0010
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
bk0010
Участник
andjeoРугается на то,что типа в анлоад файле больше столбцов чем в базе. Но количество столбцов совпадает и данные грузить вроде как начинает. Это нормально?..
У меня было такое, когда я грузил результаты dbexport Win-сервера в юниксовый информикс. Проблема была в том, что в Windows перевод строки #13#10, а в nix просто #10. Есть 3 варианта решения:
1) написать свою программу конвертации;
2) воспользоваться Dos2Unix;
3) при копировании по ftp пользоваться не двоичным, а текстовым режимом.
...
Рейтинг: 0 / 0
30.11.2010, 23:39
| Ответить | Цитировать | Написать  
25 сообщений из 54, страница 1 из 3
  1  все
Форумы / Informix [игнор отключен] [закрыт для гостей] / Миграция с 9.5 на 11.50
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=44&fpage=19&tid=1607436]:
 0ms
get settings:
 11ms
get forum list:
 13ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 46ms
get topic data:
 12ms
get forum data:
 2ms
get page messages:
 57ms
get tp. blocked users:
 1ms
others: 239ms
total:  389ms
созд. / загр.: 389ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]