Доброго времени суток!
Обновляю УПП с 1.3.69.2 на 1.3.69.3.
Из конфигуратора запускаю 1С в режиме предприятия, подтверждаю легальность получения и после этого висит крутящееся колесико, никаких сообщений. Программа вроде как работает, но процесс никак не кончается.
Кто обновлялся на 1.3.69.3? Сколько времени заняло выполнение обработок обновления?

(0) а скачать с сайта и обновиться уже в компе не пробовал?

(1) Именно это я делаю

(2) так обновление накатывается в конфигураторе, а ты открываешь 1с-предприятие.. вот я и спросил..

(3) Он завершающий этап выполняет.
(0) Можно ж отладчиком посмотреть, что там оно у тебя творит

(4) В журнале регистрации огромное количество добавляемых записей в Регистр сведений.Состояния контрагентов БЭД - это как раз новый объект в этой версии конфигурации.
Это получается, что для каждого контрагента 1С пишет запись в этот регистр. А у нас контрагентов больше 600 тыс. Сколько же времени это займет?

(4) ммм.. теперь понятно.
(5) Много времени займет. А сколько - никто не скажет :)
И не секрет это :)

ЗЫ. у меня реорганизация справочника в 7.7 (всего-то изменил свойство одного реквизита! :(( )длилась 5 часов. ГБ взвыла. Зато сейчас довольна.

+6 а записей в справочнике было около 18.000

(5) а транзакцию там не поставили при обработке записей РС ? Без транзакции будет очччень долго.

если за 1 секунду 15 записей записывается в РС, то для > 600 тыс. получается около 12 часов
Круто!
Это если не будет сбоев ни на сервере приложений 1С, ни на sql server. А если произойдет сбой, то все с начала. Прикольно!

(9) ну, тут уж уповай на небеса..

(9) пока 12 часов еще не прошли, ну можешь попробовать поставить транзакцию... Можно еще дополнительно посмотреть, насколько критична инфа - вполне вероятно, что процедуру нужно обязательно не забыть выполнить, но при первом запуске ее реально пропустить. Вытащи обработку в отдельную обработку и запусти первый запуск без нее, а затем повесь ее в своем личном сеансе и не будет так критично, сколько времени она будет выполняться.

(11) Спасибо, посмотрю.
Вчера оставляла в ночь, но утром отвалился sql server после регламентного перезапуска, с утра все с начала

А почему сначала на тестовой копии не потренировались?

(13) как вариант вполне возможно, что в тестовой такое количество контрагентов никому не нужно и их там просто нет. Копию отсадили лет 100 тому назад - так и живут эти копии в параллельной реальности, не вытаскивая туда коммерчески актуальную инфу.

(13) Хотите, чтобы я сначала 2-е суток тренировалась на копии, когда прибегает главбух и говорит, что ему нужно срочно обновить на последнюю версию, потому что там новый регламентный отчет? К тому же раньше таких проблем не было.

(15) ну Вы хотя бы архивы делать не забывайте, а то ГБ не только прибегать будет, а еще и затоптать попробует :)

(15)А подумал что тебе ГБ скажет если база грохнется? Что-нибудь типа: "Уволен!"?

(15) Мне все равно.

(16), (13) Я архивы делаю автоматически, спасибо, не забываю, и хранятся они 2 недели. А при обновлении делаю 2-мя способами. Здесь нет проблем. И обновление базы занимает пол рабочего дня и много ресурсов, поэтому тренировочные обновления я перестала делать после того, как база стала > 20 ГБ.

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

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

(21) Зачем на том же? Для тренировок и разработки должен быть отдельный сервер.

(22) Очень дорого покупать 2 серверных лицензии. Для моих тренировок работодатель не будет этого делать.

(23) Значит, ему дешевле ждать, пока рабочая база по 12 часов обновляется, и пользователи не могут работать. Хозяин-барин.

(23) Зачем вторая лицензия на сервер? Лицензия дается на физическую машину. Будь мужиком. Запусти второй сервер в командной строке, да по другому порту.

(25) Мда... чет я погорячился по поводу "Мужика". :) Но на один ключ можно поднять несколько серверов.

