Впервые сталкиваюсь с такими объемами информации, нужен совет.
Есть база оракловская, в ней 250 таблиц, самая большая из них содержит 24 миллиона записей, вторая по размеру 20 миллионов и т.д., всего записей во всех таблицах - 220 миллионов. В одной таблице содержится список абонентов (60000 записей), остальное - это связанные с ними данные, а также данные о платежах (по каждому абоненту один платеж в месяц, 12 месяцев, 5 лет = 3600000 документов). Основная суть задачи - перетащить в 1С справочник абонентов и данные о платежах за все 5 лет.
Как лучше это сделать? Внешние источники использовать? Может, возможно делать прямые запросы к ораклу и вытаскивать сразу сводную информацию, собранную в оракле запросом к нескольким таблицам с объединением?
Беда еще в том, что административного доступа к базе нет и не будет, сделать копию базы невозможно, надо тянуть все из живой базы, находящейся в работе. Есть возможность сделать запрос к каждой таблице типа select * from <table_name>, но можно ли будет потом сохранить куда-то результат этого запроса, если там 24 миллиона строк?
Может прокатит вариант создать в 1С зеркальный слепок всех таблиц оракла в виде 250-ти регистров сведений, перекачать все туда из оракла и работать потом с этими регистрами, создать в базе все необходимые справочники и документы и потом грохнуть эти регистры? Но сможет ли 1С переварить такие объемы данных?
Помогите советами, в общем. А то не знаю, с какой стороны начать съедать этого динозавра.

Думал еще над вариантом создать в оракле (если права позволят) промежуточную сводную таблицу (или несколько таблиц), заполнить их нужными данными запросами через интерфейс оракла и потом уже из этих таблиц тащить только нужные данные в 1С.

(29) OPENROWSET относиться к Microsoft Transact SQL и к OLE "обычно", имеет мало отношения.

(31) Зачем?!

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

(32) Я б на MS SQL делал.

(31) Имахется мне, что текстовый файл с 24 миллионами строк прожевать не получится.

(33) я наверно плохо читаю "Содержит все необходимые сведения о соединении, которые требуются для доступа к удаленным данным источника данных OLE DB. Это альтернативный метод для доступа к таблицам на связанном сервере и является однократным нерегламентированным методом соединения и удаленного доступа к данным с помощью OLE DB."

(37) полчуться-то получится, только зачем, опять таки.

(35) Ну вот думаю над вариантом (32). В итоге получим 60000 записей в таблице с абонентами и 3.6 миллиона документов.

Добавь Внешние Истточники Данных к этой Оракловской базе, и просто показывай в 1С таблицы и вьюшки. в динамическом списке

(39) ну надо заказячику, что вы пристали, посмотрит как это тормозитв 1С и дальше будет искать решение

(38) OLE DB не совсем тоже самое что и просто OLE.
Можно использовать ODBC так же.

2(40) Сводная таблица будет на самом деле вьюхой? И у нее будет запрос? Ну так просто выполни этот запрос через АДО, получи эти 60 тысяч записей и загрузи в регистр сведений.

(41) если ораклская БД не оптимизирована, то без десятков соединений для простого отчета не обойтись. А это - минуты на вывод отчета

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

(46) MS SQL DTS

(0) Для начала может слегка подумать головой и решить а зачем нужны все эти данные в 1С ?

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

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

(47) Это что-то вроде "я создаю пустую базу SQL, подключаюсь из скуля к ораклу и перетаскиваю все в скуль"?

(48) текстовый файл умрет и не откроется после первого миллиона строк

(49) Ну да, в первую очередь хочется именно этого, чтобы уже потом со своей базой работать спокойно.

(52) Ну так перекачивай. Зачем тебе для этого посредник типа 1с?

(48) Ой, как-то мы до тебя не догадались подумать головой. Спасибо, сейчас все выгрузим в текстовые файлы!

(51) Смотря сколько "весит" строка

