powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / sys.dm_db_index_physical_stats
25 сообщений из 31, страница 1 из 2
sys.dm_db_index_physical_stats
    #40120960
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Добрый день, знатоки.
Есть база 800ГБ. С незапамятных времен происходит ежедневное обслуживание ночью в порядке:

- полный бекап

- дефрагментация индексов. Скрипт стандартный:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
DECLARE @objectid int;
DECLARE @indexid int;
DECLARE @partitioncount bigint;
DECLARE @schemaname nvarchar(130); 
DECLARE @objectname nvarchar(130); 
DECLARE @indexname nvarchar(130); 
DECLARE @partitionnum bigint;
DECLARE @partitions bigint;
DECLARE @frag float;
DECLARE @command nvarchar(4000); 
DECLARE @page_count bigint;

if object_id('tempdb..#work_to_do') is not null drop table #work_to_do

SELECT 
object_id  AS objectid,
index_id AS indexid,
partition_number AS partitionnum,
avg_fragmentation_in_percent AS frag,
page_count AS  page_count
INTO #work_to_do
FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL , NULL, 'LIMITED') 
WHERE avg_fragmentation_in_percent > 10.0 AND index_id > 0 AND page_count > 20; 

DECLARE partitions CURSOR FOR SELECT * FROM #work_to_do ORDER BY page_count DESC;
OPEN partitions;

WHILE (1=1)
BEGIN;
FETCH NEXT
FROM partitions
INTO @objectid, @indexid, @partitionnum, @frag, @page_count;

IF @@FETCH_STATUS < 0 OR (datepart(hour, GETDATE())>=8 AND datepart(minute, GETDATE())>=0)
  BREAK;
SELECT @objectname = QUOTENAME(o.name), @schemaname = QUOTENAME(s.name)
FROM sys.objects AS o
JOIN sys.schemas as s ON s.schema_id = o.schema_id
WHERE o.object_id = @objectid;
SELECT @indexname = QUOTENAME(name)
FROM sys.indexes
WHERE object_id = @objectid AND index_id = @indexid;
SELECT @partitioncount = count (*)
FROM sys.partitions
WHERE object_id = @objectid AND index_id = @indexid;

IF @frag < 30.0
SET @command = N'ALTER INDEX ' + @indexname + N' ON ' + @schemaname + N'.' + @objectname + N' REORGANIZE';
IF @frag >= 30.0
SET @command = N'ALTER INDEX ' + @indexname + N' ON ' + @schemaname + N'.' + @objectname + N' REBUILD WITH (SORT_IN_TEMPDB = ON)';
IF @partitioncount > 1
SET @command = @command + N' PARTITION=' + CAST(@partitionnum AS nvarchar(10));
EXEC (@command);
PRINT N'Executed: ' + @command;
END;

CLOSE partitions;
DEALLOCATE partitions;

DROP TABLE #work_to_do;
GO



- обновление статистики
Код: sql
1.
2.
3.
USE DataBase
GO
EXEC sp_updatestats



Когда начал изучать все это врученное мне, заметил, что select (именно выбор из sys.dm_db_index_physical_stats) из скрипта дефрагментации может выполняться 2-3 часа.

Это нормально? И можно ли как то сократить время?
...
Рейтинг: 0 / 0
sys.dm_db_index_physical_stats
    #40121042
felix_ff
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cad2206
Добрый день, знатоки.
Есть база 800ГБ. С незапамятных времен происходит ежедневное обслуживание ночью в порядке:

Это нормально?

да

И можно ли как то сократить время?


по большей части все зависит от конфигурации вашего сервера.
если объем памяти не очень большой, то скорее всего вы упретесь в ожидания по PAGEIO_LATCH, с этим бороться не сможете не добавив оперативки.

в теории можно было бы в параллельные сессии закинуть подсчет, но опять таки возрастет нагрузка на буферный пул.

другой вопрос зачем вы по сути по большей части гоняете перестроение по такому большому объему индексов.
если у вас хранилище на ssd, то можете вообще не перестраивать индексы, а следить только за актуальностью статистики, а перестроение индекса трогать в ручном режиме при явном наличии какой то проблемы.
...
Рейтинг: 0 / 0
sys.dm_db_index_physical_stats
    #40121064
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
felix_ff,

