Увеличение скорости dbimport
Alex Ivanov
Есть машинка P4-2,4GHZ/1024MB/Linux 2.4.22/IDS 7.30UC10
Надо импортировать базу большого объема (в выгруженном формате
занимает около 800 Мб). Когда запускаю dbimport и дело доходит до
таблицы, где 1 600 000 записей, то сначала импорт идет быстро -
примерно до 600 000 записей, потом начинает работать очень медленно
- по 2-3 тыс. записей/сек.
Что можно покрутить для увеличения скорости импорта данных?
--
С уважением,
Alex Ivanov mailto:res...@narod.ru
Igor Zavgorodny
> Здравствуйте.
>
> Есть машинка P4-2,4GHZ/1024MB/Linux 2.4.22/IDS 7.30UC10
>
> Надо импортировать базу большого объема (в выгруженном формате
> занимает около 800 Мб). Когда запускаю dbimport и дело доходит до
> таблицы, где 1 600 000 записей, то сначала импорт идет быстро -
> примерно до 600 000 записей, потом начинает работать очень медленно
> - по 2-3 тыс. записей/сек.
> Что можно покрутить для увеличения скорости импорта данных?
>
HPL - high performance loader. Быстрее нет ничего. Лучше день потерять,
на настройку, но потом за пять минут загрузить. Правда насчет дня я
загнул, он не так страшен как кажется с первого раза. К сожалению Google
не хранит аттачи и мой могучий комплект где-то затерялся.
Regards, Igor.
P.S. Вроде нашел скрипт, который настраивал базу HPL (onpload), и
создавал скрипт для его запуска.
#!/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
Журавлев Денис
Перенести запросы на создание индексов в "конец" скрипта?
> Надо импортировать базу большого объема (в выгруженном формате
> занимает около 800 Мб). Когда запускаю dbimport и дело доходит до
> таблицы, где 1 600 000 записей, то сначала импорт идет быстро -
> примерно до 600 000 записей, потом начинает работать очень медленно
> - по 2-3 тыс. записей/сек.
Очень похоже что индекс создается до вставки записей, попробуй создавать
после, правда придется покрутить, чтобы индекс по такой таблице создавался
бысто.
Alex Ivanov
Вы писали 2 августа 2004 г., 21:54:05:
> Regards, Igor.
> commit;
> !
При запуске onpload говорит:
High-Performance Loader is not available on this platform.
Igor Zavgorodny
> При запуске onpload говорит:
> High-Performance Loader is not available on this platform.
Да под Linux HPL есть только под 9-кой :-(.
Regards, Igor.
Igor Zavgorodny
>
> Очень похоже что индекс создается до вставки записей, попробуй создавать
> после, правда придется покрутить, чтобы индекс по такой таблице создавался
> бысто.
>
Насколько я помню, индексы в дбэкспортовском скрипте создаются все таки
в конце, исключая primary key и неявные индексы вызванные refferential
constraint. В любом случае попробовать стоит.
Есть еще вариант поиграться с утилиткой myexport от Art.S.Kagel
(http://www.iiug.org/software/index_DBA.html), которая свободна от
многих проблем dbexport-a.
Regards, Igor.
Alex Ivanov
Вы писали 3 августа 2004 г., 13:36:50:
> Журавлев Денис wrote:
> Regards, Igor.
В скрипте индексы создаются после загрузки базы, и когда загружаешь,
то это видно.
Alex Ivanov
Вы писали 3 августа 2004 г., 13:15:40:
> Alex Ivanov wrote:
> Regards, Igor.
А зачем тогда ipload и onpload включили в дистрибутив 7-ки, если они
не работают?
Журавлев Денис
> > после, правда придется покрутить, чтобы индекс по такой таблице
создавался
> > бысто.
> >
> Насколько я помню, индексы в дбэкспортовском скрипте создаются все таки
> в конце, исключая primary key и неявные индексы вызванные refferential
> constraint. В любом случае попробовать стоит.
Често говоря мне память изменяет. Но у меня есть интуитивное ощущение что
идексы в конец скрипта dbexport стал пихать в какой-то из версий 9-ки.
Поправьте меня если глючу, 7-ку давно не видел.
> Есть еще вариант поиграться с утилиткой myexport от Art.S.Kagel
> (http://www.iiug.org/software/index_DBA.html), которая свободна от
> многих проблем dbexport-a.
Это да, стоит.
Igor Zavgorodny
> А зачем тогда ipload и onpload включили в дистрибутив 7-ки, если они
> не работают?
Видимо для того, чтобы они писали "High-Performance Loader is not
available on this platform."
Regards, Igor.
Igor Zavgorodny
> В скрипте индексы создаются после загрузки базы, и когда загружаешь,
> то это видно.
Да, но это не касается primary keys & constraints. Если их убрать
заливка пройдет конечно быстрее, правда неизвестно сколько времени уйдет
на их дальнейшее построение.
Кроме того, это может быть баг dbimport-a. Например, в ранних версиях
9-ки (сейчас не знаю, давно не пробовал), просто невозможно было
импортнуть сколько-нибудь большую таблицу с varchar-ами (сервер поедал
всю доступную память). В этом случае стоит таки поиграться с myexport.
Regards, Igor.
Литвиненко Владимир
--
-------
Литвиненко Владимир
Alex Ivanov
Вы писали 3 августа 2004 г., 14:22:04:
> Alex Ivanov wrote:
> Regards, Igor.
Там очень простая база без всяких первичных ключей и констраинтов,
одни простые индексы.
Alex Ivanov
Вы писали 3 августа 2004 г., 14:10:31:
>> > Очень похоже что индекс создается до вставки записей, попробуй создавать
>> > после, правда придется покрутить, чтобы индекс по такой таблице
> создавался
>> > бысто.
>> >
>> Насколько я помню, индексы в дбэкспортовском скрипте создаются все таки
>> в конце, исключая primary key и неявные индексы вызванные refferential
>> constraint. В любом случае попробовать стоит.
> Често говоря мне память изменяет. Но у меня есть интуитивное ощущение что
> идексы в конец скрипта dbexport стал пихать в какой-то из версий 9-ки.
> Поправьте меня если глючу, 7-ку давно не видел.
Вот кусок sql файла, созданного dbimport'ом
{ TABLE "sai".atrib row size = 357 number of columns = 4 index size = 243 }
{ unload file name = atrib00105.unl number of rows = 41 }
create table "sai".atrib
(
atrib serial not null ,
atr_name nchar(150) not null ,
komm nvarchar(200,100)
default null,
type smallint not null ,
primary key (atrib)
);
revoke all on "sai".atrib from "public";
create unique index "sai".xak1atrib on "sai".atrib (atr_name);
Это конечно ерундовая таблица, но при заливке больших таблиц перед
загрузкой данных из файла выдается такое сообщение:
create table "sai".atrib
(
atrib serial not null ,
atr_name nchar(150) not null ,
komm nvarchar(200,100)
default null,
type smallint not null ,
primary key (atrib)
);
revoke all on "sai".atrib from "public";
Потом после загрузки данных идет:
create unique index "sai".xak1atrib on "sai".atrib (atr_name);
Тут он сколько-то думает (создает индекс) и продолжает дальше.
>> Есть еще вариант поиграться с утилиткой myexport от Art.S.Kagel
>> (http://www.iiug.org/software/index_DBA.html), которая свободна от
>> многих проблем dbexport-a.
> Это да, стоит.
Журавлев Денис
>...
>...
>...
> primary key (atrib)
> );
А как ты думаешь когда создается неявный индекс по полю atrib?
Покажи кусок скрипта с большой таблицей.
Alex Ivanov
Вы писали 3 августа 2004 г., 17:55:15:
Это я взял другой пример. В той экспортируемой базе первичных ключей
нет 100-пудово. Кусок скрипта сейчас показать не могу.
Может надо onconfig как-то покрутить?
Пробовал загружать на 9.40UC4(wg) - то же самое.
Alex Ivanov
Вы писали 3 августа 2004 г., 14:22:04:
> Alex Ivanov wrote:
> Regards, Igor.
myexport у меня не идет, пишет что нет myschema.
Igor Zavgorodny
> myexport у меня не идет, пишет что нет myschema.
>
Ее можно взять там же.
Igor Zavgorodny
> Может надо onconfig как-то покрутить?
В onconfig-е для dbimport-a многого не накрутишь. Разве что увеличить
размер физического журнала или как-нибудь по другому повлиять на частоту
чекпоинтов. Можно конечно еще помониторить, как себя ведет система при
этих торможениях, т.е. чего й не хватает и от этого уже плясать. Хотя и
так можно сказать, что упирается в итоге все в диски.
Vasyl Shulzhenko
"Журавлев Денис" <z...@chspz.ru> wrote in message
news:cenh9q$bqv$1...@no-more.kiev.ua...
> > > Очень похоже что индекс создается до вставки записей, попробуй создавать
> > > после, правда придется покрутить, чтобы индекс по такой таблице
> создавался
> > > бысто.
> > >
> > Насколько я помню, индексы в дбэкспортовском скрипте создаются все таки
> > в конце, исключая primary key и неявные индексы вызванные refferential
> > constraint. В любом случае попробовать стоит.
>
> Често говоря мне память изменяет. Но у меня есть интуитивное ощущение что
> идексы в конец скрипта dbexport стал пихать в какой-то из версий 9-ки.
> Поправьте меня если глючу, 7-ку давно не видел.
Поправляю :)
Индексы создавались всегда _после загрузки данных_ таблицы, естественно, кроме
тех неявных, о которых уже упоминал Игорь.
Vasyl Shulzhenko
"Alex Ivanov" <res...@narod.ru> wrote in message
news:1831955091.2...@narod.ru...
> Здравствуйте.
>
> Есть машинка P4-2,4GHZ/1024MB/Linux 2.4.22/IDS 7.30UC10
>
> Надо импортировать базу большого объема (в выгруженном формате
> занимает около 800 Мб). Когда запускаю dbimport и дело доходит до
> таблицы, где 1 600 000 записей, то сначала импорт идет быстро -
> примерно до 600 000 записей, потом начинает работать очень медленно
> - по 2-3 тыс. записей/сек.
Не очень понимаю, как ты это видишь ?
Т.е. как ты определил , что первые 600тыс. грузятся быстро, а потом медленно ?
И сколько всего по времени грузится твоя БД на 800М ?
И сколько она занимает уже в загруженном виде ?
Какие размеры стоят для начального и вторичного экстентов этой большой таблицы ?