Конечно понимаю что лучше хотя бы эта инфа из тех. журнала чем ничего, но.. в реальной базе например у нас сотни!! внешних доп. отчетов, обработок, печатных форм и тд, а все встроенные отчеты - скд, и текст там меняется в зависимости от настроек.. то есть имея текст запроса с тех. журнала с вероятностью 90% нельзя будет ответить на вопрос "Какой отчет вызвал ошибку?". А еще бывают взаимоблокировки, которые 1С предлагает расследовать исключительно ЦУПом (если руководствоваться статьей на ИТС), но ЦУП неплохих денег стоит (100к), и решить одну конкретную проблему в каком то одном конкретном участке кода с помощью ЦУП это как микроскопом гвозди забивать, а альтернативы в 1С как обычно нет насколько я понимаю (
Не очень понял в чем проблема расследовать проблему №2 по взаимоблокировкам. Они делятся на 2 варианта: СУБДшные и платформенные. СУБДшные расследуются с помощью профайлера deadlockgraph. настраиваем профайлер или extended events. платформенные - собираем техжурнал и юзаем инструменты bash - grep sed awk. Смотрите видео Виктора на тему инструментов, если тяжко с ЦУПом. В чем проблема с логированием в ТЖ внешних отчетов - нет контекстов или что, извиняюсь не очень понял.
Александр Мурашов да, проблема в контексте, причем не только внешних отчетов, но и встроенных в конфу, там будет что нибудь типа ОбщийМодуль.СтандартныеПодсистемыСервер (на видео обратите внимание когда автор смотрит лог ТЖ видно общий модуль, а не конкретный отчет).. в общем единая точка выполнения (БСПшная) всех отчетов в фоновом режиме, от нее ни холодно, ни жарко.. от текста запроса так же не сильно много пользы, так как он изменяемый СКД, то есть точно такого же запроса который зафиксировался в ТЖ через поиск по модулям не найдешь, а с внешними отчетами так совсем беда, и поиска по их модулям даже нет ( Вот если бы была возможность в ТЖ добавлять информацию о некоторых переменных контекста, тогда это помогло бы. По поводу ЦУПа, с ним не тяжко, тяжко с бюджетом в 100к что бы расследовать одну ошибку которая появляется раз в 3 месяца... на это 100к никто не хочет выделять, дешевле и проще получается ребутнуть агента сервера, хотя и не правильно конечно ( Ну и ТЖ включенным даже с фильтрами на боевом сервере с нагрузкой под 200 чел онлайн в течении тех же 3 месяцев пока вылезет дедлок то же не комильфо.. так и живем (
Область Эксперта вообще не простая если на то пошло, т.е. делать все по какой-то за ранее созданной инструкции не получится. Вам дали пример, как использовать эти знания и где, решать вам
Максим Аввакумов попробуйте применить на реальной практике, все сами поймете.. никто не просит инструкцию нажми сюда и будет хорошо, нет, я говорю о том что текущих инструментов не достаточно. Вы пользуясь ТЖ не ответите на вопрос "А в каком конкретно отчете произошла ошибка?"
@@alexeibelousov3279 Конкретно для вашего случая используют дополнительное логирование настроек отчетов, например в регистр сведений. По ТЖ вы найдете проблемный запрос, стек вызова кода, время события, . А по сохраненным в регистре настройкам найдете, какие конкретно настройки отчета, обработки.
это если мы тж собираем, а если мы тж не собираем и у нас все зависло, если мы включим тж, то мы уже не увидим это событие.или как-то можно всё-таки увидеть?
Если запрос или вызов сервера завершился успешно, то увидите CALL, DBMSSQL/DBPOSTGRS, SDBL. А если выполняется, то можно срубить и увидеть в ТЖ события ECXP, EXCPCNTX, CALL + RetExcp, QERR Перед тем, как срубить, можно еще и посмотреть в sys.dm_exec_requests + sys.dm_exec_sql_text, что именно выполняется и кушает ресурсы конкретно на СУБД И потом сравнить с тем, что вывалится в ТЖ, чтобы свериться, что это тот самый запрос
Благодарю! Коротко и как всегда интересно
Спасибо. Очень полезная информация!
Спасибо!
Конечно понимаю что лучше хотя бы эта инфа из тех. журнала чем ничего, но.. в реальной базе например у нас сотни!! внешних доп. отчетов, обработок, печатных форм и тд, а все встроенные отчеты - скд, и текст там меняется в зависимости от настроек.. то есть имея текст запроса с тех. журнала с вероятностью 90% нельзя будет ответить на вопрос "Какой отчет вызвал ошибку?". А еще бывают взаимоблокировки, которые 1С предлагает расследовать исключительно ЦУПом (если руководствоваться статьей на ИТС), но ЦУП неплохих денег стоит (100к), и решить одну конкретную проблему в каком то одном конкретном участке кода с помощью ЦУП это как микроскопом гвозди забивать, а альтернативы в 1С как обычно нет насколько я понимаю (
Не очень понял в чем проблема расследовать проблему №2 по взаимоблокировкам. Они делятся на 2 варианта: СУБДшные и платформенные. СУБДшные расследуются с помощью профайлера deadlockgraph. настраиваем профайлер или extended events. платформенные - собираем техжурнал и юзаем инструменты bash - grep sed awk. Смотрите видео Виктора на тему инструментов, если тяжко с ЦУПом.
В чем проблема с логированием в ТЖ внешних отчетов - нет контекстов или что, извиняюсь не очень понял.
Александр Мурашов да, проблема в контексте, причем не только внешних отчетов, но и встроенных в конфу, там будет что нибудь типа ОбщийМодуль.СтандартныеПодсистемыСервер (на видео обратите внимание когда автор смотрит лог ТЖ видно общий модуль, а не конкретный отчет).. в общем единая точка выполнения (БСПшная) всех отчетов в фоновом режиме, от нее ни холодно, ни жарко.. от текста запроса так же не сильно много пользы, так как он изменяемый СКД, то есть точно такого же запроса который зафиксировался в ТЖ через поиск по модулям не найдешь, а с внешними отчетами так совсем беда, и поиска по их модулям даже нет (
Вот если бы была возможность в ТЖ добавлять информацию о некоторых переменных контекста, тогда это помогло бы.
По поводу ЦУПа, с ним не тяжко, тяжко с бюджетом в 100к что бы расследовать одну ошибку которая появляется раз в 3 месяца... на это 100к никто не хочет выделять, дешевле и проще получается ребутнуть агента сервера, хотя и не правильно конечно ( Ну и ТЖ включенным даже с фильтрами на боевом сервере с нагрузкой под 200 чел онлайн в течении тех же 3 месяцев пока вылезет дедлок то же не комильфо.. так и живем (
Область Эксперта вообще не простая если на то пошло, т.е. делать все по какой-то за ранее созданной инструкции не получится. Вам дали пример, как использовать эти знания и где, решать вам
Максим Аввакумов попробуйте применить на реальной практике, все сами поймете.. никто не просит инструкцию нажми сюда и будет хорошо, нет, я говорю о том что текущих инструментов не достаточно. Вы пользуясь ТЖ не ответите на вопрос "А в каком конкретно отчете произошла ошибка?"
@@alexeibelousov3279 Конкретно для вашего случая используют дополнительное логирование настроек отчетов, например в регистр сведений. По ТЖ вы найдете проблемный запрос, стек вызова кода, время события, . А по сохраненным в регистре настройкам найдете, какие конкретно настройки отчета, обработки.
это если мы тж собираем, а если мы тж не собираем и у нас все зависло, если мы включим тж, то мы уже не увидим это событие.или как-то можно всё-таки увидеть?
Если запрос или вызов сервера завершился успешно, то увидите CALL, DBMSSQL/DBPOSTGRS, SDBL.
А если выполняется, то можно срубить и увидеть в ТЖ события ECXP, EXCPCNTX, CALL + RetExcp, QERR
Перед тем, как срубить, можно еще и посмотреть в sys.dm_exec_requests + sys.dm_exec_sql_text, что именно выполняется и кушает ресурсы конкретно на СУБД
И потом сравнить с тем, что вывалится в ТЖ, чтобы свериться, что это тот самый запрос