Конфигурация такова:
2 CPU Intel Xeon Silver 4208 2,1GHz (по 4 ядра)
ОЗУ 70ГБ
HDD SAS RAID 5 10000rpm
...
Рейтинг: 0 / 0
sys.dm_db_index_physical_stats
    #40121070
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
felix_ff,
автордругой вопрос зачем вы по сути по большей части гоняете перестроение по такому большому объему индексов

Винты не ssd.
...
Рейтинг: 0 / 0
sys.dm_db_index_physical_stats
    #40121075
felix_ff
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cad2206,

а ну если у вас диски крутящиеся, то тут резон есть следить за фрагментацией.
но опять же, не обязательно перестройку гонять по большинству таблиц.

вы можете повысить ставки пороговые значения для выбора индексов под перестройку теже (10 % внешней фрагментации они ни о чем, стоит ребилдить когда она больше 50% "образно" для разных баз разные коэффициенты выбираются путем анализа и подбора).

к примеру пособирать статистику использования индексов и наиболее часто меняющиеся подверженные фрагментации.
в основной прогон брать наиболее используемые таблицы.

а раз в месяц/две недели/неделю в зависимости от нагрузки dml применять один общий прогон.
...
Рейтинг: 0 / 0
sys.dm_db_index_physical_stats
    #40121082
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
felix_ff,
спасибо, принял к размышлению

авторно опять же, не обязательно перестройку гонять по большинству таблиц.
вы можете повысить ставки пороговые значения для выбора индексов под перестройку теже...
но это не сократит время выполнения выбора
...
Рейтинг: 0 / 0
sys.dm_db_index_physical_stats
    #40121088
Фотография komrad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cad2206
felix_ff,
спасибо, принял к размышлению

авторно опять же, не обязательно перестройку гонять по большинству таблиц.
вы можете повысить ставки пороговые значения для выбора индексов под перестройку теже...

но это не сократит время выполнения выбора
Можно пойти от обратного и анализировать фрагментацию не всех объектов, а только критических таблиц.
Кроме того, есть известное решение от Ola Hallengren , которое "де факто" "стандарт" для обслуживания индексов, статистики, бекапов и dbcc. Рекомендую.
...
Рейтинг: 0 / 0
sys.dm_db_index_physical_stats
    #40121093
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Даже если у вас не ссд диски то наверняка какой нибудь SAN.
Попробуйте ОТКЛЮЧИТЬ ежедневную дефрагментацию на неделю и посмотреть на статистику ожиданий в течении недели.
Уверен, жалоб на то что было хорошо, а стало прямо плохо не будет ибо вы меряете avg_fragmentation_in_percent (внешнюю фрагментацию) и особо влияет avg_page_space_used_in_percent (внутренняя).

Далее, сама по себе дефрагментация - довольно затратное мероприятие, а для ссд дисков еще и губительная.

Второй момент - зачем делать полный бакап каждый день?
Это требование бизнеса или человек который настраивал этот скрипт о других не знал.

У всех баз которых я видел полный бакап делался раз в неделю. плюс ежедневный дифф для баз с простой моделью и ежечасный лог бакап для полной модели.

Есть ли у вас в плане обслуживания checkdb?

Если нет, то по ссылке от komrad выше все есть.
...
Рейтинг: 0 / 0
sys.dm_db_index_physical_stats
    #40121099
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
SERG1257,

авторПопробуйте ОТКЛЮЧИТЬ ежедневную дефрагментацию на неделю и посмотреть на статистику ожиданий в течении недели.

в том и дело, что дело до дефрагментации не доходит. Если посмотреть на скрипт, то в нем стоит отсечка на 8:00 утра (т.к. в 9:00 начинается работа с базой). Так вот, работа скрипта по дефрагментации начинается где то в 5:00 утра (с 2:00 ночи делается полный бекап с проверкой целостности). Два-три часа формируется только выборка нужных индексов для дефрагментацию. И времени на саму дефрагментацию не остается. И это длится уже давно. По сути дефрагментации то и не происходит. И уже очень давно.
Произвести ее нужно, так так результат выборки показывает проценты фрагментации не хилые такие. Вопрос как, это уже, похоже риторический. Согласен, нужно исследовать статистику использования индексов. Или раз в неделю/месяц производить полную дефрагментацию...

авторВторой момент - зачем делать полный бакап каждый день?

