Всем доброго времени суток.
Есть независимый непериодический регистр сведений. Измерения-поставщик, номенклутура, характеристика(характеристика строка) и измерение цена.
Читаю прайс-лист в миллион строк (плюс-минус  200 тысяч). Пишу это добров в регситр.
Сабж. Метод СоздатьНаборЗаписей()...Добавить()...Записать() не канает, так как встречаются одинаковые характеристики, из которых велено брать первую. Поэтому каждый раз делаю СоздатьМенеджер()...Записать(). Даже в рамках транзакции 400 тысяч почти три часа. Эска (файловый вариант) ест гиг оперативы. Пробовал транзакциями по 10 000 записей - прироста скорости замечено не было.
Как можно оптимизировать?

убирай дубли заранее - потом пиши СоздатьНаборЗаписей

(0) Сначала вогнать всё в запрос, откинуть лишнее, результат запроса вогнать в набор записей, его и записать.

(1) Как можно убрать заранее дубли при построчном считывании из файла?
(2)Как вогнать все заранее в запрос? Уж не через таблицу ли значений?
(1,2) Если все это хранить, то не окажется ли поиск по ТЗ дольше, чем запись?
Всем спасибо.

(0) никак. это 1с, она не предназанчена "по-быстрому" работать с миллионами записей
(2) какие данные будут исходными для 1С-запроса, если, скажем, прайс - в эксель? ))

(3)Юзай набор записей.Ему поровну дубли, запишет последний вариант

(0) единственно - разделите парйс на блоки (как хотите), и загружайте блоками. По-крайней мере, будут блочные записи для работы, а не обрывки, пока загрузится все остальное.

(0) "так как встречаются одинаковые характеристики, из которых велено брать первую" - так они одинаковые или брать первую?

(7) похоже что встречаются одинаковые строки

(4) а если прайс в txt ?

(5) у меня в одном наборе записи получаются неуникальные записи

(7) строки разные,характеристики (комбинация измерений для регистра) одинаковые, а цена (ресурс) разная, с учетом известной сортировки файла берем максимальную- она в строке с меньшим номером

(8) примерно

(8) в прайсе одинаковые строки? как тогда они сами ориентируются?

(9)Набор идет поодному отбору. Не может там быть неункальных записей. Он просто перезапишет если такие окажутся

(10) там есть доп. характеристики, которые нам безразличны и встречаются у единичных товаров. Вообще согласен - бардак.

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

(9) если прайс в txt - обработайте сначала сам txt (1с тоже может прочитать, набрать и снова создать txt, но это тоже долго и нужно ли?)

(11) А можно чуть подробнее? Я отбор не устанавливал вообще, а каждый раз добавляя запись указывал значение измерений и ресурса.

+ (9) у меня 5 Мб txt читался и вводился часов 5-7.

(13) Это не наш прайс)
(14) перезаписывать миллион записей в txt и обратно будет быстрее, чем добавлять записи в регистр?

(15) когда создается НаборЗаписей, обязательно указывается Отбор - иначе будет перезаписан весь регситр целиком.

(17) по-крайней мере, вы управляемо будете заменять одну строку на другую по прозрачным правилам (в случае перезаписи строк), а не как придется (точнее, как прочитается 1с-ом).

(15)Создаешь набор записей, устанавливаешь как отбор текущие данные строки, устанавливаешь данные и делаешь .Записать(истина).Если такой набор и был, то он перезапишется

(16) у меня чуть-чуть быстрее, но скорость не устраивает совсем. Сравниваем в делфовской прогой грузившей данные из того же прайса в FireBird
(18) блин, надо попробовать.
(20) т.е. по сути дела опять миллион раз вызов записать?

(17) у вас ведь задача убрать повторы? или нет?
убыстрение загрузки невозможно, по причинам неэффективности 1с в целом.

(21) сравнили оракловскую внучку и поделку 1с...

(21)Если есть дубли -по другому никак.
Только если писать напрямую на асме:-)

или хотябы на скуле

