Выполнение оператора kill не привело к ошибке субд - Oshibku.top - решение и исправление самых разных ошибок

Обновлено: 28.01.2023

Методика выявления длительной транзакции, которая привела к значительному расходу tempdb

К таким транзакциям стоит относиться подозрительно и стараться их не допускать.

Проблемы, к которым могут приводить длительные транзакции, в первую очередь связаны с избыточным потреблением каких-либо ресурсов: избыточные блокировки, избыточное потребление tempdb при работе с MS SQL Server.

Информацию по типичным причинам избыточных блокировок вы сможете найти в статье «Типичные причины избыточных блокировок и методы оптимизации».

В этой методике будет рассмотрена ещё одно достаточно неприятное проявление — избыточное потребление места в tempdb при работе с MS SQL Server.

Методика выявления длительной транзакции, которая привела к значительному расходу tempdb

1 — Зафиксировать значительное потребление tempdb

В целом объем свободного места можно оценить даже простейшим запросом

Для оперативной реакции на рост объема tempdb можно использовать «Инциденты и генерацию оповещений в ЦКК».

2 — Найти номер транзакции в MS SQL Server Management Studio

На этом шаге мы понимаем, что сейчас происходит значительное потребление места в tempdb.

Для всех систем, работающих с использованием Технологической Платформы 1С в режиме совместимости с версией 8.3. (и старше) эффективно будет выполнение запроса:

Первые две колонки — номер сессии с СУБД и длительность транзакции.

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

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

В этом запросе вы не получите объем места, использованный транзакцией, но по длительности транзакции (косвенный признак) получается идентифицировать виновника в 99% случаев.

Запоминаем номер session_id

Если проблема совсем критичная, а пользователи не могут больше работать, то нужно будет на СУБД выполнить kill 123 , где 123 — номер session_idНо это на совсем крайний случай. В этом случае в технологическом журнале будет зафиксировано исключение и событие EXCP. Такая ситуация, например, выглядит так (пример искусственный, но всё же)

В этом примере можно увидеть искомую транзакцию

Есть более «полный» запрос, который также позволит получить нужный номер транзакции, особенно, если система работает в режиме совместимости с 8.2.

Однако, приведенный ниже запрос может выполняться несколько десятков секунд (будьте к этому готовы): DECLARE @curr_date as DATETIME

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

3 — Находим код, выполнение которого привело к длительному выполнению в транзакции

Открываем консоль администрирования кластера серверов.

Переходим на закладку сеансы.

Нас интересуют две колонки:

— Соединение с СУБД

Запоминаем номер сеанса.

Обратите внимание, что session_id = Соединение с СУБД.

Опять же, если будет очень плохо, можно завершить сеанс.

В технологическом журнале это будет выглядеть так:

Но удаление сеанса — на крайний случай.

4 — Выясняем, что делает этот сеанс

Открываем журнал регистрации, отбираем по номеру сеанса , смотрим, что сеанс делает.

Если не понятно, что делает сеанс (а он ещё работает) быстро настраиваем технологический журнал по этому сеансу

Копировать в буфер обменаЗдесь 321 — это номер сеанса.

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

5 — Воспроизводим и разбираем проблему

Необходимо повторять где-то на копии ровно эту операцию.

На копии нас интересует запрос и его план, при выполнении которого потребовался большой объем данных в СУБД.

Возникает у всех пользователей.
Кеш, tempdb чистили. Полное тестирование и исправление делали. Выгрузка базы в файл .dt. Создание новой БД и загрузка из .dt была
Ошибка осталась, появляется с разной периодичностью.

При использовании платформы 8.3.6.2390 и версии Бухгалтерия 3.0.44.115 таких проблем не было
На этом же оборудовании используется ЗУП 2.5 (1С 8.2) и самописная конфигурации (1С 8.3) с большой нагрузкой проблем нет

8.3.9.2170. Server 2012R2/SQL2014 2е суток. Падения пропали.
эх, я чуть-чуть не дождался стабильного обновления. Ну да ладно .
Вопрос к тем, кто поставил новый релиз.
По истечении недели использования, ничего страшного не вылезло? Каких-то новых ошибок?
(101) Все нормально. Даже ошибку сохранения расширений исправили. Новых пока не выявил.
(101)
(104)
Windows Server 2008 R2
SQL Server 2008 R2
Платформа 8.3.9.2170 ошибка замечена на УТ 10.3 (в режиме совместимости с 8.1) через 2 недели после обновления платформы. Замечена пока всего у 2-х пользователей.
Стоит релиз уже неделю, полет нормальный, ошибок нет.
Пользователи пожаловались, что базы стали медленней крутиться на платформе 8.3.9.2170 (до этого была 8.3.8.2054). Работают в БП 3.0. Не говорю что им не может казаться. У кого-нибудь производительность изменилась?
Поставили новую платформу.
Появилась проблема. Теперь при запуске внешних обработок спрашивает о разрешении запуска внешней обработки. И об использовании внешних приложений, типа Excel (если он используется в этой обработке). И запоминает ответ. Особо одаренные пользователи, не читая, отвечают — нет.
И все, второго шанса не дает.
Печалька.:(
Кто знает, где хранятся эти настройки?
Чистка кэша не помогла.
Платформа 8.3.9.1818. Ошибка появлялась только 2 раза. Помогала чистка серверного кэша. Сейчас опять вылезла, будем обновляться.
(114) Подтверждаю. В бухии было 4-7 в день павдений . Самописка на УФ валилась каждые 15-30 минут. два месяца полёт нормальный.
У меня на 1С:Предприятие 8.3 (8.3.9.1850) тоже вылетает спонтанно. И не у всех пользователей.

То же самое
8.3.10.2561, ERP 2.4, расширения, MS SQL 17
После первичного возникновения в процессе работы, начинает проявляется при входе в 1С

в техжурнале следующее:

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

Поддерживаю, та же фигня.
Версии конфигурации, платформы и SQL такие же.
Другие базы работают нормально.

было что то похожее

Сегодня появилась с утра! Не у всех пользователей. Трое отписались с приложением скрина.

Первый раз за полгода вылез этот баг на 8.3.10.2466 + Native Client 11.0.
Надеюсь, в 8.3.11 этого бага уже нет.
Сегодня такая же ошибка в БИТ.ФИНАНС 3.1 (3.0.58.41/3.1.36.2/3.0.1.131).
Платформа 8.3.10.2580.
Тоже появилась с утра.

1С:Предприятие 8.3 (8.3.12.1440)
1С:Комплексная автоматизация 2 (2.4.3.160)

Ведомость на счета — увольнение

(126) Та же ерунда в БП 3.0 после обновления платформы. Похоже дело в ней

1С:Предприятие 8.3 (8.3.12.1412)
Зарплата и кадры государственного учреждения, редакция 3.1 (3.1.6.54)

Выходит при попытке проведения вновь созданного кассового ордера.

После обновления платформы на версию 8.3.12.1469 ошибка SQL при проведении исчезла.

перешли на платформу 1С:Предприятие 8.3 (8.3.12.1529)

на пятый день возникла ошибка у некоторых пользователей и в логах Фоновое задание. Ошибка выполнения:

Соединение с сервером баз данных непригодно для использования после разрыва соединения администратором и будет переустановлено.
Microsoft SQL Server Native Client 11.0: Запрос COMMIT TRANSACTION не имеет соответствующей инструкции BEGIN TRANSACTION.
HRESULT=80004005, SQLSrvr: SQLSTATE=25000, state=1, Severity=10, native=3902, line=1

Добрый день всем! Платформа 8.3.10.2567 клиент серверная версия 1с и sql на разных серверах у пользователей возникает ошибка Соединение с сервером баз данных непригодно для использования после разрыва соединения администратором и будет переустановлено. Подскажите в чем может быть дело?

: Ошибка при получении значения атрибута контекста (ТекущийПользователь)
Запрос.УстановитьПараметр(«ТекущийПользователь», ПараметрыСеанса.ТекущийПользователь);
по причине:
Соединение с сервером баз данных непригодно для использования после разрыва соединения администратором и будет переустановлено.
Microsoft SQL Server Native Client 11.0: Запрос COMMIT TRANSACTION не имеет соответствующей инструкции BEGIN TRANSACTION.
HRESULT=80004005, SQLSrvr: SQLSTATE=25000, state=1, Severity=10, native=3902, line=1

Платформа 8.3.10.2505 (не меняли полгода), последних 3 дня периодически выскакивает ошибка:

Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm:
по причине:
Соединение с сервером баз данных непригодно для использования после разрыва соединения администратором и будет переустановлено.
Microsoft SQL Server Native Client 11.0: Запрос COMMIT TRANSACTION не имеет соответствующей инструкции BEGIN TRANSACTION.
HRESULT=80004005, SQLSrvr: SQLSTATE=25000, state=1, Severity=10, native=3902, line=1

Нашлось решение этой проблемы или опять ждать милости 1С?

платформа 8.3.11.3034 , фоновые задания по выходным выбивают такую ошибку : Сеанс. Ошибка применения расширения конфигурации; Критичная: Уже существует объект с именем скИспользованиеРабочегоСтола.ШаблоныОграничений.скПоЗначениямУдалить . помогает перезапуск службы, но это не выход. режим совместимости 8.3.10

Коллеги,
появилась такая же ошибка.

Платформа — 8.3.10
Конфа — Документооборот.
Всё работало полтора года исправно.

Мне помогло установка Драйвера «Драйвер Microsoft® ODBC 11 для SQL Server».
(установка вместе с «Собственный клиент Microsoft SQL Server 12»).

При эсклуатации баз данных 1С вы можете сталкнуться с такой ситуацией:

Сеанс работы завершен администратором.
по причине:
Соединение с сервером баз данных разорвано администратором
Microsoft OLE DB Provider for SQL Server: Неопознанная ошибка
HRESULT=80004005

Признаки проблемы: нельзя выгрузить в dt

Внимание! Ошибок с кодом 80004005 уйма, более подробно классофикацию я описал здесь http://www.gilev.ru/1c/mssql/errsql.htm . Здесь же мы говорим именно о «неопознанной ошибке»

Сотрудники 1С рекомендуют решать проблему так:

Нюансы: обратите внимание, что «Стандартные проверки» платформой (chdbfl, в конфигураторе) упорно говорят, что с базой все ОК.

Также с этой ситуацией пересекается следующая ситуация:

Готов пояснить, фоновые задания сами по себе не зло, но регламентные процедуры
с полнотекстовым поиском — вещь в себе — и память она может через какое время
съедать ресурсы rphost.exe, что на другие операции не останеться, и просто
базу блокировать
т.е. другими словами, после первого шага уже можно проверять — возможно проблема «уйдет».

2. Перезапустить сервер

3) делаем бэкап средствами sql