(53) 1С в итоге должен стать конечным потребителем этих данных, не посредником. Я просто в серверах, скулях и ораклах не мастак, поэтому задаю тупые вопросы.

(50) вариант: из Оракла перетащить сразу в скуль в нужном формате для дальнейшего подключения и работы с 1С - выглядит неплохим)

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

(0) Есть знакомый спец по Ораклу. Могу дать контакт.

(59) Спасибо, давай, lazarenkoyv<sobaka>майл.ру

(0) кстати, перетащить разово или потом онлайн обмен?

А так несколько лямов записей для 1С не проблема. Если конечно, это не записи регистра бухгалтерии )

(61) Перетащить разово

(63) тогда в разы проще)

(63) ты пока запусти в скуле визарда импорта данных, пока тебя не закрыли ))

(0) Да вы, батенька, извращенец!  Зачем всякую фигню пихать в 1с? Обычное порево уже не устраивает? Нужно "жосткое порно"?  Цепляйся через внешнее и анализируй что нужно.

+(63) Про старую базу потом забываем, потому что ее разраб забил, не развивает, не поддерживат и вообще козел.

(66) База в любой момент может перестать работать, в любом случае надо сначала перекачать в промежуточную базу. А потом - возможно варианты: или перекачать все эти документы с платежам на 5 лет, или загрузить только остатки на начало 2016 года и по мере необходимости заглянуть в прошлые годы обращаться к промежуточной базе и отображать данные из нее.

(37) Читал по диагонали?

(51) Смотря как открывать.

(67) Если биллинг в старой базе- хрен вы про нее забудете.

(60) Сбросил ему сцыль на эту ветку.

(51) какая то детская отмазка ))

кто заставляет этот текстовый файл блокнотом то открывать?
причем лучше в несколько файлов писать по 10к строк к примеру или еще как оптимальнее
и потом из них загружать

(66) + 146
(68) что значит может перестать работать???

Кстати вы в файловый вариант 1с хотите перекачать? И в 1с какую 7.7? В дбф? ;)))))

(72) Заназачем эту муйню делать через текстовые файлы, когда штатный импорт мсскл слопает это и не подавится?
Что ж 1сники все через то место, откуда гланды удаляют, пытаются делать?...

(68) вас, наверно, шокирует слово "миллион". Просто надо работать, не обращать внимание на эти выкладки. До 1млн. записей - это вообще ни о чем - деский сад. 20-50 млн как бы средний размер. Ну у вас 220, ну и что?

(74) У штатного импорта есть проблемы с некоторыми типами данных. Плюс незачем место в скульной базе занимать ради разовой операции. Но можно и так, на выбор ТС.

(69) Не могу понять, зачем текстовые файлы, если есть скуль?

(74) может почитаем внимательнее посты ТС?

если бы был постоянный доступ к этой базе оракла и надолго то грузите вы как хотите

(71) Спс

(77) см (78)

(73) В "шестерку" конечно, жестить - так по полной.

(80) :) смешно получилось

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

вообщем сначала утащите целиком базу, потом уже думать можно и пробовать как лучше

(81) Разве это "жестить"?
Вот распечатать, калькулятор, ручку и тетрадку - вот это "гулять, так гулять" :))))

(76) Ну так мы выгрузим в промежуточную скулевую, чтобы отвязаться от РАБОЧЕЙ, в которой постоянно что-то делается, в этой скулевой создадим сводные таблицы, в которых будет находиться только необходимая нам информация, остальное грохнем. Дальше что надо - перекачаем в 1С (справочники абонентов, их техники и т.д.), остальное сможем получать запросом по необходимости. Нормально же?

(78) Может, ещё повнимательней почитаем? Нужна разовая выгрузка

(83) Точно, у меня ж МК-61 где-то в кладовке лежит )

(73) у них же там записи не как в 1с, где в документе 55 реквизитов. Там в записи наверняка 3-4 поля номер, дата и сумма.

То есть если берем в записи например 30 байт, то размер базы 220 000 000 х 30 = 6,6 гиг. Вполне влезет в файловую.

