База 1С: защита от дурака #396184

Назрел такой вопрос: где-то раз в месяц находится один шибко умный из 150 пользователей, который по ошибке или из злого умысла запускает особо тяжелый отчет (например, с выборкой по документам за 3 года с мелими отборами и т.п.) Сервер у нас неплохой, он не валится сразу от такой наглости, а начинает увлеченно лопатить данные и довольно скоро затыкается - перестает отвечать... Приходится рестартовать, причем, именно SQL, т.к. с сервером приложений всё в порядке - он курит бамбук, пока SQL находится в запарке. Вопросы: 1. как вычислить гада? 2. как обезопасить себя от таких фокусов?

Мне кажется, что проблема не в пользователях, а в сервере.

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

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

:D

с ограничением по отборам и группировкам не выход: например, отчет "Валовая прибыль" абсолютно безболезненно можно запускать со сложной группировкой по документу-регистратору, номенклатуре и т.п. за день-два или с группировкой по дням и по подразделениям за 3 года, но вот всё вместе за год вызовет полный ступор. А учесть все сочетания отборов и группировок всех отчетов (а у нас только внешних отчетов больше сотни + почти 2/3 стандартных отчетов УПП) невозможно :( Сбрасывать в какой-нибудь лог все настройки каждого запускаемого отчета? Опять же это значит, надо в каждый отчет впихнуть модуль логгирования.

Имхо, заморачиваться особо не стоит. Достаточно записывать в лог время начала и окончания заполнения отчета. С началом все просто - пристроить код к кнопке. А вот как "отследить" окончание - надо подумать :(

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

без изменения отчетов думаю сложно будет...

+1 согласен, - запись в лог только длительное исполнение. Мы ловим акул - не стоит мелочится :)

Интересно, можно ли отсекать на уровне MS SQL? Например, результат по выборке превышает определенный порог (100 мб, например), то дальше не выбирать, а стопить (возможно, с ошибкой)

нет

(мысли в процессе) Юзвер, запустивший "конфликтный" отчет, - затормозит исполнение простых отчетов - они тоже станут "длительными". Нужен анализ - кто первый всех тормознул :)

+ можно у юзверя на машине, если загрузка проца процессом больше 49% (для двухядерного) на протяжении больше 5 мин., сносить процесс

верно. вчера была ситуация - сервер 1С стоит без дела, SQL сервер настолько отчаянно молотит, что просто открытие документа занимало по 5-6 минут (против обычных 1-2 секунд), не говоря уж о запуске даже самых простых отчетов

Нет, не пройдет. Машина юзвера, запустивщего отчет, - не парится особо, ожидая отклика от SQL-сервера

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

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

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

предлагаю топ 3 наказывать =)

на sql в свойствах базы есть параметр "время ожидания выполнения" 0 - бесконечное. попробуй поменять

Нет, лучше отрезать хвост по самую голову - автоматом отключать соединение. Вот

Ни в коем случае :( Будет валиться на индексации и прочих "нужных", но длинных, вещах.

дельный совет, передам админу, будем пробовать

только очень осторожно:) см.

черт. и правда. у нас база 34 Гб, многие регламентные процедуры очень долгие :( а резать базу будем только в конце года

Я против "в принципе". Дурные юзверы грузят сервер, а мы им что? Потакаем, - ищем пути решения последствий. А надо - источники проблемы решать. Имхо, не только прогерсками и админсткими штучками, - но и административно.

сорри поспешил - опечаток много :(

сколько процов у сервера? какая память?

а как интересно отследить окончание отчета - если в перезагружают сервер?

И что? Все данные пропадают при этом?

делай регистр сведений... тип аразрешенные настройки для пользователей/групп.... кто в них не попадает... выдается типа " превышен интервал отчета"...

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

Записи о начале запуска отчета остаются в регистре накопления - достаточно что-бы понять кто был инициатором "зависания". Разумеется, регистр независимый, "статистику" - чистим, удаляя не актуальные записи. Реализовать алгоритм работы с ним и его обслуживание - это уже мелочи...

* с учетом Но можно реализовать и по другому - не настаиваю.

+1 но автор "против" в

2хXeon 5440 / 32 Gb / база лежит на 2 полках массива IBM DS 4700

SQL сервер перегружается крайне редко - раз в 2-3 месяца, когда вот такая байда возникает. И то  - предпочитаем ждать окончания работы отчета, если дело происходит не в часы наибольшей нагрузки. при большой плотности работы в одно время может быть запущено, допустим 20 отчетов, 15 из них окажутся "короткими", 4 - "длинными", а 1 - "критичным". В регистре при рестарте сервера останутся незаконченными все 20 отчетов.