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

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

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

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

(1) Да я бы только за! Не дают, цобаки! )

А что у вас там 4 часа происходит?

Это же функция корп и нового БСП

Там смысл обновляется урбд копия и дальше обмен

в нормальных компаниях обновление происходит по ночам роботами

Типовой функционал - обновление через копию. Кто пробовал?

(3) Накатывание обновления + сохранение изменений + принятие изменений в базе.

Я сама в шоке от количества времени, затрачиваемого на обновление конкретно этой базы.

Всякие ЗУПы и просто БП - быстро накатываются.

Основная база БП+БИТ. И вот она-то и есть самая основная головная боль.

А зачем на рабочем месте быть.
Обычно такое из дома делается

(5) А сверхурочные за работу по ночам тоже роботы получают?

(8) Дома нужно с семьёй время проводить, а не базы обновлять.

Работы там 5+5 мин

(0) Компании, которые работают 24/7, 1С не используют. (Демонический смех)

По крайней мере в тех процессах, которые действительно должны работать 24/7. А не бумажки выписывать.
И скажу по секрету, в таких компаниях тоже иногда приходится останавливать критичные процессы для обновления. Но редко.

(8) Мы из дома работаем!!! )

(10) Жму руку! )

(9) Роботы пока денег не просят

(9) За сверхурочные мы к отпуску получаем дни.

(15) Зато 1снику лишние деньги не помешают.

(16) Как лохи? если будете каждый день обновлять - у вас будет не работа, а сплошной отпуск ))

(18) Ну, все не так плохо )

Слово "обновлятор" еще никто не писал?
Ни разу не на правах рекламы,просто очень удобно

(0) в любом деле ремонт на ходу = плохая идея

(20) А где об этом почитать можно?
Дайте пару ссылок.

(21) Да это понятно... (

(22) google://обновлятор+1с

(22) на форуме есть окошко поиска, туда надо написать обновлятор ;-)

Так в любом случае нужно запустить и потом проверить. О чем я писал еще в (11)
Для 1 базы можно и скрипт написать

Я фигею: люди за 3-4 часа могут обновиться...

(27) Это долго?

(27) Очень быстро? ))
У нас одна УТ может (было пару раз) обновляться и почти сутки...

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

Что может быть еще?

(30) а на какой операции тормозит? Может, вы там каждый раз регистр партий меняете...

(7) Почему нельзя сделать "Накатывание обновления + сохранение изменений" в рабочее время? Для этого не нужно выгонять пользователей.
Выгнать пользователей нужно чтобы сделать бекап и применить изменения.
Не так ли?

(0) тех. окно должно быть.

(32) для бэкапа никого не нужно выгонять

(33) 4 часа никто не даст

(34) в этом случае изменения, которые делаются в процессе бекапа не попадут в бекап. Если не критично, то можно и не выгонять.

(36) на скуле как раз попадут

Задайте вопрос программисту, что за обновления он там делает. Видимо реструктуризация регистра партий, раз на 4 часа.

Все транзакции которые завершатся в процессе бэкапа будут там

(32) "Безумству храбрых поем мы песню"
А если при обновлении конкретно Ващей базы что-то пойдет не так что будете делать?

(32) Вот это самое "применить изменения" и занимает основное время.

(39) Ты гонишь.

(37) Ага. Скуль закончил в 19-02, обновление началось в 19-05.
А склад в 19-03 ввёл пачку документов на отгрузку.
Потом обновление обломалось и восстановили бекап...

(42) Нет

Да, я как раз такую сделал недавно.
Есть база, есть распределенные базы на точках. На каждом компьютере две базы, основная и запасная. Когда надо обновить, делаем быстрый обмен и все переходят на запасную базу.
Обновляется основная база, все переходят на основную базу и делается обмен распределенных. Все автоматизировано и без отрыва от свежих данных.
Есть схема и скрипты. Да, изврат, но по-другому никак, работа круглосуточная, интернет модемный.

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

(44) Ссылку можно?

(47) BOL.

вообще я ее делал для свертки базы без отрыва от производства, так как свертка может занимать несколько дней, а работать надо. Тогда я сделал свертку помесячно и она за пару недель сворачивает год.
Вот схема https://files.fm/f/6kpj3w3ec

(48) Еще скажи Интернет

(50) Нет, именно BOL
Там расписано, как транзакции попадают в бекап.

Я думал, это давно известный факт...
Может, ты ещё думаешь, что ДедМороз существует?

Те транзакции что начаты до попадут, а вот те что начаты во время?

(40) для этого тестируется обновление на копии базы, чтобы посмотреть, не будет ли ошибок или еще каких плохих ситуаций.
Убедившись, что на копии обновление проходит нормально, можно обновить рабочую базу. Причем выгонять пользователей разумно только на бекап и применение изменений.