(22) Задача загрузить прайс в базу 1С. Просто регистр повторов не допускает.
(23) Ну не на два порядка же падение скорости.

(24) загрузка на асме в 1с? )))

(26) если у вас такие опреативные данные (миллион строк туда, миллион сюда), то вам не к 1с.
Кроме постоянной покупки все более мощных серверов будете всегда иметь проблемы скорости.

(28) По Вашему мнению даже переход на SQL-версию не поможет?

(27)Ну..Некоторые пишут Песнь о Вещем Олеге на рисовом зернышке через микроскоп. А чем это не хобби на года:-)

+ (28) нет, вас, конечно, будут убеждать тру-1сники, что у них дескать миллионы записей в регистрах, но почему-то ихние отчеты не используют весь миллион одновременно, хотя они постоянно ставят знак равенства "иметь миллион записей в базе = обрабатывать в транзакции миллион записей"

(31)На то и  существуют виртуальные таблицы, посчитанные заранее.

(29) SQL полностью задавлен 1с-ом как СУБД, и даже преимущетсва SQL как СУБД практически полностью игнорируются 1с-ом и подменяются её кредо "а мы лучше знаем, как надо хранить, обрабатывать и оперировать записями!"

(32) это костыли, причем трухлявые (кривая реализация виртуальных таблиц).
Для нормального учета нужны не "предварительно рассчитанные" по ПРЕДПОЛОЖЕНИЮ данные, а реальная обработка в текущем времени.
Данные меняются в один период времени (скажем, раз в час), а вирт. таблицы - в другой, более длительный (когда там итоги пересчитываются? раз в месяц?).

(34)Кажется как поставишь - так и расчитываются:-)...Но уход со скуля - это решения в разы и десятки дороже самой 1С...Так что они сами пока только подступают скромно и к облакам и ко всему такому прогрессивному

В кулаурах конечно рекомендуют переходить на Оракл.  Но  прямо заявить....
Их тоже понять можно.
"Купите нашу авторучку! Она классная!...Правда для того что бы ей писать придется купить Автомобиль, но это такая мелочь!"
:-))

даже если на эти натяжки закрыть глаза - ВТ рассчитывается по количественным полям и по измерениям (тупо суммируется-вычитается).
А нужно именно АНАЛИЗ многомерных данных (откуда и получается миллионы строк), а не просто сложить "2 рулона + 2 рулона поступило, 1 рулон продали = 3 рулона осталось" ))

(37)да я согласен, что ты меня убеждаешь:-)

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

(38) другие почитают - может, задумаются...

(39)Месье:-) Успокойтесь:-)) Все враги уже разбежались

Честно говоря, так и не понял, есть ли смысл в переходе на SQL-версию (скажем, Postgre для начала) и почему?

(42)Для мелко -средних баз смысла нет.Даже иногда вредно.
Для оборота, скажем больше 5-10 тыс. документов в день уже смыл появляется

(43) документов в день гораздо меньше. Основная нагрузка - обработки по типу сабжевой.

(42) - (41) а вы говорите - не надО!!!! )))
(42) вы сначала оцените, какой объем будет обрабатываться в базе.
Если вы уже сейчас грузите только прайс из миллиона строк - то какие же остальные справочники (Номенклатуры, Характеристик и т.д.).
А это все надо будет крутить и перелопачивать, а 1с очень интересная система, тянущая за запрашиваемым объектом все ссылочные в запрос...
Есть методики для оценки на основе тезиса из (43) - каков объем вводимых документов, одновременно работающих пользователей..

(44)Если сабж происходит регулярно, то тут тебя никакой скуль не спсет.Скуль - это удобство хранения данных, их чтения...Для записи скуль не намного больше помошник чем все остальное. Мильен записей  записать- это и в Африке мильен записей

(43) от количества доков не зависит: например, в день вводится от силы 100-300 доков, а расчет себестоимости (и последующее восстановление последовательностей) занимает 5-9 часов.
на SQL-ной базе, два 2хпроцессорных сервера. Пользователей - 30 человек.