Делать резервное копирование рекомендую при любых действиях, когда может потребоваться «возврат» к предыдущему состоянию данных

4) снимаем базу с поддержки, выгружаем cf

убиваем в менежмент консоли базе данных в таблице config запись более 120Мб, делаем «загрузить конфигурацию» (не объединение) убиваем в менежмент консоли базе данных в таблице config запись более 120Мб, делаем «загрузить конфигурацию» (не объединение)

вот пример работоспособности этого приема

DROP TABLE [dbo].[Config]

5) делаем «загрузить конфигурацию» (не объединение) из cf

после этого проверяем, проблема уходит.

P.S. Если у Вас есть возможность поделиться своим опытом, то давайте расширим данный материал.

Специальные предложения

54-ФЗ

Недавно возникла эта проблема
симтомы
1. Любое действие записи вызывает данную ошибку.
2. Не грузятся обмены
3. Невозможно запустить проверку БД и выгрузку
4. Невозможно открыть конфигуратор из-за блокировки информационной базы

Собственно никаких блокировок БД не было, проверялось и в консоли сервера приложений 1с и в консоли SQL сервера
Лечение.
1. делаем бэкап (на всякий пожарный, можно и не делать у кого смешанная модель бэкапа позволяющая восстановить базу на состояние часа назад к примеру )
2. сносим базу с сервера приложений(не трогая БД на SQL сервере)
и заводим её заново (можно наверно и перезагрузить сервер приложений 8.1,
но у меня на нем крутится более 20 баз, которые работали вполне адекватно)
итого починка занимает не более 5 минут(без бэкапа)

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

спасибо, интересный пример
но если не запускалась проверка, то неплохобы было увидеть текст ошибки (собрать можно технологическим), тогда причина станет очевидней
(3) ПОТРЯСАЮЩЕ! А статью вы пробывали читать или ваша рекомендация отличается от приведенных рекомендаций в статье? ИЛИ ВЫ ПОТВЕРЖДАЕТЕ ПРАВИЛЬНОСТЬ МЕТОДА?
подтверждаю опытным путем было получено, что ошибочка вылетает
при некорректном закрытии программы пользователем (во время заполнения книги продаж в типовой бухне, например ) «Ну надоело ждать».
тока все таки лучшее перегрузить, чем сносить, если есть возможность. Был еще такой глюк с такой же ошибкой в итоге, один из пользователей ставил отбор по одному из сотрудников и вылетали все. пытались повторить на других машинах и другими пользователями, хрена. дальше все продолжают успешно работать, кроме как Невозможно запустить проверку БД и выгрузку. перегружаемси, индекируемси — те же грабли.
У нас не выгружались ни cf ни dt. Оказалось, что после некорректного заверешения сервера предприятия остался висеть процесс rphost. Выяснилось это только через неделю (когда увидели что их больше чем надо :)))). Судя по всему старый процесс блокировал запись в таблице config
Были такие грабли, поставил сервер 2008 с сиквел 2008, 3-й месяц все в норме
У меня всегда лечится перезапуском Сервера 1С. Интересно в новой платформе 8.1.13.37 не решили эту проблему?!
что-то там колдуют с контролем двоичных данных в реквизитах на размер, надеемся на 14 релиз

Включив технологический журнал на время загрузки, можно определить таблицу, в которой содержатся такие хранилища. Найдите средствами MS SQL Server Query Analizer в этой таблице колонки типа image. Для каждой колонки типа image выполните запрос вида:

sel ect top 10 DATALENGTH(_Fld4044)
from _InfoReg4038
order by DATALENGTH(_Fld4044) desc

Он позволит узнать максимальные длины хранимых в них данных. Не рекомендуется хранить данные длиннее 100 — 200Mb.

Ошибка :»Соединение с сервером баз данных разорвано администратором
Microsoft OLE DB Provider for SQL Server: Неопознанная ошибка
HRESULT=80004005″

Имеем : 1C 8.1.13.41 УПП 1.2.19.21 на MS SQL 2005 SP3 на Win2003 Server Enterprise на компе 4Gb физ. памяти (SQL настроен на Max Memory 2Gb)

Решение в моем случае:
Виндовс по-умолчанию 2Гб берет себе, а 2 отдает нам. SQL почти всю остальную память поедал (в настройках стоит 2Gb) и оставлял для всех остальных только 128Мб физ. памяти(как и положено SQL- он не должен забирать ВСЁ, должен 128 оставить). Ошибка 1С начала проявляться после перехода на релиз 1.2.21.1. Да, действительно, в релизе 1.2.19.1 в файле dbo.Config не было записей больше 120Мб. А вот после обновления на 1.2.21.1 такая запись (примерно 135мб )появляется. При снятии с поддержки запись исчезает сама, и ничего удалять не приходится. При постановке на поддержку -снова появляется. Я так понял, что это и есть конфигурация поставщика.
Если SQL оставляет всего 128, а надо целых 135, то вывод- надо дать рабочим процессам живую физическую память. Moжно урезать SQL. А можно винды. Установив в boot.ini ключ /3GB я тем самым отдал виндам 1Gb, а всему остальному 3Gb, а не 2/2 как по умолчанию. После перезагрузки — все ОК.
Буду рад, если эти рекомендации помогут кому-нибудь еще

(14) да, в отношении Config, пункты 1 и 2 как раз и позволяют бороться с размером в 1.2.21.1. Спасибо что подтвердили верность инструкции.
описанная проблема полностью описывает траблы с сифилисом который сейчас твориться у меня с базой (бекапы собственные не создаются) попробую данные здесь рекомендации.
Вопрос — а если отключить поддержку, то как ее вернуть? =) как не странно помогло (проверил на демо базе =)))
Возникла ошибка «Сеанс работы завершен администратором». Установив в boot.ini ключ /3GB ошибка устранилась. Огромное спасибо за полезную информацию.
(21) artur.antipin, аналогичная проблема. Я думаю вряд ли поможет, если 32 Gb на сервере, SQL использует 30, 1Gb погоды не сделает
а можно конкретнее пожалуйста где именно в файле boot.ini установить данный ключ /3GB ?

Недавно у клиентов была такая проблема, просто отпала база с указанной ошибкой. MS SQL 2000 показывал базу не в состоянии Suspend, а в состоянии Offline. Понятно что наивный расчет на Online базы не оправдался и я устроил допрос.

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

После перезагрузки никто не смог войти, т.к. был Offline режим файлы базы скопировать тоже не удавалось, без меня делать детач боялись. Но так как мне ничего не оставалось я нажал детач. Сервер не много подумал и отключил базу но в списке баз отключенная база осталась не отобража имени, просто пустая строка, перезапуск сервера открылся с(!) подключенной живой базой. Но была проблема, беглый осмотр основных мест показал, что полностью упали итоги регистра Заказы покупателей( изб блокировки были связаны скорее всего с этим) в итоге пришлось их пересчитывать 2,5 часа не долго, но обычно за месяц итоги считались минут 15, значит точно упали.
КонецИстории )

з.ы. причин установить не удалось

Целый день бьюсь с этой проблемой. Пришлось потанцевать с бубном. УПП 1.2.27 Платформа 15. sql 2005. Ошибка решилась соблюдением следующей последовательности действий.
1) удаляю записи больше 120 мб в sql.
2) Снимаю базу с поддержки
3)Объединяю с типовой cf 1.2.27 без галок (одновременно ставлю на поддержку) 1.2.27 предварительно протестирована и исправлена (не знаю важно ли это, но было именно так)
Возникла аналогичная проблема «Соединение с сервером баз данных разорвано администратором Microsoft OLE DB Provider for SQL Server: Неопознанная ошибка
HRESULT=80004005″ при выгрузке конфигурации из БП 1.6.24.7 на 1С 8.2, сервер SQL 2000. Вопрос решился добавлением рабочего процесса в консоли «Серверы 1С:Предприятия 8.2». Попробуйте.
Тоже возникла проблема с основной конфигурацией в файловом варианте. Как посоветуете drop-нуть ConfigSave?

Ошибка: Сеанс работы завершен администратором.
по причине:
Соединение с сервером баз данных разорвано администратором
Microsoft OLE DB Provider for SQL Server: [DBNETLIB][ConnectionRead (recv()).]General network error. Check your network documentation.
HRESULT=80004005, SQLSrvr: Error state=1, Severity=10, native=11, line=0

1C 8.1.14 + MS SQl 2005 + Терминальник (на 3х серверах)

Ошибка возникает при любых действиях пользователя — хаотично ((( причин установить не удалось

(27) как ваша ошибка коррелирует с указанной в статье «Неопознанная ошибка»?
У вас же проблема с большей вероятностью в включенном файрволе.
(28) файрволов/антивирусов нет на сервере + Ошибка возникла без каких либо изменений в системе через год после експлуатации.
(27) Vet_ne, Не подскажете как проблема решилась, у меня тоже HRESULT=80004005, SQLSrvr: Error state=1, Severity=10, native=11, line=0
бодаюсь пока безрезультатно.

вот выдержка из этой статьи (хоть и для 2000, но принцип тотже):

Устранение неполадок с установкой подключений
Большинство подобных неполадок в SQL Server 2000 возникает из-за проблем с протоколом TCP/IP или проверкой подлинности Windows либо сочетанием проблем обоих типов.

Внимание! Перед тем как приниматься за устранение неполадок с установкой подключений в SQL Server 2000, убедитесь, что на компьютере с SQL Server запущена служба MSSQLServer.

ping <Server Name>

Запишите возвращенный IP-адрес.
4. Из командной строки выполните следующую команду (где IP address — это IP-адрес, выписанный при выполнении действия 3):

ping –a <IP address>

Убедитесь, что команда возвращает правильное имя сервера. Если же одна из указанных выше команд завершается сбоем, возвращает неправильное значение или истекает время ожидания для ее выполнения, значит, неправильно работает просмотр DNS или существует иная проблема, связанная с функционированием сети или маршрутизацией. Чтобы просмотреть текущие параметры DNS, запустите из командной строки следующую команду:

Чтобы устранить эту проблему, добавьте запись для сервера в файл %systemroot%system32driversetchosts на клиентском компьютере. Кроме того, обойти проблему можно путем установки подключения к серверу с помощью сетевой библиотеки именованных каналов.

Примечание. Необходимо включить хотя бы протокол TCP/IP и именованные каналы.
3. Откройте вкладку Псевдоним и проверьте псевдонимы, настроенные для экземпляра SQL Server.
4. Убедитесь, что в свойствах псевдонимов правильно настроены имя сервера (IP-адрес) и протокол.
Можно создать новый псевдоним для тестирования подключения по имени сервера, IP-адресу или другому протоколу.

Примечание. В более ранних версиях компонентов доступа к данным Майкрософт (MDAC) интерфейс программы сетевого клиента отличается. Таким образом, если вы не видите описанных в этой статье элементов интерфейса, установите на клиентском компьютере более новую версию компонентов MDAC.

3. Также с этой ситуацией пересекается следующая ситуация:
10007066 Запись данных, содержащих колонки типа ХранилищеЗначения
Проблема:
При использовании СУБД MS SQL SERVER при записи объекта базы данных, содержащего несколько колонок типа ХранилищеЗначения, данные для которых получены из файлов, может происходить ошибка
Ошибка СУБД:Microsoft OLE DB Provider for SQL Server: String data length mismatchHRESULT=80004005и аварийное завершение работы программы.

S_elect top 10 DATALENGTH(_Fld4044)
from _InfoReg4038
order by DATALENGTH(_Fld4044) desc

Нюансы: обратите внимание, что ”Стандартные проверки” платформой (chdbfl, в конфигураторе) упорно говорят, что с базой все ОК.

1С:Предприятие 8.2. Лицензия на сервер (x86-64)

По опыту проблема связана с хранением данных в реквизите хранилище значений либо наличием в таблице config двоичных данных БОЛЬШЕ 120 mb.

Обобщенные рекомендации, если рекомендации от 1С не помогли (проделать следующие действия в указанном порядке):

1. Выключить все фоновый задачи у всех баз
В 8.1.11 появился переключатель “запрет на фоновые задания” в
момент создания базы.

Готов пояснить, фоновые задания сами по себе не зло, но регламентные процедуры
с полнотекстовым поиском – вещь в себе – и память она может через какое время
съедать ресурсы rphost.exe, что на другие операции не останеться, и просто
базу блокировать
т.е. другими словами, после первого шага уже можно проверять – возможно проблема “уйдет”.

3) делаем бэкап средствами sql
Делать резервное копирование рекомендую при любых действиях, когда может потребоваться “возврат” к предыдущему состоянию данных

4) снимаем базу с поддержки, выгружаем cf
убиваем в менеджмент консоли базе данных в таблице config запись более 120Мб, делаем “загрузить конфигурацию” (не объединение) убиваем в менеджмент консоли базе данных в таблице config запись более 120Мб, делаем “загрузить конфигурацию” (не объединение)

1. Открыть конфигратор;
2. Снял конфигурацию с поддержки, ПРИ ЭТОМ КОНФИГУРАЦИЮ НЕ СОХРАНЯЛ!
3. Далее Сохранить конфигурацию в файл (не сохраняя измененной конфигурации);
4. В SQL для требуемой базы выполнил следующую команду:
DELETE FROM dbo.Config WHERE DataSize > 125829120
5. Загрузить сохраненную конфигурацию обратно.

можно попробовать и более радикальный шаг здесь:
удаляем (в менеджмент консоли) в базе данных таблицу “config”
D_rop TABLE [dbo].[Config]

5) делаем “загрузить конфигурацию” (не объединение) из cf
после этого проверяем, проблема уходит.

6) Ошибка :»Соединение с сервером баз данных разорвано администратором
Microsoft OLE DB Provider for SQL Server: Неопознанная ошибка
HRESULT=80004005″

Имеем : 1C 8.1.13.41 УПП 1.2.19.21 на MS SQL 2005 SP3 на Win2003 Server Enterprise на компе 4Gb физ. памяти (SQL настроен на Max Memory 2Gb)

Читайте также:

Автокад на задний план команда
Csv перенос строки в ячейке excel
1с как настроить дисконтные карты в 1с
Как сделать шаблон для шокобокса в ворде
Обработать резолюцию 1с что это

Я думаю каждый хоть раз, но сталкивался с ошибкой 1С Соединение с сервером баз данных разорвано администратором Microsoft SQL Server Native Client 10.0: Неопознанная ошибка HRESULT=80004005

Вот некоторые способы, которые помогут решить данную проблему:

1. Проверить конфигурацию на наличие некорректной информации (мусора). Для этого следует выполнить команду “Проверка конфигурации” с установленным флажком “Проверка логической целостности конфигурации”. При выявлении проблем будет выдано сообщение. Некорректная информация при этом будет удалена автоматически, однако следует обеспечить доступность для изменения корневого объекта конфигурации (напимер, при работе с хранилищем его следует захватить).

2. Если Ваша конфигурация находится на поддержке, следует подобным образом проверить конфигурацию поставщика. Для этого в настройке поддержки следует сохранить конфигурацию поставщика в cf файл, загрузить его в новую базу и выполнить описанную в пункте 1 процедуру. В случае, если было получено сообщение об исправлении, значит конфигурация поставщика содержит некорректную информацию. В этом случае следует снять Вашу конфигурацию с поддержки и заново поставить путем объединения со свежим релизом конфигурации поставщика. В настоящее время все релизы выпускаемые 1С проходят проверку и выпускаются без данной проблемы.

S_elect top 10 DATALENGTH(_Fld4044)
from _InfoReg4038
order by DATALENGTH(_Fld4044) desc

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

1С:Предприятие 8.2. Лицензия на сервер (x86-64)

2. Перезапустить сервер
Второй шаг является частным случаем для вашего случая и после него тоже
есть смысл проверять работоспособность. Однако поскольку существуют утечки памяти http://www.gilev.ru/1c/memleak, то через некоторое время после рестарта пролема может вернуться.

вот пример работоспособности этого приема
http://partners.v8.1c.ru/forum/thread.jsp?id=543293

или

Взято с http://www.forum.mista.ru/topic.php?id=465608

5) делаем “загрузить конфигурацию” (не объединение) из cf
после этого проверяем, проблема уходит.

Имеем : 1C 8.1.13.41 УПП 1.2.19.21 на MS SQL 2005 SP3 на Win2003 Server Enterprise на компе 4Gb физ. памяти (SQL настроен на Max Memory 2Gb)

Решение в моем случае:
Виндовс по-умолчанию 2Гб берет себе, а 2 отдает нам. SQL почти всю остальную память поедал (в настройках стоит 2Gb) и оставлял для всех остальных только 128Мб физ. памяти(как и положено SQL- он не должен забирать ВСЁ, должен 128 оставить). Ошибка 1С начала проявляться после перехода на релиз 1.2.21.1. Да, действительно, в релизе 1.2.19.1 в файле dbo.Config не было записей больше 120Мб. А вот после обновления на 1.2.21.1 такая запись (примерно 135мб )появляется. При снятии с поддержки запись исчезает сама, и ничего удалять не приходится. При постановке на поддержку -снова появляется… Я так понял, что это и есть конфигурация поставщика.
Если SQL оставляет всего 128, а надо целых 135, то вывод- надо дать рабочим процессам живую физическую память. Moжно урезать SQL. А можно винды. Установив в boot.ini ключ /3GB я тем самым отдал виндам 1Gb, а всему остальному 3Gb, а не 2/2 как по умолчанию. После перезагрузки — все ОК.

У Вас есть свое решение!? оставьте его в комментариях)

Содержание:

1. Ошибка СУБД – файл базы данных поврежден

2. Создание резервной копии базы данных

3. Самые распространенные ошибки информационной базы 1С

1. Ошибка СУБД – файл базы данных поврежден

Приветствую, коллеги! Сегодня разберем ситуацию, при которой конфигуратор при попытке выгрузить информационную базу сообщает об ошибке СУБД.

Рис. 1 Ошибка СУБД – файл базы данных поврежден

В сообщении об ошибке СУБД указано, что файл базы данных поврежден. Если посмотреть расшифровку «Подробнее», ничего нового система нам не сообщит. Эта ошибка информационной базы 1С 8.3 возникает исключительно в файловых базах данных. В клиент-серверных базах она не наблюдается.

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

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

Итак, возникает закономерный вопрос: как сделать резервную копию базы, если процедура «Выгрузить информационную базу» не работает из-за ошибки СУБД?

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

Теперь расскажу, как найти утилиту для исправления базы данных? Переходим туда, где на ПК расположена Ваша база (путь можно посмотреть в свойствах ярлыка на рабочем столе), чаще всего – на диске С. Находим каталог 1cv8, где видим список установленных платформ на текущий момент. Выбираем ту, которую мы запомнили в конфигураторе на предыдущем шаге, заходим в неё, далее – в каталог bin. Теперь нам необходимо найти приложение с именем Chdbfl. Этот файлик будет помечен именно как приложение. Запускаем его

Рис. 2 Приложение chdbfl

Теперь для исправления ошибки СУБД необходимо выбрать имя файла базы данных. Находим битую базу в каталоге, выбираем этот файл и ставим галочку «Исправлять обнаруженные ошибки». При анализе физической целостности файла базы данных утилита будет автоматически исправлять ошибки.

Нажимаем кнопку «Выполнить» – происходит проверка файла базы данных.

Рис. 3 Окно проверки физической целостности файла

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

2. Создание резервной копии базы данных

Перед любыми манипуляциями с программой обязательно делаем резервную копию базы данных. Кликаем на ярлык 1С два раза, в открывшемся списке баз выбираем нужную и переходим в Конфигуратор. Сверху выбираем меню «Администрированье». Далее выбираем пункт выгрузка информационной базы, затем выбираем путь сохранения, пишем имя файла выгрузки. Программа подумает некоторое время и далее оповестит вас, что выгрузка информационной базы успешно завершена.

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

