Pull to refresh

Comments 6

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


а снепшоты базы для этой цели не думали использовать?
правда у варианта со снепшотом есть минус — в случае неудачного деплоя, вам основную базу надо из снепшота восстанавливать, но если изменений немного — то восстановление из снепшота происходит быстро, создается снепшот очень быстро по сравнению с созданием копии. вариант снепшотов не подходит для если вы деплоитесь на базу которая работает 24\7, но если есть окно обслуживания, то вариант со снепшотом вполне себе рабочий
Вы обозначили обе причины, по которым мы не используем снимки )))
Просто из любопытства вопрос:
А почему было не реализовать средствами 1С (ну, или, скажем так — 1С + что-то) на филиале выгрузку в некую промежуточную структуру, например — xml файл, а на уровне хранилища — загрузку из типового xml файла? Ну хорошо, версионированного файла.
Да, для каждого филиала выгружалку придется писать и поддерживать индивидуально, но вы в любом случае это делали.
И никакого безобразия с монструозными SSIS пакетами с замудрённой логикой на уровне хранилища — нету. Каждый отдельный кусок замечательно тестируется и обкатывается (и загружается) — индивидуально.
Может, я не понял вопроса… Но кажется причина была описана
Первая проблема заключалась в том, что у 1С77 нет никакого сервера приложений или другого дЕмона, позволяющего взаимодействовать с ней без запуска платформы. Кто работал с 1С77 -знает, что у нее нет полноценного консольного режима. Можно запустить платформу с параметрами и даже что-то выполнить на их основе, но консольных параметров очень мало и цель их была в другом. Но даже с их помощью можно наколхозить целый комбайн. Однако она может непредсказуемо вылететь, может вывести модальное окно и ждать, пока кто-то нажмет ОК и прочие прелести. И, пожалуй, самая большая проблема — скорость работы платформы оставляет желать… Поэтому решение тут только одно — прямые запросы в БД 1С.

Поэтому выгрузка из самой 1С даже не рассматривалась.
(ну, или, скажем так — 1С + что-то)

Если прямые запросы запускать на стороне филиала с помощью чего-то еще, то какая разница, будет этим «что-то» какой-то другой продукт или SSIS?
Монструозность можно было бы уменьшить (не избежать), если использовать те функции, что есть в конфигурации 1С, написанные на языке 1с, позволяющие добраться до документа основание или еще что-то, но это противоречит первому условию
Всё это множество переходов и условий в SSIS появились не из-за прямых запросов, а из-за большого числа сущностей, которые в хранилище нужно слить воедино. Для каждого XML файла пришлось бы делать то же самое — как минимум один компонент на файл, если файлов десятки, то и компонентов десятки, вот они уже и на экран не умещаются. Однако в случае с файлами нужно было бы обеспечить их транспорт, а это еще один сервис. Ну не в шару же их выкладывать.
Плюс логика обработки самих файлов — какой период в них лежит? А есть ли предыдущая версия файла рядом? В какой последовательности их загружать и что делать с соседним файлом в котором такой же или перекрывающий период? Религиозный вопрос — нужно ли хранить где-то историю этих файлов, т.е. уже загруженные/ошибочные/планируемые к загрузке копии…
Вот люблю такое, когда человек берет инструменты и совсем немного изоленты и решает задачу — у меня в силу профессиональной деформации всегда первым делом идет мысль «щаща, возьмем .Net или яву и напишем»… Респект вам в этом плане.
Sign up to leave a comment.

Articles