(45)>>каков объем вводимых документов, одновременно работающих пользователей..
Это тоже критерий, согласен. Блокировки -бич одинесников:-)

(47)Эт смонтря как эти доуи вводятся. Вполне могут скопом проводиться гдето в одной базе

(45,46) Докуметов до сотни в день. Ради выполнения загрузки - оставим одного пользователя.

доуи  =доки

(48) в прмере без блокировок, в этот момент все равно никто не может работать.
(46) если бы не было прослойки в виде 1с-сервера, а использовлся движок SQL для индексации, поиска, обработки - было б не на два порядка медленнее, а в разы ))
если по сравнению с Оракл ))

+(52) имеется ввиду, в мной приведенном примере

(52)Не надо про Оракл:-) ..Мне сдается на него переходить через год-другой...От головная боль то..

(49) нет, проводятся то они последовательно, а не скопом.
как раз миллионыы строк в запросах дает требуемая детализация и аналитика.
Поэтому ТС надо серьезно подойти к оценке смысла перехода, иначе потмо деваться будет некуда - обратно с 1с уже не перейдешь никуда...

(55)Да что ты его пугаешь как попы женидьбой:))  Типа все, на всю жизнь.При желании хоть с чего хоть куда перейти можно. Вопрос во времени и в ресурсах

(56) с 1с нельзя соскочить ))
именно по причине бардака в базе данных.

(57)да брось. Бардак - это свойство организации труда , а не 1С.
Мне попадались вполне грамотно организованные базы. Правда они были следствием грамотно организованного процесса труда.

(49) переход дело уже решенное. В первую очередь по необходимости иметь "все в одном флаконе". Доработанная УНФ решает все необходимые задачи, за исключением сабжевой. Главный плюс - все данные в одном месте.

(59)Начинай думать об оптимизации процесса записи больших массивов в базу, раз не можешь оптимизировать их объем.

(60) так в том и вопрос - как можно оптимизировать. Потоков то в 1с нету.

(58) ссылочность, которая порождает ссылочность, которая порождает другую ссылочность, а та - еще одну.
ЭТО нельзя развернуть в реляционную структуру.
Посмотрите выгрузку из 1С - там же одни ссылки, и практически нет данных ))
это надо писать некий алгоритм выгрузки и обработки этих ссылок для представления в прозрачном виде, а это сродни изобретению 1с-сервера, и кто будет этим заниматься? ))

(61)Зато есть транзакции.Если не ест целиком - значит надо кормить маленькими кусочками.

(62)Ты не поверишь:-) Ссылочность- это и есть реляционная структура:-)

(64) в (0) уже писал, что кормил транзакциями по 10 тыс. операций записи.

(65)Корми по 500. Это нормально

(64) ага ))
только когда ссылочность прозрачна, и ссылка дает данные (или позволяет их извлечь), а не другую ссылку на ячейку, содержащую такую же ссылку ))
Это понятно 1су, но как вы ораклу объясните, что вот эта цепочка ссылок (Контрагент-Документ-Номенклатура-Характеристики) это не тоже самое, что Регистр-Документ-Номенклатура-Сумма? )

(65) будем пробовать.

(67)Оракл вообще отдельно хранит твои наборы данных и делай ты с ним што хошь:-)  Но мы же про скуль говорим.

(61) можно обрабатыать данные вне 1с, а 1с-у скармливать уже выжимку.
Можно сихронизировать в нерабочее время.
Можно блоками (по-контрагентно, по-организационно и т.д.) - т.е. пока не задействованные контрагенты не учавствуют в перегрузках....

Проверь, сколько занимает запись в базу - это и есть основное ограничение скорости. Проверку на дубли можно сделать очень просто и быстро, времени занимает незначительно.

Недавно организовал "онлайновую" (опрос с интервалом 60 сек) синхронизацию номенклатуры 1С с базой SQL (из SQL в 1С). Размер номенклатуры полмиллиона. Первичная загрузка при подключении чистой базы 1С занимает около 2-х часов. Дубли проверяются (у меня это не дубли, а обновление, а отличии от добавления). Около 90% времени занимает запись в базу. Загрузка идет пакетами по 500-1000 записей. Для выборки на изменение пакет размером 1000 записей грузится во временную таблицу, затем выполняется запрос. Такая проверка на дубли занимает 1% от всего времени.