Как определить, что режим работы файловый, и папку, в которой храниться база? Заходим в лаунчер 1С и выбираем нужную базу. Нажимаем кнопку «Изменить», если указатель стоит на первом пункте, то база файловая, а чуть ниже написано места ее расположения. Изображение номер 4.

Рис. 4 Местонахождение базы на компьютере

Заходим в папку с базой и копируем ее в другое место. Таким образом мы получаем резервную копию базы данных.

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

3. Самые распространенные ошибки информационной базы 1С

А теперь перейдём к другим ошибкам информационной базы 1С 8.3 и способам их устранения. Первая – ошибка формата потока при загрузке базы. Причин появления этого сообщения великое множество, поэтому перейдем сразу к лечению, варианта всего три. Первый – тестирование и исправление базы 1С. Второй – утилита chdbfl. Третий – это очистка кэша.

Для тестирования и исправления заходим в конфигуратор. Сверху выбираем меню «Администрирование → Тестирование/исправление». Далее выставляем галочки как показано на изображении 5 и нажимаем кнопку «Выполнить».

Рис. 5 Тестирование и исправление базы 1С

Теперь переходим к утилите chdbfl. Находим папку, куда была установлена программа 1С. В ней ищем папку bin, где будет иконка синего цилиндра под названием chdfbl. Запускаем утилиту. В открывшемся окне ищем папку, в которой хранится наша информационная база. Зайдя в неё, выбираем файл 1сv8 1cd. Затем устанавливаем галочку «Исправлять обнаруженные ошибки» и жмем «Выполнить». Когда chdbfl закончит свою работу, можем пробовать зайти в программу.

Как уже было сказано, третий способ – это очистка кэша. Кэшем называют определенное место на компьютере для хранения записей копий страниц в Интернете. Даже единожды зайдя на какой-либо сайт, Вы автоматически создаете на своем ПК его копию, чтобы ускорить загрузку страниц при последующих посещениях. Рекомендуются через некоторое время очищать кэш браузера, так как со временем некоторые страницы сайта обновляются, a кэш этой страницы будет по-прежнему загружать старую версию. Также если Вы обнаружили вирус и на своем компьютере, после его удаления или лечения обязательно почистите кэш браузера, чтобы повторно не заразить компьютер. Если долгое время не чистить кэш, объем копируемых страниц для памяти может существенно увеличиться, тем самым замедляя работу кэширования. Ускорение обработки веб-страницы имеет такой же принцип, как на современных смартфонах.

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

После удаления базы из списка ее нужно опять добавить. Для этого нажимаем кнопку добавить, выбираем второй пункт из трех предложенных, а именно: «Добавление в список существующих ИБ». Нажимаем «Далее», указываем наименование базы, папку, где хранится база, и снова нажимаем «Далее», а затем – «Готово». Теперь мы можем проверять работоспособность программы.

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

Ошибка «Недостаточно свободной памяти» – третья в нашем списке. Данное сообщение обычно появляется при обновлении программы, формирование большого отчета и прочих сложных операциях. Запускаем командную строку и вписываем следующее:

Рис. 6 Исправление ошибки недостаточно свободно памяти в командной строке

Число в конце — это размер желаемой памяти. Перезагружаем компьютер, заходим в 1С и пробуем сделать ту операцию, в процессе которой появилась ошибка.

Номер четыре – ошибка «Запись дампа», появляющаяся при выполнении какой-либо операции в программе. Данная ошибка показана на рис. 7.

Рис. 7 Окно ошибки дампа

В первую очередь пробуем отключить аппаратное ускорение видео карты. Как это делать, Вам придётся загуглить самим, потому что последовательность здесь зависит от операционной системы. Второй способ устранения данной проблемы – установка другой версии платформы 1С.

Номер пять – ошибка СУБД: Внутренняя ошибка компонента dbeng8.

Изображение 9 – Ошибка СУБД

Для исправления этой ошибки идем по стандартному сценарию: тестирование и исправление; если не помогает, то chdbfl; если также не помогает, то обновление платформы 1С.

Номер шесть – «Неверный формат хранилища данных».

Рис. 9 Ошибка формата хранилища данных

Возможные варианты устранения данной ошибки – это очистка кэша или тестирование и исправление базы 1С.

Если 1С отказывается запускаться и выдает ошибку: «У текущего пользователя нет доступных ролей для запуска информационной базы», то этому пользователю необходимо назначить соответствующую роль через конфигуратор, перейдя в «Администрирование → Пользователи → [выбрав пользователя] Прочее».

Рис. 10 Ошибка прав доступа

Иногда при старте 1С возникает сообщение об отсутствии прав для запуска требуемого вида клиента. Возможно, был создан новый пользователь вообще без ролей. Как это понять? Заходим в Конфигуратор, переходим к списку пользователей и видим напротив имени интересующего нас сотрудника знак вопроса. Делаем то же самое, что и в предыдущем пункте: заходим в карточку пользователя и на вкладке «Прочие» назначаем ему нужную роль.

Специалист компании «Кодерлайн»

Никита Брежицкий

Источник

Обновлено: 28.01.2023

Методика выявления длительной транзакции, которая привела к значительному расходу tempdb

К таким транзакциям стоит относиться подозрительно и стараться их не допускать.

Методика выявления длительной транзакции, которая привела к значительному расходу tempdb

1 — Зафиксировать значительное потребление tempdb

В целом объем свободного места можно оценить даже простейшим запросом

Для оперативной реакции на рост объема tempdb можно использовать «Инциденты и генерацию оповещений в ЦКК».

2 — Найти номер транзакции в MS SQL Server Management Studio

На этом шаге мы понимаем, что сейчас происходит значительное потребление места в tempdb.

Первые две колонки — номер сессии с СУБД и длительность транзакции.

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

Запоминаем номер session_id

В этом примере можно увидеть искомую транзакцию

3 — Находим код, выполнение которого привело к длительному выполнению в транзакции

Открываем консоль администрирования кластера серверов.

Переходим на закладку сеансы.

Нас интересуют две колонки:

— Соединение с СУБД

Запоминаем номер сеанса.

Обратите внимание, что session_id = Соединение с СУБД.

Опять же, если будет очень плохо, можно завершить сеанс.

В технологическом журнале это будет выглядеть так:

Но удаление сеанса — на крайний случай.

4 — Выясняем, что делает этот сеанс

Открываем журнал регистрации, отбираем по номеру сеанса , смотрим, что сеанс делает.

Копировать в буфер обменаЗдесь 321 — это номер сеанса.

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

5 — Воспроизводим и разбираем проблему

Необходимо повторять где-то на копии ровно эту операцию.

На копии нас интересует запрос и его план, при выполнении которого потребовался большой объем данных в СУБД.

в техжурнале следующее:

Поддерживаю, та же фигня.
Версии конфигурации, платформы и SQL такие же.
Другие базы работают нормально.

было что то похожее

Сегодня появилась с утра! Не у всех пользователей. Трое отписались с приложением скрина.

1С:Предприятие 8.3 (8.3.12.1440)
1С:Комплексная автоматизация 2 (2.4.3.160)

Ведомость на счета — увольнение

(126) Та же ерунда в БП 3.0 после обновления платформы. Похоже дело в ней

1С:Предприятие 8.3 (8.3.12.1412)
Зарплата и кадры государственного учреждения, редакция 3.1 (3.1.6.54)

Выходит при попытке проведения вновь созданного кассового ордера.

После обновления платформы на версию 8.3.12.1469 ошибка SQL при проведении исчезла.

перешли на платформу 1С:Предприятие 8.3 (8.3.12.1529)

на пятый день возникла ошибка у некоторых пользователей и в логах Фоновое задание. Ошибка выполнения:

Платформа 8.3.10.2505 (не меняли полгода), последних 3 дня периодически выскакивает ошибка:

