Коллеги, привет.
На данный момент, в нашей фирме обновления проходят, как в обычных компаниях.
Ждем 19:00 и запускаем обновление. Сам процесс (если нет сбоев каких-то) занимает 3-4 часа.
Так как ИТ также "негласно" присутствует при обновлении, то получается, на обновлении заняты 2 человека.
Собственно, программист 1С и еще сотрудник ИТ, чтобы восстановить копию в случае сбоя.

Встал вопрос. А можно ли обновлять рабочие базы в рабочее время?!
Я только ЗА! Но отключать базу на 3-4 рабочих часа - этого никто не позволить. Особенно, финдиректор. )
Так вот, есть ли какие-то новые техники в обновлении баз 1С. Может уже изобрели, просто я о них не знаю.

Ведь есть компании, которые работают 24/7. Вот как у них все это происходит?!

(116) *перейду

(113) Бекап хранилище - само собой разумеющееся действие.
А вот пересоздание заново из-за сбоев в сети при работе с файловой шарой - дичь.
Кстати при работе с хранилищем через шару сталкивались ещё с проблемой, что у разных разработчиков оказывались захваченными для изменений разные версии одного и того же объекта. И когда один из них помещал свои изменения в хранилище, то затирал изменения другого разраба. Правда дело было очень давно и точных подробностей уже и не вспомню.

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

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

(45) Перед обновлением с рабочей производится обмен на запасную? чтобы актуализировать? или как?
и как после обновленяи рабочей туда попадает все что наколотили в запасной?

(115) Да, есть такая проблема.
Для особых извращений решается (теоретически - сами не пробовали) примерно так же как поднятие на одном хосте нескольких различных версий сервера 1С. Разнос по различным портам и ручная регистрация служб.
Изврат ещё тот. Но если очень сильно надо, то можно.

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

(59) а те что на завершились до завершения бэкапа? - получится, они потеряются?

(114) "люди просто оплачивают себе сверхурочные" Вот честно, это не так!!!!!!!!!!!)

Сейчас отправлю вопросы ИТ.

(123) Они будут в следующем.

(125) хм.. ну так сделали бэкап. часть незакрытых транзакций не забэкапилась. накатываем обновления. что-то пошло не так. база рухнула (условно). откуда мы вытащим не попавшее в бэкап? (или я что-то не понимаю?)

(114)
1. 10Гб
4. кластер из 3-х ВМ, 2 сервера приложений 4vCPu XEON E7-8867 2.5Ghz, 16Gb RAM, SAS hdd
Сервер СУБД 4vCPu XEON E7-8867 2.5Ghz, 16Gb RAM, SSD

(126) Из астрала, разумеется. Откуда ещё?

(127) в общем попробуйте заново хранилище развернуть и потестить, все должно норм работать

(124) Совершенно честно и верно, что это именно так.
Будь у вас специалист со знанием дела, как минимум бы уже давно взял эти жалкие 10 гб, развернул на своем домашнем пк/ноуте, накатил любое обновление за 2 минуты и ткнул бы результатом в официальном письме начальнику IT и финдиректору с пометкой: господа, разберитесь, что там у вас с серверами, так как на простом домашнем пк все летает.

(127)

1) Вы хотели сказать наверное 10 Терабайт ?
2) У меня на телефоне 6Гб ОЗУ. Дома на компе 16Гб. Но даже на 16 -- 4 часа...
Либо там какой-то лютый ужас в базе, либо я даже и не знаю

P.S.
10 Гб -- это детский сад.

А СУБД какая?

Имя, сестра, имя(с)

(131) зато проц как я понял 250к+ стоит)

+ к (130) и выяснится за пару дней, что и виртуальные машины через задницу сделаны, и настройки SQL из коробки, и masterdb 180Гб занимает и потеря пакетов и вообще у нас там майнинг, проц на 99% забит

(130) Спасибо! Я так и сделаю.

(133) Ну, так нельзя. Мы же команда и должны работать вмсете.
Нужно нежно намекнуть )))))))))))))))))))))))

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

(135) вы можете вообще копию рабочей базы развернуть в файловом варианте, на нем же загрузить cf с обновлениями и показать админу, вот смотри приятель, 2мин и все готово на обычном юзверном компе, почему на вашем супер крутом сервере с процом за 250тыс это занимает 3 часа?)

(136) Да, серверная.

(131) MS SQL Server

(0) Методика непрерывного обновления есть на ИТС. Кстати, в (6) он упоминается.
Один минус - правила нужно самому писать дополнительно к обновлению.

(140) тут нет смысла база всего 10 гигов)

(131) Да, не 10 Гб (это бекап сжатый) а 50Гб)
СУБД MS SQL 13.0.1742.0