(84) спорим что сразу через "текстовые файлы" из оракла в 1С будет быстрее чем через промежуточную скулевую ?

т.е. делаем полную выгрузку из оракла, а в 1С сразу грузим что нужно и сколько нужно

(87) Именно так. Данные об абонентах, например, там раскиданы по 10 таблицам.

правильно понимаю, что операция переноса разовая, но работать в режиме билинга 1С будет и после переноса?

(0) Если не хочешь своими запросами повесить рабочую бд, то требуй, чтобы тебе сделали готовые сводные вьюхи с абонентами. Как они будут делать уже не твоя забота. Твоя задача сводится тупо к обращению к вьюхе через адо. Без разницы сколько там записей.

(91) у него разработчику плохие, пошлют

(92) Как общаться, чтобы не посылали, а выполняли поставленные задачи - это уже вопрос за гранью мисты)

(0)а чо сразу 220 миллионов? абонентоа 60000 по 200 байт да 3600000 документов по 100 байт на каждый. быстро выгружай в текстовый файл и на флешку. в 1с будет долго, но если работа почасовая, то это даже хорошо.

Взять бэкап базы оракла и развернуть у себя.

(90) Верно

(91) Я там не могу ничего требовать, мне дали оракловскую базу без админского доступа и конфу 1С с пустой базой. Через немного месяцев 1С должна будет делать то, что раньше делал оракл. Сотрудник заказчика пока что не может мне даже сказать, какого размера у них текущая рабочая база и как ее забэкапить. Вот как-то так.

(84) Нормально.

все эти жеки .. муторные конторки .. вот зачем то решили прикончить оракл .. будут мучать пенсионеров 1с.

будет как в сбере - электрическая очередь расчетов

(0) не надо грузить в 1с

(99) Разраб сидит на территории Украины, им работать с крымчанами заподло. Так что вариантов нет.

В общем, картина ясна, стратегия обозначена, спасибо, коллеги!

(103) чё делать то будешь?)

(102) ну тогда надо сносить к черту этот вражеский оракл. Я просто имел подобный опыт рядом с Москвой .. там был серпентарий ..и на пару порядков меньшие объемы , но настроение и все эти схемы этим то а этим се отвращали.

(104) Импортнем базу в скуль.
Определимся, какие данные из разных таблиц нам нужны, создадим для них сводные таблицы, методами скуля заполним эти таблицы.
Все лишнее грохнем,чтобы место не занимало.
То, что должно быть в 1С (справочники абонентов, оборудования и т.д.) перекачаем.
Перенесем остатки взаиморасчетов на начало 2016 года в 1С.
Новые документы по биллингу будем создавать в 1С, старые смотреть через внешние источники, путем подключения к скулю.

С помощью SSIS легко. Писать сразу в таблицы справочника 1С.

(106) все вроде ровно

дай доступ нам, мы поможем, пока админ не прикрыл базу :)

(108) )))
(109) Та не, пока справляемся вроде )

Возможно чуть не в тему, но делал как-то проверку по базе недействительных паспортов ФМС. Там увесистый такой файлик.
Загрузка в РС - долго, а она ежедневно делается. Ну, думаю, в MS SQL залью, из 1С прицеплюсь. Фиг там, у клиента MS SQL лицензионно урезанный - только для 1С можно использовать.

И теперь вопрос. Вот тут в топике большая таблица. У меня тоже, плоская. А если бесплатный PostgreSQL использовать? Будет ли это медленнее РС в 1С на MS SQL? Есть у кого-то опыт?

(43) Зачем OLE если можно писать напрямую?

(37) Пережует и не подавится. https://technet.microsoft.com/ru-ru/library/ms190312(v=sql.120).aspx

Смотри Bulk операции

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

(49) +1

(114) а что будете делать с новыми записями, которые будут писатся пока будите перекидывать инфу?

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

(114) OPENROWSET позволяет работать с любыми источниками. Что проще то и выбирай.
24 миллиона это по нынешним мерам мелочь. Другое дело, что индексы могут тормозить при записи

