Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Проблема переноса данных из одной БД в другую [IB6.x]

Страницы: 1 2 >
Alex-- © (2005-10-14 09:41:00)
Проблема состоит в замедлении копирования таблицы после 200 т.з. до 1 записи в секунду. Всего в таблице 600 т.з.(8 столбцов - integer). IB6.5. Загрузка проца 50%. Памяти 50%.

Используются компоненты: (BDE) 2 DataBase и 2 Query и 1 UpdateSQL.

Способ копирования: Подключаем базу источник (данные) и базу приемник (пустая). Открываем таблицу в Query (источник)
и таблицу в Query (приемник). Прогоняем строку источника - генерируем текст SQL, кидаем его в UpdateSQL. Делаем приемник Query.Post; Query.ApplyUpdates;

Сначала копирование проходит бодро, но после 200 т.з. становится грустно. С одной транзакцией на все изменения по таблице тот же результат.
Размер страницы БД делал и 4096 и 8192.
Способ бэкапа и восстановки данных проходит тоже долго.
Можно порекомендовать другой способ слива данных.

Danilka (2005-10-17 14:10:00) [1]
ой, блин, тема-то еще пятничная.. и за все это время аффтор сумел тока индексы отключить?
вот-же люди ленивые пошли, им легче тупо смотреть как по 1-й записи в секунду в базу пишецца, чем попробовать то, что посоветовали три дня назад...

Danilka (2005-10-17 14:02:00) [2]
Первым делом надо выкинуть UpdateSQL.
Для вставки использовать только запрос INSERT INTO... с параметрами.
До цикла с инсертами сделать ему prepare.
В самом цикле только подставлять параметры и выполнять запрос.

Если БДЕ выбран только для универсальности, чтоб можно было и к ИБ и к Ороклу цепляться, то, думаю, следует присмотреться к ДБЭкспресс-у, т.к. у него некешируемые однонаправленные компоненты доступа, в отличие от БДЕ, у которого все 600тыс.записей, после прохода до конца датасета, будут сидеть у тебя в памяти до тех пор, пока не закроешь запрос.
Если универсальность нафиг не нужна - используй для чтения IBX-компоненты, конкретно IBSQL, который также не кеширует записи.
Но самый главный источник тормозов, на мой взгляд, это использование UpdateSQL.

Sergey13 (2005-10-17 12:33:00) [3]
2[36] Alex-- (17.10.05 12:25)
Самый быстрый вариант - это выбирать не всю исходную таблицу, а ее часть. После записи части коммит и выборка следующей части. Так до упора. С размером части можно экспериментировать. И UpdateSQL конечно выкинуть.

Alex-- (2005-10-17 12:25:00) [4]
Только индексы, ка самый быстрый вариант. Буду копать загрузку из скрипта с данными, с комитом пакета данных. Ну и без UpdateSQL попробую.

Sergey13 (2005-10-17 12:09:00) [5]
2 [34] Alex-- (17.10.05 12:02)
А что ты еще попробовал кроме индексов? UpdateSQL выкинул?

Alex-- (2005-10-17 12:02:00) [6]
>индексы точно удалил? а PK и FK?

Точно. Не отключил, а удалил. И PK и FK.
Чеки и процедуры удалил навсякий.

Desdechado (2005-10-17 11:55:00) [7]
индексы точно удалил?
а PK и FK? В FB для них индексы создаются автоматически, тем паче такой длинный ключ. Лучше грохнуть PK и FK, а после заливки создать заново.

Alex-- (2005-10-17 11:21:00) [8]
Удаление индексов ожидаемого результата не принесло. Все постарому, скорость копирования падает. IBServer грузит систему на 80%. ХЗЧ.

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