У тебя регистр, а не справочник, поэтому можно попробовать грузить пакеты, а не по одной записи, как у меня.

+(71) Все тесты делались на моем ноутбуке, для хорошего сервера будет быстрее.

(71) у вас тоже из SQL была промежуточная выгрузка в файл? Нет?
Тогда почему вы утверждатете, что это одно и тоже при том, что чтение из txt занимает у 1с чудовищно много времени?
это окромя обработки такого количества, о чем мы выше спорим )

(73) чтение из txt было построчно или сразу весь прочитали?

(69) именно, что в реляционных СУБД хранятся избыточные данные (создается, к примеру, вместо одной таблицы - три, где связи между данными и назначение таблиц определяется ключами-идентификаторами), но это позволяет мгновенно находить нужное.
1с же "откапывает" из-под слоев ссылок то же самое, тратя время на обработку раскопок. Это занимает меньше места в базе (ссылки же везде), но удлиняет и усложняет обработку - кроме непосредственного распутывания клубка еще надо и проверять корректность типов извлекаемых данных, всякие там проверки делать...
(74) если вы подразумеваетет под "сразу весь прочитали" Файл.Открыть - то открывается сразу и весь.
А читается все равно посторочно, а как иначе? Вы как полученные строки обрабатываете - 1с сама распределяет данные, куда заблагорассудится? )))

+ вернее, там Файл.Прочитать... но не суть важно...

(73) Нет, чтение было сразу из SQL, но через VPN, прокинутый по интернету :)
Я не утверждаю, что это одно и то же.
Но если честно, сомневаюсь, что такая простая операция, как чтение из TXT (с локального диска!) может заметно тормозить все дело. Если тормозит - это повод для анализа. Может, он читается построчно или целиком, но не помещается в память или что-то в этом роде? Может, стоит его читать через ADO?

(73) Какой объект использовался - ТекстовыйДокумент? Что конкретно тормозит - ПолучитьСтроку?

(71) по отладчику запись занимает 60% времени.
(73) файл читал способом ПрочитатьСтроку(). Текстовик весит 20 метров. Читать целиком побоялся.
(77) Памяти 3гига, из них винда и прочие отъедают меньше одного. Основная проблема видится именно в записи.

(77) это как через ADO? текстовый файл он не предоставляет механизма доступа к самому к себе ))
Тормозит стандартная 1с-я команда Прочитать-Текстовый-Файл (давайте не будем гонять меня в конфигуратор и искать, как она там выглядит :)

(80) у кого тормозит команда ПрочитатьФайл?

(78) ну конечно тормозит не открытие файла, а построчное чтение. И строки вы как еще получатете из текстового файла?

Если написать ОбменДанными.Загрузка=истина и отключить использование итогов то в 1с запишется быстрее. )
(82) ну вот. )

(83) а как иначе? ))
какой ОбменДанными с текстовым файлом, простите? ))

(84) причем тут текстовый файл уже, я про запись в 1с. )

(83) у меня регистр сведений - итогов нет. В каком месте надо писать по Вашему ОбменДанными.Загрузка?

(79) - 60%? Это через менеджер записи? А через набор - быстрее? (Хотя бы просто попробовать, пусть с дублями для начала). Дубли отсечь - просто, уже написал как.
(80), (82)
Текстовый файл с разделителями можно открывать через микрософтовские источники данных как таблицу. Сам не пробовал, это просто как идея, может это будет хуже.
То есть, у тебя чтение из текста занимает больше времени, чем запись в 1С?
 Если честно, последовательное чтение текста - очень простая операция, ну не должна она тормозить.

(0)-(83)
А что такое миллион строк в прайсе?  Вы представляете себе ассортимент товара такой компании? Там менеджеры продаж повесятся или сбегут.
Даже в современном самолете боинге "дрим лайнере", всего 90 тысяч полуфабрикатов и материалов по 2 тысячам поставщиков.

