Comments 36
Было бы прекрасно, если бы автор дополнил статью техническими подробностями, объем базы, количество документов в базе (интересует порядок, а не с точностью до штуки). Какая именно база используется, потому, что для 1С возможны варианты, какой серверный ресурс. Иначе сложно оценить это история успеха или нет.
Проект давно делали, года три назад. Количество документов не могу сказать. Знаю, что зп считалась по 2000 сотрудников.
Вопрос какая база используется не понял. Конфигурация в статье указана - зуп корп.
Сервер свой использовали, т.к. у клиента dev окружение не очень. Сервер был примерно такой: 128 гигов оперативки, ксеон (точную марку не скажу, с тех пор уже обновились) 6 ядер, по 3 гигагерца, ssd диски.
Я такую задачу делал, если баз около 5ти, то удаляет 1базу за 4 минуты и это норм. Но была задача, где 250 баз! Там вычистить и оставить 1у это 2е суток ) Кому интересно, выложил скрипт на гитхабе https://github.com/horhex64/oneass_sql.git
Что мешало создать 2 новые "разделенные" базы заранее, не останавливая деятельность основной и доставлять туда новые появляющиеся документы? Могли бы и за час тогда перейти.
Ваш путь с прямым удалением в SQL:
во-первых, нарушает лицензию 1с у клиента. Сейчас за таким никто не гоняется, но в любой момент могут начать. Донесли ли вы до клиента, что если этот кейс получит юридические претензии, то клиенту потом заново лицензии покупать? Плюс условный миллион рублей на затраты
во-вторых, крайне сложно проверить целостность данных. Тестирование и исправление - не панацея. А последствия этого метода вполне могут выявится не сразу при приемке, а спустя время, чем сильно все осложнить.
перенос справочников / документов в пустую базу потребовал бы очень серьезной проработки постановки задачи аналитиком по ЗУПу, тут даже предпроект в 40 часов вряд ли уложился бы. Ну и после переноса сверка. Это был бы очень серьезный проект.
Здесь как раз история в том, что было найдено техническое решение которое позволило без потери качества снизить сроки и стоимость.
Я и не предлагаю перенос в пустую базу.
1) добавляете план обмена в основную базу на все документы (один узел = одной новой базе, как-то там деля по организациям между ними)
2) Создаете 2 "разделенные базы" копиями с основной.
3) Удаляете в них ненужные части (длительная операция, без прямого доступа к СУБД)
4) Делаете предварительную сверку (данные должны быть актуальными на момент создания копии)
5) Доставляете накопившееся в плане обмена до разделенных баз
6) Допроверяете перенесенное (ориентировочно за 14 дней доки тут будут)
7) Переводите пользователей на разделенные базы
---
С 5 по 7 пункты накрываем блокировкой входа пользователей во все базы - это и будет даунтайм. Если хочется его сократить, то можно сделать эти пункты в 2 итерации: в первую итерацию без блокировки входа перенести за 14 дней и допроверить их, а потом с блокировкой еще накопившийся за это время кусок (врятли он будет больше 2х дней).
первым делом мы пробовали удалять объекты штатными средствами, т.е. обработкой. Запустили обработку на 8 часов, остановили, посчитали процент удаленных. Прикинули линейный прогноз, вышло что до даты х мы точно не успеваем, причем раза в два. Так что такой вариант не подошел бы.
Ну и трудозатраты в вашем варианте в разы больше. Чего ради?
Можно было наверное в день х закрыть доступ в базу, снять дамп, развернуть дамп на другом сервере, открыть доступ, настроить разграничения по организациям. Или в принципе настроить репликацию средствами СУБД и в день х реплику сделать вторым мастером.
Есть стандартный "Правильный" способ сделать это в 1С но она работает долго? Проблему до конца не локализовали?
Хочется подробностей, а то вдруг у меня тоже будет задача разделить 1С и я такой - давайте в БД скриптом выпилим. А меня спросят почему иммено так? - а я статью на хабре читал там так делали.
Стандартный способ работы 1с с субд - вносить изменения по каждому объекту отдельно. Что тут локализовывать? И это нормально что 1с так делает, не думаю, что в том же SAP или MS Dynamics изменения по-другому вносятся. Я правда не проверял, кто знает, напишите, интересно.
Мы скриптом сделали работу в разы быстрее. Лазить в субд на проектах 1с абсолютно нормально. Если у вас 200+ активных пользователей, по-другому просто не прожить.
Недавно ездили с коллегой на курсы Богачева, по подготовке к эксперту по технологическим вопросам. Так вот он конечно говорил, что индексы лучше руками не делать, искать варианты через платформу, но в целом, вендор с пониманием относится к решению вопросов производительности через субд.
Кто/что помешало не трогать старую базу но настроить РИБ на две новые "разделенные"?
Сначала двусторонний обмен, затем отключаем и все.
Честно, не знаю, есть ли в ЗУПе РИБ с разделением по организациям и как там сотрудники и ФЛ мигрируют. Мы такой вариант кратко обсуждали, решили что скорее всего ФЛ поедут во все базы, их придется все равно вычищать (было требование не передавать лишние перс данные). Решили что проще и быстрее вычистить все скриптом SQL, а базу просто скопировать.
напрямую через SQL - нарушение лицензии 1С п. 65 (https://v8.1c.ru/priobretenie-i-vnedrenie/otvety-na-tipovye-voprosy-po-litsenzirovaniyu-1s-predpriyatiya-8/#27). Скопировать 8 раз (или сколько там юр лиц), разделить правами и спокойно удалять по Организации по ночам/выходным недорого и правильно.
Про ограничение лиц политики 1с знаем и всегда, перед такими работами предупреждаем клиента. Он сам принимает риск. Может выбрать быстро и дешево, может долго и дорого.
Это по сути лишает клиента возможности отправить базу в поддержку 1с, в случае, если мы как партнер не сможем решить их проблему. Точнее так, отправить они могут, но поддержка может отказать в разборе, поскольку в бд вносились изменения. Хотя еще не понятно как это выявить можно.
Случаи обращения за поддержкой к вендору единичны, за свои 25+ лет работы с 1с такое было только на первых версиях и то по пальцам одной руки пересчитать.
Это не является нарушением лицензии, поскольку покупатель не использует SQL сервер для иных своих (производственных) задач кроме как взаимодействие с платформой. Так можно дойти до абсурда и объявить нарушением лицензии средства резервного копирования и администрирования сервера SQL в поставках от третьих лиц. Там тоже "напрямую через SQL".
Не той лицензии. Вы пишете о нарушении лицензии бандла SQL - это дешевый вариант лицензии, но привязанный к использованию только платформой 1с.
Но нарушается лицензия на саму 1с:
п.4 Лицензиат обязуется ... не совершать и не допускать совершения третьими лицами ... вносить какие-либо изменения в содержимое баз данных ... за исключением тех изменений, которые вносятся штатными средствами (1с) ... и описанными в сопроводительной документации (1с).
---
Простыми словами - любое изменение данных в обход платформы 1с - это нарушение лицензии.
200 часов? Смешные вы, да тут 2000 часов на подобную задачу это даже мало по "современным" меркам.
Что мешало удалять параллельно работе? Рассказывайте, что мешало подробнее описать удаление через СУБД
Как это, удалять параллельно работе?
Упрощенно, есть база, в ней работают бухгалтера из организации 1, ведут учет по организации 1 и 2. В день икс, в понедельник появляются новые бухгалтера и им нужно отдать базу с организацией 2 и без организации 1. На всю процедуру разделения есть только выходные.
Можно было бы заранее сделать две базы, и объяснить бухгалтерам из организации 1 что вы теперь ведете учет по организации 1 в одной базе, по организации 2 в другой. Была бы путаница, истерики и тормоза от удаления документов параллельно с работой пользователей. Это точно было бы дольше и дороже раза в два как минимум.
А в чём истерика? Они все равно будут работать в 2х базах в итоге. Даже если просто пометить организации на удаление, уже будет предупреждение при её использовании. Потом пометить все документы удаляемых организаций в каждой базе. Это всё можно сделать штатными средствами. Рассказывайте, сколько это займёт по времени
Истерика от путаницы, в какой базе что вести.
Мы избежали работы в двух базах. В пятницу бухгалтерия организации 1 ведет организацию 1 и 2 в одной базе. В понедельник у них останется та же база, они продолжают вести организацию 1. Организацию 2 начинают вести бухгалтера второй организации в отдельной базе.
Текст ни о чём: удаление через субд стандартный инструментарий тех же самых Инструментов Разработчика.
Мне вот как буху кажется совсем очевидным другое решение
Старую базу оставить у основного юр. лица
А новому юр. лицу начинать с чистого листа, с новой базы. Для чего ему старые данные?
В данном случае речь не о новых юрлицах. По франшизе были переданы действующие рестораны и соответствующие юрлица с оформленными сотрудниками. Заводить заново данные 500-600 сотрудников кажется плохим решением.
тогда нужно больше информации о юр. структуре бизнеса. иначе это все голословно
что значит данные по сотрудникам - справочники или кадровые документы, документы начислений?
это не такой уж и большой объем данных, что бы заморачиваться, как пишет автор
в общем что то не вяжется со смыслом (хотя мы не знаем реальной картины, а судим лишь по описанию задачи)
Какие то странные люди пишут. Напрямую из SQL удалить основные таблицы, потом почистить. Никто за вами гоняться не будет и отбирать лицензию.
Такое же удаление без проверки целостности есть в 1с.
У меня кровь из глаз пошла при чтении статьи. За много лет работы с 1С я насмотрелся всякого, но такое! Статья вредная. Так делать нельзя. По факту из одной нормальной базы сделали две битых. Я тут бы людям рекомендовал два пути. 1 РИБ и выгрузка в две базы (довольно быстро работает, зависит от объёма). 2 Две копии базы, включить РЛС по Организации и сделать обработчик который ночью удалит лишнее. Как то так.
У меня кровь из глаз пошла при чтении статьи. За много лет работы с 1С я насмотрелся всякого, но такое!
Крокодиловы слезы, видимо. Бывает.
Автор статьи и ее коллеги сделали совершенно правильный выбор. И результат их работы правильность этого выбора абсолютно подтверждает. По поводу якобы (да хоть бы и не якобы) нарушения лицензирования в случае прямой работы средствами SQL-server - смешно читать, вроде умные люди должны быть, ИТ-шники как-никак.
Расскажу случай годичной давности:
Некоему довольно крупному казахстанскому ритейлеру вот так же понадобилось дочернюю контору выделить в отдельную базу. Конфа - КА для Казахстана с собственными доработками, размер базы - 180Гб, при этом на дочернюю приходится ~6%, если говорить о документах. В базе 10 организаций. Выпилить нужно с сохранением всех документов в новой базе, т.е. ввод остатков не прокатывает. Было два предложения - наше и одного омского франча.
Наше (перевожу в рубли) - фиксированная стоимость 650.000. Согласно нашему предложению, новая база, полностью обрезанная, начала бы работать максимум через 30 дней после подписания договора (и это мы еще с запасом брали, страховались на всякий случай, т.к. нужна была не только обрезка, но и корректировка\настройка обменов с сайтами\датареонами и т.д. и т.п.). Выполнили у себя тестовую обрезку с помощью собственной разработки (с успехом применяем ее и сейчас), средствами SQL-server, разумеется - все прошло отлично, никаких гнуснопрославленных битых ссылок и прочего уксуса в виде кривой ОСВ, убитого СебестоимостьТоваров или потерянных данных ЗУП. Непосредственно удаление занимало 1 ч 38 мин. на нашем вполне рядовом сервере. Плюс пересчет итогов - не помню уже, что-то в пределах часа. Разумеется, не все ненужные данные удалялись напрямую, что-то пришлось обработками выпиливать - еще полчаса при готовности обработок, да это уже мелочи, можно и после запуска базы сделать. Т.е., при самом тяжелом раскладе гарантированно укладывались даже не за сутки - за ночь. Статистика по удаляемым данным: Документы - 5.250.000 до, 352.000 после. Независимые РС - 48.924.000 до, 2.242.000 после. Справочники - 4.560.000 до, 2.242.000 после.
Проект в итоге делал некий франч из Омска, мурыжили месяцев 9, выбрав максимально затратный по всем параметрам и рискованный в плане потери данных путь - план обмена, РИБ\не РИБ, уж не знаю. Вынесли бедным бухам все мозги, истрепали нервы бесконечными потерями справочников\документов. Начали в июле, новая база начала работать с 1-го января, закончили в марте. Разбогатели на 3.500.000
Что ж, в конце концов, никому не запрещается наживаться на идиотизме заказчика (особенно если сын директора заказчика как раз в этом франче и работает). А засранцы из ИТ-отдела заказчика начали хвастаться, как у них все хорошо прошло, и "это был самый успешный и безболезненный переход, что мы когда-либо видели", "был выбран самый оптимальный путь" и прочий льстивый бред.
"Такая вот история ...", как говаривал, бывало, крестный отец...
Разделили базу 1С за 40 часов вместо 200. Не стали создавать пустую базу и переносить данные