(25) Я про SQL Server.
(24) 12-часовое обновление - это что-то из ряда вон выходящее, обычно все проходило за 2-4 часа вместе предварительным резервным копирование. Никто не ожидал, что это обновление займет столько времени.
(26)не переживай. У нас работают 2 сервера приложений 1С на одной машине на разных портах, 8.1 и 8.2. Скоро еще 8.3 будет

(27) А вот второй скуль для тренировок необязателен, хоть и желателен в идеале. Очень сложно уронить скуль обновлениями. Тут надо сильно постараться.

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

" Как показывает практика базы 1С и не 1С-ные базы могут плохо уживаться на одном sql сервере"


Практика какая-то ущербная...
У меня они прекрасно уживались даже при приличной нагрузке...

(30) может и ущербная, может можно и лучше настроить сервер, но это в ведении системных администраторов, возможно, что при имеющемся оборудовании лучше сделать нельзя, не знаю.

(29) Это миф или криворукие админы. У нас куча баз 1С и не только 1С прекрасно себя чувствуют на одном сервере скуля.

(27) SQL server тоже можно поднять несколько экземпляров на одной машине (если покупали с 1С и старая лицензия). У нас два экземпляра поднято на одной машине. Разграничили их по памяти, по процессорам, и по дискам. Сидят себе, не мешаются друг другу.

(32) Там действительно есть особенность. Кэш при разной природе нагрузки может скидываться часто. Мы как раз для этого подняли второй экземпляр. На одном рабочие базы. На втором - отладочные и для разработки.

(32) А у нас регулярно отваливается sql сервер во время работы пользователей. Последний раз он сдох во время ТИИ базы 1С, после чего она повредилась на уровне таблиц в БД, пришлось использовать средства sql для восстановления.
(27) покупали не с 1С и на машине не хватит ресурсов, чтобы 2 сервера работали

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

(29) легенды криворуких одминов сидящих возле глючного железа

(32) И базы по 900 Гб? И работает все как часы?

(36) что-то странное советуешь... У них нет лишней лицензии на приложение, а ты про субд толкуешь...

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

>а не еще одна воркстэйшин,

собранная на савеле

на которую накатили серверное ПО.

с диска 5-тилетней давности "Вся винда за 100 рублей"

(38) базы по 900 гб крутить нужно не на том же физическом железе, на которое установлено приложение 1С-Сервер "Кластер серверов". Нужно реально ставить сервер для СУБД, забивать этот сервер СУБД дисками большой емкости с зеркалированием и прочими ништяками и работать в классической трехзвенке, а не двухзвенке.

Судя по вашему замечанию о дороговизне лицухи на 1С-сервер - это не ваш путь.

(41) С чего вы взяли, что у нас все на одном сервере, sql на одном сервере, 1С-сервер на другом. И говорила я про стоимость лицензии на sql server, кстати цена 1с-ной серверной лицензии тоже не маленькая, но речь шла не о ней.

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

Кстати, могу предположить, что ваши проблемы в (0), скорее всего, как раз и обусловлены проблемами администрирования скуля, а не проблемами 1С. Или всё в комплексе.

(43) Я не говорила, что разрушение одной базы повлияло на работу других баз. Я в (35) написала, что у нас упал sql сервер, после чего бд стала повреждена.

(45) Хм. Я прочитал так: "Последний раз он сдох во время ТИИ базы 1С". ТИИ не должно вызывать падения скуля. Так что здесь возможно проблемы с железом.

(44) У меня была проблема в том, что обработки при обновлении ИБ работали очень долго при последнем обновлении конфигурации, чего раньше никогда не было. Я хотела узнать как прошло обновление на 1.3.69.3 у других пользователей УПП. Откуда можно было заранее знать, что при обновлении ИБ для каждого контрагента (которых у нас > 600 тыс.) будет создаваться запись в новом РС.

(35) почему у меня ничего не отваливается?

(42) в общем, все плохо!
Так больше нельзя.

(46) прошу прощения, возможно я нечетко сформулировала

(47) "Откуда можно было заранее знать, что при обновлении ИБ для каждого контрагента (которых у нас > 600 тыс.) будет создаваться запись в новом РС" - вот как раз для этого обновления накатывают сначала на тестовой базе, а не сразу на боевой. И в своей жизни я сталкивался с ситуациями (хоть и не часто), когда ОФИЦИАЛЬНЫЙ релиз приводил к критическим ошибкам и невозможности работать, и приходилось ждать выхода следующего релиза.

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

Да. Кстати скажем, это же наверное очень долго приходится восстанавливать базу из бакапа и есть опасность, что не взирая на его наличие, бакап может и не подняться.
Так что после неудачного обновления на боевом серваке можно очень много времени убить. Причем, времени пользователей.
Впрочем, это у вас и так произошло, правда, не столь критично - не до убийства.

>Откуда можно было заранее знать, что при обновлении ИБ для каждого контрагента (которых у нас > 600 тыс.) будет создаваться запись в новом РС

в "библиотеке обработок обновления" все написано что будет вызвано при обновлении...

>для каждого контрагента (которых у нас > 600 тыс.) будет создаваться запись в новом РС"

накой хрен они кстати нужны...

(51) для этого есть копия базы, сделанная непосредственно перед обновлением. Копия восстанавливается в рабочую базу и пользователи работают дальше, как до обновления
(53) копия делается 2-мя способами, в sql при резервном копировании можно поставить галку verify backup as finished, хоть какая-то гарантия.  Restore делается 15 мин., из .dt около 1ч. Из хоть 2-х копий одна восстановится.
А так-то можно вообще ничего не обновлять, вдруг чего, риск есть всегда

(54) где это можно увидеть, пожалуйста, поподробнее

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

>где это можно увидеть, пожалуйста, поподробнее

"сравнить/объединить" в пофигураторе... там все есть

(58) лишняя база для теста есть.
Здесь много можно говорить, каждый все равно при своем мнении останется.
(59) Где конкретно? Даже спецы из техподдержки не знают

>Где конкретно? Даже спецы из техподдержки не знают


ОбщийМодуль.ОбновлениеИнформационнойБазыЭД

Процедура ПриДобавленииОбработчиковОбновления(Обработчики) Экспорт

...........

Обработчик = Обработчики.Добавить();
Обработчик.Версия = "1.1.20.3";
Обработчик.Процедура = "ОбновлениеИнформационнойБазыЭД.ПроверитьКонтрагентовБЭД";
Обработчик.НачальноеЗаполнение = Ложь;

(61) спасибо
Да, тут работы не на 2 часа, если проверить все обработчики
Там еще и в других модулях есть процедура ПриДобавленииОбработчиковОбновления(Обработчики) Экспорт

(5) 600K+ контриков? Мамодорогое. Вы работаете со всеми фирмами и ИП России и ближайшего зарубежья, что ли?

(63) Хочешь себе столько? "Засоси" через сервис создания контрагента по ИНН. Нагенерируй только правильных, годных ИНН-ов.

(64) Зачем? Чтобы получить тот же гимор что и у ТС?

(63) оказываем разовые услуги физическим лицам

В тестовой базе на свежей копии рабочей обновление заняло 1,5 часа. В рабочей работает уже > 12. Где конец? Причем некоторые транзакции завершены, а некоторые не завершены.

(66) так а в чем отличие данных в тестовой базе от данных рабочей?

(67) В рабочей базе еще добавился день работы пользователей.

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

(69) т.е. без подтверждения легальности каким-то образом попадает обработка ожидания, на которую нет ответов пользователя или они не требуются, но ожидание висит... хороший такой глюк.

(70) нет, обработка работает, в ЖР пишутся записи об изменении РС.СостоянияКонтрагнетовБЭД. Но сначала сначала они пишутся со скоростью 15 записей в секунду, потом постепенно, через несколько часов работы скорость падает до 4-5 записей в секунду, при этом появляются незавершенные транзакции. Если прервать и начать заново, то все очень быстро завершается и приходит к успешному завершению обновления.

(66) оказываем разовые услуги физическим лицам
И что, каждый раз нового контрагента для этого заводите? Почему бы не завести контрагента "физлицо" и не оказывать услуги ему одному? Зачем базу-то раздувать?

+ (72) просто у меня тоже УПП и мы продаем продукцию сотрудникам. Сделано именно так - создан контрагент Физлицо, на него выписываются документы и от него принимаются деньги. Уже лет 8 так работаем, претензий нет ни у кого.

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

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

(75) У нас тоже предоплата, но выполнение работ производиться в течении 2-х недель, иногда и дольше. И нужен билинг по подразделениям и участкам. Где сколько чего выполнено и где есть дебиторская задолженность, а где есть кредиторская.