Автор у вас там что? Весь РосАТОМ или весь РосКОСМОС.
Зачем придумывать задачи которые никому не нужны!!!
Если вам нужен анализ, то поставьте себя на место пользователя, для которого вы ВЫДУМАЛИ и РЕАЛИЗОВАЛИ возможность анализа цен по миллиону записей и десятку аналитик.

(85) в (9) из текстового файла грузится

а про запись в базу - это с (71) поста началось, мы более общие вопросы обсуждали ))

(87) ексель откроет и правильно распределит 20мб текста? сомнительно....

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

(87) >>  Если честно, последовательное чтение текста - очень простая операция, ну не должна она тормозить
а в 1с пошли своим путем ))

(71) +1

(92) наверное, ВЫГРУЖАТЬ нужно будет только изменившиеся позиции ))

(88) Ассортимент не представляю, он передо мной, более полмиллиона :)
Это справочник номенклатуры моего клиента. Чем занимается клиент говорить не буду, но ты задумывался, сколько номенклатурных позиций, например в справочнике яндекс-маркета? :)

(94) я не понял шифровку - +1 как относится к оптимизации? ))

(88) количество деталей, производимых концерном VAG составляет более 6 миллионов позиций. Из них в РФ поставляют чуть меньше трёх. С учетом характеристик ЛКМ получается очень весомо. Попрошу не оффтопить и не хамить.

(95) +1

А вообще вопрос о том, как оптимизировать загрузку большого количества значений в регистр сведений. Вернее как оптимизировать запись всего этого в БД.

(97) да какая разница, прайс это или не прайс.
Если клиент БУДЕТ оперировать такими данными, готовьтесь к текучке 1с-админов-программистов.
Ибо еще НИКТО не заставил 1с обрабатывать огромные объемы и не подавиться ))

100

(98) >> как оптимизировать загрузку большого количества значений
если отсечь чисто организационные (порции, нерабочее время), то только выбросить промежуточную выгрузку и заставить базу-источник предоставить ADO-COM.
Больше вариантов не вижу.

Таки никто? А если писать напрямую, а не через механизмы 1с?

(98) Хранить отдельной таблицей в скуле. Запись в 1с никак не оптимизируешь. Еще раз говорю - 6 миллионов - это постоянные детали с постоянными характеристиками. Их нужно записать только один раз.

(102) напрямую куда? а 1С их как читать будет?
(103) а 1с как их пользовать будет?

(104) Напрямую в скл. Или ты думещь, что 1с делает это иначе?

(104) Например во вспомогательную скульную базу. 1с без проблем с этим работает.

(105) да уж, 1с-программситы такие затейники, из любой базы в SQL кинут ))
>> что 1с делает это иначе
именно что 1с делает (точнее, 3х уровневая система), а не пользователь напрямую ))
(106) опять же: обработка?
и как 1с будет номенклатуру брать - в SQL ссылки давать? ))

(107) то есть ты не умеешь напрямую создавать 1с-объекты в скуле. Так и запишем.

(108) ага, т.е. вы напрямую получаете ссылку на Номенклатуру и саму номенклатуру? Минуя 1с-сервер? так и запишем.

(109) Заканчивай ламерить... Ты уже поддостал...
Кто мешает создать запись в скуль-таблице и получить её ид? Я подскажу, что...

(101)
Так я подсказал же вариант - писать через набор записей пакетами на добавление, дубли отсекать до записи. Что бы выяснить целесообразность такого пути, нужно попробовать, насколько быстрее запись пакетами на добавление. Это делов на 20 минут. Если выяснится, что это, скажем, в 5 раз быстрее, то примерно во столько же раз можно ускорить эту байду. Без всяких прямых доступов к базе и прочее.

вносить прямо в скуль уже предлагали? 1с и по быстрому - вещи не совместимые