(46) Сервер у боевых баз один.

(54) Исчерпывающая информация) У нас, к примеру, несколько 1с серверов запущено. Ну и еще нюансов с десяток.

(53) примерно так и происходит. Всегда обновляем сначала копию, проверяем что все ок и только потом планируем обновление боя.
Но я реально не продумала момент, что можно начать обновление до 19:00, чтобы к этому времени уже осталось только внести изменения в базу.
Хотя, с другой стороны, копию базы средствами sql делают ИТ и делают они это примерно в 18:30.
В общем, все равно при сбое, может часть информации пропасть ((((

(53) чтобы сделать свежую копию, тоже надо выгонять

(51) Я знаю, что там расписано, но где именно? Если ты читал, потрать минуту и дай ссылку.

(52) Все, что завершены до завершения бекапа

(58) https://docs.microsoft.com/en-us/sql/relational-databases/backup-restore/full-database-backups-sql-server?redirectedfrom=MSDN&view=sql-server-ver15
A full database backup backs up the whole database. This includes part of the transaction log so that the full database backup can be recovered. Full database backups represent the database at the time the backup finished.

(56) а вы хранилищем конфигурации не пользуетесь что ли?)

Я думаю меня сейчас тапками закидают. Но я уже 15 лет начиная с 7.7 делаю так:
1. делаю копию базы которую буду использовать для обновлений на какой то момент времени.(назовем Базовая Копия)
2. Для всех обновлений использую только одну эту копию и храню ее как зеницу ока.
3. При выпуске 1с нового релиза на "Базовую Копию" накатываю новые обновления.
4. Выгружаю из "Базовой копии" cf.
5. Ночью срабатывает планировщик и загружает cf в рабочую базу.Не сравнением а просто загрузкой.
6. Ну и ночью же автоматом запускается обновление в пользовательском режиме.

Я таким образом обновляю 5 рабочих конфигураций из одного cf.
Понятно что способ нестандартный используется на свой страх и риск.
Лично у меня базы не летели ни разу.

(60) Спасибо.

В таком случае создание бэкапа по состоянию "на сейчас" становится нетривиальной задачей.

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

у нас все изменения делаются через хранилище, все это дело тестируется на копии, после этого, в техническое окно, рабочая база обновляется из хранилища. Это занимает минуту от силы. База пиленная перепиленная под 100гигов. Первый раз слышу, чтобы обновление конфы шло 3+ часа. Такое я могу себе представить при обновлении с очень старого релиза на новый базы с измененной конфигурацией, где львиная доля будет занимать сравнение конфигураций.

(61) Ну, программист один.
Я пыталась "завести" себе хранилище. Но после того, как время обновления увеличилось почти в 2 раза - час на захват, час на помещение изменений в хранилище - я просто с ужасом отказалась от него.

У других, кстати, все происходит гораздо быстрее.

(62) В этой схеме самый большой риск, что утром выясняется, что в п. 6 что-то пошло не так, а времени на анализ и исправление нет.

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

(68) Да. Думаешь, проблема увеличения времени, из-за того, что хранилище файловое?!
Скорее всего так и есть. Пошла почитаю про вариации на тему.

(67) Как нет. Есть бэкап. Если что то пошло не так быстро из бэкапа достаешь базу до обновления.

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

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

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

(71) Изменения? Или все-таки обновления до нового релиза?

(70) В (62) у тебя бэкапа нет. И восстановление может быть не быстрым, если база большая.

(73) у нас бекап ежедневный+транзакции каждые 15мин. Так, что не запариваемся с бекапом перед обновлением. В крайнем случае потеряем 15мин работы. Для текущей конфы и бизнес процессов это не критично. А вот если обновление будет занимать вместо 1мин все 30мин, вот это уже будет критично)

(75) Да про бэкап пропустил. Извиняйте. Я просто не подумал что кто то это без бэкапа будет делать.

Хранилище может быть только файловым.

В остальном - обратитесь к профессионалам тут или, например, в softpoint.ru

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

(74) изменения и обновления. Но до! применения изменений.

(73) накуя выгонять и бекапить, если есть полная модель восстановления?

(81) ну вот экономять на транзакциях, делают симпл, а потом юзверы сидят по пол часа ждут пока бекап сделается и обновления внесут)

и при симпле никого не нужно выгонять

(81) не принципиально. И так и так можно.

(66) >> пыталась "завести" себе хранилище. Но после того, как время обновления увеличилось почти в 2 раза - час на захват, час на помещение изменений в хранилище...

2 часа может понадобиться на создание хранилища и первое подключение новой базы к хранилищу.
В дальнейшем помещение изменений в хранилище и обновление из хранилища происходит достаточно быстро. Хотя и не секунды, как пишут некоторые, когда речь идёт о больших конфигурациях и помещении большого количества изменений, связанных с обновлением.
Но в любом случае никто не заставляет это время сидеть у пялиться в монитор. Можно параллельно решать другие задачи (обновлять прочие мелкие базы, например). И никто не запрещает вообще автоматизировать этот процесс.

скрипт написать
1. загрузка цф в конфу
2. бэкап
3. обновление
4. запуск и обработчики

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

(87) по сети лучше не стоит. лучше сервер хранилища юзать

(88) что вы имеете в виду под сервером хранилища? У нас на отдельном сервере и развернуто хранилище, а к нему доступ по локальной сети.

(69) >> Думаешь, проблема увеличения времени, из-за того, что хранилище файловое?

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

(78) Благодарю.

(89) доступ по tcp прописан?

(89) есть такая прога: сервер хранилища

(92) обычный путь аля \\server\1c\confStorage

(93) прикольно, буду знать)

