Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Прочее";
Текущий архив: 2006.11.19;
Скачать: [xml.tar.bz2];

Вниз

Импорт dbf   Найти похожие ветки 

 
Тыгыдым   (2006-10-30 07:51) [0]

Задача:
есть dbf dBase IV (количество записей около 2млн).
Необходимо перенести их в таблицы Оракла.
Кроме как:
while dbf.Eof do begin
 with Proc do begin //                    
   ParamByName("").AsInteger := dbf.FieldByName("").AsInteger;
   ...
   Execute;
 end;
 dbf.Next;
end;


ничего лучше не придумал... Скорость импорта оставляет желать лучшего...
Пробовал перед вставкой отключать индексы, но результат мало изменился...
Возможно ли как-нибудь ускорить этот процесс?


 
Тыгыдым   (2006-10-30 07:52) [1]

Proc - ХП вставки записи


 
KilkennyCat ©   (2006-10-30 08:21) [2]

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


 
Sergey13 ©   (2006-10-30 08:28) [3]

Выгрузить все в текстовый файл и потом залить оракловым лодером.


 
Тыгыдым   (2006-10-30 09:29) [4]

[2]
т.е. читать по блокам? неужели это ускорит процесс?

[3]
это предполагается делать на одном из клиентов несколько раз в месяц. я думаю будет не совсем удобно :)


 
KilkennyCat ©   (2006-10-30 09:34) [5]

> [4] Тыгыдым   (30.10.06 09:29)

А что может быть быстрее прямой работы с файлом? Разумеется, если алгоритм обработки примитивен. Я не знаю формата Оракла, возможно, можно еще хитрее конвертировать, перетасовывая и изменяя громадными кусками.
А неужели нет готового решения, в виде утилиты?


 
Sergey13 ©   (2006-10-30 09:54) [6]

> [4] Тыгыдым   (30.10.06 09:29)
> это предполагается делать на одном из клиентов несколько
> раз в месяц. я думаю будет не совсем удобно :)
Почему? Какая разница какой код будет выполняться по нажатию кнопки? 8-)


 
Александр Иванов ©   (2006-10-30 10:00) [7]

У майкрософта есть MTS(или MDS).
Но я бы не усложнял. Подключил бы таблицы в Access и перенес бы все одним простым INSERTом.


 
Александр Иванов ©   (2006-10-30 10:02) [8]

Невнимательно прочита, думал операция разовая.


 
Alien1769 ©   (2006-10-30 10:34) [9]


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

Надеясь, что количество полей в базе не меняется.


 
jack128 ©   (2006-10-30 11:51) [10]

Тыгыдым   (30.10.06 7:51)
Скорость импорта оставляет желать лучшего...

что означает "оставляет желать лучшего" ?? Все таки 2 млн записей - это весьма солидная цифра.
PS что такое dbf ??  Он буфферизирует прочитанные записи? Если да, то в топку.


 
Anatoly Podgoretsky ©   (2006-10-30 12:10) [11]

0,3 миллисекунды


 
Тыгыдым   (2006-10-30 12:17) [12]


> что означает "оставляет желать лучшего"

Около 2х часов. Абсолютно неприемлемо...


> 0,3 миллисекунды

Вай-вай... А можно подробности "эксперимента"?


> что такое dbf ??  

Да, забыл сказать... Это Halcyon. Не могу сказать насчет буферизации...


 
Desdechado ©   (2006-10-30 12:25) [13]

про лоадер уже сказали
но даже в коде
ParamByName("").AsInteger := dbf.FieldByName("").AsInteger;
есть место для значительного ускорения.
Например, заранее узнать эти ParamByName("") и dbf.FieldByName(""), сохранив в отдельных переменных и обращаясь уже к ним вместо определения одного и того же указателя на каждой из 2 млн итераций. Да и AsInteger тоже время занимает. При однотипности лучше Value.


 
Anatoly Podgoretsky ©   (2006-10-30 12:26) [14]


> Вай-вай... А можно подробности "эксперимента"?

Это средняя величина, от 3 т. записей в секунду. Обычно порядка 10 т.
Но у меня не Оракл и тем боле не Halcyon.


 
Mutnauq   (2006-10-30 12:45) [15]

Halcyon, также как и TDbf, обеспечивают нативный доступ к файлам. Чего уж может быть прямее?


 
Игорь Шевченко ©   (2006-10-30 12:52) [16]


> Да и AsInteger тоже время занимает. При однотипности лучше
> Value.


Чем докажешь свое ложное утверждение ?


 
Petr V.Abramov   (2006-10-30 12:55) [17]

