Недавно, при динамическом обновлении конфигурации sql -базы на платформе 8.2 возник сбой, после которого, перестал запускаться конфигуратор, выдавая сообщение «Внимание!!! При обновлении данных, после последней реструктуризации, произошла ошибка. Повторить обновление?», если ответить Да, то появлялось второе сообщение «Обнаружена незавершенная операция сохранения конфигурации. Для продолжения работы необходимо завершить операцию.»
Данная проблема я не встречал ни разу на платформе 8.3
До обновления конфигурации я не делал архивную копию и потому восстановить базу из резервной копии предыдущего дня невозможно без потери информации.
Поиск решения вопроса в интернете дал мне надежду. Очень помогла статья на сайте 42clouds Незавершенная операция обновления конфигурации БД
Как известно, вся информационная база представляется в базе данных в виде набора таблиц. Среди них есть несколько таблиц, которые обязательно присутствуют в представлении любой информационной базы ( подробнее можно посмотреть на диске ИТС Размещение данных 1С:Предприятия 
. Из всех этих таблиц для нас имеет значения только 2 таблицы из них:
- dbo.Config – основная конфигурация информационной базы. Эта конфигурация соответствует реальной структуре данных и используется 1С:Предприятием 8.0 в режиме Предприятия данные переносятся в эту таблицу после обновления
- dbo.ConfigSave – конфигурация, редактируемая Конфигуратором. Конфигурация из ConfigSave переписывается в Config при выполнении “Обновления конфигурации базы данных” в Конфигураторе, а наоборот – при выполнении в Конфигураторе операции “Конфигурация – Конфигурация базы данных – Вернуться к конфигурации БД”
Согласно информации в интернете проблема связана с испорченной таблицей dbo.Config и предлагается 2 варианта решения:
Вариант 1: Воспользоваться возможностью скопировать таблицу dbo.Config из идентичной базы в неработающую
Вариант 2 Удалить все найденные изменения. Для этого вам необходимо выполнить 3 запроса:
- delete from config where FileName = ‘commit’
- delete from config where FileName = ‘dbStruFinal’
- delete from config where FileName = ‘dynamicCommit’
Я выполнил все 3 запроса, но говоря, что иногда достаточно выполнить только первый запрос.
В других статьях в интернете предлагают другой вариант по шагам:
- Делать бэкап рухнувшей базы средствами SQL.
- Очистить таблицу dbo.config рухнувшей базы SQL- Profiler запустить команду:
Use BaseName go Delete From [DBO].[Config] go
где BaseName – это имя рухнувшей базы.
Обнаружена незавершенная операция сохранения конфигурации
Ошибка возникает после динамического обновления.
При запуске 1с сначала выходит диалог с ошибкой «При обновлении данных после последней реструктуризации произошла критическая ошибка. Повторить обновление».
Если попытаться обновить, бывает два варианта сценария
- все применяется корректно, но потребуется завершить работу пользователей для обновления
- обновление не проходит: выходит сообщение («Обнаружена незавершенная операция сохранения конфигурации«)
Причины и обстоятельства
Такие ошибки возникают обычно на старых версиях платформы. В настоящее они время проявляются очень редко (на 8.3 не встречалось ни разу).
Также замечу: в последней платформе 8.3.8 появилось долгожданное динамическое обновление в клиент-серверном режиме без перезапуска конфигуратора (ранее такое было только на файловых базах).
Можно долго говорить о том, что не надо пользоваться динамическим обновление, необходимо организовывать работу так, чтобы это происходило реже, но это документированный функционал платформы, соответственно он должен работать корректно.
Что же делать при такой ошибке?
- запомнить/записать точное время возникновения ошибки.
- сообщить всем о том, что ошибка известна, вы работаете над ее решением и база некоторое время работать не будет (далее игнорируете всех, кто не может вам помочь иначе вас затерроризируют вопросами)
- сделать полную копию базы данных
- развернуть(открыть) копию базы, где конфигурация соответствует составу реквизитов (они должны совпадать), код модулей и форм может отличаться (быть не актуальным)
- если есть отличия в реквизитах постараться «свести» конфигурации
Если копий нет, то в случае если конфигурация типовая и правки не затрагивают структуру данных, то разворачивайте типовую конфигурацию.
Далее, производите замещение конфигурации из «копии» в «исправляемую» базу
Для этого Запускаете SQL Management Studio и выполняете такой запрос:
delete from [ИмяИсправляемойБазы].[dbo].[Config] GO insert into [ИмяИсправляемойБазы].[dbo].[Config] SELECT [FileName] ,[Creation] ,[Modified] ,[Attributes] ,[DataSize] ,[BinaryData] FROM [КопияБазы].[dbo].[Config] GO
В 99% случаев он вам поможет (мне помогало 3 раза). Исправление занимало от 5 до 20 минут.
Далее восполняете пробелы в коде. Если конфигурация подключена к хранилищу, необходимо синхронизировать захваченные объекты (отпустить и захватить заново), внести правки.
Если версия файловая произведите тестирование утилитой «C:\Program Files (x86)\1cv8\8.*.*.*\bin\chdbfl.exe».
При отсутствии конфигурации/копии:
- смотрите записи таблицы dbo.ConfigSave, при наличии — очищайте (пробуйте запустится)
- смотрите записи таблицы Config, на поле «FileName», если есть со значением «commit»,»dbStruFinal» или «dynamicCommit» — удаляйте
- либо в этой же таблице смотрите записи с именами подобными %_dynupdate_ % (здесь потребуется «по манипулировать» с датами и именами, но у меня не получалось)
Не помогло?
В остальных случаях придется поднимать и откатывать копии базы данных или транзакции (при полной модели восстановлении).
При небольшом документообороте может оказаться проще откатить базу на несколько минут назад — быстрее восстановить работоспособность (внести данные заново), чем поднимать другие копии.
Рекомендации
- Используйте полную модель восстановления
- Чаще делайте копии и базы, и конфигурации (в идеале: перед каждым обновлением)
- Используйте хранилище для разработки
- Держите рядом копию базы (это сэкономит время для восстановления)
- При подозрительных ошибках в момент обмена с хранилищем не обновляйте базу при работающих пользователях
В моем случае возникла ошибка snegopat-а при обмене с хранилищем, а затем такая же в момент обновления — с вытекающими проблемами.
Реклама – это не выигрывание призов Эффи и Золотых Львов. Это зарабатывание денег рекламодателям.
Внимание!!! При обновлении данных, после последней реструктуризации, произошла ошибка. Повторить обновление?
Опубликовано: 16.02.2018 /
Переезжали мы на новый сервер. На нем SQL и 1C. В сравнении со старыми был намного круче. И тест Гилева это тоже подтвердил: против 10-15 на старых серверах выдавал 39. Поэтому мы сразу после покупки перенесли базу и начали работу.
Но в какой-то момент что-то пошло не так — пользователи стали жаловаться на медленную работу. Произвели определенные настройки сервера и служб (какие — тема отдельного поста) и решили перезагрузить сервер, благо скорость перезагрузки — 2 минуты (на других серверах до 10 доходило). После этого при входе в 1С получаем следующее сообщение:
«Внимание!!! При обновлении данных, после последней реструктуризации, произошла ошибка. Повторить обновление?» «Да, Нет»
После нажатия кнопки «Да» появляется следующее:
«Обнаружена незавершенная операция сохранения конфигурации. Для продолжения работы необходимо завершить операцию.»
Первое, что решил сделать — CHECKDB на в Managment Studio — после 2х часов ожидания (база 500 ГБ) — все ОК.
На просторах сети нашел информацию, что такая же ошибка бывает при динамическом обновлении.
Решения, предложенные в сети сходу не помогли, но вкупе с другими действия дали результат. Итак, что я делал:
Решение:
- То, чего не хватало для решений из сети:
sp_configure ‘allow updates’, 1
reconfigure with override
go
2. Переводим базу в режим восстановления
alter database [db_name] set EMERGENCY, SINGLE_USER
3. Выполняем тестирование базы:
dbcc checkdb(‘db_name’, REPAIR_ALLOW_DATA_LOSS )
4. Выводим базу из режима восстановления:
alter database [db_name] set ONLINE, MULTI_USER
5. В принципе, если уверены что с самой базой все ок, то можно не делать 2-4 пункты. Далее выполняем два запроса в профайлере SQL:
delete from config where FileName = ‘commit’
delete from config where FileName = ‘ dbStruFinal’Эти записи и отвечают за динамическое обновление — можно не бояться их удалять.
В рабочих версиях баз запросы:
select * from Config WHERE FileName = ‘commit’
select * from Config WHERE FileName = ‘dbStruFinal’
будут пустые.
6. возвращаем настройки:
sp_configure ‘allow updates’, 0
go
7. После этого удалось запустить конфигуратор и база заработала.
Также база может заработать после удаления первого флага.
Еще из решений, которые есть в сети, полная замена таблицы Config.
Что у меня использовалось:
Платформа 1С: 1С:Предприятие 8.3 (8.3.10.2466)
SQL: Microsoft SQL Server 2008 R2 Standard Edition (64-bit) 10.50.6220.0
Также обратил внимание, что проблема повторяется на всех версиях платформ и SQL.
Всем удачи с решением таких проблем. Если есть трудности, обращайтесь, помогу.
p.s. бекап был, но терять даже несколько часов работы не очень хотелось
Юзер123
27.11.17
✎
10:40
Добрый день.
С прошлой недели стал замечать интересную фигню в работе 1С.
8.3.10.2580
Работаю с обработкой или общей формой . Меняю значение реквизита / меняю код добавляю новые процедуры или функции.. Т.е. все как обычно. Делаю динамическое обновление программы. У всех пользователей которые зашли после обновления все изменения работают. Все как надо. Я не закрываю конфигуратор!!!1 закрываю объект с которым работал . открываю его опять и там все как было до изменения. Конфикоратор говорит что база не изменялась, но если я запущусь в режиме отладки то все внесенные изменения ранее пропадают. . Если перезапустить конфигуратор — все становится на свои места. Изменения появляются. Но после любого изменения и динамического обновления опять откат… кто сталкивался? как лечится?
Волшебник
модератор
27.11.17
✎
10:42
динамическое обновление очень глючное
ildary
27.11.17
✎
10:44
(0) 8.3.10.2466 — у меня пару раз было подобное безо всякого динамического обновления. Вылечил ребутом тестового сервера —
аптайм был где-то 3 недели, а авторебута не было.
nordbox
27.11.17
✎
10:45
динамическое обновление ЗЛО
lodger
27.11.17
✎
10:46
Конфикоратор глюкнуло от демонического обновления.
остановить 1с(если клиент-сервер, то сервер тоже). дропнуть кэш(если клиент-сервер, то сервер тоже). запустить 1с(если клиент-сервер, то сервер тоже).
Про100Филя
27.11.17
✎
10:46
Смизжено:
«Здравствуйте, меня зовут Алексей и я делаю динамическое обновление.
Раньше, я делал динамическое обновление по три или даже целых пять раз в день.
Я мог не спросить пользователей, не сделать бекап средствами СУБД и динамически обновить базу ради изменения макета печатной формы счета на оплату.
Но потом случилось горе и в одно прекрасное обновление база просто не запустилась.
Это был ч0рный день в моей жизни.
Я потерял друзей, коллеги отвернулись от меня.
Жена меня бросила и дети не хотят со мной разговаривать.
Попа болела после долгого и многозначительного разговора с начальством.
И я решил изменить свою жизнь.
Я теперь занимаюсь спортом
Стал посещать бассейн.
Питаюсь правильно и соблюдаю правила дорожного движения.
Сегодня у меня праздник.
Я уже 30 дней не делаю динамического обновления без ахивации базы данных средствами СУБД.
Я практически готов полностью отказаться от динамического обновления.
Вообще не обновлять динамически.
Преодолеть зависимость от динамического обновления мне помогли 12 простых шагов:
12 ШАГОВ , РАЗРАБОТАННЫЕ САМИМИ ДИНАМИЧЕСКИМИ ОБНОВЛЯЛЬЩИКАМИ
1. Признать свое бессилие перед поведением платформы 1с при динамическом обновлении.
2. Согласиться с утверждением, что без посторонней помощи не обойтись.
3. Мысленно перепоручить себя некой Высшей силе, которая поможет.
4. Проанализировать свои поступки.
5. Признать перед собой и кем-то еще свои ошибки.
6. Не сомневаться, что бекап перед динамическим обновлением сработает.
7. Просить высшие силы избавить от недостатков.
8. Составить список всех людей, кому причинили зло, и захотеть загладить свою вину перед ними.
9. Лично возместить этим людям ущерб, нанесенный вами и вашим динамическим обновлением.
10. Продолжать самоанализ и, при малейших ошибках, сразу признавать, что вы их таки совершили.
11. Не переставать размышлять и благодарить помощника из пункта 3.
12. Достигнув пробуждения, благодаря пунктам 1-11, помогать другим динамическообновлялщикам.
АЛИЛЛУЯ братья и сестры!
АМинь!»
Юзер123
27.11.17
✎
10:56
(5) распечатал!! 111 =))
Юзер123
27.11.17
✎
10:56
(4) Спачибо
Fragster
27.11.17
✎
11:02
начиная с 8.3.10.25хх очень сильно сломали демоническое обновление
Fragster
27.11.17
✎
11:03
и в конфигураторе динамически обновленной базы ничего делать нельзя
ildary
27.11.17
✎
11:05
(8) спасибо за предупреждение! Может настал тот час, когда сами разрабы решат «Хватит это терпеть» и таки починят?
Fragster
27.11.17
✎
11:05
методика, когда обновление готовится в базе разработчиков (хранилище, и т.п.), а потом .cf накатывается на рабочую (даже динамически), работает
Fish
27.11.17
✎
11:08
(9) А я на 8.3.10.2561 пару раз использовал ДО, и после в конфигураторе что-то делал. Что теперь со мной будет? :))
Fish
27.11.17
✎
11:10
+(12) Да, у меня клиент 1С 64х.
nordbox
27.11.17
✎
11:12
(12)>>Что теперь со мной будет? :))
Десять лет расстрела с повешением в газовой камере и каждый день до смерти. )))))
Йохохо
27.11.17
✎
11:15
(12) Слухай сюды! Положь колдобину со стороны загогулины и два раза дергани за пимпочку. Опосля чего долбани плюхалкой по кувывалке и, коды чвокнет, отскочь дальшее, прикинься ветошью и не отсвечивай. Потому как она в это время шмяк… ту?дыть, сподыть, ёксель?моксель, ерш твою медь… Ш?ш?ш! И ждешь, пока остынет. Остыло — подымаесся, вздыхаешь… Осторо?о?ожненько вздыхаешь про себя, шобы эта быдла не рванула! И бегишь за угол за поллитрой. Потому как пронесло!
elCust
27.11.17
✎
11:15
(9) А подробнее можно, чем обусловлено Ваше высказывание?
Какие ограничения накладываются на работу в конфигураторе после ДО?
Я периодически на базе разработки делаю ДО, никаких глюков не выявлено. (8.3.10.2580).
Полагаю, что кэш страдает после ДО, в случае, когда операционка загажена.
Fish
27.11.17
✎
11:19
(14) Ну вообще, я обычно делаю по методу (11), но был один-два раза, когда после накатывания cf, выявлялась какая-нибудь незначительная ошибка — запятую забыл в макете поставить или ещё какая опечатка. И для скорости правил прямо в рабочей, применяя ДО. Пока прокатывало, хотя опасения были, конечно.
Fragster
27.11.17
✎
11:22
(12) возможно, ты потерял часть того, что ты демонически обновил.
Fragster
27.11.17
✎
11:25
(16) теряются доработки от последнего недемонического обновления и до демонического. причем произвольным образом (если не закрывать доработанный модуль, то его даже пару раз можно обновить, если же закрыть, обновить демонически, запустить отладку, открыть доработанный модуль, то код может быть потерян). Лично видел, как теряется код модулей, изменения макетов СКД. Одним из условий является запуск отладки после демонического обновления.
Fragster
27.11.17
✎
11:26
очень сильно началось на 8.3.10.25хх и последующих. на 8.3.6.2639 все еще воспроизводится.
Леха Дум
27.11.17
✎
11:31
Наблюдаю то же самое. Спасает снос папок с кэшем.
Fish
27.11.17
✎
11:33
(18) (19) Да вроде ничего не потерялось (тьфу-тьфу-тьфу). Возможно, потому, что на отладку не запускал после ДО.
romix
27.11.17
✎
11:44
(0) последние релизы 8.3 более или менее нормально работают с динамическим обновлением, но есть недокументированная особенность — надо чистить кеши.
В параметрах запуска 1C:Предприятия (тестовая и рабочая база) указать параметр:
/ClearCache
При основном обновлении (с отключением пользователей) надо пользоваться бат-файлом:
set LOG_FILE="scripts.log"
set SERVICE_1C_NAME="1C:Enterprise 8.3 Server Agent (x86-64)"
set SERVICE_RAS_NAME="1C:Enterprise 8.3 Remote Server"
set CNTX_PATH="C:\Program Files\1cv8\srvinfo\reg_1541"
set PFL_PATH="C:\ProgramData\1C\1cv8"
set TEMP_PATH="C:\Windows\Temp"
echo stop %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
sc stop %SERVICE_1C_NAME%
sc stop %SERVICE_RAS_NAME%
timeout 5
taskkill /f /im "rphost.exe"
taskkill /f /im "rmngr.exe"
taskkill /f /im "ragent.exe"
taskkill /f /im "ras.exe"
timeout 5
echo done stop %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
echo clean temp %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
DEL /Q /F /S %CNTX_PATH%\snccntx*
DEL /Q /F %PFL_PATH%\*.pfl
DEL /Q /F /S %TEMP_PATH%\*.*
echo done clean temp %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
echo start %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
sc start %SERVICE_1C_NAME%
sc start %SERVICE_ RAS _NAME%
echo Service %SERVICE_1C_NAME% restarted at %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
pause 1000
https://its.1c.ru/db/metod8dev/content/5899/hdoc
Остановка службы 1С:Предприятие с очисткой временных файлов.
Веселый собака
27.11.17
✎
11:44
(0) Я вот перезапускаю конфигуратор, когда он просит, и все пучком.
Fish
27.11.17
✎
11:45
(24) В последних версиях платформы уже не просит 
romix
27.11.17
✎
11:47
+(23) Параметры запуска находятся в стартовом окне, где кнопки Добавить-Изменить-Удалить. По кнопке «Изменить…» перейти на вторую закладку и ввести (или добавить) значение
/ClearCahce
в поле «Дополнительные параметры запуска».
Fish
27.11.17
✎
11:49
(26) Емнип, ключ /ClearCahce работает только для тонкого клиента, а конфигуратор вроде — это всегда толстый. Непонятно, как этот ключ помогает при ДО. Или я ошибаюсь?
Fragster
27.11.17
✎
11:49
(26) не поможет, если не перезапускаешь после демонического обновления. например обновил запустил отладку, проверяешь работу — работает. открываешь какой-нибудь (допустим) другой модуль, программируешь дальше, сохраняешь конфу. все. изменениям из демонического обновления хана.
romix
27.11.17
✎
11:51
(27) Я не могу сейчас найти документацию на этот ключ поиском по сайту 1С. Может он всё там чистит, включая и конфигурацию?
romix
27.11.17
✎
11:52
(27) 10060739 Кеш метаданных
Проблема:
При частом изменении конфигурации, при использовании тонкого клиента или толстого клиента в управляемом режиме работы, происходит увеличение объема кэша клиент-серверных вызовов.
Способ обхода:
Выполнить запуск с параметром командной строки /ClearCache.
Дата публикации: 2010-08-06
romix
27.11.17
✎
12:12
С кешами вообще какая-то ерунда — если они нужны для ускорения обращений без ZIP упаковки и распаковки, то как бы не оказалось, что на современных системах результат получается обратный.
Если нужны для полнотекстового поиска по модулям, то может как-то это выделить — базой данных искать.
Я не понимаю, зачем они нужны (т.е. какое действие ускоряют). Если секретный ключик /ClearCache их выключает и всё становится хорошо, то возникает вопрос, а зачем они включены.
romix
27.11.17
✎
12:14
Скорее всего, ускоряет запись за счет записи без транзакции — а она всегда и повсюду глючит (в любых СУБД).
Дык ё
27.11.17
✎
14:52
romix
27.11.17
✎
20:00
Вот сейчас у меня сглючило — я посмотрел, а на этой базе ключика-то /ClearCache и нет.
Tateossian
27.11.17
✎
21:30
Динамичное обновление самое лучшее:) Нужно только кэши чистить.
Tateossian
27.11.17
✎
21:31
(31) Можно файл кэша открыть и посмотреть чего там. (29) https://its.1c.ru/db/v8310doc#bookmark:adm:TI000000495
Andreyyy
28.11.17
✎
01:07
(20) Поддерживаю, сломали что-то.
1Сергей
28.11.17
✎
06:47
Мыши и кактусы…
PCcomCat
28.11.17
✎
08:32
(11), (17) А я попадала на том, что при таком способе (сравнение, объединение с cf) тоже не все изменения накатывались — тупо конфигуратор не видел изменений.
Fragster
28.11.17
✎
10:31
(39) при чем тут сравнение?
romix
01.12.17
✎
14:28
(34) Вчера еще раз словил эту же проблему — тоже не было /ClearCache.
portowyi
01.12.17
✎
14:32
(0) Лечится отказом от динамического обновления. Ибо программисты 1С бывают двух типов — те кто уже положил базу динамическим обновлением и те кому это еще предстоит.
kiruha
01.12.17
✎
14:40
(42)
Выше отписали —
лечится чисткой кэша, динамически обновлять можно и нужно в некоторых случаях(например мелкая ошибка в модуле набора регистра)
Ради более красивого отчета — это конечно изврат
portowyi
01.12.17
✎
14:53
(43) У меня был случай года три назад — динамическое обновление (чистка кэша при помещении, чистка кэша при получении изменений из хранилища на боевой базе) положило базу, причем довольно интересно — стало невозможно авторизоваться в базе. Перезалив таблицы users не помог, восстанавливали из архива. После этого динамическое обновление у нас применяется разве что только на тестовом контуре.
romix
01.12.17
✎
17:36
(44) Пару раз в день делаю динамическое обновление, но с предварительным разностным бэкапом.
Один раз слетало до неработоспособности — кажется, тоже года три назад, восстанавливали поврежденную таблицу из бэкапной копии по рецепту из интернета. Хочется надеяться, что в новых релизах это починили.
Совсем не использовать тоже можно — но тогда надо более основательно вести цикл разработок и тестирований — пользователи же хотят быстрее, у них клиенты-сроки, задержка дала бы минус к конкурентному преимуществу, либо всех выгонять (это в обед приемлемо, в течение дня же причиняет пользователям беспокойство).
romix
13.12.17
✎
20:04
Словил то же самое при наличии /ClearCache.
1С:Предприятие 8.3 (8.3.10.2639)
Видимо, где-то еще есть один кеш — в хранилище, наверное.
Глюк после динамического обновления? |
Я |
Юзер123
27.11.17 — 10:40
Добрый день.
С прошлой недели стал замечать интересную фигню в работе 1С.
8.3.10.2580
Работаю с обработкой или общей формой . Меняю значение реквизита / меняю код добавляю новые процедуры или функции.. Т.е. все как обычно. Делаю динамическое обновление программы. У всех пользователей которые зашли после обновления все изменения работают. Все как надо. Я не закрываю конфигуратор!!!1 закрываю объект с которым работал . открываю его опять и там все как было до изменения. Конфикоратор говорит что база не изменялась, но если я запущусь в режиме отладки то все внесенные изменения ранее пропадают. . Если перезапустить конфигуратор — все становится на свои места. Изменения появляются. Но после любого изменения и динамического обновления опять откат… кто сталкивался? как лечится?
Волшебник
Модератор
1 — 27.11.17 — 10:42
динамическое обновление очень глючное
ildary
2 — 27.11.17 — 10:44
(0) 8.3.10.2466 — у меня пару раз было подобное безо всякого динамического обновления. Вылечил ребутом тестового сервера —
аптайм был где-то 3 недели, а авторебута не было.
nordbox
3 — 27.11.17 — 10:45
динамическое обновление ЗЛО
lodger
4 — 27.11.17 — 10:46
Конфикоратор глюкнуло от демонического обновления.
остановить 1с(если клиент-сервер, то сервер тоже). дропнуть кэш(если клиент-сервер, то сервер тоже). запустить 1с(если клиент-сервер, то сервер тоже).
Про100Филя
5 — 27.11.17 — 10:46
Смизжено:
«Здравствуйте, меня зовут Алексей и я делаю динамическое обновление.
Раньше, я делал динамическое обновление по три или даже целых пять раз в день.
Я мог не спросить пользователей, не сделать бекап средствами СУБД и динамически обновить базу ради изменения макета печатной формы счета на оплату.
Но потом случилось горе и в одно прекрасное обновление база просто не запустилась.
Это был ч0рный день в моей жизни.
Я потерял друзей, коллеги отвернулись от меня.
Жена меня бросила и дети не хотят со мной разговаривать.
Попа болела после долгого и многозначительного разговора с начальством.
И я решил изменить свою жизнь.
Я теперь занимаюсь спортом
Стал посещать бассейн.
Питаюсь правильно и соблюдаю правила дорожного движения.
Сегодня у меня праздник.
Я уже 30 дней не делаю динамического обновления без ахивации базы данных средствами СУБД.
Я практически готов полностью отказаться от динамического обновления.
Вообще не обновлять динамически.
Преодолеть зависимость от динамического обновления мне помогли 12 простых шагов:
12 ШАГОВ , РАЗРАБОТАННЫЕ САМИМИ ДИНАМИЧЕСКИМИ ОБНОВЛЯЛЬЩИКАМИ
1. Признать свое бессилие перед поведением платформы 1с при динамическом обновлении.
2. Согласиться с утверждением, что без посторонней помощи не обойтись.
3. Мысленно перепоручить себя некой Высшей силе, которая поможет.
4. Проанализировать свои поступки.
5. Признать перед собой и кем-то еще свои ошибки.
6. Не сомневаться, что бекап перед динамическим обновлением сработает.
7. Просить высшие силы избавить от недостатков.
8. Составить список всех людей, кому причинили зло, и захотеть загладить свою вину перед ними.
9. Лично возместить этим людям ущерб, нанесенный вами и вашим динамическим обновлением.
10. Продолжать самоанализ и, при малейших ошибках, сразу признавать, что вы их таки совершили.
11. Не переставать размышлять и благодарить помощника из пункта 3.
12. Достигнув пробуждения, благодаря пунктам 1-11, помогать другим динамическообновлялщикам.
АЛИЛЛУЯ братья и сестры!
АМинь!»
Юзер123
6 — 27.11.17 — 10:56
(5) распечатал!! 111 =))
Юзер123
7 — 27.11.17 — 10:56
(4) Спачибо
Fragster
8 — 27.11.17 — 11:02
начиная с 8.3.10.25хх очень сильно сломали демоническое обновление
Fragster
9 — 27.11.17 — 11:03
и в конфигураторе динамически обновленной базы ничего делать нельзя
ildary
10 — 27.11.17 — 11:05
(8) спасибо за предупреждение! Может настал тот час, когда сами разрабы решат «Хватит это терпеть» и таки починят?
Fragster
11 — 27.11.17 — 11:05
методика, когда обновление готовится в базе разработчиков (хранилище, и т.п.), а потом .cf накатывается на рабочую (даже динамически), работает
Fish
12 — 27.11.17 — 11:08
(9) А я на 8.3.10.2561 пару раз использовал ДО, и после в конфигураторе что-то делал. Что теперь со мной будет? :))
Fish
13 — 27.11.17 — 11:10
+(12) Да, у меня клиент 1С 64х.
nordbox
14 — 27.11.17 — 11:12
(12)>>Что теперь со мной будет? :))
Десять лет расстрела с повешением в газовой камере и каждый день до смерти. )))))
Йохохо
15 — 27.11.17 — 11:15
(12) Слухай сюды! Положь колдобину со стороны загогулины и два раза дергани за пимпочку. Опосля чего долбани плюхалкой по кувывалке и, коды чвокнет, отскочь дальшее, прикинься ветошью и не отсвечивай. Потому как она в это время шмяк… ту?дыть, сподыть, ёксель?моксель, ерш твою медь… Ш?ш?ш! И ждешь, пока остынет. Остыло — подымаесся, вздыхаешь… Осторо?о?ожненько вздыхаешь про себя, шобы эта быдла не рванула! И бегишь за угол за поллитрой. Потому как пронесло!
elCust
16 — 27.11.17 — 11:15
(9) А подробнее можно, чем обусловлено Ваше высказывание?
Какие ограничения накладываются на работу в конфигураторе после ДО?
Я периодически на базе разработки делаю ДО, никаких глюков не выявлено. (8.3.10.2580).
Полагаю, что кэш страдает после ДО, в случае, когда операционка загажена.
Fish
17 — 27.11.17 — 11:19
(14) Ну вообще, я обычно делаю по методу (11), но был один-два раза, когда после накатывания cf, выявлялась какая-нибудь незначительная ошибка — запятую забыл в макете поставить или ещё какая опечатка. И для скорости правил прямо в рабочей, применяя ДО. Пока прокатывало, хотя опасения были, конечно.
Fragster
18 — 27.11.17 — 11:22
(12) возможно, ты потерял часть того, что ты демонически обновил.
Fragster
19 — 27.11.17 — 11:25
(16) теряются доработки от последнего недемонического обновления и до демонического. причем произвольным образом (если не закрывать доработанный модуль, то его даже пару раз можно обновить, если же закрыть, обновить демонически, запустить отладку, открыть доработанный модуль, то код может быть потерян). Лично видел, как теряется код модулей, изменения макетов СКД. Одним из условий является запуск отладки после демонического обновления.
Fragster
20 — 27.11.17 — 11:26
очень сильно началось на 8.3.10.25хх и последующих. на 8.3.6.2639 все еще воспроизводится.
Леха Дум
21 — 27.11.17 — 11:31
Наблюдаю то же самое. Спасает снос папок с кэшем.
Fish
22 — 27.11.17 — 11:33
(18) (19) Да вроде ничего не потерялось (тьфу-тьфу-тьфу). Возможно, потому, что на отладку не запускал после ДО.
romix
23 — 27.11.17 — 11:44
(0) последние релизы 8.3 более или менее нормально работают с динамическим обновлением, но есть недокументированная особенность — надо чистить кеши.
В параметрах запуска 1C:Предприятия (тестовая и рабочая база) указать параметр:
/ClearCache
При основном обновлении (с отключением пользователей) надо пользоваться бат-файлом:
set LOG_FILE="scripts.log" set SERVICE_1C_NAME="1C:Enterprise 8.3 Server Agent (x86-64)" set SERVICE_RAS_NAME="1C:Enterprise 8.3 Remote Server" set CNTX_PATH="C:Program Files1cv8srvinforeg_1541" set PFL_PATH="C:ProgramData1C1cv8" set TEMP_PATH="C:WindowsTemp" echo stop %DATE% %TIME% >> %TEMP_PATH%%LOG_FILE% sc stop %SERVICE_1C_NAME% sc stop %SERVICE_RAS_NAME% timeout 5 taskkill /f /im "rphost.exe" taskkill /f /im "rmngr.exe" taskkill /f /im "ragent.exe" taskkill /f /im "ras.exe" timeout 5 echo done stop %DATE% %TIME% >> %TEMP_PATH%%LOG_FILE% echo clean temp %DATE% %TIME% >> %TEMP_PATH%%LOG_FILE% DEL /Q /F /S %CNTX_PATH%snccntx* DEL /Q /F %PFL_PATH%*.pfl DEL /Q /F /S %TEMP_PATH%*.* echo done clean temp %DATE% %TIME% >> %TEMP_PATH%%LOG_FILE% echo start %DATE% %TIME% >> %TEMP_PATH%%LOG_FILE% sc start %SERVICE_1C_NAME% sc start %SERVICE_ RAS _NAME% echo Service %SERVICE_1C_NAME% restarted at %DATE% %TIME% >> %TEMP_PATH%%LOG_FILE% pause 1000
https://its.1c.ru/db/metod8dev/content/5899/hdoc
Остановка службы 1С:Предприятие с очисткой временных файлов.
Веселый собака
24 — 27.11.17 — 11:44
(0) Я вот перезапускаю конфигуратор, когда он просит, и все пучком.
Fish
25 — 27.11.17 — 11:45
(24) В последних версиях платформы уже не просит 
romix
26 — 27.11.17 — 11:47
+(23) Параметры запуска находятся в стартовом окне, где кнопки Добавить-Изменить-Удалить. По кнопке «Изменить…» перейти на вторую закладку и ввести (или добавить) значение
/ClearCahce
в поле «Дополнительные параметры запуска».
Fish
27 — 27.11.17 — 11:49
(26) Емнип, ключ /ClearCahce работает только для тонкого клиента, а конфигуратор вроде — это всегда толстый. Непонятно, как этот ключ помогает при ДО. Или я ошибаюсь?
Fragster
28 — 27.11.17 — 11:49
(26) не поможет, если не перезапускаешь после демонического обновления. например обновил запустил отладку, проверяешь работу — работает. открываешь какой-нибудь (допустим) другой модуль, программируешь дальше, сохраняешь конфу. все. изменениям из демонического обновления хана.
romix
29 — 27.11.17 — 11:51
(27) Я не могу сейчас найти документацию на этот ключ поиском по сайту 1С. Может он всё там чистит, включая и конфигурацию?
romix
30 — 27.11.17 — 11:52
(27) 10060739 Кеш метаданных
Проблема:
При частом изменении конфигурации, при использовании тонкого клиента или толстого клиента в управляемом режиме работы, происходит увеличение объема кэша клиент-серверных вызовов.
Способ обхода:
Выполнить запуск с параметром командной строки /ClearCache.
Дата публикации: 2010-08-06
romix
31 — 27.11.17 — 12:12
С кешами вообще какая-то ерунда — если они нужны для ускорения обращений без ZIP упаковки и распаковки, то как бы не оказалось, что на современных системах результат получается обратный.
Если нужны для полнотекстового поиска по модулям, то может как-то это выделить — базой данных искать.
Я не понимаю, зачем они нужны (т.е. какое действие ускоряют). Если секретный ключик /ClearCache их выключает и всё становится хорошо, то возникает вопрос, а зачем они включены.
romix
32 — 27.11.17 — 12:14
Скорее всего, ускоряет запись за счет записи без транзакции — а она всегда и повсюду глючит (в любых СУБД).
Дык ё
33 — 27.11.17 — 14:52
romix
34 — 27.11.17 — 20:00
Вот сейчас у меня сглючило — я посмотрел, а на этой базе ключика-то /ClearCache и нет.
Tateossian
35 — 27.11.17 — 21:30
Динамичное обновление самое лучшее:) Нужно только кэши чистить.
Tateossian
36 — 27.11.17 — 21:31
(31) Можно файл кэша открыть и посмотреть чего там. (29) https://its.1c.ru/db/v8310doc#bookmark:adm:TI000000495
Andreyyy
37 — 28.11.17 — 01:07
(20) Поддерживаю, сломали что-то.
1Сергей
38 — 28.11.17 — 06:47
Мыши и кактусы…
PCcomCat
39 — 28.11.17 — 08:32
(11), (17) А я попадала на том, что при таком способе (сравнение, объединение с cf) тоже не все изменения накатывались — тупо конфигуратор не видел изменений.
Fragster
40 — 28.11.17 — 10:31
(39) при чем тут сравнение?
romix
41 — 01.12.17 — 14:28
(34) Вчера еще раз словил эту же проблему — тоже не было /ClearCache.
portowyi
42 — 01.12.17 — 14:32
(0) Лечится отказом от динамического обновления. Ибо программисты 1С бывают двух типов — те кто уже положил базу динамическим обновлением и те кому это еще предстоит.
kiruha
43 — 01.12.17 — 14:40
(42)
Выше отписали —
лечится чисткой кэша, динамически обновлять можно и нужно в некоторых случаях(например мелкая ошибка в модуле набора регистра)
Ради более красивого отчета — это конечно изврат
portowyi
44 — 01.12.17 — 14:53
(43) У меня был случай года три назад — динамическое обновление (чистка кэша при помещении, чистка кэша при получении изменений из хранилища на боевой базе) положило базу, причем довольно интересно — стало невозможно авторизоваться в базе. Перезалив таблицы users не помог, восстанавливали из архива. После этого динамическое обновление у нас применяется разве что только на тестовом контуре.
romix
45 — 01.12.17 — 17:36
(44) Пару раз в день делаю динамическое обновление, но с предварительным разностным бэкапом.
Один раз слетало до неработоспособности — кажется, тоже года три назад, восстанавливали поврежденную таблицу из бэкапной копии по рецепту из интернета. Хочется надеяться, что в новых релизах это починили.
Совсем не использовать тоже можно — но тогда надо более основательно вести цикл разработок и тестирований — пользователи же хотят быстрее, у них клиенты-сроки, задержка дала бы минус к конкурентному преимуществу, либо всех выгонять (это в обед приемлемо, в течение дня же причиняет пользователям беспокойство).
romix
46 — 13.12.17 — 20:04
Словил то же самое при наличии /ClearCache.
1С:Предприятие 8.3 (8.3.10.2639)
Видимо, где-то еще есть один кеш — в хранилище, наверное.
Внимание!!! При обновлении данных, после последней реструктуризации, произошла ошибка. Повторить обновление?
Опубликовано: 16.02.2018 /
Переезжали мы на новый сервер. На нем SQL и 1C. В сравнении со старыми был намного круче. И тест Гилева это тоже подтвердил: против 10-15 на старых серверах выдавал 39. Поэтому мы сразу после покупки перенесли базу и начали работу.
Но в какой-то момент что-то пошло не так — пользователи стали жаловаться на медленную работу. Произвели определенные настройки сервера и служб (какие — тема отдельного поста) и решили перезагрузить сервер, благо скорость перезагрузки — 2 минуты (на других серверах до 10 доходило). После этого при входе в 1С получаем следующее сообщение:
«Внимание!!! При обновлении данных, после последней реструктуризации, произошла ошибка. Повторить обновление?» «Да, Нет»
После нажатия кнопки «Да» появляется следующее:
«Обнаружена незавершенная операция сохранения конфигурации. Для продолжения работы необходимо завершить операцию.»
Первое, что решил сделать — CHECKDB на в Managment Studio — после 2х часов ожидания (база 500 ГБ) — все ОК.
На просторах сети нашел информацию, что такая же ошибка бывает при динамическом обновлении.
Решения, предложенные в сети сходу не помогли, но вкупе с другими действия дали результат. Итак, что я делал:
Решение:
- То, чего не хватало для решений из сети:
sp_configure ‘allow updates’, 1
reconfigure with override
go
2. Переводим базу в режим восстановления
alter database [db_name] set EMERGENCY, SINGLE_USER
3. Выполняем тестирование базы:
dbcc checkdb(‘db_name’, REPAIR_ALLOW_DATA_LOSS )
4. Выводим базу из режима восстановления:
alter database [db_name] set ONLINE, MULTI_USER
5. В принципе, если уверены что с самой базой все ок, то можно не делать 2-4 пункты. Далее выполняем два запроса в профайлере SQL:
delete from config where FileName = ‘commit’
delete from config where FileName = ‘ dbStruFinal’Эти записи и отвечают за динамическое обновление — можно не бояться их удалять.
В рабочих версиях баз запросы:
select * from Config WHERE FileName = ‘commit’
select * from Config WHERE FileName = ‘dbStruFinal’
будут пустые.
6. возвращаем настройки:
sp_configure ‘allow updates’, 0
go
7. После этого удалось запустить конфигуратор и база заработала.
Также база может заработать после удаления первого флага.
Еще из решений, которые есть в сети, полная замена таблицы Config.
Что у меня использовалось:
Платформа 1С: 1С:Предприятие 8.3 (8.3.10.2466)
SQL: Microsoft SQL Server 2008 R2 Standard Edition (64-bit) 10.50.6220.0
Также обратил внимание, что проблема повторяется на всех версиях платформ и SQL.
Всем удачи с решением таких проблем. Если есть трудности, обращайтесь, помогу.
p.s. бекап был, но терять даже несколько часов работы не очень хотелось
Не зря в народе динамическое обновление 1С называют «демоническим».
Многие утверждают что оно удобно для экстренного исправления ошибок в алгоритмах, но это самообман. На самом деле исправления для старых сессий не начнут действовать. Поведение системы, когда в разных сеансах пользователи с одними и теме же таблицами работают де-факто по разным алгоритмам — просто становится не очень прогнозируемым и стабильным.
1. Например можно словить:
Ошибка СУБД:
ERROR: relation «_reference5029» does not exist
2. Если изменилась (или удалилась) функция — будет фатальная ошибка или отсутствие контроля целостности данных.
3. Еще одна неприятная ситуация возникает при некорректной работе с кэшем метаданных.
Кэш метаданных расположен в папке <Имя пользователя OS>Local SettingsApplication Data1C1Cv81
В нем необходимо стереть подпапки Config, ConfigSave, DBNameCache, SICache.
В результате легко получить ошибку «Ошибка потока формата».
Примечание.
UUID информационной базы можно посмотреть в файле
C:Documents and Settings<Имя пользователя>Application Data1C1Cv81ibases.v8i.
Не исключены также проблемы с падением производительности.
При этом в технологическом журнале могут встречаться сообщения типа: Попытка подключения к контексту сервера с неподходящей версией метаданных.
Возможные проблемы:
1. Основная проблема в работе с КЭШ.
1.1. У пользователя может не обновиться кэш на клиенте.
1.2. Кэш на сервере может не обновиться.
1.3. Кэш у разработчика может не обновиться (если работают несколько разработчиков)
2. Сталкивались с такой ситуацией когда делаешь штук 5 демонических обновлений а потом обычное. При обычном все демонические пропадают. Т.е. все что нажито непосильным трудом…
3. Сама ошибка заключатся в том, что в момент записи в таблицу «Config» что-то произошло, что помешало корректно закончить данную процедуру.
Часто программисты не учитывают, что есть список объектов, НЕ доступных для динамического обновления
Регламентные задания
Общие реквизиты
Планы обмена
Реквизиты, предопределенные элементы, иерархия, владельцы, нумерация справочников
Реквизиты, нумерация, движения, последовательности, ввод на основании документов
Перечисления
Тип значений характеристик, реквизиты, нумерация, предопределенные элементы планов видов характеристик
Реквизиты, нумерация, субконто, предопределенные элементы планов счетов
Реквизиты, нумерация, расчет, предопределенные элементы планов видов расчета
Реквизиты, регистраторы регистров сведений, накопления, бухгалтерии, расчета
Реквизиты, нумерация, расчет, предопределенные элементы планов видов расчета
Реквизиты, адресация, нумерация задач
Реквизиты, нумерация, ввод на основании бизнес-процессов
Были известны случаи, когда «демоническое обновление» останавливало работу всей системы, а исправление последствий отнимало уйму времени или базы восстанавливали из копии, потеряв часть данных.
Динамическое обновление есть смысл делать только в том случае если информационная система уже стоит, неработоспособна и хуже уже не будет. о всех остальных случаях мы рекомендуем избегать динамического обновления!
Если вы работаете с часто изменяемой печатной формой и не хотите постоянно выгонять пользователей, используйте внешние обработки.
Хорошей практикой считается все плановые изменения вносить например раз в неделю, например во вторник. К этому дню все правки тестируются не только по отдельности, но и в общем взаимодействии. Если во вторник информационная система ухудшила свою работу, значит сразу понятно, что надо откатить последний релиз к предыдущему. А это означает бэкап не только базы, но и бэкап cf перед внесением изменений.
Если Вы словили проблему связанную с динамическим обновлением, то обязательно очистите сеансовые данные с рестартом службы сервера 1С.
Если проблема не ушла, то запускайте сеанс 1С с ключом /ClearCache .
Народное творчество. Порочность динамического обновления воспета народом в интернете:
«Здравствуйте, меня зовут Алексей и я делаю динамическое обновление.
Раньше, я делал динамическое обновление по три или даже целых пять раз в день.
Я мог не спросить пользователей, не сделать бекап средствами СУБД и динамически обновить базу ради изменения макета печатной формы счета на оплату.
Но потом случилось горе и в одно прекрасное обновление база просто не запустилась.
Это был ч0рный день в моей жизни.
Я потерял друзей, коллеги отвернулись от меня.
Жена меня бросила и дети не хотят со мной разговаривать.
Попа болела после долгого и многозначительного разговора с начальством.
И я решил изменить свою жизнь.
Я теперь занимаюсь спортом
Стал посещать бассейн.
Питаюсь правильно и соблюдаю правила дорожного движения.
Сегодня у меня праздник.
Я уже 30 дней не делаю динамического обновления без архивации базы данных средствами СУБД.
Я практически готов полностью отказаться от динамического обновления.
Вообще не обновлять динамически.
Преодолеть зависимость от динамического обновления мне помогли 12 простых шагов:
12 ШАГОВ , РАЗРАБОТАННЫЕ САМИМИ ДИНАМИЧЕСКИМИ ОБНОВЛЯЛЬЩИКАМИ
1. Признать свое бессилие перед поведением платформы 1с при динамическом обновлении.
2. Согласиться с утверждением, что без посторонней помощи не обойтись.
3. Мысленно перепоручить себя некой Высшей силе, которая поможет.
4. Проанализировать свои поступки.
5. Признать перед собой и кем-то еще свои ошибки.
6. Не сомневаться, что бекап перед динамическим обновлением сработает.
7. Просить высшие силы избавить от недостатков.
8. Составить список всех людей, кому причинили зло, и захотеть загладить свою вину перед ними.
9. Лично возместить этим людям ущерб, нанесенный вами и вашим динамическим обновлением.
10. Продолжать самоанализ и, при малейших ошибках, сразу признавать, что вы их таки совершили.
11. Не переставать размышлять и благодарить помощника из пункта 3.
12. Достигнув пробуждения, благодаря пунктам 1-11, помогать другим динамическообновлялщикам.
Механизм работы обновления:
Процесс динамического обновления (и обновления вообще) происходит следующим образом:
- Анализируется корректность метаданных;
- проверяется наличие пользователей с административными правами;
- проверяется необходимость обновления структуры ИБ:
- если не понятно, что обновления структуры ИБ не требуется, запускается обновление структуры ИБ. При появлении необходимости изменения структуры делается попытка заблокировать ИБ монопольно.
- если попытка блокировки удалась — процесс обновления продолжается, динамического обновления не происходит;
- если попытка блокировки не удалась — процесс обновления завершается.
- если не понятно, что обновления структуры ИБ не требуется, запускается обновление структуры ИБ. При появлении необходимости изменения структуры делается попытка заблокировать ИБ монопольно.
- если необходимо, то обновляется информация необходимая полнотекстовому поиску;
- если необходимо, то обновляется информация требующаяся для отложенной загрузки метаданных;
- если после всех этих действий монопольная блокировка не установлена, делается попытка её установить.
- если попытка блокировки не удается — пользователю предлагается повторить блокировку или обновить ИБ динамически.
- выполняется операция обновления ИБ в обычном или динамическом режиме;
- если это динамическое обновление — в ИБ записывается разность между предыдущим и текущим поколением метаданных и информация необходимая для корректной работы.
- если это монопольное обновление и перед ним происходили динамические обновления — из информационной базы удаляются сведения об устаревших поколениях.
- если обновление происходит монопольно или динамически, но клиент подключен к файловой ИБ — конфигуратор просто обновляет свои внутренние структуры и продолжает работу. Процесс обновления ИБ завершен.
- в случае если обновление происходит динамически, но клиент подключен к клиент-серверной ИБ — конфигуратор уведомляет сервер о том, что поколение метаданных, с которым он сейчас работает, устарело. Сервер запоминает этот факт и при подсоединении первого нового клиента «поднимает» для него самое актуальное поколение метаданных. Уже подключенные клиенты живут в старом поколении до тех пор, пока они подключены к серверу. Так как конфигуратору для продолжения работы после обновления ИБ требуется самое новое поколение, а он подключен к старому, то конфигуратор перезапускается
В случае если обновление происходит динамически и клиент подключен к клиент-серверной ИБ, тогда конфигуратор уведомляет сервер о том, что поколение метаданных, с которым сейчас работает сервер, устарело. Сервер запоминает этот факт и при подсоединении следующего нового клиента «поднимает» для него самое актуальное поколение метаданных. Уже подключенные клиенты живут в старом поколении до тех пор, пока они подключены к серверу. Так как конфигуратору, для продолжения работы после обновления ИБ, требуется самое новое поколение, а он подключен к старому, то конфигуратор перезапускается, чтобы подключится к новому поколению метаданных на сервере.