Мастера 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.
Способ бэкапа и восстановки данных проходит тоже долго.
Можно порекомендовать другой способ слива данных.

Desdechado (2005-10-14 12:33:00) [21]
коммит после каждой записи тоже сильно тормозить может (в общем, а не "после 200тыс.")
ищи компромисс числа записей и числа коммитов

Desdechado (2005-10-14 12:31:00) [22]
>Копирование данных делается неквалифированными сотрудниками
Что мешает выгружать скрипт автоматически, сохранить его во временный буфер и скормить поставляемой с сервером программе заливки данных?
И все это нажатием одной кнопки в твоей программе...

Alex-- (2005-10-14 12:30:00) [23]
>Это происходит от накопления информации для отката транзакции
Транзакцию не коплю. Комит проходит для каждой записи.

Скорость падает после 200 т.з

Alex-- (2005-10-14 12:26:00) [24]
Прочитал статейку про Гетерогенные запросы на BDE
http://www.delphiworld.narod.ru/base/bde_architecture2.html

по их примеру пишу в Query

select x.Name FROM ":A:dc" x, ":B:dc" z

A,B - как я понял внутренние алиасы баз
dc - таблица которая присутствует в обоих базах IB.

Выполняем - итог "Operation not applicable".

>быстрее скрипта ничего не будет
иногда в нем стоит вставлять commit

Копирование данных делается на стороне множества заказчиков, не квалифированными сотрудниками

Desdechado (2005-10-14 12:24:00) [25]
удалить индексы - это жестко
достаточно сделать INACTIVE

Seg (2005-10-14 12:21:00) [26]
Это происходит от накопления информации для отката транзакции

Вот здесь написан правильный ответ.

в целевой таблице индексы

И это тоже надо учесть, т.е. удалить все индексы в целевой таблице.

Desdechado (2005-10-14 12:13:00) [27]
быстрее скрипта ничего не будет
иногда в нем стоит вставлять commit

Alex-- (2005-10-14 11:21:00) [28]
Да Sergey13 я непонял вопроса. Тогда имел ввиду IB генерит скрипт с данными типа INSERT INTO fckTable () VALUES(). И этот скрипт пробывал прогонять в консоли на базу приемник - долго.

Sergey13 (2005-10-14 11:14:00) [29]
2[8] Alex-- (14.10.05 11:09)
>БД естессно 2е.
А как тогда понять
"Такой запрос в самом IB можно сгенерить"?
Insert into BD1.Table1 Select * from BD2.Table1
Это гетерогенный запрос по 2 БД сразу. БДЕ такое может. Оракл тоже может. ИБ - вроде нет.

Desdechado (2005-10-14 11:12:00) [30]
я бы сделал так:
1. читаю набор из первой БД
2. формирую параметрический INSERT
3. открываю транзакцию
4. пробежкой по первому набору заполняю параметры INSERT, и выполняю его (не через UpdateSQL!)
5. закрываю транзакцию

PS вполне возможно, что в одной транзакции это со временем будет выполняться все медленнее и медленнее. Это происходит от накопления информации для отката транзакции. Если целостность данных контролировать не надо, до можно коммитить каждую запись или небольшими пачками (НП, по 1000 штук) - найти компромисс легко.

Alex-- (2005-10-14 11:12:00) [31]

> Значит точно - в целевой таблице индексы и/или триггера
> тормозят.

Так а чо до 200 т.з. летаем, а потом грустим?

Alex-- (2005-10-14 11:09:00) [32]
БД естессно 2е. А вешается копинг на таблице с 600 т.з.
Копирование проходят все таблицы последовательно, причем бодро(небольшие).

Sergey13 (2005-10-14 11:04:00) [33]
2[5] Alex-- (14.10.05 10:52)
>Универсальность заключается в использовании как баз IB так и Oracle.
Ну тогда не IBSQL а простой Ткверик. Только не Select-овый с UpdateSQL, а просто ему в SQL Update напиши. Суть - не формировать на клиенте второй набор данных.

>Такой запрос в самом IB можно сгенерить и выполнить одним скриптом.
А у тебя точно 2 БД, а не 2 таблицы в одной БД?

ANB (2005-10-14 10:58:00) [34]

> Такой запрос в самом IB можно сгенерить и выполнить одним
> скриптом.
> Но ситуация похожа - выполняется, но долго.

Значит точно - в целевой таблице индексы и/или триггера тормозят.

Alex-- (2005-10-14 10:52:00) [35]
Универсальность заключается в использовании как баз IB так и Oracle.
(Пока вариант с ораклом не риходилось попробывать).

>Можно, если юзаешь БДЕ почитать про гетерогенные запросы и сделать все одним запросом Insert from Select.

Такой запрос в самом IB можно сгенерить и выполнить одним скриптом.
Но ситуация похожа - выполняется, но долго.

Sergey13 (2005-10-14 10:34:00) [36]
2[2] Alex-- (14.10.05 10:02)
>Сделано для универсальности.
В чем тут универсальность то? Надо просто IBSQL с параметрами выполнять. Зачем тебе 2 одинаковых набора на клиенте?

>4
Комитишь когда? Желательно записей через 500-1000 (можно поподбирать).

Можно, если юзаешь БДЕ почитать про гетерогенные запросы и сделать все одним запросом Insert from Select

ANB (2005-10-14 10:13:00) [37]
1. Вообще то лучше insert ... select.
2. Если уж приспичило через клиента - лучше через 2 квери - одной доставать данные, в другой - присваивать параметры в заранее сгенеренный SQL и выполнять. Можно еще препарировать для скорости (иногда мешает).
3. Замедление скорее всего из-за переполнения памяти начинается, так как кверя хранит в оперативке все ранее выбранные строки. Нужно это ликвидировать. Для IB - не знаю как, в DOA есть компонент, не являющийся дэйтасетом. Возможно, можно попробовать включить Unidirectional.
4. Использовать BDE для доступа к IB да еще когда нужна высокая скорость я бы не стал.
5. Полезно еще в целевой таблице посрубать индексы и триггера.

Alex-- (2005-10-14 10:02:00) [38]
>1. Нафига вообще перегонять?
Необходимо делать так. Раскрытие этого вопроса повлечет дискусию не относящуюся к вопросу.

>2. Как часто надо перегонять?
Довольно редко. Но процесс копирования должен проходить не 4 суток.

>3. Нафига "кидаем его в UpdateSQL."? Может ты и в грид все выводишь?
Сделано для универсальности. Софтинка предпологает не только копирование данных. Компоненты отображения данных не использую.

>4. Как фиксируешь вставку?
Если правильно понял твой вопрос то:
Query.Post;
Query.ApplyUpdates;

Sergey13 (2005-10-14 09:46:00) [39]
1. Нафига вообще перегонять?
2. Как часто надо перегонять?
3. Нафига " кидаем его в UpdateSQL."? Может ты и в грид все выводишь?
4. Как фиксируешь вставку?

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

Наверх

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