> [3]
> это предполагается делать на одном из клиентов несколько раз в месяц. я
> думаю будет не совсем удобно :)
думаю бат-файл спасет :)


 
Desdechado ©   (2006-10-30 13:10) [18]

Игорь Шевченко ©   (30.10.06 12:52) [16]
Автором не сказано, что типы полей совпадают со способом преобразования. Так что можно поля ftString через AsInteger перегонять, а уж наоборот (ftInteger через AsString) - так вообще типичная практика. Поэтому мое утверждение верно. Да и не факт, что поле в таблице вообще будет правильно типизировано (опознано) движком. А тут преобразования неизбежны.


 
Игорь Шевченко ©   (2006-10-30 14:09) [19]

Desdechado ©   (30.10.06 13:10) [18]

Ты посмотри, как Value работает...Оно полезно.

Я тебе могу примерно подсказать, реализаторы свойства Value у класса TField это GetAsVariant и SetAsVariant. SetAsVariant в свою очередь вызывает SetVarValue, которое для строковых полей вызывает SetAsString, для Integer- полей вызывает SetAsInteger, в общем, делается все то же самое, только с двумя дополнительными вызовами как минимум, один из которых обернут в try except. C GetAsVariant примерно то же самое...


 
roottim ©   (2006-10-30 14:22) [20]

Либо используй SqlLoader (dbf тоже текстовый , полагаю надо только правильно ctl файл настроить)
Лиьо используй его возможности в oci, только компоненты нужны Odac Doa и тп..
Конкретно в ODAC есть TOraLoader, который пользовал я, 2 млн - пару минут.


 
старый маразматик(с)   (2006-10-30 14:49) [21]


> Anatoly Podgoretsky ©   (30.10.06 12:26) [14]
> Но у меня не Оракл и тем боле не Halcyon.

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

откуда раблы могут быть...
если по сетке. лечится копированием на локалку, или выкачивать в память. собственно, однофигственно.
сам Оракл тормозит? криво код написан для Оракла? я с этим зверем не работал, потому молчу.
потому надо тестик писать, шоб увидеть, откуда ноги растут.


 
1g0r ©   (2006-10-30 15:47) [22]

Тыгыдым<

DOA, TOracleQuery

var OracleQuery: TOracleQuery;
...
OracleQuery.ExecuteArray()
...

работает по принципу ораклового лоадера
На моих таблицах скорость закрузки быстрее где то в 10 раз чем  стандартными средствами (твой пример или скриптом)

Удачи


 
Тыгыдым   (2006-10-31 08:54) [23]

[22]
У меня ODAC. Использую TStoredProc

[21]
[i]> криво код написан для Оракла?[/i]
Какой? INSERT INTO ... VALUES(...)?

[i]> не знаю как там оракл с производительностью, но Halcyon по чтению вполне производительный. если без индексов из одной таблицы. практически прямой достут к файлу, скорость по чтению... ну никак не два часа. пару минут, навскидку. ну, с десяток.[/i]
А он не кеширует записи? А то я глянул, постепенно скорость падает и падает...

[20]
[i]> Конкретно в ODAC есть TOraLoader, который пользовал я, 2 млн - пару минут.[/i]
пасиб, попробую


 
старый маразматик(с)   (2006-10-31 10:55) [24]


> Тыгыдым   (31.10.06 08:54) [23]


> А он не кеширует записи?

нет. просто чтение стандартными ф-циями типа FileRead(). но можно и закешировать в память(структура файла известна и примитивна, можно и свой движок написать, тем паче токо чтение, см. CreateFileMapping). но на современных винчестерах смысла нету, мне так кажеца. правда, на двух лимонах записей не тестил, у меня скромнее в одной таблице стоко нету, на пятисот штуках - некретично, секунда дело.

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


 
Чапаев ©   (2006-10-31 10:59) [25]

> [0] Тыгыдым   (30.10.06 07:51)
Помнится, с Делфи до 7 включительно, шёл такой инструмент как DataPump. Не подходит?



Страницы: 1 вся ветка

Форум: "Прочее";
Текущий архив: 2006.11.19;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.51 MB
Время: 0.044 c
15-1162206003
maxmax111
2006-10-30 14:00
2006.11.19
поскажите программу, которая..


2-1162203378
Access
2006-10-30 13:16
2006.11.19
Acces, ADO - как получить структуру таблицы?


15-1162046383
ArtemESC
2006-10-28 18:39
2006.11.19
Ух... Опять Си...


15-1162378180
SpellCaster
2006-11-01 13:49
2006.11.19
Фотографии Макинтоша


15-1162162008
Maxim Suvorov
2006-10-30 01:46
2006.11.19
Алгоритм решения полинома высокой степени >100?





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский