Аварийное завершение работы?

Question

[NewDevLab]

Была произведена установка в Конфигураторе последовательно несколько новых конфигураций. Последнее обновление выдало предупреждение, которое было успешно проигнорировано.

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

Собственно, это и случилось. См. скрин. Такое происходит спустя 2-5 минут после логина в любых экранах. Было произведено "Тестирование и исправление" в конфигураторе, что-то исправило, но помогло слабо.

Бакуп базы есть только середины прошлого года.
Вопрос: как починить базу?

Comments

[ScriptKiddo]

Что в отчете интересного есть?

[NewDevLab]

ScriptKiddo, пусто

"errorInfo": {
		"systemErrorInfo": {
			"clientStack": " ",
			"clientStackHash": "7215EE9C7D9DC229D2921A40E899EC5F",
			"systemCrash": true
		},
		"applicationErrorInfo": {
			"errors": [
				[
					"Аварийное завершение",
					[]
				]
			]
		}
	}

Answer 1

[Дмитрий Кинаш]

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

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

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

Comments

[NewDevLab]

спасибо за дорожную карту, займусь этим и отпишусь.

Answer 2

[АртемЪ]

Ну так откатите базу на момент до обновления.
И такой вопрос - вы кэш чистили после обновления?

Comments

[NewDevLab]

база имеет простую модель восстановления, следовательно не откатится.
кеш чего?

[АртемЪ]

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

Очистка кэша осуществляется путем запуска базы с ключом /ClearCache

Так же можно вручную удалить файлы кэша.
Для файловых баз - они в профилях пользователя на клиентских компьютерах
Для клиент-серверной архитектуры они в папке на сервере 1с.

[АртемЪ]

NewDevLab,

база имеет простую модель восстановления

А резервная копия перед обновлением???

[NewDevLab]

АртемЪ,

Для клиент-серверной архитектуры они в папке на сервере 1с.

не нашел ничего подобного, смотрел C:\Program Files\1cv8\ и C:\ProgramData\1C

[АртемЪ]

NewDevLab,
Не там смотрели- C:\Users\%Вася%\AppData\Local\Temp
Где Вася это пользователь от имени которого запущен сервер.
Для чистки кэша требуется остановка сервера.

Answer 3

[LollyFox]

Бакуп базы есть только середины прошлого года.
Вопрос: как починить базу?

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

несколько новых конфигураций

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

Comments

[NewDevLab]

@LollyFox
Сейчас:
платформа - 8.3.18.1208
конфигурация - 3.0.91.31

обновления c 3.0.88.22 -> 3.0.88.28 -> 3.0.89.51 -> 3.0.91.31
всё согласно readme допустимо.

[LollyFox]

обновления c 3.0.88.22 -> 3.0.88.28 -> 3.0.89.51 -> 3.0.91.31
всё согласно readme допустимо.

Допустимо, но при условии, что после каждого обновления программа будет запускаться в режиме 1С:Предприятия.
Если же запуск в режиме 1С:Предприятия не выполнялся, то обработчики перехода не запускались и результат будет такой же, как если сразу переходили 3.0.88.22 -> 3.0.91.31.
Скорее всего проблема в последнем обновлении, т. к. в 3.0.91.31 много чего переделали и некоторые механизмы вообще новые.

[NewDevLab]

LollyFox,

Скорее всего проблема в последнем обновлении

это я понял:

Последнее обновление выдало предупреждение, которое было успешно проигнорировано./blockquote>

[LollyFox]

NewDevLab,
Честно говоря я даже не знаю, что вам теперь посоветовать, бекапы вы не делаете, обновлять не умеете, предупреждения игнорируете.
Лучше всего пригласить специалиста, а то сами совсем доканаете базу.

[АртемЪ]

Не обязательно скакать через релизы чтобы получить битую базу при обновлении.

[АртемЪ]

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

Если обновление делается штатными методами из интерфейса 1с предприятия - то бэкап создается автоматически.
Вполне возможно он у вас есть.
Хотя я честно говоря ни разу не делал обновление штатными методами для клиент-серверной базы. Как то не довелось. Все либо через конфигуратор, либо из командной строки.

Answer 4

[Константин]

может вот это https://infostart.ru/public/1419212/