TaPaKесли не смотрите в конкретные запросы, то начните например
https://blog.sqlauthority.com/2011/01/03/sql-server-2008-missing-index-script-download/

с фильтром на ваши основные объектынужно предупредить - что все рекомендации, выдаваемые такими скриптами, требуют тщательной проверки! Возможно, в системе уже есть подобные индексы, у которых всего лишь не хватает поля-другого в секции include. Слепо плодить индексы - не стОит, они - не бесплатные. Индексы нужно хранить, индексы нужно поддерживать в актуальном состоянии (и сейчас речь не за пользовательские манипуляции, а про "подкапотную" работу сервера, связанную с поддержанием целостности и актуальности индексов и с вязанной с ними информацией).

TaPaK,

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

Щукина Анна,

я к тому, что стОит делать акценты на очевидные (не для новичка), но критичные в ситуации ТС моменты...

TaPaK,

вас никто не заставляет его читать... ;)
можете просто игнорировать посты с моим авторством...
в конце концов - я же не вам помогаю ;)

Serg58А можно вопрос? А то запутались совсем...
- Разностное резервное копирование (Differential backup) BACKUP DATABASE WITH DIFFERENTIAL;
- Резервное копирование журнала транзакций (Transaction Log Backup) BACKUP LOG;

это взаимоисключащие вещи или нет? То есть, если мы делаем разностное копирование надо ли нам делать второе?
[SET "Captain Obvious" = ON]

Гораздо правильнее будет сказать - "взаимодополняющие".

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

2) Разностный бэкап, как и алгебраическая "разность", представляет собой разницу между "уменьшаемым" и "вычитаемым" - то есть, по сути, это копия тех страниц, что претерпели изменения с момента последнего бэкапа. И так как это "разность", то сама по себе, без исходного состояния базы, он не представляет никакой ценности. Для восстановления с разностной копии требуется "уменьшаемое" - стартовая ПОЛНАЯ копия базы + все промежуточные "разности". Восстановление возможно лишь на момент выката любой из разностных копий. При наличии только разностной копии, без полной - восстановиться невозможно.

3) Копия транзакт-лога. Журнал, он и в африке - журнал. Содержит все ЛОГИРУЕМЫЕ операции, применяемые к базе. Сам по себе - малоинтересен и бесполезен. Но при наличии исходной полной копии и промежуточных копий журнала позволяет восстановиться на любой момент времени.

В этом плане, если и решать вопрос резервного копирования, то предпочтительнее будет делать полное копирование (обязательно) + копии журнала (обязательно) + разностные копии (по желанию). Периодичность того или иного вида копирования - выбирать исходя из требований ко времени восстановления и допустимому "объему" потерянных данных в случае краха. Потому как, восстановиться с недельной давности полной копии + накат разностных копий за неделю + накат логов с момента последнего разностного бэкапа до момента краха, скорее всего, будет быстрее, чем восстановление с полной копии + накат всех логов за неделю.

[SET "Captain Obvious" = OFF]

Serg58,

1) В общем случае, транзакт-лог - это "бесконечная лента", размер которой ограничен либо заданным на уровне базы лимитом, либо (в отсутствии лимита) - доступным размером свободного места на диске. Как вам уже отвечали ранее другие ораторы - размер лога (занятое место внутри LDF-файла) уменьшается (штатно) только механизмом его резервного копирования. Ни полный бэкап, ни разностный бэкап - размер транзакт-лога не уменьшают. Есть "нештатный" способ уменьшения лога - перевод базы в режим восстановления "simple" с последующим шринком лога. Почему "нештаный"? Потому что есть ограничения на его применения. Если в базе используются вещи, требующие режима "full" или "bulk" (к примеру, лог-шиппинг), то перевод базы в "simple" "ломает" эти вещи и требует дальнейшей их повторной настройки. Более того - сервер будет всячески сопротивляться переводу в simple в этом случае. Поэтому, сначала придется "сломать" лог-шиппинг, после - перевести базу в симпл, урезать лог, а затем - всё вернуть в исходное состояние. Поверьте - по количеству телодвижений и потенциальных мест для факапа - это сильно сложнее, чем банальный бэкап транзакт-лога.

2) Если есть набор разных вариантов бэкапа, то и варианты восстановления будут разные. Можно восстановить полный бэкап и накатить на него все доступные копии журнала транзакций, без промежуточного наката разностных копий. Можно восстановиться с полной копии, "догнаться" всеми промежуточными разностными до какой-то точки, после чего "шлифануть" всё копией журнала. Тут главное помнить - движемся от большего к меньшему. Накатили полный - (опционно) накатили разностные - накатили журнал.

Serg58Вооот! У вас очень просто и понятно написано, откуда вы цитируете если не секрет?Это - вольный, адаптированный и упрощенный пересказ документации ;). Хотя, некоторые считают, что это всего лишь "охх сколько бессмысленного текста..." :)

Minamoto,

верное замечание... видимо, в голове "сварилась каша" из Oracle/PostgreSQL/MS SQL...
В целом, понятно, что общие стратегии и подходы - везде если не одинаковы, то схожи...
Нужно будет вспомнить СУБД-зависимые нюансы и разложить всё по полочкам... :)