Нашлось решение этой проблемы или опять ждать милости 1С?

Коллеги,
появилась такая же ошибка.

Платформа — 8.3.10
Конфа — Документооборот.
Всё работало полтора года исправно.

При эсклуатации баз данных 1С вы можете сталкнуться с такой ситуацией:

Признаки проблемы: нельзя выгрузить в dt

Сотрудники 1С рекомендуют решать проблему так:

Также с этой ситуацией пересекается следующая ситуация:

2. Перезапустить сервер

3) делаем бэкап средствами sql

4) снимаем базу с поддержки, выгружаем cf

вот пример работоспособности этого приема

DROP TABLE [dbo].[Config]

5) делаем «загрузить конфигурацию» (не объединение) из cf

после этого проверяем, проблема уходит.

P.S. Если у Вас есть возможность поделиться своим опытом, то давайте расширим данный материал.

Специальные предложения

54-ФЗ

sel ect top 10 DATALENGTH(_Fld4044)
from _InfoReg4038
order by DATALENGTH(_Fld4044) desc

Имеем : 1C 8.1.13.41 УПП 1.2.19.21 на MS SQL 2005 SP3 на Win2003 Server Enterprise на компе 4Gb физ. памяти (SQL настроен на Max Memory 2Gb)

з.ы. причин установить не удалось

1C 8.1.14 + MS SQl 2005 + Терминальник (на 3х серверах)

Ошибка возникает при любых действиях пользователя — хаотично ((( причин установить не удалось

вот выдержка из этой статьи (хоть и для 2000, но принцип тотже):

ping <Server Name>

ping –a <IP address>

S_elect top 10 DATALENGTH(_Fld4044)
from _InfoReg4038
order by DATALENGTH(_Fld4044) desc

1С:Предприятие 8.2. Лицензия на сервер (x86-64)

5) делаем “загрузить конфигурацию” (не объединение) из cf
после этого проверяем, проблема уходит.

Имеем : 1C 8.1.13.41 УПП 1.2.19.21 на MS SQL 2005 SP3 на Win2003 Server Enterprise на компе 4Gb физ. памяти (SQL настроен на Max Memory 2Gb)

Читайте также:

Автокад на задний план команда
Csv перенос строки в ячейке excel
1с как настроить дисконтные карты в 1с
Как сделать шаблон для шокобокса в ворде
Обработать резолюцию 1с что это

Источник

Вот некоторые способы, которые помогут решить данную проблему:

S_elect top 10 DATALENGTH(_Fld4044)
from _InfoReg4038
order by DATALENGTH(_Fld4044) desc

1С:Предприятие 8.2. Лицензия на сервер (x86-64)

вот пример работоспособности этого приема
http://partners.v8.1c.ru/forum/thread.jsp?id=543293

или

Взято с http://www.forum.mista.ru/topic.php?id=465608

5) делаем “загрузить конфигурацию” (не объединение) из cf
после этого проверяем, проблема уходит.

Имеем : 1C 8.1.13.41 УПП 1.2.19.21 на MS SQL 2005 SP3 на Win2003 Server Enterprise на компе 4Gb физ. памяти (SQL настроен на Max Memory 2Gb)

Решение в моем случае:
Виндовс по-умолчанию 2Гб берет себе, а 2 отдает нам. SQL почти всю остальную память поедал (в настройках стоит 2Gb) и оставлял для всех остальных только 128Мб физ. памяти(как и положено SQL- он не должен забирать ВСЁ, должен 128 оставить). Ошибка 1С начала проявляться после перехода на релиз 1.2.21.1. Да, действительно, в релизе 1.2.19.1 в файле dbo.Config не было записей больше 120Мб. А вот после обновления на 1.2.21.1 такая запись (примерно 135мб )появляется. При снятии с поддержки запись исчезает сама, и ничего удалять не приходится. При постановке на поддержку -снова появляется… Я так понял, что это и есть конфигурация поставщика.
Если SQL оставляет всего 128, а надо целых 135, то вывод- надо дать рабочим процессам живую физическую память. Moжно урезать SQL. А можно винды. Установив в boot.ini ключ /3GB я тем самым отдал виндам 1Gb, а всему остальному 3Gb, а не 2/2 как по умолчанию. После перезагрузки — все ОК.

У Вас есть свое решение!? оставьте его в комментариях)

Источник

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

Инфраструктура

Платформа 1С:Предприятие 8, версия 8.3.17.1549
1С:ERP Управление предприятием 2, версия 2.5.5.77
Сервер СУБД: MS SQL Server
Виртуализация средствами VMware
Количество баз ERP: 20+
Все 20 ИБ работают в режиме «20 кластеров на одной ВМ»:

один сервер приложений 1C

один сервер СУБД

один сервер лицензирования

Проблема с которой пришел заказчик

В одном крупном отечественном публичном акционерном обществе, в более 20 дочерних организаций (далее ДО) учет ведется в 1С:ERP Управление предприятием 2 (далее ERP) – по базе на ДО. В одной из баз ДО (наиболее крупной) процедуры быстрого закрытия месяца выполнялись неприемлемо долго.

Детализация проблемы – понимаем масштаб бедствия

Что показало обследование текущего положения дел:

1. Сроки выполнения закрытия месяца не устраивали заказчика абсолютно. Например, в самой крупной ДО вся процедура стала выполняться более суток!

2. А самая длительная операция – непосредственно расчет себестоимости, – выполнялась порядка 9-11 часов.

3. Длительность операции отражения документов в регламентированном учете достигала 12 часов.

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

5. Исходя из аппаратных мощностей заказчика были попытки запустить на одновременное выполнение закрытие месяца в 20+ баз ERP, но эти попытки к успеху не привели – фатальная деградация производительности возникала и в этом случае.

На момент обращения к нам у заказчика был организован такой порядок: закрытие месяца запускалось последовательно в каждой базе ERP. С дежурством ответственных лиц по круглосуточному графику.

Самое начало – декомпозиция проблемы

После обследования проблему заказчика укрупненно разбили на две подзадачи:

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

Решение задачи стабильности

Решать задачи быстродействия без устранения проблем стабильности было бы не корректно, поэтому начинаем со стабильности.

То, что фоновое задание расчета регулярно «падало» без каких-либо явных причин, на наш взгляд, требовало первоочередного решения.

В момент прерывания фонового задания единственное, что появлялось в Журнале регистрации 1С (далее ЖР 1С) – это запись, что фоновое задание «отменили». Здесь важно отметить: пользователи «всё отрицали», а сама отмена происходила по ночам, когда люди никак на это не влияли (спали).

Для начала нужно убедиться, что аппаратные (в данном случае – средства виртуализации), средства СУБД, сервера приложений и другие программные средства работают в штатном режиме. То есть исключить ошибки и проблемы на этом уровне – провести аудит инфраструктуры.

Для этого обновили параметры Технологического журнала 1С (далее ТЖ 1С) с целью сбора более полной картины работы платформы 1С. Также настроили сбор счетчиков загрузки оборудования при помощи perfmon.

На инфраструктурном уровне было выявлено три ключевые проблемы:

1. Ощутимо длительная миграция Виртуальных машин (далее ВМ).

2. Большое количество переподписок на уровне хостов.

3. Софтверное ограничение на количество операций ввода-вывода для дисковой подсистемы в настройках ВМ, особенно на дисках под СУБД.

В связи с проблемами 1 (длительная миграция) и 2 (много переподписок) наблюдались «фризы» гостевой ОС, на которой располагались серверы 1С и СУБД – это показал анализ ТЖ 1С. Такая ситуация приводила к аварийному завершению процессов в кластерах 1С – подсистема отслеживания разрыва соединений 1С завершала их по таймауту, что было вполне штатным поведением в этом случае.

