Serg58Вопросы:
1) Надо ли ещё что-нибудь делать в нашем случае?
2) Не совсем понял момент по значению data - оно не уменьшилось после удаления записей, а наоборот выросло, так и должно быть?
3) Вечером перезагружаем сервер, после полного запуска SQL съедает 15-25% ОЗУ, утром приходим(ночью отработал скрипт расчистки, потом бекап, потом индексация, потом шринк) и съедено 70-90% ОЗУ, в течение дня доходит до ~97%. Так и должно быть?1.а Шринк срочно уберите, он раз за разом замедляет работу базы.
1.б Пытайтесь оптимизировать работу приложения, например, модифицируйте его, если возможно, или попытайтесь построить недостающие индексы.
2. Вообще должно уменьшаться, раз удаляете.
3. Нормально. Если на сервере запущены ещё какие то приложения, кроме MSSQL, то можете ограничить ему память. Он забирает столько памяти, сколько дадут.

Serg58И ещё момент: шринк вообще отключать на совсем? или не делать его ежедневно?
Со слов технаря он отключал шринк, но тогда лог вырастает до 200Гб.Да, насовсем. Файл должен вырасти до некоторого размера, а потом стабилизироваться.
Скорее всего, для выполнения некоторых действий (например, реиндексации) нужен запас пространства, вот файл и растёт. после выполнения этих действий место в файле освобождается. Так зачем сокращать файл, если он потом всё равно расширится?
Шринк - это аварийная разовая операция, которая делается для устранения последствий каких либо ошибок в эксплуатации базы, делать его нужно не по расписанию, а обдуманно, и вместе с устранением этих ошибок.

Serg58а вообще после обширного удаления данных что необходимо сделать? переиндексацию?Да, можно перестроить индексы, после завершения всего процесса удаления (не очередной порции)
Serg58Приложение не наше, не доступно для изменения, и относительно часто обновляется, поэтому даже доступные для изменения хранимые процедуры, которые использует приложение не хочется трогать, т.к. в случае будущих обновлений можно что-либо упустить. И изменять структуру БД уж совсем не хочется.Да, это понятно, ну вот, на этот случай я добавил про "индексы". Проанализируйте профайлером долгие запросы, посмотрите рекомендации сервера (он их показывает при просмотре планов), и возможно либо решите проблему созданием индексов, либо обновлением статистики, либо хотя бы передадите конкретику разработчикам.
Serg58Параллельно веду переписку с разработчиком ПО, они говорят, что база огромна и надо расчищать :-\Это яркий и однозначный признак непрофессионализма разработчиков. Не должны старые данные влиять на скорость выполнения оперативных транзакций.
Serg58полагаю, мы делаем, что то не правильно, я здесь и пытаюсь разобраться. Сам я НЕ обслуживаю БД, я с ней работаю, тот кто обслуживает говорит, что планы настроил в соответствии с инструкцией которую получил от поставщика ПО.И к тем, кто обслуживает, тот же самый вопрос. Почему разбираетесь вы, а не они, почему не они задают тут вопросы, почему не они дают вам эти советы, и вообще, просто не решают проблемы, что бы вы и пользователи их даже не заметили? "Планы настроил в соответствии с инструкцией"? Он кто, секретарша-машинистка, тексты набирает по инструкции, или специалист по MSSQL?
Serg58Индексацию выключали и не помнят когда.Вообще говоря, перестроение индекса нужно, что бы устранить последствия шринка (и для других подобных случаев). Для нормального использования индексов их не нужно перестраивать.
Достаточно обновлять статистику, да и то можно не каждый день.

Serg58Мне приходит в голову идея сначала очищать базу до максимально возможного и на ночь включать пересоздание индексов. Только вот очищать базу мы будем примерно месяц.Вот через месяц всё это и сделаете.

Уберите шринк, сделаете его вручную после очистки, тогда же сделаете и переиндексацию
В ежедневных джобах оставьте бакап и статистику, последнюю можно попробовать перенести на выходные, если не будет хватать времени.

Serg583) шринк - каждые 6 часов начиная с 04:00 и до 23:59 (резервное копирование (журнал транзакций), сжатие бд, очистка журнала, очистка после обслуживания(удаление резервного копирования бд), очистка после обслуживания(отчёт плана обслуживания)).:-) В общем, напихали всё, про что прочитали :-)

