Загрузить данные из базы oracle в 1С, 220 миллионов записей. #757119

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

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

Читай сразу сводную информацию для построения отчёта. Всю эту фигню в 1с грузить - не нужно.

а зачем?

Не угадал :) Основная суть задачи - перетащить в 1С справочник абонентов и данные о платежах за все 5 лет.

Основная задача поставлена некорректно. мы ж тут не все кодеры... Иногда и программисты, и даже постановщики задач, встречаются...

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

Вполне решаемо, конечно, но таки согласен с

не, ну у меня был на полтора миллиона абонентов биллинг. два РС. а проводки - сводные.

УИДы есть? если да то по тихоньку, пачками пиши по оле

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

у меня всё хорошо :)

Клиенту нужны остатки на начало 2010-го года и движения за 5 лет, таковы условия в ТЗ.

Как, простите? :)))))

Ему нужны остатки и движения, или таки отчёты по этим остаткам и движениям?

>таковы условия в ТЗ. переходите на что-то более легкое - героин например...

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

как обычно

В файловую БД наверняка не влезет.

... и как же это "обычно"?

да. Ты правильно понял. Чем в этом отношении оракл отличается от мсскл?

Нужны остатки на начало 2010-го года и все движения за 5 лет, в виде документов в 1С.

А что они с этими документами будут делать? Открывать и любоваться?

Средствами 1С замучаетесь тянуть движения.

Скуль поднимем, это не проблема. Я ж не в курсе, поэтому и уточняю. А то напридумываю сейчас вариантов выполнения задачи, а окажется, что они принципиально не рабочие.

OPENROWSET и прямая запись

Нет, отвечать абонентам, почему у них сегодня такой долг - "потому что 3 года назад у вас вот там недоплата", поэтому нужны движения.

про скуль Вы правы. Именно. Создать необходимую структуру данных в 1С, посмотреть как называются поля и таблицы, средствами DTS заполнить данными.

вон хотяб как в

+ по идее, можно создать view и делать в неё INSERT

Данные можно выгружать в CSV или текстовые файлы. SQL*Plus или PL/SQL Developer справятся. Загружать обработкой в фоновом задании, используя ЧтениеТекста. Файлы разбить по месяцам, чтобы в случае облома не начинать все сначала. Но таки да, смысл в этом сомнительный. Разве что заменить ораклиста - ваятеля отчетов на более дешевого 1С-ника.

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

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

Зачем?!

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

Я б на MS SQL делал.

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

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

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

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

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

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

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

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

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

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

MS SQL DTS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Перетащить разово

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

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

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

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

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

Читал по диагонали? Смотря как открывать.

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

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

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

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

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

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

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

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

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

Спс

см

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

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

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

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

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

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

у них же там записи не как в 1с, где в документе 55 реквизитов. Там в записи наверняка 3-4 поля номер, дата и сумма. То есть если берем в записи например 30 байт, то размер базы 220 000 000 х 30 = 6,6 гиг. Вполне влезет в файловую.

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

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

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

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

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

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

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

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

Верно

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

Нормально.