Решением здесь стало устранение миграций ВМ (запретили в настройках). Настроили выделение хостов таким образом, чтобы снизить количество переподписок и их перегрузки. Дополнительно увеличили значения «ping period» и «ping timeout». Теперь время миграции сократилось с минут до секунд, а кластер 1С это переживал штатно и аварийно процессы не завершал.

Вторая проблема была связана с бизнес-процессами заказчика, т.к. каждый ресурс для ВМ предоставляется «как сервис» и настройки изначально были установлены в режим минимального потребления. Ограничение IOPS для дисков с базой данных и tempdb на сервере СУБД было установлено в 8000. Наблюдалось огромное накопленное ожидание времени отклика и очереди к дискам.

Здесь добились снятия ограничений.

Решив проблемы инфраструктурного уровня, вернулись к проблемам внутри 1С. Оказалось, что проблема отмены фонового задания никуда не делась. С одной стороны, мы видим, что оно не завершается аварийно – то есть с точки зрения работы кластера 1С проблем нет. С другой стороны, по факту фоновое задание не завершено успешно.

Складывается ощущение, что какой-то пользователь отменяет выполнение операции (случайно или нет). Клиент утверждает, что так его пользователи в системе 1С себя не ведут. Не забываем, также, про ночь — чаще всего проблема возникает в момент неактивности пользователей.

ОКей. Настраиваем ТЖ 1С. Помимо «джентельменского набора» из событий ADMIN, CLSTR, PROC, ATTN, EXCP, SESN и CONN, которые мы собираем во всех случаях, здесь нам, кажется, придется добавить и события по ”SCALL” и “CALL”, причем с контекстами — мы хотим понять, кто сделал вызов, который привел к отмене задания. Чтобы логи не были большими, добавим фильтр по имени метода MName=cancelJobs:

Запускаем контрольный расчет. Дожидаемся очередной «отмены».

Смотрим в ТЖ 1С: на контексты, на пользователей, в них участвующих. Начинаем во всем этом разбираться…

*** По соображениям NDA мы не можем опубликовать здесь логи заказчика, но так как мы хорошо разобрались в проблеме — для статьи воспроизвели аналогичную ситуацию у себя. Публикуем оттуда ключевые моменты ***

Конечно, мы видим в журнале событие ADMIN с Func=killClient:

34:27.654029-0,ADMIN,2,process=rphost,p:processName=ServerJobExecutorContext,OSThread=16140,t:clientID=20,t:applicationName=JobScheduler,t:computerName=ITE-MP-00159,Func=killClient,ClusterID=21a7019b-f1a0-422e-9387-95dab1819984,ConnectionID=0f337f02-6264-4b0d-86a5-917909aa7cc3,Mode=0,Ref=Expert_ERP(Expert_ERP),Host=ITE-MP-00159,Connection=171,Administrator=Unknown,Result=Success

Вслед за ним после нотификации CALL с MName=killConnections видим EXCP, тот самый, который увидел пользователь:

34:27.670002-0,EXCP,4,process=rphost,p:processName=Expert_ERP,OSThread=17276,t:clientID=35,t:applicationName=BackgroundJob,t:computerName=ITE-MP-00159,t:connectID=171,SessionID=5,Usr=Administrator,Exception=95c658d1-d3d5-4ea9-8a81-1bf820fea4a8,Descr='src\rscalls\src\RemoteCallListenerImpl.cpp(4014):
95c658d1-d3d5-4ea9-8a81-1bf820fea4a8: Сеанс работы завершен администратором.',Context='
ОбщийМодуль.ЗакрытиеМесяцаСервер.Модуль : 3322 : Обработки.ОперацииЗакрытияМесяца.ВыполнитьРасчетЭтапов(ПараметрыЗапуска);

Эта информация нам ничего не дает. Зато сделанный примерно в то же время в сеансе пользователя, запустившего фоновое задание, исходящий вызов:

34:26.779013-4,SCALL,3,process=rphost,p:processName=Expert_ERP,OSThread=23516,t:clientID=19,t:applicationName=1CV8C,t:computerName=ITE-MP-00159,t:connectID=1,SessionID=1,Usr=Administrator,AppID=1CV8C,ClientID=46,Interface=90d50089-2b1d-4316-ad85-32c83d325a76,IName=IClusterJobManager,Method=9,CallID=12735,MName=cancelJobs,DstClientID=62,Context='Форма.Вызов : Обработка.ОперацииЗакрытияМесяца.Форма.ЗакрытиеМесяца.Модуль.ЗавершениеЗаданийПриЗакрытииФормы
Обработка.ОперацииЗакрытияМесяца.Форма.ЗакрытиеМесяца.Форма : 1293 : ОтменитьФоновоеЗадание(ИдентификаторЗаданияРасчетаЭтапов, Ложь);
	Обработка.ОперацииЗакрытияМесяца.Форма.ЗакрытиеМесяца.Форма : 1939 : Если НЕ ЗакрытиеМесяцаСервер.ОтменитьВыполнениеФоновогоЗадания(ИдентификаторЗадания) Тогда
		ОбщийМодуль.ЗакрытиеМесяцаСервер.Модуль : 4732 : СостояниеЗадания.Задание.Отменить();'

Наконец приоткрывает завесу тайны.

…оказывается пользователь действительно не нажимал никаких «отмен».

НО!

Но пользователь запускал расчет через управляемую форму, которую затем закрывал. И как видно из отрывка кода этой формы – при её закрытии происходило завершение всех фоновых заданий, связанных с ней.

Хорошо. Проблему неожиданной «отмены» фонового задания выявили. заказчику рекомендовали изменить логику поведения формы, ответственных пользователей попросили на период выполнения процесса закрытия месяца – форму не закрывать.

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

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

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

ОКей, меняем настройки терминального сервера так, чтобы убрать таймауты и сессии пользователей не завершать.

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

Но в один из дней в тестовом контуре заказчика мы ловим очередную проблему с тяжелым фоновым заданием. В одном из тестов оно снова завершается досрочно. На этот раз оно не «отменено». На этот раз завершается аварийно. Причина в логах указано как:

Соединение с сервером баз данных разорвано администратором

Обращаемся к администраторам с вопросом, зачем они с нами так. Ожидаемый ответ: «мы ничего не делали». Идем в логи

В логах СУБД чисто – никаких команд на разрыв нет. Сервер СУБД вроде как работает штатно. Опять какая-то «магия».

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

При анализе ТЖ 1С видно – процессы не завершаются, на серверах СУБД нет никакой характерной активности (команду «kill» никто, включая платформу 1С, не вызывал). Следов зависаний и перезапуска ВМ – не видим. Как будто бы все работает штатно.

Единственное, за что зацепился глаз – за 20 минут до аварийного завершения фонового задания, один из сеансов записал в ТЖ 1С ошибку соединения с сервером баз данных.

Смутило именно точное число – 20 минут. Поэтому изначально предположили, что речь идет о каких-то кэшах, сеансовых данных и тому подобных вещах. И какое-то время потратили на попытку разобраться, что, где и как может мешать нормальной работе системы. Это на какое-то время отвлекло нас от более глубокого анализа инфраструктуры: изначально мы сразу сделали экспресс-аудит и выдали набор стандартных рекомендаций по самым очевидным вещам, поэтому ожидалось что наши рекомендации учтены и работы по замечаниям выполнены.

Эти «20 минут» не давали покоя, поэтому не найдя ничего на уровне прикладного ПО и СУБД, мы снова вернулись на уровень инфраструктуры. Детальное расследование показало, что в момент времени «за 20 минут до завершения фонового задания» происходила миграция ВМ – очень быстро и кратковременно. Поэтому в ТЖ это даже никак и не отражалось. При таком стечении обстоятельств соединения с СУБД в пуле, сформированном платформой 1С, могут оказаться невалидны: попытка их использования даже спустя 20 минут после миграции выполняется платформой, но тут же завершается ошибкой.