118+ Ну и при обновлении данных смотри в сторону Merge

(119) Хорошо, буду смотреть в сторону Merge. Скорее всего, я для данного процесса просто привлеку специалиста по базам )

(111) Если прямыми руками делать, будет быстрее.

Делал как-то подобное на Оракле. Загрузка файлика во временную таблицу, затем FULL OUTER JOIN с основной, получаем разницу, и ее INSERT/UPDATE в цикле.

Очень трудоемко, но можно все сделать. Я бы попробовал так: 1. Берём 1 большую таблицу оракла. Создаём базу 1с в управляемом режиме блокировками. Делаем регистр сведений - копию этой таблицы, подобрав измерения и ресурсы по типам. 2. Базу размещаем на быстром и надёжном ссд, конечно же серверный вариант. 3. Пишем коннектор к ораклу, который будет выбирать из таблицы оракла по 100 тыс записей. Надо только придумать, как не выбирать повторно уже выбранные ранее. Эти 100 тыс записей в 1с, делим на порции по 10 тыс и пишем параллельно. Асинхронный код, то есть, каждые 10 тыс пишет свое фоновое задание. 4. Весь процесс заворачиваем в регламент задание. 5. Сидим пьём чай, пока таблица копируется. 6. Повторяем тоже самое для следующей таблицы.

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

Потом в 1с можно нарисовать формы "архивных" документов, где выводить данные из регистров сведений, с отборами. Это чтобы потом уже из регистров не переносить данные в документы.

Если колонка в таблице оракла - это ссылка на другую таблицу,то предварительно создать в 1с справочник, выбрать все различные ссылки из оракла, записать в справочник 1с. То есть сначала создаём копию ссылочной целостности структуры оракла, потом заполняем таблицы регистров. Как-то так... Должно взлететь, мне кажется

Я уже потерял суть рассуждений.
Сдается мне надо декомпозировать задание.
1. надо разработать структуру БД в 1С
2. Надо забрать данные из оракл
3. Надо убедиться в работоспособности и приемлемой скорости работы 1С на таких объемах.


Самый простой вопрос №2.
&НаКлиенте
Процедура ЗагрузитьПоступления(Команда)
    Объект.ТаблицаДокументов.Очистить();
    Объект.ТаблицаТоваров.Очистить();
    
#Область ПодключениекБазеСупермаг
    ИмяБазыСуперМаг             = "sm";
    ИмяПользователяСуперМага     = "sm";
    ПарольПользователяСуперМага = "sm";

    
    Состояние("Подключение к базе..");
    СтрокаСоединения =
    "Provider=MSDAORA;"+
    ";Password="+сокрЛП(ПарольПользователяСуперМага)+";"
    ";User Id="+сокрЛП(ИмяПользователяСуперМага)+ ";"+
    "Data Source="+СокрЛп(ИмяБазыСуперМаг)+
    ";Persist Security Info=True;";
    
    
    Подключение = Новый ComObject("ADODB.Connection");
    Подключение.ConnectionString=СтрокаСоединения;
    
    Попытка
        Подключение.Open();
        Состояние("Подключение к серверу Супермаг...");
        Сообщить = ("На связи "+ИмяБазыСуперМаг);
    Исключение
        Сообщить(ОписаниеОшибки());
    КонецПопытки;
#КонецОбласти

#Область ЗагрузкаДанныхСуперМага
    Command = Новый COMОбъект("ADODB.Command");
    Command.ActiveConnection = Подключение;
    RecordSet = Новый COMОбъект("ADODB.RecordSet");

    
    НачДата = ПолучитьДатуСКЛ(Объект.ДатаЗагрузки);
    Кондата = ПолучитьДатуСКЛ(Объект.ДатаЗагрузки);
        ТекстУсловияПоДате ="
        |    (
        //|     (to_char(SUPERMAG.smdoclog.eventtime, 'RRRR:MM:DD') >= '"+НачДата+"' and to_char(SUPERMAG.smdoclog.eventtime,'RRRR:MM:DD') <= '"+КонДата+"')
        //|        or     
        |      (to_char(SUPERMAG.smdoclog.docdate,'RRRR:MM:DD') >= '"+НачДата+"' and to_char(SUPERMAG.smdoclog.docdate,'RRRR:MM:DD') <= '"+КонДата+"')
        |    )  ";

    Состояние("Выполняется запрос..");
    ТекстЗапроса = "SELECT ALL SUPERMAG.FFMAPREP.SALETYPE as DOCTYPE, SUPERMAG.FFMAPREP.SALEID as DOCID, SUPERMAG.FFMAPREP.INCOMEID as INCOMEID, SUPERMAG.FFMAPREP.INCOMEDATE as INCOMEDATE,
            |SUPERMAG.SMWAYbillsIn.SUPPLIERINVOICE as SUPPLIERINVOICE, SUPERMAG.SMWAYbillsIn.SUPPLINVOICECREATE as SUPPLINVOICECREATE, SUPERMAG.SMWAYbillsIn.SUPPLIERDOCCREATE as SUPPLIERDOCCREATE,  SUPERMAG.SMWAYbillsIn.SUPPLIERDOC as SUPPLIERDOC,
            |SUPERMAG.FFMAPREP.SALELOCATIONFROM as Склад, SUPERMAG.FFMAPREP.SALELOCATIONTO as СкладВ, SUPERMAG.FFMAPREP.SALEDATE as CREDATE,
            |SUPERMAG.FFMAPREP.SALECLIENTINDEX as SUPPLIER, SUPERMAG.SACardClass.Tree as Узел,
            |SUPERMAG.FFMAPREP.SALESUM as Всего, SUPERMAG.FFMAPREP.SALEQ as Колво, SUPERMAG.FFMAPREP.SALENOVAT as Сумма, SUPERMAG.FFMAPREP.SALEVATRATE as СтавкаНДС, SUPERMAG.FFMAPREP.PRIMECOST as ВсегоСебест,
            |SUPERMAG.FFMAPREP.PRIMECOSTNOVAT as СуммаСебест, SUPERMAG.FFDOCUMENTS.USEROP as ПользОпер, SUPERMAG.FFDOCUMENTS.SUPPLIERINVOICE as INVOICE,
            |SUPERMAG.FFDOCUMENTS.SUPPLINVOICECREATE as SUPDATA, SUPERMAG.FFDOCUMENTS.SupplierDoc as NAKLAD,
            |SUPERMAG.SAOperation.NAME as Операция,
            |SUPERMAG.SMClientInfo.ID as SMClientInfoID, SUPERMAG.SMClientInfo.NAME as Имя, SUPERMAG.SMClientInfo.INN as ИНН, SUPERMAG.SMClientInfo.KPP as КПП,
            |SUPERMAG.SMClientInfo.PASSPORT as Паспорт
            |FROM SUPERMAG.FFMAPREP, SUPERMAG.SAOperation,SUPERMAG.SMCARD, SUPERMAG.SACardClass, SUPERMAG.FFDOCUMENTS,
            |SUPERMAG.SMClientInfo,  SUPERMAG.SMWAYbillsIn
            |where
            | SUPERMAG.FFMAPREP.SALEID in
            |    (
                |SELECT SUPERMAG.SMDOCLOG.ID FROM SUPERMAG.SMDOCLOG,SUPERMAG.SMDOCUMENTS
                |WHERE (SUPERMAG.SMDOCUMENTS.ID = SUPERMAG.SMDOCLOG.ID)
                |and"
                +ТекстУсловияПоДате+"
                |and (SUPERMAG.SMDOCUMENTS.ID = SUPERMAG.SMDOCLOG.ID)
                |and (SUPERMAG.SMDOCLOG.NEWSTATE=3)
                |and (SUPERMAG.SMDOCUMENTS.doctype in ('WI','WO'))
                |and (SUPERMAG.SMDOCUMENTS.doctype=SUPERMAG.SMDOCLOG.doctype)
                |and (SUPERMAG.SMDOCUMENTS.OPCODE in (0))
                |and ((SUPERMAG.SMDOCUMENTS.LOCATIONFROM in (2) )or (SUPERMAG.SMDOCUMENTS.LOCATIONTO in (2)))
                |    )
                //|and (SUPERMAG.SMWAYbillsIn.SUPPLIERDOC = '12755')
                |and (SUPERMAG.SMWAYbillsIn.ID = SUPERMAG.FFDOCUMENTS.ID)
                |and (SUPERMAG.SMClientInfo.ID = SUPERMAG.FFMAPREP.SALECLIENTINDEX)
                |and (SUPERMAG.FFMAPREP.RECTYPE=1)
                |and (SUPERMAG.FFMAPREP.SALEID=SUPERMAG.FFDOCUMENTS.ID)
                |and (SUPERMAG.FFMAPREP.SALETYPE=SUPERMAG.FFDOCUMENTS.DOCTYPE)
                |and (SUPERMAG.FFDOCUMENTS.OpCode=SUPERMAG.SAOperation.ID)
            |and (SUPERMAG.FFMAPREP.ARTICLE=SUPERMAG.SMCARD.ARTICLE)
            |and (SUPERMAG.SMCARD.IDCLASS=SUPERMAG.SACardClass.ID)
            |order by SUPERMAG.FFMAPREP.SALEID";    
    Command.CommandText = ТекстЗапроса;
    RecordSet = Command.Execute();
    
    Состояние("Выполняется обработка..");

    МассивДляПередачиНаСервер  = Новый Массив;

    Пока RecordSet.EOF() = 0 Цикл
        СтруктураДляПередачиНаСервер = Новый Структура;
        СтруктураДляПередачиНаСервер.Вставить("DOCTYPE"             , RecordSet.Fields("DOCTYPE").Value);
        СтруктураДляПередачиНаСервер.Вставить("DOCID"                 , RecordSet.Fields("DOCID").Value);
        СтруктураДляПередачиНаСервер.Вставить("INCOMEID"             , RecordSet.Fields("INCOMEID").Value);
        СтруктураДляПередачиНаСервер.Вставить("INCOMEDATE"            , RecordSet.Fields("INCOMEDATE").Value);
        
        СтруктураДляПередачиНаСервер.Вставить("SUPPLIERINVOICE"     , RecordSet.Fields("SUPPLIERINVOICE").Value);
        СтруктураДляПередачиНаСервер.Вставить("SUPPLINVOICECREATE"     , RecordSet.Fields("SUPPLINVOICECREATE").Value);
        СтруктураДляПередачиНаСервер.Вставить("SUPPLIERDOCCREATE"    , RecordSet.Fields("SUPPLIERDOCCREATE").Value);
        СтруктураДляПередачиНаСервер.Вставить("SUPPLIERDOC"            , RecordSet.Fields("SUPPLIERDOC").Value);
        
        СтруктураДляПередачиНаСервер.Вставить("Склад"                 , RecordSet.Fields("Склад").Value);
        СтруктураДляПередачиНаСервер.Вставить("СкладВ"                 , RecordSet.Fields("СкладВ").Value);
        СтруктураДляПередачиНаСервер.Вставить("CREDATE"                , RecordSet.Fields("CREDATE").Value);
        СтруктураДляПередачиНаСервер.Вставить("SUPPLIER"             , RecordSet.Fields("SUPPLIER").Value);
        СтруктураДляПередачиНаСервер.Вставить("Узел"                 , RecordSet.Fields("Узел").Value);
        СтруктураДляПередачиНаСервер.Вставить("Всего"                 , RecordSet.Fields("Всего").Value);
        СтруктураДляПередачиНаСервер.Вставить("Колво"                 , RecordSet.Fields("Колво").Value);
        СтруктураДляПередачиНаСервер.Вставить("Сумма"                 , RecordSet.Fields("Сумма").Value);
        СтруктураДляПередачиНаСервер.Вставить("СтавкаНДС"             , RecordSet.Fields("СтавкаНДС").Value);
        
        СтруктураДляПередачиНаСервер.Вставить("ВсегоСебест"         , RecordSet.Fields("ВсегоСебест").Value);
        СтруктураДляПередачиНаСервер.Вставить("СуммаСебест"         , RecordSet.Fields("СуммаСебест").Value);
        СтруктураДляПередачиНаСервер.Вставить("ПользОпер"             , RecordSet.Fields("ПользОпер").Value);
        СтруктураДляПередачиНаСервер.Вставить("INVOICE"             , RecordSet.Fields("INVOICE").Value);
        СтруктураДляПередачиНаСервер.Вставить("SUPDATA"                , RecordSet.Fields("SUPDATA").Value);
        СтруктураДляПередачиНаСервер.Вставить("NAKLAD"                 , RecordSet.Fields("NAKLAD").Value);
        СтруктураДляПередачиНаСервер.Вставить("Операция"             , RecordSet.Fields("Операция").Value);
        
        
        СтруктураДляПередачиНаСервер.Вставить("SMClientInfoID"        , RecordSet.Fields("SMClientInfoID").Value);
        СтруктураДляПередачиНаСервер.Вставить("Имя"                 , RecordSet.Fields("Имя").Value);
        СтруктураДляПередачиНаСервер.Вставить("ИНН"                 , RecordSet.Fields("ИНН").Value);
        СтруктураДляПередачиНаСервер.Вставить("КПП"                 , RecordSet.Fields("КПП").Value);
        СтруктураДляПередачиНаСервер.Вставить("Паспорт"             , RecordSet.Fields("Паспорт").Value);
        МассивДляПередачиНаСервер.Добавить(СтруктураДляПередачиНаСервер);                
        
        RecordSet.MoveNext();
    КонецЦикла;
