медленно работает база, после динамического обновления #671584

Добрый день, ситуация такая, база по непонятной причине отключилась от хранилища, ее снова подрубили, после этого получения конфиги из хранилища обновили БД (F7), после чего база стала загружаться очень медленно(минут 5) и все справочники и доки открываются по минуте, пробовал ТИ, а также выгружал в локальную и chdbfl, ничего не помогло, что подскажете?

Замер производительности, чистка кеша - делал?

кеш чистил, проблема у  всех юзеров, замер производительности сделать не могу, конфигуратор так и повис при открытии

Клиент-серверные БД после демонического (не опечатка) обновления иногда себя так ведут. Фирма 1С знает об этой ошибке и не считает необходимым исправлять её (БГ в подобных случаях спрашивает - "насколько поднимутся продажи?"). Иногда удаётся дождаться окончания нагрузки на сервер. Чаще база поднимается из архива, при этом становится на одного любителя демонического обновления меньше.

а сервер 1с перегружал ?

да, сервер перегружал

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

Я бы проверил конфигурацию. Вероятно она сбойная (скрытые ошибки).

а как ?

В конфигураторе, штатная процедура

ТИ ? так ТС его делал, говорит

Нет, он сказал, что у него кофигуратор завис :-)

не ТИИ, именно проверка конфигурации. Делать на компе с очищенным кэшем конечно

а кстати плохой тон вроде подключать к рабочей базе Хранилище

т.е плохой тон? а как разработки в рабочую базу попадать будут? что за проверка конфигурации?

У нас была такая ситуация. Симптоматика один-в-один. При этом в техжурнале сыпет 100500 запросов к серверу про _dynupdate Метода решения два: 1. Восстановить из бекапа. Второй метод поприятнее, но и подольше: Заблокировать регламентные задания. Разрешить начало сеанса только с паролем (чтобы не увеличивать и тк жесткую нагрузку на сервер). Дождаться открытия конфигуратора. Это у нас заняло 15-20 минут. Внести ЛЮБОЕ изменение, которое приведет к реструктуризации бд. Например, длину строки неидексируемой увеличить на 1. Обновить базу. Все вернется в норм состояние.

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

на рабочую базу накатывать сравнением-объединением с цф-ником хранилища.

Продиагностировать, эта ли проблема именно из за дин обновления - в профайлере SQL или техжурнале 1С. Хранилище после этого придется пересоздать. Считай, что оно уже умерло.

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

поздравляю, вы словили первый сюрпрайз от 1с

Вообще-то, для разработки и накатывания обновлений, можно и специальную базу создать (к ней подключено хранилище). А в рабочую базу сливается только "итого" через загрузку CF...

или пакет обновлений.