Всего таблиц 50. Не более 600 записей в каждой. Копируются без проблем.
Настройки IB по умолчанию.
Проблемная таблица:
CREATE TABLE VHH ( DCID SMALLINT NOT NULL, OBJID SMALLINT NOT NULL, DEVID SMALLINT NOT NULL, JOINID SMALLINT NOT NULL, CHANID SMALLINT NOT NULL, STAMP DATE NOT NULL, VAL NUMERIC (18, 5), RELIABLE SMALLINT); /* Primary keys definition */ ALTER TABLE VHH ADD PRIMARY KEY (DCID, OBJID, DEVID, JOINID, CHANID, STAMP); /* Foreign keys definition */ ALTER TABLE VHH ADD CONSTRAINT VHH_FOREIGN FOREIGN KEY (DCID, OBJID, DEVID, JOINID, CHANID) REFERENCES CHANNELS (DCID, OBJID, DEVID, JOINID, CHANID) ON DELETE CASCADE ON UPDATE CASCADE;

Количество записей 600 000.

>и много еще чего...
Пиши конкретно, укажу.

>На фоне таких объемов 600 000 записей за 4 суток как-то заставляет задуматься.

Чем успешно и занимаемся :)
Такое время ни кто не ждал. Тут или я делаю не правильно (вероятнее) или сервер.
200 т.з копим на ура. 600 - 200 = 400 т.з.
копируется ~ 1 запись в секунду.
400 000 / 60 / 60 / 24 = 4.62 суток.

Anatoly Podgoretsky (2005-10-14 14:19:00) [9]
Seg (14.10.05 13:35) [28]
А зачем ты за 4 суток берешь, надо как минимум 125000*365*N

Sergey13 (2005-10-14 13:48:00) [10]
2 Alex--
В ИБ можно еще попробовать через внешнюю таблицу. Универсальность правда лесом идет, но как вариант.

Sergey13 (2005-10-14 13:39:00) [11]
2[28] Seg (14.10.05 13:35)
> На фоне таких объемов 600 000 записей за 4 суток как-то заставляет задуматься.
Так автор и задумался. Даже ветку создал, где советов спрашивает. 8-)

Seg (2005-10-14 13:35:00) [12]
Я не претендую на точность до грамма.
Просто привел порядок цифр. На фоне таких объемов 600 000 записей за 4 суток как-то заставляет задуматься.

Sergey13 (2005-10-14 13:32:00) [13]
2[26] Desdechado © (14.10.05 13:21)
Приведенные цифры вообще ни о чем не говорят и к сабжу имеют очень далекое отношение. ИМХО

Desdechado (2005-10-14 13:21:00) [14]
2 Seg
для корректной оценки приведенных цифр неплохо бы указывать и количество таблиц, и размер записей, и много еще чего...

Seg (2005-10-14 13:06:00) [15]
Самое долгое копирование, которое мне приходилось делать на Оракле - 135 000 000 записей.
Процесс длился 3 суток, правда копирование производилось на одном сервере в пределах одной схемы.

Загрузка из дампа 50 000 000 записей происходила за 1.5-2 часа.

Правда на хорошем 4-х процессорном серваке.

Alex-- (2005-10-14 12:55:00) [16]
>На Оракле до 1 000 000 записей копируется одной транзакцией на ура.
>Не 4 суток, а часа 2-4.
На оракле такое не пробывал. Просто предпологается в будущем.
Уверен сним проблем то и небудет.

Digitman (2005-10-14 12:55:00) [17]

> Alex--

поставь ту же версию IB-совместимого сервера на линуховый хост (если таковая под Линух имеется) и приятно удивись - при абсолютно тех же условиях "тормоза" при таком массированной вставке ощутимо снизятся

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

ну а в целом и общем основные рекомендации были даны правильные :

1. перед массированной вставкой выключай целевые индексы/триггеры

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

Alex-- (2005-10-14 12:53:00) [18]
Щас буду пробывать отрубание индексов. Результаты сообщу.
Можно и генерацию скрипта с комитом попробывать.

Seg (2005-10-14 12:51:00) [19]
На Оракле до 1 000 000 записей копируется одной транзакцией на ура.
Не 4 суток, а часа 2-4.
Если 600 000 записей копируются 4 суток, то дело может и не в серваке, а в сети или на клиенте...

ANB (2005-10-14 12:47:00) [20]

> Скорость падает после 200 т.з
- не в коммите дело. Кстати, пакетные коммиты дают не очень большой прирост скорости. Индексы отрубил ?

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »