Здравствуйте, прошу сильно не бить, а если и бить то не по почкам.
С sql я знаком дня этак 3, нужен скрипт перестроения индекса в T-SQL, кто может подсказать как сформировать правильный запрос?
Нужно что-то универсальное, т.к. серверов несколько, везде свой лес (свои настройки и структура бд), времени на изучение вопроса катастрофически нет. Ну и если не сильно универсальное то хотя бы в какую сторону копать, синтаксис команды ALTER INDEX (Transact-SQL) в силу отсутсвия знаний не дает ровным счетом ничего, просто из-за того, что нужно понимать всю суть всего что касается индексов, на что сейчас просто нет времени :(
Делаю обслуживание БД через sqlcmd с логированием результата и подтягиванием аларма в систему мониторинга, что бы быть в курсе где что не так с БД.

Так же хотел бы уточнить, верно ли я понимаю суть обслуживания БД SQL
1) проверка целостности БД
2) перестроение индекса
3) обновление статистики
4) очистка процедурного кэша
5) собственно сам бэкапинг базы
6) очистка журнала

p.s. ну и предвидя возможные вопросы, почему не делать все это через планы обслуживания - используем sql express :) ну и лично для меня в систему мониторинга так проще запросы подтягивать наверное

Владислав КолосовTaPaKIvanIvan48,

а кэш вам чем мешает?

У какого-то индуса прочитал.
именно так) но вроде как аргументирванно)

[youtube=

Короче вот тут он про очистку процедурного кэша, в предыдущем сообщении что-то ролик не заработал как должен был)

в ролике на 29ой минуте 17 секнде

есть ALTER INDEX (Transact-SQL)
можно ли сделать универсальный запрос по перестройке индексов или тут нужно прям дла каждой отдельно взятой базы все подстраивать до мелочей? сори если задаю глупые вопросы :)

автор https://ola.hallengren.com/downloads.html
ну я так понял это что-то типа процедуры, по проще варианта нет, чем портянка на 5 страница 10 шрифтом?!)

uaggsterчеловек_ниоткуда1) проверка целостности БД
Не нужна если БД на СХД или RAID с проверкой целостности.
...
RAID5/1/10 и т.д.?
Какая-нибудь бяка в драйвере контроллера, и всё, понеслось!
...
у нас такой случай был, бэкапилось все на тот же диск, думали что raid 10 это что-то вечное, из гранита, в итоге умерло все) после этого рейдам я доверяю еще меньше чем раньше.

Вы мне глупому нубу скажите, копать или не копать?)
Я так понял переиндексацию делать не стоит, базы максимум по 30-40 гиг и не сильно нагружены, т.е. изменения не прямо вот быстрые какие-то, просто пополняют потиху)
Что выполнять, что не выполнять? А то тут холивар разгорается :D

1) проверяю целостность БД
2) обновляю статистику
3) делаю шринк
4) бэкаплю
так?

еще по t-sql
тут все верно по скриптам или как-то не так? а то sql сказал что он мол не отвечает за последствия предоставленного им кода)))

1) проверяю целостность БД
/chesk.sql
USE [mytest001]
GO
DBCC CHECKDB(N'mytest001') WITH NO_INFOMSGS

2) обновляю статистику
/stat.sql
use [mybase123]
GO
UPDATE STATISTICS [dbo].[Table_1]
WITH FULLSCAN

3)
/shrink.sql
USE [mytest001]
GO
DBCC SHRINKDATABASE (mytest001, TRUNCATEONLY)

4)
/backup.sql
BACKUP DATABASE [mybase123] TO DISK = N'C:\script\BASE\mybase' WITH RETAINDAYS = 3, NOFORMAT, INIT, NAME = N'mybase123_backup_2017_05_24_234900_4553030', SKIP, REWIND, NOUNLOAD, COMPRESSION, STATS = 10
GO
declare @backupSetId as int
select @backupSetId = position from msdb..backupset where database_name=N'mybase123' and backup_set_id=(select max(backup_set_id) from msdb..backupset where database_name=N'mybase123' )
if @backupSetId is null begin raiserror(N'Ошибка верификации. Сведения о резервном копировании для базы данных "mybase123" не найдены.', 16, 1) end
RESTORE VERIFYONLY FROM DISK = N'C:\script\BASE\mybase' WITH FILE = @backupSetId, NOUNLOAD, NOREWIND

так?

авторsp_updatestats выполняет инструкцию UPDATE STATISTICS, указывая ключевое слово ALL, на всех пользовательских и внутренних таблиц в базе данных. sp_updatestats выводит сообщения о ходе своего выполнения. По завершении обновления выдается отчет о том, что обновление статистики произведено для всех таблиц.

Процедура sp_updatestats обновляет статистику по отключенным некластеризованным индексам и не обновляет статистику по отключенным кластеризованным индексам.

Для дисковых таблиц sp_updatestats обновляет только статистику, требующую обновления, основываясь на modification_counter сведения в sys.dm_db_stats_properties представления каталога, таким образом предотвращаются ненужные обновления статистики по неизменным строкам. Статистика в таблицах, оптимизированных для памяти всегда обновляется при выполнении sp_updatestats. Поэтому не следует вызывать sp_updatestats чаще, чем необходимо.

sp_updatestats можно запустить повторную компиляцию хранимых процедур или других скомпилированного кода. Тем не менее sp_updatestats может не вызвать повторную компиляцию, если только один план запроса для целевых таблиц и индексов на них. Повторная компиляция в этих случаях будет не нужна даже при обновлении статистики.

Для баз данных с уровнем совместимости ниже 90 при выполнении процедуры sp_updatestats не сохраняет последнее значение параметра NORECOMPUTE для заданной статистики. Для баз данных с уровнем совместимости 90 или выше sp_updatestats сохраняет последнее значение параметра NORECOMPUTE для заданной статистики. Дополнительные сведения об отключении и повторном включении обновления статистики см. в разделе статистики.


я так понял, что просто по дефолту UPDATE STATISTICS делается только для строго указанных таблиц и прочего, когда их много, то видимо замудохаешься их переписывать, для удоства сделали процедуру sp_updatestats, которая автоматом все подтягивает, лучше использовать ее или все таки руками все шкрябать в скрипт?

рабочий вариант скрипта:
авторUSE [mytest001]
GO
EXEC sp_updatestats

лог после выполнения:
авторКонтекст базы данных изменен на "mytest001".
Обновление [sys].[sqlagent_jobs]
[sqlagent_jobs_clust], обновление не обязательно...
[sqlagent_jobs_nc1_name], обновление не обязательно...
Статистика по индексам 0 обновлена, 2 не потребовало обновления.
Обновление [sys].[sqlagent_jobsteps]
[sqlagent_jobsteps_clust], обновление не обязательно...
[sqlagent_jobsteps_nc1], обновление не обязательно...
[sqlagent_jobsteps_nc2], обновление не обязательно...
Статистика по индексам 0 обновлена, 3 не потребовало обновления.
Обновление [sys].[sqlagent_job_history]
[sqlagent_job_history_clust], обновление не обязательно...
[sqlagent_job_history_nc1], обновление не обязательно...
Статистика по индексам 0 обновлена, 2 не потребовало обновления.
Обновление [sys].[sqlagent_jobsteps_logs]
[sqlagent_jobsteps_logs_nc1], обновление не обязательно...
Статистика по индексам 0 обновлена, 1 не потребовало обновления.
Обновление [dbo].[Table_1]
[PK_Table_1], обновление не обязательно...
Статистика по индексам 0 обновлена, 1 не потребовало обновления.
Обновление [dbo].[sysdiagrams]
[PK__sysdiagr__C2B05B61256235CA], обновление не обязательно...
[UK_principal_name], обновление не обязательно...
Статистика по индексам 0 обновлена, 2 не потребовало обновления.
Обновление [sys].[queue_messages_1977058079]
[queue_clustered_index], обновление не обязательно...
[queue_secondary_index], обновление не обязательно...
Статистика по индексам 0 обновлена, 2 не потребовало обновления.
Обновление [sys].[queue_messages_2009058193]
[queue_clustered_index], обновление не обязательно...
[queue_secondary_index], обновление не обязательно...
Статистика по индексам 0 обновлена, 2 не потребовало обновления.
Обновление [sys].[queue_messages_2041058307]
[queue_clustered_index], обновление не обязательно...
[queue_secondary_index], обновление не обязательно...
Статистика по индексам 0 обновлена, 2 не потребовало обновления.
Обновление [sys].[filestream_tombstone_2073058421]
[FSTSClusIdx], обновление не обязательно...
[FSTSNCIdx], обновление не обязательно...
Статистика по индексам 0 обновлена, 2 не потребовало обновления.
Обновление [sys].[syscommittab]
[ci_commit_ts], обновление не обязательно...
[si_xdes_id], обновление не обязательно...
Статистика по индексам 0 обновлена, 2 не потребовало обновления.
Обновление [sys].[filetable_updates_2105058535]
[FFtUpdateIdx], обновление не обязательно...
Статистика по индексам 0 обновлена, 1 не потребовало обновления.
Статистика по всем таблицам обновлена.

И еще вопрос по шринку, есть ли смысл его включать в обслуживание, если майкрософт не советует это делать, т.е. ну понятно, если прям критический вопрос в плане места, то придется в любом случае, но вот что мелкософты пишут:
авторРекомендации
Обратите внимание на следующие сведения при планировании сжатия базы данных.
Наибольший эффект от операции сжатия достигается при ее применении после операции, создающей много неиспользуемого пространства, например после усечения таблицы или удаления таблицы.
Большинству баз данных требуется некоторое свободное пространство для выполнения обычных ежедневных операций. Если сжатие базы данных производится регулярно, но она снова увеличивается в размерах, это означает, что место, освобожденное при сжатии, необходимо для нормальной работы. В таких случаях повторное сжатие базы данных бессмысленно.
Операция сжатия не избавляет от фрагментации индексов в базе данных и обычно приводит к еще более сильной фрагментации. Это еще одна причина, по которой не стоит выполнять регулярное сжатие базы данных.
Не следует устанавливать параметр базы данных AUTO_SHRINK в значение ON без достаточных на то оснований.
поэтому вот даже хз) индексы типа сильнее фрагментируются.

Со шринком все понятно, журнал раз в сутки, базу раз в месяц и то, в крайнем случае. По остальному тоже понятно. Честно говоря я всегда думал что проверка базы делает в режиме read-only, у меня все обслуживаение и бэкапинг будет исключительно ночью.
По какой причине сначало надо бэкапить, а потом уже проверять базу? Просто ну для меня это не логично) при проверке происходит запись в эту же базу что ли?