Перенос большой базы 1С с MS SQL на Oracle #738097

Добрый день. Собрались переходить вот. В связи с этим вопрос, а вообще реально средствами 1С выгрузить и загрузить в/из dt базу весом в 1 террабайт?

Добрый день. Собрались переходить вот. В связи с этим вопрос, а вообще реально средствами 1С выгрузить и загрузить в/из dt базу весом в 1 террабайт?

я сомневаюсь что DT в теробайт реален.... может лучше скулевским экспортом через ODBC  ???

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

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

чет я подозреваю, что терабайт и средствами "не-1С" сложновато будет перенести

Короче запустил выгрузку в dt с копии базы. )))

я думаю можно смело идти пить пиво. надеюсь с утра что то будет :)

я думаю, что можно идти пить пиво до самой Пасхи.

а бы было.а так то совет а

если у вас есть свободное место для временного файла на сервере 1С то теоретически можно, но скорее всего нет. А чего там в 1ТБ то? может можно сократить?

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

стандартный подход ко всяким таким операциям требует ТРООЙНОЙ объем... так, что не пройдет....

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

Больше проблем будет с загрузкой, чем с выгрузкой. 1С-ка при загрузке дтшника создаёт временные файлы соизмеримого с самим дтшником размера. Кроме того, очень желательно иметь свежую версию платформы 8.3 и конфу не в режиме совместимости с 8.2 - это уже для эксплуатации, а не для переезда. Есть ещё нюансы: возможно придётся переписать некоторые запросы, т.к. оптимизатор Оракла не всегда адекватно воспринимает конструкции, идеальные с точки зрения стандартов 1С. Но в целом на хорошем железе все должно летать. Да, и без рекомендованных патчей не заведётся - имейте это ввиду.

Ускорение будет за счёт того, что это версионник. Плюс приятный бонус - формирование отчётов без богомерзкого nolock. Т.е. подобающая солидным системам целостность читаемых данных, не то что на скуле.

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

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

[Хотелось бы конечно стандартными средствами 1С, но что-то мне подсказывает что это не наш случай. ] типичный случай выгрузкизагрузкичерезxml в идентичную конфигурацию путем отборов нет проблем сделать это частями и не порождать 2 Тбайтный xml

зачем пересчет итогов ? индексация зачем ? с Вашими подходами нужен спец по ораклу. без шаманства 1с8 с ораклом не работает.

В каком смысле полную переиндексацию? При заливке дтшника все структуры хранения создаются заново, так что "пере" надо заменить на просто "индексацию". Вообще индексы создаваемые под разные платформы отличаются, и не только именами :) А вот пересчет итогов не обязателен.

обычно на скуль уходят с оракл.

я имею в виду вариант прямого экспорта через ODBC

Про оптимизатор можно почитать здесь: Но это скорее для общего развития. Вообще же, на мой взгляд, проблемы две: не вполне корректная статистика по полям таблиц, содержащим ГУИДы (а это как мы знаем ссылочные поля по которым надо делать джойны), и кривые предположения оптимизатора о распределении данных во временных таблицах - тут скуль сильнее (он нормально собирает стату по ним при создании). Проще говоря всё это выливается в то, что запрос, написанный как велит 1С - с передачей параметра в виртуальную таблицу может отработать сильно медленее того же запроса с условием вынесенным в ГДЕ. В моем случае пришлось править книги покупок и продаж в УПП.

временный файл создается при выгрузкезагрузке на сервере 1С в зависимости настройки переменных сред. По умолчанию это диск С. Если у вас диск С не 1ТБ и больше, сразу фэйл. Руководству вбить в голову гвоздь. Не взлетит ваша затея. Слишком трудоемко, дорого, долго т.д. Минусов от такой миграции больше чем плюсов, тем более если вопрос производительности не стоит.

А это вообще рабочий вариант? Бинарники нормально конвертируются? Таблицы разве все по именам совпадают на разных платформах?

Предлагаешь вручную настраивать соответствие полей/таблиц? Полагаю, через dt быстрее будет.

Всё будет ОК, если деньги сэкономленные на лицензиях потратят на спецов :))) Хотя надо помнить о платности поддержки Оракла при расчетах.