(11) и всю конфу переписывать под поиск и использование ИД записей скуль-базы, потому что ты так сказал?
ну-ну
я уж не говорю о том, что при переиндексации меняются ИД строк (наверное, ты хотел про ключ сказать?).

(112) мечтатели вы, господа ))
1с свой сервер придумывала для прямого чтения/записи в SQL без его участия? ))

(102) Ты что, это же нелицензионно! :D

(114) гы... ты думаешь сервер приложений делает с данными нечто высокоинтелектуальное?

(115) наличие этой строчки в лицухе 1с всегда потешало

записывай в наборе по 1000 записей, перед добавлением проверяй на дубли

(115) Если это отдельная база данных в скуле - это что в этом нелицензионного? Рарус во всю юзает для обмена.

(118)+ перед добавлением отключи индексы для этого регистра сведений, потом обратно включишь и переиндексируешь

+ (118) Делал в наборе по 10 000 записей, всего по подсчетам получалось около 5 000 000 записей, и ничего. тога прочитать потом сложновато.

(118)+ перед добавлением в наборзаписей проверять на дубли, а не в регистре

(119) Речь не про отдельную базу.

(111) Еще в порядке бреда. Добавить в регистр измерение а ля счетчик, писать с дублями, резать дубли после загрузки.

(119) >> Рарус во всю юзает для обмена.
именно для обмена. Т.е. данные все-таки загружаются позже в 1с-базу.
(116) я думаю, что сервер записывает данные в такой структуре, которая читается средствами 1с потом, а не прямым обращением к SQL из конфигуратора.

(0) откажитесь от регистра сведений, сделайте справочник без кода и наименования

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

(126) не поможет, все равно часами будет миллионы строк гонять...

(113) я где-то сказал про ид строки? Где????

(124) Соответствие ГУИД-ов двух баз (с наименованиями) хранится в третьей и редактируется через обработку. В обработке доступны все команды обычного SQL update,delete,insert. Ну так пиши свою обработку и храни хоть сто миллионов записей. А уж что ты сними делать будешь - дело твое.

(124) А что мешает писать напрямую именно в такой структуре?

+(130) Ну, кроме ЛС, конечно ;-)

(4) Насмешил. Особенно если учесть что есть биллинг на 1с.

(130) что писать - типовую? ))
(129) а что мешает тогда продвинуть идею подключаться сразу к базе источнику и оттуда брать все данные?
>> Соответствие ГУИД-ов двух баз (с наименованиями)
на одном конце - миллион записей, на другом (1С) - нет ничего (ничего ведь не перегружаем). Соответствие между чем и чем будет?

(132) читай (32)
биллинг-то знаешь как работает? там данные за прошлый месяц можно сразу отрезать и в архив отправлять. Месяц прошел, если деньги заплатили - никому эти данные больше не нужны.
что же с вами будет еще через 5 лет.... страшно становится...

(134) Не говори сказки . Как можно обрезать если глубина перерасчета 3 года в коммуналке?

(135) Мало того что знаю как работает , так один в общем написан. Который сейчас работает на миллионе абонентов.

(136) тогда к (32)

(137) Аналитика не позволяет использовать виртаульные таблицы. Подумываем отключить итоги , отчеты выдает за секунды .Что делаем не так?

(133).1 Ээээ ... при чем тут типовая? Ты за нитью разговора вообще следишь? Еще раз, что мешает писать данные напрямую в sql-ную базу в том самом формате, в котором их пишет 1С?

(138) Вы всё делаете не так. Вам же сказали, 1С не предназначена для нормальной работы. Если ваша программа написана на 1С, то она не может работать, не может, не может, не может.

(138) опять ВТ...
у вас либо данных мало, либо суперкомпьютер стоит, а не сервер.
Я спецом проверял на десятках тысяч записей свои запросы: делал идентичные, разница - одни на ВТ, другие суммированием (ес-но, где можно было сунуть ВТ, т.к. и это очень и очень ограничено к применению); в 40% разницы между ВТ и обычным обращением нет (составляло доли секунды по замерам).
Не говоря уже про примеры выше.
У 1с тоже в презентациях все прекрасно.
Но что-то с внедрениями капец полный. Или никто виртуальныные таблицы не использует? принципиально?

