Если обрывы будут постоянными до 35 сек каждую минуту?
Тут as design. Если обрывается соединение, то и запрос будет откатываться. Для таких целей есть функционал копирования сгенерированного скрипта и его запуск со стороны сервака.
Цель предоставить функционал, а то как ним пользоваться уже дело пользователя. Зачастую ребилд индексов и вправду смысла не имеет. А вот обновление статистики, сжатие индексов и прочии перки — это да.
Из базы с более 1500 индексов с трудом притаскивает около сотни
Все настройками устанавливается. По дефолту не тянутся индексы тяжелее 8Гб.
Не говоря уже о том что считать эти индексы уходит аж несколько (5-7) минут
Скажем за это спасибо Microsoft. Данные о фрагментации индекса не кешируется на постоянной основе, потому происходит частичный скан индекса если его нет в буффер пуле (потому ограничение по размеру и делал).
Ну не совсем так. Реализован механизм частичного дескрайба. То есть все тянется не одним большим запросом, а вначале получаются все мелкие индексы за раз, а потом в цикле добирается точечными запросами большие по размеру индексы (если что настраивается).
Что в файле *.log? Ситуаций может быть тьма. Как вариант все индексы не требуют обслуживания. Или слишком большие, что не включаются в общий список при анализе. Может быть бажина какая-то в запросе. Если покажете лог в личке, то смогу точно сказать. Ну и как вариант посмотрите на настройки свои.
Идея хорошая, но у меня сейчас все силы на другое брошены: техническая статья о том как прога работает, публикация на английском и прочее. Чем больше народ будет тулом пользоваться тем больший фитбек я получить смогу и сделать все лучше.
Мое мнение, индексы нет особого смысла дефрагментировать – лишняя нагрузка на дисковую подсистему и процессор. А вот тот факт, что статистика обновляется за счет ребилда – это штука полезная, поэтому чаще нужно не на индексы смотреть, а на статистику. Плюс чаще всего обслуживание индексов делать нужно для сокращения занимаемого места на диске, а не для борьбы с логической фрагментацией (кучи не в счет, потому что там forwarded records — это проблема насущная).
Спасибо бро. Как говорил мой знакомый «от души душевно в душу». Суть идеи — наклепать полезных тулов, которых в работе мне всегда не хватало… и чтобы народ ними тоже пользовался.
Все таки люблю ваши статьи читать. Спасибо за полезный материал. Чисто из любопытства не подскажите тулы самописные, которые напрямую будут из mdf / ldf данные читать?
Что сказать… я доволен. Разработчики Oracle последовали примеру Microsoft. Где начиная с SQL Server 2016 SP1 можно на экспрессе использовать фишки более старших версий (секционирование, колумнсторы и ин-мемори). Авось и в 2019 версии чуть уменьшат ограничения по ресурсам по примеру Oracle.
Так сделайте усечение файла данных. SQL Server за Вас это не будет делать (если конечно одна плохая настройка не включена по дефолту). Почитайте как сделать Shrink Flies.
Можно попробовать в следующий раз написать более медленный вариант скрипта по удалению :) но суть не поменяется. А вообще-то советую свежие обновления на машину поставить и посмотреть что и как можно сконфигурировать, чтобы все быстрее шевелилось. Например, за счет Instant File Initialization.
А что опасного? Если нет никаких блокировок на изменению схемы, то все нормально сможеть выполниться. Решите для себя нужны ли Вам эти данные. В них хранится история запуска планов обслуживания, насколько я помню. Что такое сжатие в Вашем понимании? Есть на уровне ROW, PAGE и отдельный фетиш — ColumnStore (начиная с 2014го).
USE msdb
GO
ALTER TABLE dbo.sysmaintplan_log
DROP CONSTRAINT FK_sysmaintplan_log_subplan_id
ALTER TABLE dbo.sysmaintplan_logdetail
DROP CONSTRAINT FK_sysmaintplan_log_detail_task_id
GO
TRUNCATE TABLE msdb.dbo.sysmaintplan_logdetail
TRUNCATE TABLE msdb.dbo.sysmaintplan_log
GO
ALTER TABLE dbo.sysmaintplan_log WITH CHECK
ADD CONSTRAINT FK_sysmaintplan_log_subplan_id
FOREIGN KEY(subplan_id)
REFERENCES dbo.sysmaintplan_subplans (subplan_id)
GO
ALTER TABLE dbo.sysmaintplan_logdetail WITH CHECK
ADD CONSTRAINT FK_sysmaintplan_log_detail_task_id
FOREIGN KEY(task_detail_id)
REFERENCES dbo.sysmaintplan_log (task_detail_id) ON DELETE CASCADE
GO
Тут as design. Если обрывается соединение, то и запрос будет откатываться. Для таких целей есть функционал копирования сгенерированного скрипта и его запуск со стороны сервака.
Цель предоставить функционал, а то как ним пользоваться уже дело пользователя. Зачастую ребилд индексов и вправду смысла не имеет. А вот обновление статистики, сжатие индексов и прочии перки — это да.
Все настройками устанавливается. По дефолту не тянутся индексы тяжелее 8Гб.
Скажем за это спасибо Microsoft. Данные о фрагментации индекса не кешируется на постоянной основе, потому происходит частичный скан индекса если его нет в буффер пуле (потому ограничение по размеру и делал).
Да. Изначально так и работает.
Учитывает редакцию сиквела. И если есть возможность только тогда используется (при условии что в настройках включена).
Ограничения контрола. Увы пока исправить не могу. Возможно в будующем, когдна новую логику реализую.
Что в файле *.log? Ситуаций может быть тьма. Как вариант все индексы не требуют обслуживания. Или слишком большие, что не включаются в общий список при анализе. Может быть бажина какая-то в запросе. Если покажете лог в личке, то смогу точно сказать. Ну и как вариант посмотрите на настройки свои.
Мое мнение, индексы нет особого смысла дефрагментировать – лишняя нагрузка на дисковую подсистему и процессор. А вот тот факт, что статистика обновляется за счет ребилда – это штука полезная, поэтому чаще нужно не на индексы смотреть, а на статистику. Плюс чаще всего обслуживание индексов делать нужно для сокращения занимаемого места на диске, а не для борьбы с логической фрагментацией (кучи не в счет, потому что там forwarded records — это проблема насущная).
Ссылка на исходники программы:
github.com/sergeysyrovatchenko/SQLIndexManager
Обсуждение нового функционала:
www.sql.ru/forum/1312218/sql-index-manager-besplatnaya-utilita-po-obsluzhivaniu-indeksov-dlya-sql-server-i-azure