(94) лучше поднимайте сервер хранилища

(94) файлы по сети имеют свойства биться в самый неподходящий момент

не пойму какая проблема с хранилищем? У нас файловое хранилище и конфа из хранилища подтягивается достаточно быстро. И зачем выгонять пользаков во время обновления из хранилища? После того, как новая конфа будет сохранена, то планово выгоняешь пользаков и обновляешься.
1) Если реструктуризация адовая - можно попробовать либо обновиться на сервере, либо использовать реструктуризацию v2.0. Выигрыш по сравнению с в1.0 примерно в два раза. Проверено на остаточном регистре с ахулиардом записей.
Если реструктуризации нет - то сравнительно быстро. Чему там долго обновляться? Формам, или текстовому коду?
2) Если по каким-либо причинам реструктуризация не произвелась, то можно откатиться, подкинув в таблицу Config ранее сохраненную конфу. У меня пару раз так было - удалось подлечить. если не удастся - тогда уже разностный бэкап в среднем, на полчаса потери инфы. Ну тут уж каждый владелец сам решает, что для него критичней.

(93) Оно?
https://wiseadvice-it.ru/o-kompanii/blog/articles/hranilishhe-konfiguracii-v-1s-8-3-ustanovka-i-nastroika/

(98) обновляться всегда нужно на сервере. зачем на клиенте то вообще?

(98) Да я только ЗА хранилище конфигураций.
Надо, действительно, проанализировать в чем дело и почему так долго происходит захват/помещение данных в него.

(98) можно и без подкидывания конфига. есть опция - вернуться к конфигурации бд

(99) Да.

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

(101) мне помогла очистка кэша

(89) https://its.1c.ru/db/v8320doc#bookmark:dev:TI000001130

(106) да спасибо, уже загуглил за это дело)

(102) Если конфа на хранилище, эта опция недоступна )0

(108) если все сломалось, то можно и отключиться

(109) Идеально )))))))))))))))

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

(104) >> ни разу с такой проблемой не сталкивался.

Это не значит, что такой проблемы не существует.
Мы сталкивались. Не скажу, что прям часто, но бывало.
После перехода на вариант работы с сервером хранилища проблемы ушли.

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

Вы ох*ели совсем?... Херить хранилище с изменениями за несколько лет только из-за того, что кому-то впадлу поднять и настроить службу, вовремя делать бекапы хранилища и правильно организовать работу с хранилищем? Да ну на. Хранилище, к которому подключена боевая база как раз и нужно для хранения истории всех изменений, которые попали в итоге в продуктив. Более ни для чего оно не нужно.
Для технических проектов (доработок) делаются отдельные хранилища. Да и то не всегда, а только когда это реально нужно - при групповой разработке или на длительные проекты.

(112) а что мешает бэкапить хранилише?

(0)

3-4 часа это время общее?
1) Размер базы ?
2) Время применения изменений?
3) Накатить cf-ник с измененным комментарием в общем модуле это тоже займет 4 часа ?
4) Характеристики сервера - процессор, ОЗУ, дисковоая подсистема. А то может у вас на сервере "целых" 4 Гб ОЗУ, а мы тут копья ломаем

P.S.
Либо сложилась ситуация "а мы всегда так делали", либо люди просто оплачивают себе сверхурочные

(112) сервер хранилища это издевательство. Там, где используется хранилище, обычно, используется групповая разработка, которая намекает на то, что задач великое множество. В связи с этим, все обновления необходимо протестить на базах, которые подключены к хранилке. Но о чудо!- иногда выходят свежие релизы платформы, которые тоже как-то надо тестировать (было как-то раз, когда после выхода нового релиза асинхронные вызовы в толстом клиенте обычного приложения просто отказались работать). И всё. Сервер хранилища не поддерживает работу в различных платформах. И что, плясать с бубном разворачивая отдельные сервера с базами? Ооочень неудобно.

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

(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) на больших таблицах раструктуризация может занимать часы