нет конечно . Имена полей совпадают . Имена таблиц отличаются первым символом.

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

убъёшься разные длины полей, разные тайм-стампы

Или наоборт. Но точно не одинаковые.

быстрее будет через xml

В оракуле подчеркивание в скуле буква f вроде

экспотры они довольно умные сейчас... я с ораклом никогда не работал, по этому это только мои предположения :) тем не менее я переносил с 2012 скуля (после рековер студия) на скуль 2000, там то-же были проблеммы с разными фрматами...

Имхо имея опыт на оракуле могу сказать штаа скуль вариант ентерпрайз без альтернативен

если DT терабайт - какой размер XML будет???? думаю под 100 терабайт :) придется кусками... это на неделю....

Ну, вообще dt намного меньше mdf+ldf.

//временный файл создается при выгрузкезагрузке на сервере 1С в зависимости настройки переменных сред. а какая переменная среды за это отвечает?

Да, еще кое-что: рекомендую загуглить V81C_INDEX_BIG - сэкономит время :))

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

+ Но для автора пожалуй что да - безальтернативен.

пока вы предполагаете это уже давно пройденный этап

Погодите про ентерпрайз ))) мне сначала надо как-то данные перенести.

да ок. Делайте выгрузку штатными средствами движка 1c   И штатными же средствами загружайте. Разве вендор глаголит иначе?

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

у меня наоборот оракл забыт как страшный сон

Давайте без холиваров плз. Тем более вопрос надо ли переходить не ставится.

Вот и поведал бы о проблемах, если в курсе конечно. Глядишь и нашлись бы аргументы для ТСа, чтобы объяснить руководству о несоответсвии стоимости овчинки и выделки.

холивара нет. Вендор четко регламентирует порядок переноса между Субд. Все остальное  танцы на атомной станции

ИМХО, интеграция лучше с MS, ну чисто из-за того что платформа написана на VSС++(исходя из ошибок платформы, которые выдавало иногда). Поэтому, можно землю пахать на верблюде, но лучше, к этому, приспособлена лошадь.

А если РИБ сделать...

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

топик изначально холивар, пока на копии базы не выгружен dt или пока не произошёл сбой при выгрузке

Свойство системы-Переменные среды-переменные Temp и TMP ЕМНИП 1С при выгрузке дт использует BULK COPY. Можно попробовать выгрузить из SQL через BCP, предварительно прогнав выгрузку небольшой копии и через профайлер сгенерить список командтаблиц.

правда потом загружать в Oracle, делать мапинги, преобразование типов и т.д тп проще уволить руководство)

1ТБ - это что весит? MDF?

+100. Тоже хотел предложить. И грузить частями...

Вам деньги некуда девать что ли?

с этим не взлетит?

в mssql это тоже есть

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

"пока на копии базы не выгружен dt или пока не произошёл сбой при выгрузке" На самом деле даже при загрузке dt может произойти фигня. Сама 1С поэтому не рекомендует использовать dt-шник в качестве единственного источника архива - [i]"что не всегда может быть получено при использовании режима загрузки/выгрузки информационной базы. Например, если в базе данных есть нарушения, то при выгрузке некоторая информация может быть не выгружена"[/i]

хочется спросить у ТС, как там дела с , на сколько десятых процента дело продвинулось?

трудно ТС-у, будучи прикованному к rphost-у,дотянуться до интернета =)

смотрите новый сериал "Переход". Первый сезон "Выгрузка"

А мне нравится идея с РИБ...

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

ни на сколько ))) через 3 часа вырубил.

с РИБ - да, стоящая идея.

тот же файл xml, но долго и мучительно создаваемый, накую это нужно при двух идентичных конфигурациях ?

Почему один и тот же? Никто же не мешает риб кусками гонять

кто-то мешает гонять те же отборы в выгрузке/загрузке ?

Никто. Так что разницы никакой, согласен. Консенсус детектед )

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

Бюджет осваивают. Может им вообще шринк надо сделать и куча места освободится :-)

Я не был бы столь категоричен не зная "Что за контора", "Какой период" в данной базе. Если контора разорилась на серваки и на сам Оракл, то есть гипотеза, что это далеко "не маленькая хач-палатка"