Serg58Правильно ли я понял, что после порционного удаления можно делать обновление статистики (exec sp_msforeachtable 'update statistics ?') а когда расчистим базу сильно сделать переиндексацию(exec sp_msforeachtable 'dbcc dbreindex(''?'')')Да.

Serg58Два вопроса:
1) когда нужно использовать дефрагментацию индексов(exec sp_msforeachtable 'dbcc INDEXDEFRAG (BDname, ''?'')' ?
2) сейчас у нас стоит цель из 22млн(основной таблицы) расчистить не нужные нам данные, это где то 50-80%, и мы выйдем на ориентировочно следующий цикл: в день поступает ~30-50 тысяч новых записей, и примерно столько же будет удаляться старых(которые отлежали примерно год в базе), в таком случае какой принцип обслуживания, когда что делать?1. Когда индексы фрагментируются. Погуглите скрипты, они обычно оценивают уровень фрагментации, и потом делают дефрагментацию, если надо.
Но можно не связываться, а делать (редко, раз в месяц, например) перестроение индексов, или вообще никогда не делать - зависит от вашей системы.
2. Делать обновление статистики раз в неделю.
Serg58А тут запустили удаление старых данных и сразу же появились проблемы с тем, что раньше работало. Причём работает это именно с теми таблицами, которые очищаются.Это может быть из за неактуальной статистики, или от шринка.
Serg58Думается мне, что если запустить обновление статистики и дефрагментацию индексов запрос будет выполнятся в разы быстрее.Да, или статистику и дефрагментацию, или перестроить индексы (вместе и то и другое не надо - при перестроении статистика становится актуальной, и фрагментация исчезает).
Serg58Щукина Анна1) Бэкапы. В общем случае принято делать не только полный бэкап базы, но и периодические бэкапы транзакт-лога (между полными бэкапами). Периодичность выбирать исходя из интенсивности изменения данных и желаемого размера транзакт-лога. В этом случае размер лога не будет выходить "за рамки приличия". А его шринки станут невостребованной операцией.
Про бекап, повторюсь, буду разбираться отдельно. Сейчас у нас полное зеркалирование БД идёт в 2 сервер.
И вот эти бекапы, о которых писал выше.Если у вас модель полная, и нет бакапа лога, то разобраться с этим - первоочередная задача, потому что все изменения, которые вы делаете с данными (в том числе удаляемые старые данные) остаются в базе.

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

2.в связи с отключением шринка посмотреть сколько будет весить журнал(лог), если он будет слишком огромный просчитать вариант перехода на 2-3 полных бекапа в неделю, вместо одного, либо вообще рассмотреть вариант отказа от разностного(дифференцированного) варианта и перейти на бекап лога (журнал транзакций).
В полной модели лог хранится вечно , он не удаляется дифф или полными бакапами, шринком и т.д.
Освободить место в файле лога можно только бакапом лога, и никак иначе.
Либо вообще ничего там не хранить, переведя базу с полной модели на простую.
Serg58ещё прочитал про очистку процедурного кэша (DBCC FREEPROCCACHE), но пока не понял, надо ли оно.Обычно это делают для тестирования, регулярно не надо.

В остальном да, ну, может мелочь какая то.

Обновлять статистику до или после бакапа - неважно.

Щукина АннаalexeyvgЛибо вообще ничего там не хранить, переведя базу с полной модели на простую.Судя по тому, как ТС притворяет рекомендации с форума в жизнь своей системы - не мешало бы уточнить, чем чревато держать базу в режиме Simple.Просто начинающему не-сиквелисту не рассказать про весь сиквел в обычном ответе на вопрос, поэтому я не стал углубляться. Ну и бакап лога не делается, а лог они видимо очищают каким то надыбанным в инете скриптом, поэтому хуже уже не будет :-)
Наверное, их устраивает возможность восстановления на время создания дифф бакапа, ну и ладно.
Щукина АннаКроме того, ТС пару раз упоминал о зеркалировании. Непонятно, что за зеркалирование и на чем построено. Может там лог-шиппинг, несовместимый с простым режимом или ещё что-то....Да, я тоже заметил. Ну, если лог нужен для зеркалирования, сиквел про это скажет, не даст перевести в симпл.