Так, я вангую, что в файловую она у меня не развернется ((((((((((

(142) блин так и пишите, что 50гб)) но тоже это не такой уж большой объем для БД. В файловую да, вряд ли развернете.

(142) на что уходит львиная доля обновления? реструктуризация?

но вот оперативки в 16 гигов для базы в 50гигов это как то маловато...

(144) Накатывание обновлений на базу через Сравнить/Объединить и применение этих изменений - самый длительный процесс...

(145) Принято.

(146) а зачем вы в рабочей базе сравнение/объединение делаете? Или вы новые релизы от 1с накатываете на не типовую базу?

ВМ говно

Советую взять приличный комп 5ГГц с NVMe SSD PCIe 4.0 и просто потестить скорость обновления
Имхается за полчаса-час обеда можно успешно обновлять

Если не успеваем то просто переключаем базу сервера 1С на другую базу скуля

у меня по молодости была задачка 20 баз обновить до последнего релиза, так вот, если конфа была отредактирована, то время обновления просто ппц как увеличивалось из-за этого сравнения объединения. В итоге проще было привести конфу к типовой, быстро обновить до последнего релиза, а после обратно накатить изменения конфы (если есть необходимость).

(148) так. стоп.
Затупила, простите. Естественно, через Поддержка - Обновить конфигурацию!

(151) что за конфа? Она типовая на замке?

(152) Да, практически все изменения в расширениях.
С корня замок снят, но только для внесения новых объектов и включения модальности.

"для внесения ... включения модальности."
Зачем?

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

(154) Для пользования обработки "Инструменты разработчика". Уж больно она мне нра.

Но сняли корень с поддержки до меня. Кажется, там режим совместимости хотели изменить.

(155) Печаль.
Никак не исправить это?

Чтобы и волки и овцы?!

(157) Бесплатно нет

(158)+ Все равно придется чем то вам заплатить

(157) я бы протестировал следующий вариант, в тестовую накатить все обновления, проверить что расширения не отвалились и все работает. После выгрузить конфу в файл, а на рабочей ее развернуть. Тогда никакой проверки не будет. Но лучше потестить такой вариант на копии.

(156) Даже конфа УТ 11.4 "со снятым замочком", это не 4 часа

Вопросы:
А зачем кластер?
А зачем сервер 1С не вместе с сервером SQL ?
А скорость между ними ок?
А зачем в 2021 году 16Гб памяти?

(157) А сколько идет бэкап этой чудесной базы? Надеюсь не дольше 5-ти минут?

(157) Вы так и не написали какая у вас конфа

(162) Шутишь!?
Не знаю сколько средствами sql, меня туда не допускают. Святая только для мужчин )
Но средствами 1С - минут 30. Давно уже не делала, но сегодня сделаю.

(163) Да, извините.


БП 3.0 + БИТ.

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

(165) но даже для изменной конфы накатить 1 релиз за 3часа это очень долго. Я бы еще понял 30мин

А могут ли быть на сервере запущенны какие-то процессы (не относящиеся к 1С), которые бы тормозили обновление просто потому что нагружали бы память?

Я сейчас просто размышляю на тему...

(168) У вас нет памяти. 16 Гб это не память

сколько пользователей? Работают терминально? терминальный сервер находится вместе с кластреом 1с, или с скулем?

(168) там просто так не скажешь. Надо смотреть, сколько отжирает памяти каждый рпхост и смотреть, идет ли ее утечка. Плюс, если скл разнесено на другой сервак(что, конечно же, и должно быть) - смотреть что там происходит с памятью (но тут хз - скл агент отжирает вообще всю доступную память, обычно для своей комфортной работы). Если же не разнесено - то 16 гигов через шаред мемори - это катастрофически мало.

Так совет в (160) отличный. Готовим в рабочее время cf на тесте, в 19:00 делаем резервную копию базы средствами SQL, загружаем конфигурацию из теста.

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

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

(174) Это уже выполняется в пользовательском режиме для новых версий, также можно указать несколько потоков.
(175) Если лохматые конфигурации, то промежуточные выгружать из тестовой в cf и накатывать по-одной в рабочей с запуском пользовательского.
Основная проблема, как понимаю, в долгом сравнении-объединении из-за низкой частоты ЦП на сервере и неверно настроенной ВМ, а не обработчиках обновления и реструктуризации базы.

(176) это понятно, я специально расписал для ТС, что есть нюансы, о которых надо помнить при такой схеме работы

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

(178) я так понял обновление в нерабочий период. Бухгалтера отработали до 6ти и домой, а ТС с чашкой кофе в обнимку с сисадмином обновляют базу) Так что ничего страшного не произойдет, в крайнем случае останутся до ночи и вернут базу к исходному значению к утру.

так что выгружай свои смешные 10гб на калькулятор, демонстрируй результат и пусть вджобывают. В моей практике за 2-5 дней вдруг решались задачи многомесячного головняка

(180) уже выяснилось, что база около 50 гигов, а 10 в сжатом виде. В файловую ТС вряд ли развернет. А скуль локально для ТС вряд ли стоит. Так что разницы особой не будет.

(179) обновление по 4 часа - это только начало. Да и мне сложно представить, чтобы кто-то давал такое тех окно. Час от силы, раз в неделю. На все. Бекап, обноаление, рестор.

(182) ну вот бывают конторы, которые работают с 9-18 к примеру, а все что после тех окно, хоть каждый день))

(181) причем здесь файловая? Я за одну ночь выгрузил пару БП 3.0 овер 120гб к себе на домашний комп, поставил скуль, снял видео как проводятся документы и скинул в it отдел.

(184) ну так надо же себе домой купить серверную лицензию 1с, а так же скуль. Я не думаю что у ТС это все есть

(185) а, ну да, точно. И распаковать архив лицензированным winrar

(184) в общем, если работать через cf то проблема думаю будет решена. Так же я бы проверил сетку, терминалку на отдельный сервак. выделить больше памяти для скуля и для кластера 1с. Разнести их так же на разные машинки.

(186) обязательно! Но на крайний случай есть zip)

(186) да и не во всех конторах есть возможность базу домой утащить. А если ты еще такой гордый скажешь, мол я слил себе базу домой и у меня там все летает, то могут и наказать за это.

(187) все эти телодвижения только после сбора статистики. Смысл что-то закупать, если мощностей в избытке? Добавть 64гб оперативки только потому, что какой-то sql job жрет все ресурсы в 5 утра, создает задержки записи, дэдлоки и вылеты сессий?

(190) я лишь написал на что обратить внимание, бездумная покупка железа тут вряд ли поможет

(189) значит придумать другой вариант. Развернуть sql на рабочем пк. И такое проходили.

(192) у меня так и сделано, куплена лицензия сервер мини и скуль развернут локально. Локальная машинка более менее мощная.

(48) ДенисЧ https://habr.com/ru/company/postgrespro/blog/442804/
Несогласованное чтение и Несогласованное чтение и потерянные изменения
не всё так просто на болших таблицах

(173) я правильно понимаю, что именно загружаем, а не через сравнение/объединение. Даже если 1С пищит, что это страшно-опасно?!

(177) Да, да, я помню, что все надо делать последовательно.

(195) 1с вас предупреждает, что данные прошлой конфигурации будут потеряны, только и всего)

(194) Упоминаемый BOL и информация из него, они к постгре не относится, кагбэ.

(194) Как связана студенческая под(д)елка постгре и мсскл, о котором я говорил (о чём впрямую говорит слово BOL, то есть Books OnLine, то есть документация опять же к MSSQL) ?

Или это такая линуксячья привычка "Зато я использую линух"?

(195) "Даже если 1С пищит, что это страшно-опасно"
1с пищит, но делает

(195) Да, загружать. Плюс не будет ошибок если в тестовой подготовили базу, а 1С:
Справочник1 -> УдалитьСправочник1 (переименовали)
Справочник1 (был добавлен)

Через сравнение\объединение будет добавлен УдалитьСправочник1, а через загрузить переименован и добавлен Справочник1.

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

(199) там теория и пример что даже сериалайзебл не панацея

(202) Какая прекрасная ветка получилась... по всем канонам мисты!

(202) В выходные нужно отдыхать. Мысли сами придут в порядок к Пн. Там и действовать пора...

(202)  В выходные не отдыхаешь? Сгоришь.
Анекдот в тему. Выходит одинэсник из офиса в пятницу вечером. Видит - машина горит... Ну далее вы знаете. "You are fired".

(127) Из-за виртуалок на медленных процах тормоза у вас. Вынесите службы серверов 1С на физические быстрые процы.

(0)
обновляйтесь вторым способом обновления  https://wonderland.v8.1c.ru/blog/optimizatsiya-restrukturizatsii-bazy-dannykh/.
либо

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

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

(209) "типовые юзают, и обновляют раз в квартал перед отчетностью"
У тебя странное понятие "норм"... Нас требуют ежемесячно обновлять типовые...

(194) Несогласованное чтение в 1С разруливается управляемыми блокировками. А каким боком оно относится к бэкапам - я вообще не понял.

(0) Выше уже советовали - чтобы сократить время на обновление, загружайте в рабочую базу уже обновленную конфу. Удобнее всего это делать через хранилище. Если хранилище тормозит - нужно разбираться в причинах. Поднятие сервера хранилище даст выигрыш по скорости только если в сети какие-то проблемы, тормозящие работу через файловую шару. В нормальной ситуации выигрыша по скорости не будет.
Без хранилища можно попробовать работать через "Сохранить конфигурацию в файл" - "Загрузить конфигурацию из файла". При желании все это несложно автоматизировать до любой степени.

(209) >в норм компаниях типовые юзают, и обновляют раз в квартал перед отчетностью...
Молодцы, особенно если косяки повылезают из-за обновления, и это будет прям перед отчетностью. :)

(208) Хороший совет.
Плюс не забываем про https://its.1c.ru/db/metod8dev/content/5945/hdoc
Реструктуризация пройдет быстро и безболезненно :)

(0) у вас чё, каждый день обновления?

(65) на больших таблицах раструктуризация может занимать часы