Дальнейшее расследование привело к регистрации ошибки платформы 1С:

Иными словами, фоновое задание само по себе оказалось ни при чем. Сказалось неудачное стечение обстоятельств в комбинации с работой механизмов платформы 1С и средств виртуализации.

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

Заказчику было рекомендовано обновить версию платформы 1С.

Здесь можно подвести некоторые итоги – так сказать, зафиксировать промежуточный результат:

1. Решены все проблемы стабильности – в первую очередь в работе длительного фонового задания расчета себестоимости.

2. При этом расчет выполняется стабильно, но стабильно медленно

Переходим к решению вопросов производительности

Изучаем подробный протокол расчета себестоимости. В частности, «топ 10» самых медленных этапов.

На примере самого крупного ДО заказчика показатели были такими:

расчет согласно протоколу в среднем длился 9 часов
при этом на этапе Партионный учет: ЗаписатьСформированныеДвижения в течение более 3 часов записывалось свыше 10 миллионов результирующих записей в регистры по итогам этого расчета

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

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

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

В итоге нам удалось снизить время расчета с 9 часов до 4.5 часов.

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

Для оптимизации этого процесса было решено распараллелить запись движений внутри каждого регистра (настройки по умолчанию подразумевают параллельную запись в разные регистры, но в рамках одного — строго последовательную). Для этого в настройках параметров расчета в ERP разрешили параллельную запись движений в 20 потоков. Кроме этого, в конфигурацию самой СУБД внесли следующие изменения:

Max Degree of Parallelism (MAXDOP) = 8
Cost Threshold for Parallelism (cost degree) = 400
TF 1224 (заранее понимаем, что без него никак)

ВНИМАНИЕ! Настройки СУБД не являются рекомендованными, подобраны в этой конкретной ситуации опытным путем и приводятся только с целью ознакомления.

Результат после применения такой настройки по времени выполнения снизился с 4.5 часов до 2.5 часов.

Казалось бы, целевой показатель на базе самого крупного ДО достигнут и можно выдыхать

Ан нет!

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

Тестовый запуск закрытия месяца в двух ДО одновременно показывает следующее:

загрузка процессора на серверах не выше 40 %
RAM на сервере кластера 1С – свободна на 50%
PLE на сервере СУБД не падает ниже 20-30 тысяч
buffer cache hit ratio 100%
время отклика дисков – ниже 10 миллисекунд

То есть показатели «железа» в норме и с большим запасом. Однако время расчета и в основном в части записи движений увеличивается в 1.5-2 раза в случае запуска в нескольких базах одновременно. И все эти показатели почти никак не отличаются от показателей во время закрытия месяца в какой-нибудь одной базе, но скорость самого закрытия в таком режиме – в два раза выше.

Вот некоторые показатели, полученные из SolarWinds (промышленное программное обеспечение для управления сетями, системами и инфраструктурой) заказчика:

Ожидания СУБД при расчете в одной базе

Ожидания СУБД при параллельном расчете в 2 ИБ

(обратите внимание на желтый показатель – ASYNC_NETWORK_IO)

СУБД: Page life expectancy

СУБД: Avg. Disk sec/Write

СУБД: % Processor Time

Внимательно все снова изучив (и не по одному разу), предполагаем, что проблема где-то в сети (потому что все остальное у нас покрыто метриками). Точнее понять, что именно и с чем это связано – не получается. Ни один график загрузки оборудования явных подсказок не дает.

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

Для этого используем хорошо себя зарекомендовавший Windows Performance Recorder (WPR) в паре с Windows Performance Analyzer (WPA) – подчас именно они выручают в ситуациях, когда «ничего не понятно, но что-то происходит».

Замечаем на сервере СУБД на одном ядре загрузку CPU system time, близкую при параллельном расчете к 100%. При этом остальные ядра могут простаивать. Явно что-то происходит в системных функциях ОС.

Для того чтобы выяснить, что именно происходит в системном слое ОС, включаем трассировку WPR. Открываем в WPA и практически сразу обращаем внимание на системный драйвер «NDIS.SYS» – он с большим отрывом оказался в топе, причем работает действительно на одном ядре в один момент времени — том самом, которое в то же самое время показывало 100% загрузку в привилегированном режиме:

Иными словами, анализ трассировки WPR сервера СУБД подтвердил предположение о том, что наибольшую нагрузку на CPU в привилегированном режиме создает драйвер сетевого интерфейса NDIS.SYS.

К слову, предположение о возможной проблеме нами уже озвучивалось ранее в проколе рекомендаций по итогам экспресс-аудита инфраструктуры. Тогда мы отмечали высокую нагрузку на одно ядро на сервере СУБД, источник которой на тот момент не был установлен.

Полезно тут отметить вот что. Важно перепроверять не только свои действия/гипотезы, но и работу других команд в процессе решения общей проблемы. Здесь мы выдали в самом начале рекомендации «как устранить», но не проверили их применение. И отсутствие выполнения работ по нашим рекомендациям потом замедлило и усложнило нам путь в решении проблемы. В общем, принцип «доверяй, но проверяй» работает и на ИТ-проектах. Не наступайте на наши грабли! И мы тоже больше не будем

Разбираемся. В настройках ВМ есть параметр Receive Side Scaling (RSS), отвечающий за способ разбора сетевого трафика – одним ядром это выполняется (выключен), либо распараллеливается (включен и указано количество). И в данном случае RSS был включен для ОС, но выключен для сетевого адаптера vmxnet3:

По рекомендации VMware включаем RSS для адаптера и выполняем его настройку, в частности, задаем Max Number of RSS processors = 4.

Проверяем. Вуаля: разницы при параллельном и последовательном расчете в нескольких базах ERP теперь нет. Сервер СУБД наконец-то загружен на все 70-80%.

Заказчик полученными показателями доволен

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

Благодарим за внимание!

Вместо Post Scriptum

Конечно, процесс оптимизации можно продолжать [бесконечно]. Например, мы выявили что был также выключен прямой доступ к памяти (NetDMA). При необходимости, можно включить и его.

Узнать подробнее про WPR можно здесь:
https://docs.microsoft.com/ru-ru/windows-hardware/test/wpt/windows-performance-recorder

Про WPA там же рядом:
https://docs.microsoft.com/ru-ru/windows-hardware/test/wpt/windows-performance-analyzer

Что такое RSS, как технология обеспечивает распределение обработки входящих сетевых потоков по нескольким vCPU – неплохо описано в базе данных Microsoft:
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh997036(v=ws.11)

Рекомендации по включению и настройке RSS от VMware:
https://kb.vmware.com/s/article/2008925

Примеры настройки RSS:
https://communities.vmware.com/t5/ESXi-Discussions/RSS-issues-at-Windows-2012-R2-with-VMXNET3-and-10-2-0-VM-Tools/td-p/2747421

Обязательно убедитесь, что установлены актуальные версии драйверов!

Впервые статья опубликована в сообществе Инфостарт: https://infostart.ru/1c/articles/1692364/

Источник

Сеанс работы завершен администратором. ☑ 0

Robin iz Robinov

02.05.13

✎

16:21

Помогите люди добрые.

При обмене выходит ошибка:

Сеанс работы завершен администратором.

по причине:

Соединение с сервером баз данных разорвано администратором

Microsoft SQL Server Native Client 10.0: Неопознанная ошибка

HRESULT=80004005,

Также не выгружает DT.

Также не идут регламентные задания (обмен).

База на SQL

Чисти dbo._ConfigChngR, dbo._ConfigChngR_ExtProps без результатов.

SQL 2008 R2

1C 8.2.17.157

Wobland

02.05.13

✎