Константин, я вижу, что ваша база данных хорошо структурирована и обвязана хранимыми процедурами. Процедуры даже избыточны, например некоторые из блока Health дублируют функционал инструментов MSSQL. Это говорит о том, что вы заложили в систему хорошие возможности автоматизации, наверное не хотели привязываться к версии сервера баз данных и упростить требования к квалификации персонала. Хочется этими возможностями пользоваться, поэтому я и задаю свои вопросы.
Логика подробного логирования понятна.
Уточню, что говоря ниже про лог я имею в виду внутреннее логирование Vogbit, а не лог SQL.
Не понятно влияние объема лога на производительность. Я не знаю деталей вашей реализации, поэтому могу только предполагать.
По идее лог - это такая структура, в которую данные много и последовательно пишутся и редко, только в случае инцидентов, читаются. Для того, чтобы он быстро отрабатывал запись, ему нужно упростить структура (возможно за счет избыточности уменьшить количество взаимосвязанных таблиц) и минимизировать количество индексов, триггеров и правил. Пусть уж чуть медленнее происходят редкие разборы полетов, чем тормозит основной функционал. В любом случае набор таблиц для логирования не пересекается же с таблицами для производственных данных. Как же его объем может влиять на скорость манипуляций с производственными данными? На мой взгляд в двух случаях:
1) Лог сам по себе так реализован, что медленно отрабатывает запись, поэтому тормозять и прочие операции, которые ждут записи в лог. Тут уж надо что-то в системе кардинально менять...
2) Лог занимает в базе значительное место, а база сильно фрагментирована. В нашем случае, как я предполагаю, это и было основной причиной. Про исправление данной ситуации я все подробно написал выше.
Давайте теперь порассуждаем про обслуживание лога. Тут, как мне кажется у вас есть перекос в логике.
С одной стороны вы говорите, что без человека не обойтись при очистке. С другой стороны функционал очистки вешаете на SA. У него может быть в обслуживании несколько десятков серверов и сотня баз данных. Что этот человек должен знать о сеансах Vogbit? Как принимать решение об очистке? Придется пригласить кого-нибудь из пользователей Vogbit, того, кто в Vogbit является администратором, но почему-то как раз сеансы чистить и не может, хотя это полностью внутренняя кухня Vogbit. Это мне напоминает анекдот на тему "Сколько программистов нужно, чтобы выкрутить лампочку". Такой подход провоцирует на удаление всего закрытого без разбора при возникновении тормозов в работе. Ну и в чем тогда ценность лога?
На мой взгляд, если уж в систему заложена возможность автоматизации, то замечательно работала бы схема:
1) Администратор Vogbit имеет право чистить сеансы
2) Можно настроить задание SQL Agent на запуск хранимой процедуры (у вас там даже есть какие-то заглушки General.CleanEvents, General.CleanObject), которая бы удаляла данные из лога, например так: все закрытые операции, дата закрытия которых произошла более 1 года назад. Срок давности можно задавать параметром.
В сочетании с правильно настроенным размером базы, FillFactor-ом и ребилдом индексов это создаст хорошо обслуживаемую, стабильную систему.
Очистку устаревших производственных заданий можно реализовать по этой же схеме.
Для особых случаев можно очищаемые данные не просто удалять, а выгружать в архив (хоты бы простой CSV) для тех, кому и очистить базу для производительности надо и данные необходимо хранить лет 10 по каким-либо требованиям законодательства.
Мне кажется, что возможности к автоматизации вы заложили, но сами же их и отключили своим завышенным требованием к работе от SA.