+ да, где ВТ давало наибольшей эффект, было не мгновенно, а всего раза в полтора быстрей - вполне соизмеримо.

(141) Ладно ,верю верю .

(46) > Мильен записей  записать- это и в Африке мильен записей
Немного оффтоп: на Оракле (да,да,на "дорогом атомобиле") каждую ночь обрабатывается ~90млн.записей, происходит их АГРЕГАЦИЯ, запись/обновление ~15млн.записей.
Самая большая таблица приближается к 3,5млрд. записей (растет на 7.5млн/ночь).
Это дело занимает ~4-8часов времени

(144) + аВтомобиле *

(144) 7.5 млн за ночь , какой же этот Оракл тормозной )))))

(146) если есть предложения ускорения, РАБОТАЮЩИЕ предложения, буду только за )))

(147) Я не буду делать рекомендаций и выводом без обследования системы.

(0) ускоряется элементарно, весь регистр сведений читается в тз, в тз добавляется строки из загружаемого файла,тз сворачивается по измерениям и записывается в регистр. тысяч 120 строк проводок бухгалтерского регистра на нормальном сервере записываются за 15 минут, с регистром сведений всё будет намного быстрее. Мишу Лажаагра можешь не слушать, он года два сопли размазывает по форуму, никак 8 не выучит.

(149) Если делать на сервере , то взлететь может . А на толстом клиенте можем упереться в 2 гига.

(144) я базульку 30гигов копирую за 40 минут на скуле, без аггрегаций, но с отбором. это порядка 30млн записей во всякие физические таблицы...
чтото гдето не так ИМХО..

(151) т.е. простой insert .. select .. where .. ?

без маппингов, staging area и т.д.. ?

(151) т.е. у тебя "репликация" / разовая операция / ETL ?

(151) копируешь каким методом?
в журнал транзакций что-то пишется?

(149) Спасибо, примерно так и сделал - скорость записи увеличилась ровно на порядок.

(149) ага, так ну их эти регистры вообще - давайте все в ТЗ и в память??
1.2 млн записей : 120 = 10
15мин х 10 = 150 мин, реально 3 часа.
Да, теперь клево, за смену управимся. Главное, не давать базе распухать.
Это если еще хватит памяти под передачу 120 тыс строк на "нормальном сервере".
А что уж не лабораторные исследования 1с - у них вообще за 20 минут все гоняется-обрабатывается.
Только чаю попить.

Всем привет.

Опять баяны трете? А в поиск ходили?

(158) Привет.
Так кто же их пошлёт...

ну не читают "старожилы" баяны ))
или забыли уже ))

(155) копирую из одной базы в другую средствами скуля без нихто и то с включенными индексами.
правда диск "быстрый" =) но на базу в несколько лярдов записей медленные диски - это извините извращение

(161) ничего, что у вас SQL напрямую сам с собой работает, да еще и системы хранеия (да и сервера наверняка) оптимизированы? ))

(162) для тех кто в танке мы обсуждаем оракл и 15млн записей за 8 часов.

На Инфостарте О-Планет как-то писал статью, как он в файловой 1С 7.7 автоматизировал лотерею. Если это не фарс, а задача, смотрю, сходная, можно поискать оное.

(163) для тех, кто под танком: кто будет писать взаимодействие между оракл и SQL??
и еще, кто совсем под танком: в основном обсуждается запись в 1С-БАЗУ.

(165) дааа.. танк совсем непробивной =) общались не с тобой про оракл/скуль (не взаимодействие, а производительность этих СУБД), ты влез.. тебе оно надо?

Успокойтеся, у нас не просто запись в таблицы Оракл/МС-СКЛ, как у Акселя.
У нас ETL, что подразумевает и staging и маппинги и проверки и агрегацию (суммы, нумерация, и т.д.) и конечно же индексы и констрейнты на хранилище.
Также переливка данных идет не локально на сервере, а через дблинк с другого серва.