совершенно точно, это требование бизнеса. Но возможно это требование я смогу оспорить. Но пока только принял все сервера и исследую то что сейчас имеется. На данный момент модель восстановления полная, полный бекап каждую ночь, бекап журнала каждые 15 мин.

авторЕсть ли у вас в плане обслуживания checkdb?

на данный момент проверки баз данных не производятся, но в плане (моем плане)) конечно есть запускать ее периодически (раз в неделю, например)
...
Рейтинг: 0 / 0
sys.dm_db_index_physical_stats
    #40121104
felix_ff
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cad2206,

вы отсечь таблицы по кол-ву строк кол-ву страниц заранее можете.

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
select
      p.[object_id],
      p.[index_id],
      f.[avg_fragmentation_in_percent],
      f.[avg_page_space_used_in_percent]
from sys.partitions p
    join sys.allocation_units au on au.[container_id] = p.[hobt_id] and au.[type] in (1,3)
        cross apply sys.dm_db_index_physical_stats(db_id(), p.[object_id], p.[index_id], p.[partition_number], 'limited') f
where p.[index_id] > 0
  and (p.[rows] > 1000000 or au.[used_pages] > 1000) 



LOB не брал там немного другое соединение.

берите какие то крупные таблицы, можно сюда же прикрутить sys.dm_db_index_operational_stats /sys.dm_db_index_usage_stats что бы посмотреть какие индексы активно используются ( правда там инфа хранится до рестарта инстанса или чистки буферов)

можно вообще сначала оперировать только представлениями без sys.dm_db_index_physical_stats, а уже когда составите список таблиц индексов в какой то времянке, уже к ней апплаить это представление
...
Рейтинг: 0 / 0
sys.dm_db_index_physical_stats
    #40121106
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
felix_ff,

авторвы отсечь таблицы по кол-ву строк кол-ву страниц заранее можете.

так и делаю, в скрипте сортирую выборку по полу page_count:
авторDECLARE partitions CURSOR FOR SELECT * FROM #work_to_do ORDER BY page_count DESC
тем самым, начинаю дефрагментировать самые большие индексы (правда не отсекаю, а сортирую только)

авторможно сюда же прикрутить sys.dm_db_index_operational_stats /sys.dm_db_index_usage_stats

уже изучаю
...
Рейтинг: 0 / 0
sys.dm_db_index_physical_stats
    #40121108
Фотография komrad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cad2206


авторЕсть ли у вас в плане обслуживания checkdb?


на данный момент проверки баз данных не производятся, но в плане (моем плане)) конечно есть запускать ее периодически (раз в неделю, например)
Я бы на вашем месте сначала озаботился проверкой целостности, чем оживлением реиндекса, тем более что и без него всё работает (по факту).
...
Рейтинг: 0 / 0
sys.dm_db_index_physical_stats
    #40121117
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cad2206совершенно точно, это требование бизнеса.Вот с этого момента поподробнее.
Бизнесу пофиг на ваши бакапы. Бизнесу надо ВОССТАНОВЛЕНИЕ на определенную дату (RPO), за определенное время (RTO). И вот для того чтобы обеспечить эти аббревиатуры вы и делаете бакапы.
https://habr.com/ru/company/veeam/blog/328068/

В любом случае не мешает обговорить это с начальством (своим от IT и от бизнеса) и провести тест на предмет сколько это займет в реальности.
...
Рейтинг: 0 / 0
sys.dm_db_index_physical_stats
    #40121122
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
komradЯ бы на вашем месте сначала озаботился проверкой целостности, чем оживлением реиндексаплюс много
Если какой нибудь запрос будет работать медленно то вас не уволят.
Могут уволить если вы потеряете данные, не сможете восстановить базу и т.д.
...
Рейтинг: 0 / 0
sys.dm_db_index_physical_stats
    #40121214
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
komrad,

А разве не достаточно проверки целостности бекапа (в параметрах бекапа)? Или все же стоит периодически проводить ее на рабочей базе?
...
Рейтинг: 0 / 0
sys.dm_db_index_physical_stats
    #40121215
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
SERG1257,

авторБизнесу надо ВОССТАНОВЛЕНИЕ на определенную дату...

согласен с Вами.
...
Рейтинг: 0 / 0
sys.dm_db_index_physical_stats
    #40121223