Имха  скрипт  на стороне оракля  через  линк к скулю и перегон в таблицы . Я бы копнул именно так.  Ораклевый линк к таблицам скуля довольно шустр .

У одного из моих заказчиков был опыт сопровождения 1С на Оракле, база около 800 Гб. Мучались 3 года. Тормозило. В компании три крутых оракл-админа. Ставили апдейты и оракла, и 1С. Особенно изящно делали реструктуризацию регистра бухгалтерии: в оракле не проходило впринципе, поэетому я им в шутку предложил решение: - выгружать в dt - загружать назад в оракл Сначала все смеялись, потом именно так и начали делать В конце концов перешли назад на скуль, производительность выросла в разы. Очень довольны.

А если у вас база 1 Тб, то могу сделать вам свертку базы за 2 часа. Есть универсальное решение, моя разработка. Пробовал на двух базах 1 Тб и 0.5 Тб А также на десятке мелких, от 100 до 200 Гб Врмени практически не занимает, проходит влет. 100% контроль ссылочной целостности, не  нужно пересчета итогов, не нужно изменений в конфигурации.

Столько шума из-за жалкого терабайта. Микрософт имхо перегнул палку с лицензированием по ядрам. Настолько, что Оракл стандарт стал реальной альтернативой скулевскому энтерпрайзу.

Платная?

Вознаграждение конечно хочу, но значительно меньше, чем любой франч возьмет за работу по свертке базы. И меньше, чем штатный программист получит за эту работу в виде ЗП. Так как для меня сверка любой базы - это не работа, а пара пустяков)) Если интересно, пишите в личку, уверен что договоримся.

Да не, мне-то не надо. Просто интересно, почему всё так просто. На ИС или где-то ещё есть описание работы?

гений1с?

это тяжкое оскорбление, в прошлом веке за такое  в рожу канделябром заезжали =)

Описание могу дать Могу показать реальный отзыв от клиента, у которого база была 1 Тб + куча более маленьких в РБД. Больше года не знали даже как подступить к задаче свертки. Нашли меня, так до сих пор удивляются как это может быть быстро и просто :)

Так выкладывай описание в свободный доступ - озолотишься :)

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

500 Гб переносил через dt - проблем не было. Только надо место под dt иметь на диске, где крутится сервер 1С (он там временно создается). 80гб примерно будет dt от террабайтной базы (если нет несжимаемых данных). Ну и запас времени в пару суток на выгрузку/загрузку.

писал на рейд построенный на ССД?

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

Там не на диски основная нагрузка, а на процессор. Но в моем случае - да, raid из ssd :)

Ну и вдогонку к : свертка на террабайтной базе за 2 часа - это что-то совсем фантастическое. Очистка даже одного регистра в 100 млн. записей будет идти долго, а потом - пересчет итогов. Разве что таблица пересоздается или транкейтится, и делается перенос только небольшого кол-ва "нужных" записей. Тогда - да.

Не поверите, но это универсальное решение, которое перед сверткой осуществляет анализ связанности документов. И не удаляет ссылки, на которые есть связи в открытом периоде. Пробовал на УПП 1.3, Бух 3.0 с разделителями, УТ 10, ЗУП 2.5, а также на полностью самописной конфигурации. Есть реальные заказчики, которые подтвердят работоспособность и скорость работы свертки. Писал долго, месяца 3. Тестировал тоже долго. Поэтому решение универсальное. Помимо сверки, есть еще одна функция - поиск и быстрое удаление неиспользуемых элементов справочников. Два заказчика таким образом почистили спр Номенклатура и Единицы от 1.2 млн и 0.9 млн сответственно неиспользуемых позиций. Плюс куча мусора в других справочниках.

И никакого пересчета итогов нет! Он не нужен в моем случае. Просто надо знать скуль на 5 с плюсом и понимать структуру хранения таблиц 1С ))) Вот и все

пока никакой конкретики... потом мне одному напоминает речь продажника толкающего то, что у него есть для продажи? , что-то более конкретное будет или как?

в зупе как это можно универсально свернуть?не погорячились ли

Дождались, кнопка "Сделать все" существует! Сарказм оправдан отсутствием конкретики

Можете задать в личку любые вопросы, уточню конкретику :) Могу провести демонстрацию по удаленке