![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Загрузка объемных данных в рамках одной транзакции [D7, MSSQL]
MsGuns © (2006-07-14 16:18:00)Требуется сделать следующее:
1. Создать в БД таблицу, если ее нет, или очистить от записей, если есть
2. Создать ХП вставки в таблицу
3. С помощью этой ХП из текстового файла загрузить в таблицу данные (порядок - от сотни тысяч до миллионов)
4. ХП удалить из БД
5. Транзакцию подтвердить.
6. В случае ошибки создания (очистки) таблицы или создания ХП транзакцию откатить, оставив таблицу в прежнем состоянии
Сейчас получается все, кроме отката, поэтому даже в случае прерывания процесса, в БД остается и ХП, и новые данные в таблице.
Посоветуйте что-нибудь в этом направлении. В BOL, к сожалению, не описаны подобные ситуации или я их не нашел, хотя искал две недели.
Спасибо за подсказки и советы
ЗЫ. MS SQL Server 8 + ADO (OLE DB)
Медведъ (2006-07-23 17:24:00) [1]но впрочем я думаю мы поняли друг друга, нет смысла продолжать дискуссию на мой взгляд
Медведъ (2006-07-23 17:23:00) [2]способ хороший, но не в том случае когда оператору нужно импортировать заказ клиента из хлс файла в базу на удаленном сервере
я понимаю что есть системы в которых файловый обмен активно используется но это не гуманно
Anatoly Podgoretsky (2006-07-23 17:13:00) [3]Медведъ (23.07.06 17:09) [46]
Вот и мы про тоже
В MS SQL есть несколько аналогов, например заливка с помощью DTS, скорость несколько десятков тысяц в секунду.
Anatoly Podgoretsky (2006-07-23 17:12:00) [4]Медведъ (23.07.06 17:06) [45]
Ты потерял нить обсуждение, речь шла про повальное увлечение XML а не DBF и про то, что XML для таких объемов не подходят.
Медведъ (2006-07-23 17:09:00) [5]и вообще я привел програмное решение, если мне просто нужен импорт я замечательно пользую DTS Wizard
Медведъ (2006-07-23 17:06:00) [6]>Anatoly Podgoretsky
насчет повального увлечения - автор вроде ничего не говорил про 500 мегабайтные dbf-таблицы, к тому же
3. С помощью этой ХП из текстового файла загрузить в таблицу данные (порядок - от сотни тысяч до миллионов)
а файл мы на сервер предварительно по фтп зальем, да ?
красота
давайте сразу про терабайты говорить, тогда вообще проще жесткий диск по почте переслать в другой город где сервер находится
Anatoly Podgoretsky (2006-07-23 11:45:00) [7]AlexAlex (20.07.06 18:36) [39]
В MS SQL есть несколько аналогов, например заливка с помощью DTS, скорость несколько десятков тысяц в секунду.
Anatoly Podgoretsky (2006-07-23 11:43:00) [8]DiamondShark © (23.07.06 10:28) [41]
Это точно, проверено на практике. Есть одна задача импорт данных из старой программы на основе DBF в MS SQL.
Ее можно выполнить двумя путями, через импорт с помощью XML или с помощью прямого импорта из DBF таблиц. Суммарный размер базы порядка 500 мегабайт.
Первый путь требует свыше 7 дней и гигабайты памяти, второй три часа и ничтожно мало памяти. Повальное увлечение новомодными технологиями до добра не доводит.
Anatoly Podgoretsky (2006-07-23 11:39:00) [9]MsGuns © (14.07.06 16:18)
Требуется сделать следующее:
1. Создать в БД таблицу, если ее нет, или очистить от записей, если есть
2. Создать ХП вставки в таблицу
3. С помощью этой ХП из текстового файла загрузить в таблицу данные (порядок - от сотни тысяч до миллионов)
4. ХП удалить из БД
5. Транзакцию подтвердить.
6. В случае ошибки создания (очистки) таблицы или создания ХП транзакцию откатить, оставив таблицу в прежнем состоянии
1. Создать в БД таблицу вне зависимости есть данные или нет. Это быстрее, чем удалять записи
2.
3.
4. ХП удалить из БД вне зависимости от состояния
5.
6. при откате транзакции ничего делать не надо, кроме удаления ХП
поэтому операцию удаления ХП выносим за рамки пунктов 1-6
Все это можно сделать с помощью сгенерированого скрипта, в EM и после небольшой заточки использовать его.
Заливку даннных делать с помощью BCP из ранее подготовленных данных.
Возможны варианты.
DiamondShark (2006-07-23 10:28:00) [10]
> Медведъ (19.07.06 13:01) [37]
XML ну никак не предназначен для заливки больших объёмов...
DiamondShark (2006-07-23 09:44:00) [11]
> поэтому пакетная текстовая заливка (bcp) не "катит"
Не "поэтому", а потому что кто-то BOL ленится читать.
См. раздел
Performing Bulk Copy Operations
BCP для таких вещей -- самое то что надо. Данные заливаются со скоростью молнии, смазанной салом.
Если кому интересно -- стукнитесь в почту или асю...
Вышлю дельфишные интерфейсный модули для ODBC и BCP, или примерчики какие-нибудь.
AlexAlex (2006-07-20 18:36:00) [12]1. В Informix есть оператор Load для загрузки данных из текстовых файлов. Найдите аналог в MSSQL и будет вам скорость.
2. Так же может сущетвовать скоростной загрузчик, поищите у Microsoft
3. Попробуйте спросить на SQL.ru - там есть профильный форум
stud (2006-07-19 16:15:00) [13]так а если:
1 создать ХП
2 очистить табл ---
3 внести данные ---
4 в любом случае удалять ХП
2 и 3 это можно реализовать в одной транзакции в случае отката должна остаться старая таблица
Медведъ (2006-07-19 13:01:00) [14]>Fay © (18.07.06 13:38) [24]
>Приходилось ли самому мег по 100 так отправлять ?
по 100 мег не приходилось, можно разбивать на блоки меньшего размера
будет на порядки быстрее чем "В цикле TADOCommand(cmdStoredProc).Execute"
впрочем я не настаиваю, пойду покушаю, у нас сегодня окрошка
Медведъ (2006-07-19 12:49:00) [15]>MsGuns © (18.07.06 13:45) [25]
>К сожалению, не знаком с этой технологией.
что непонятно то, на клиенте в цикле пробешаемся по всем записям и форимруем строку типа
<PACKET>
<ROW GOODID="123" QTY="45.67" />
<ROW GOODID="124" QTY="3.1415" />
</PACKET>
передаем эту строку в процедуру с NTEXT параметром, далее читаем BOL OPENXML
CREATE PROCEDURE ImportOrder @AccId INT, @ImportMode INT, @Xml NTEXT AS
SET NOCOUNT ON
DECLARE @Tree INT
EXEC sp_xml_preparedocument @Tree OUTPUT, @Xml
INSERT INTO ...
SELECT T.GOOD, T.QTY FROM OPENXML(@Tree,'//ROW',2) WITH (GOOD INT, QTY INT) T
EXEC sp_xml_removedocument @Tree
а делать 10^6 запросов к серверу и ожидать при этом приемлемой производительности глупо
Slym (2006-07-19 12:11:00) [16]И обязательно с параметрами
Slym (2006-07-19 12:10:00) [17]MsGuns © (18.07.06 13:45) [25]
При записи Insert`ми делали и с параметрами, и без - разница почти никакая,
Insert.Prepared:=true;?
Val (from Kiev) (2006-07-19 12:05:00) [18]>MsGuns © (18.07.06 14:02) [30]
как читаются данные для вставки - в том же цикле, по строчке?
код вставки данных на клиенте д.б. таким:
start_transaction;
try
do_all_inserts;
commit;
except
rollback;
end;
на сервере отменить обертку каждого оператора в свою транзакцию.нужные ddl выполнять до и после приведенного псевдокода. иметь в виду, что ddl, в обычной практике автоматически, коммитит транзакцию.
>sniknik © (18.07.06 15:32) [32]
не с одним. насколько я понял автора в [17], автор просто обернул одиночный инсерт в процедуру и вызывает ее в цикле нужное количество раз. Не знаю как и что сравнивалось, но в теории параметрический инсерт в сравнении с такой процедурой(где тот же запрос) должен выполняться одинаково, если не быстрее.... не знаю особенностей мс скл, к сожалению, если автор говорит - процедура работает быстрее - это меня удивляет.
sniknik (2006-07-18 15:32:00) [19]> Самый здоровый файл (больше лимона записей) загружался инсертами
> Когда задействовали ХП, состоящую всего лишь из одногоинсерта,
ничего не смущает? сравниваете более милиона вызовов пусть и параметрических с одним...
нет уж, вы либо в запросе аналогичный, один инсерт поставьте либо в процедуре на позаписную вставку (по записи на инсерт) разбейте. либо вообще не говорите что у вас было какоелибо "сравнение"...
команды обрабатывающие данные пакетами всегда быстрее, так уж исторически сложилось...
Fay (2006-07-18 14:45:00) [20]MsGuns © (18.07.06 14:02) [30]
Я имел ввиду "инсёртов в секунду"