Фотография komrad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cad2206
komrad,

А разве не достаточно проверки целостности бекапа (в параметрах бекапа)? Или все же стоит периодически проводить ее на рабочей базе?

если подразумевается verifyonly, то это проверка целостности бекапа, а не базы

https://www.mssqltips.com/sqlservertutorial/113/checking-to-make-sure-a-sql-server-backup-is-useable/

проверка самой базы - это отдельная регулярная задача
смотрите команду dbcc checkdb() и её параметры
...
Рейтинг: 0 / 0
sys.dm_db_index_physical_stats
    #40121248
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cad2206 А разве не достаточно проверки целостности бекапа (в параметрах бекапа)?Наверное вы имеете ввиду WITH CHECKSUM?
Теоретически, это должно быть равнозначно checkdb with physical_only.
Однако вот мнение от автора checkdb
https://www.sqlskills.com/blogs/paul/a-sql-server-dba-myth-a-day-2730-use-backup-with-checksum-to-replace-dbcc-checkdb/
...
Рейтинг: 0 / 0
sys.dm_db_index_physical_stats
    #40121272
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
В параметрах бекапа, при установленной галке "Проверять целостность резервной копии". Я это имею ввиду. Данная галка добавляет к скрипту запись
Код: sql
1.
RESTORE VERIFYONLY FROM  DISK = N'bd.bak' WITH  FILE = @backupSetId,  NOUNLOAD,  NOREWIND


И это именно проверка бекапа. Но не означает ли это, что если проверка бекапа успешна, то и рабочей базой все в порядке?
...
Рейтинг: 0 / 0
sys.dm_db_index_physical_stats
    #40121273
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
SERG1257,

в sql server 2014 опции "расчитать контрольную сумму" в параметрах резервного копирования еще не было, а на исследуемом сервере как раз установлен 2014
...
Рейтинг: 0 / 0
sys.dm_db_index_physical_stats
    #40121275
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
В любом случае, регламентный checkdb() для рабочей базы планирую.

Сейчас, все же, хочу понять, почему выборка из темы сообщения такая не быстрая, что на это влияет, hdd, ОЗУ, процессор, работа с базой?

В скрипт дефрагментации добавил логирование. Так вот, ночью(с базой не работают), после полного бекапа выборка
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
SELECT
object_id  AS objectid,
index_id AS indexid,
partition_number AS partitionnum,
avg_fragmentation_in_percent AS frag,
page_count AS  page_count
FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL , NULL, 'LIMITED') 
WHERE avg_fragmentation_in_percent > 10.0 AND index_id > 0 AND page_count > 20


заняла всего 30 мин, после нее сама дефрагментация 2 часа, закончившись до начала работы с базой (отсечки в 8:00).

Запустив эту же выборку в 10 утра (с базой уже работали), без дефрагментации, время выборки заняло 2ч30м.
...
Рейтинг: 0 / 0
sys.dm_db_index_physical_stats
    #40121288
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cad2206в sql server 2014 опции "расчитать контрольную сумму" в параметрах резервного копирования еще не было, а на исследуемом сервере как раз установлен 2014 Серьезно?
https://docs.microsoft.com/en-us/previous-versions/sql/2014/relational-databases/backup-restore/enable-or-disable-backup-checksums-during-backup-or-restore-sql-server?view=sql-server-2014
...
Рейтинг: 0 / 0
sys.dm_db_index_physical_stats
    #40121306
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
SERG1257,

Может не так выразился, в плане обслуживания, при добавлении элемента "Резервное копирование", в параметрах нет такой галки:
...
Рейтинг: 0 / 0
sys.dm_db_index_physical_stats
    #40121396
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Еще один повод отказаться от планов обслуживания в пользу решения от Ola Hallengren 22411163
...
Рейтинг: 0 / 0
sys.dm_db_index_physical_stats
    #40121478
Владислав Колосов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cad2206,

авторесли проверка бекапа успешна, то и рабочей базой все в порядке

С чего бы? Система проверить корректность контрольной суммы файла резервной копии, а не базы. Однако, единственной достоверной проверкой качества резервной копии является восстановление базы из резервной копии.
...
Рейтинг: 0 / 0
25 сообщений из 31, страница 1 из 2
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / sys.dm_db_index_physical_stats
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]