#КонецОбласти

    ЗагрузитьПоступленияНаСервере(МассивДляПередачиНаСервер);

КонецПроцедуры


Запрос к ораклу - строить можно через SQL plus

для ответа на 1 вопрос данных недостаточно - но для начала можно попробовать напрямую интерпретировать структуру из оракла в сопоставимые объекты 1С.

ответ на 3 пункт будет нужен по факту выполнения первых двух. Но могу предложить следующий вариант - загрузит 1 год а 1С и посмотреть на производительность - если позволяет грузить дальше, если нет - то грузить по годам.

Поскольку реально сводные данные за 5 лет нужно обычно по 1 абоненту - то можно сваять отчет который будет тянуть в разрезе одного абонента данные из 5 баз по СОМ.

(123) А по-моему все-таки запись в регистр будет узким местом.

Инари?

http://dist.1c.ru/docImages/1ConOracle.pdf
Если и имеет смыл то базы опять таки на самом oracle вести.

Как то нужно было из Firebird в 1С 7.7 перетащить данные.
Некоторые таблицы содержали до 10 млн. записей.
ТаблицаЗначений /точнее 1С/ такого количества не скушает за раз.
Поэтому в цикле загрузки таблицы выполнялся запрос с SKIP, позволяющий пропустить указанное количество записей
и FIRST /выбрать заданное количество записей/
Ну а дальше тривиально из ТЗ в цикле переносим данные в 1С.

ТекстЗапроса =
  "SELECT    FIRST " + cntRecAll +
  "
  |
  |          SKIP  " + VpSkipRec +
  "
  |          oplata.ls,
  |          oplata.opltype,
  ...

  НачатьТранзакцию();

  тзРезультат = СоздатьОбъект( "ТаблицаЗначений" );
  
  тзРезультат = ODBCRecordSet01.ВыполнитьИнструкцию( ТекстЗапроса, тзРезультат );
  
  VpОбКолСтр  = тзРезультат.КоличествоСтрок();

Про прямую запись в регистры сведений v8: _SimpleKey и его установка