|
sys.dm_db_index_physical_stats
|
|||
---|---|---|---|
#18+
Добрый день, знатоки. Есть база 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.
- обновление статистики Код: sql 1. 2. 3.
Когда начал изучать все это врученное мне, заметил, что select (именно выбор из sys.dm_db_index_physical_stats) из скрипта дефрагментации может выполняться 2-3 часа. Это нормально? И можно ли как то сократить время? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.12.2021, 11:36 |
|
sys.dm_db_index_physical_stats
|
|||
---|---|---|---|
#18+
cad2206 Добрый день, знатоки. Есть база 800ГБ. С незапамятных времен происходит ежедневное обслуживание ночью в порядке: Это нормально? да И можно ли как то сократить время? по большей части все зависит от конфигурации вашего сервера. если объем памяти не очень большой, то скорее всего вы упретесь в ожидания по PAGEIO_LATCH, с этим бороться не сможете не добавив оперативки. в теории можно было бы в параллельные сессии закинуть подсчет, но опять таки возрастет нагрузка на буферный пул. другой вопрос зачем вы по сути по большей части гоняете перестроение по такому большому объему индексов. если у вас хранилище на ssd, то можете вообще не перестраивать индексы, а следить только за актуальностью статистики, а перестроение индекса трогать в ручном режиме при явном наличии какой то проблемы. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.12.2021, 14:14 |
|
sys.dm_db_index_physical_stats
|
|||
---|---|---|---|
#18+
felix_ff, Конфигурация такова: 2 CPU Intel Xeon Silver 4208 2,1GHz (по 4 ядра) ОЗУ 70ГБ HDD SAS RAID 5 10000rpm ... |
|||
:
Нравится:
Не нравится:
|
|||
17.12.2021, 15:18 |
|
sys.dm_db_index_physical_stats
|
|||
---|---|---|---|
#18+
felix_ff, автордругой вопрос зачем вы по сути по большей части гоняете перестроение по такому большому объему индексов Винты не ssd. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.12.2021, 15:23 |
|
sys.dm_db_index_physical_stats
|
|||
---|---|---|---|
#18+
cad2206, а ну если у вас диски крутящиеся, то тут резон есть следить за фрагментацией. но опять же, не обязательно перестройку гонять по большинству таблиц. вы можете повысить ставки пороговые значения для выбора индексов под перестройку теже (10 % внешней фрагментации они ни о чем, стоит ребилдить когда она больше 50% "образно" для разных баз разные коэффициенты выбираются путем анализа и подбора). к примеру пособирать статистику использования индексов и наиболее часто меняющиеся подверженные фрагментации. в основной прогон брать наиболее используемые таблицы. а раз в месяц/две недели/неделю в зависимости от нагрузки dml применять один общий прогон. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.12.2021, 15:58 |
|
sys.dm_db_index_physical_stats
|
|||
---|---|---|---|
#18+
felix_ff, спасибо, принял к размышлению авторно опять же, не обязательно перестройку гонять по большинству таблиц. вы можете повысить ставки пороговые значения для выбора индексов под перестройку теже... но это не сократит время выполнения выбора ... |
|||
:
Нравится:
Не нравится:
|
|||
17.12.2021, 16:13 |
|
sys.dm_db_index_physical_stats
|
|||
---|---|---|---|
#18+
cad2206 felix_ff, спасибо, принял к размышлению авторно опять же, не обязательно перестройку гонять по большинству таблиц. вы можете повысить ставки пороговые значения для выбора индексов под перестройку теже... но это не сократит время выполнения выбора Можно пойти от обратного и анализировать фрагментацию не всех объектов, а только критических таблиц. Кроме того, есть известное решение от Ola Hallengren , которое "де факто" "стандарт" для обслуживания индексов, статистики, бекапов и dbcc. Рекомендую. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.12.2021, 16:42 |
|
sys.dm_db_index_physical_stats
|
|||
---|---|---|---|
#18+
Даже если у вас не ссд диски то наверняка какой нибудь SAN. Попробуйте ОТКЛЮЧИТЬ ежедневную дефрагментацию на неделю и посмотреть на статистику ожиданий в течении недели. Уверен, жалоб на то что было хорошо, а стало прямо плохо не будет ибо вы меряете avg_fragmentation_in_percent (внешнюю фрагментацию) и особо влияет avg_page_space_used_in_percent (внутренняя). Далее, сама по себе дефрагментация - довольно затратное мероприятие, а для ссд дисков еще и губительная. Второй момент - зачем делать полный бакап каждый день? Это требование бизнеса или человек который настраивал этот скрипт о других не знал. У всех баз которых я видел полный бакап делался раз в неделю. плюс ежедневный дифф для баз с простой моделью и ежечасный лог бакап для полной модели. Есть ли у вас в плане обслуживания checkdb? Если нет, то по ссылке от komrad выше все есть. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.12.2021, 17:02 |
|
sys.dm_db_index_physical_stats
|
|||
---|---|---|---|
#18+
SERG1257, авторПопробуйте ОТКЛЮЧИТЬ ежедневную дефрагментацию на неделю и посмотреть на статистику ожиданий в течении недели. в том и дело, что дело до дефрагментации не доходит. Если посмотреть на скрипт, то в нем стоит отсечка на 8:00 утра (т.к. в 9:00 начинается работа с базой). Так вот, работа скрипта по дефрагментации начинается где то в 5:00 утра (с 2:00 ночи делается полный бекап с проверкой целостности). Два-три часа формируется только выборка нужных индексов для дефрагментацию. И времени на саму дефрагментацию не остается. И это длится уже давно. По сути дефрагментации то и не происходит. И уже очень давно. Произвести ее нужно, так так результат выборки показывает проценты фрагментации не хилые такие. Вопрос как, это уже, похоже риторический. Согласен, нужно исследовать статистику использования индексов. Или раз в неделю/месяц производить полную дефрагментацию... авторВторой момент - зачем делать полный бакап каждый день? совершенно точно, это требование бизнеса. Но возможно это требование я смогу оспорить. Но пока только принял все сервера и исследую то что сейчас имеется. На данный момент модель восстановления полная, полный бекап каждую ночь, бекап журнала каждые 15 мин. авторЕсть ли у вас в плане обслуживания checkdb? на данный момент проверки баз данных не производятся, но в плане (моем плане)) конечно есть запускать ее периодически (раз в неделю, например) ... |
|||
:
Нравится:
Не нравится:
|
|||
17.12.2021, 17:26 |
|
sys.dm_db_index_physical_stats
|
|||
---|---|---|---|
#18+
cad2206, вы отсечь таблицы по кол-ву строк кол-ву страниц заранее можете. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
LOB не брал там немного другое соединение. берите какие то крупные таблицы, можно сюда же прикрутить sys.dm_db_index_operational_stats /sys.dm_db_index_usage_stats что бы посмотреть какие индексы активно используются ( правда там инфа хранится до рестарта инстанса или чистки буферов) можно вообще сначала оперировать только представлениями без sys.dm_db_index_physical_stats, а уже когда составите список таблиц индексов в какой то времянке, уже к ней апплаить это представление ... |
|||
:
Нравится:
Не нравится:
|
|||
17.12.2021, 17:42 |
|
sys.dm_db_index_physical_stats
|
|||
---|---|---|---|
#18+
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 уже изучаю ... |
|||
:
Нравится:
Не нравится:
|
|||
17.12.2021, 17:47 |
|
sys.dm_db_index_physical_stats
|
|||
---|---|---|---|
#18+
cad2206 авторЕсть ли у вас в плане обслуживания checkdb? на данный момент проверки баз данных не производятся, но в плане (моем плане)) конечно есть запускать ее периодически (раз в неделю, например) Я бы на вашем месте сначала озаботился проверкой целостности, чем оживлением реиндекса, тем более что и без него всё работает (по факту). ... |
|||
:
Нравится:
Не нравится:
|
|||
17.12.2021, 17:49 |
|
sys.dm_db_index_physical_stats
|
|||
---|---|---|---|
#18+
cad2206совершенно точно, это требование бизнеса.Вот с этого момента поподробнее. Бизнесу пофиг на ваши бакапы. Бизнесу надо ВОССТАНОВЛЕНИЕ на определенную дату (RPO), за определенное время (RTO). И вот для того чтобы обеспечить эти аббревиатуры вы и делаете бакапы. https://habr.com/ru/company/veeam/blog/328068/ В любом случае не мешает обговорить это с начальством (своим от IT и от бизнеса) и провести тест на предмет сколько это займет в реальности. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.12.2021, 18:11 |
|
sys.dm_db_index_physical_stats
|
|||
---|---|---|---|
#18+
komradЯ бы на вашем месте сначала озаботился проверкой целостности, чем оживлением реиндексаплюс много Если какой нибудь запрос будет работать медленно то вас не уволят. Могут уволить если вы потеряете данные, не сможете восстановить базу и т.д. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.12.2021, 18:33 |
|
sys.dm_db_index_physical_stats
|
|||
---|---|---|---|
#18+
komrad, А разве не достаточно проверки целостности бекапа (в параметрах бекапа)? Или все же стоит периодически проводить ее на рабочей базе? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2021, 13:15 |
|
sys.dm_db_index_physical_stats
|
|||
---|---|---|---|
#18+
SERG1257, авторБизнесу надо ВОССТАНОВЛЕНИЕ на определенную дату... согласен с Вами. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2021, 13:17 |
|
sys.dm_db_index_physical_stats
|
|||
---|---|---|---|
#18+
cad2206 komrad, А разве не достаточно проверки целостности бекапа (в параметрах бекапа)? Или все же стоит периодически проводить ее на рабочей базе? если подразумевается verifyonly, то это проверка целостности бекапа, а не базы https://www.mssqltips.com/sqlservertutorial/113/checking-to-make-sure-a-sql-server-backup-is-useable/ проверка самой базы - это отдельная регулярная задача смотрите команду dbcc checkdb() и её параметры ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2021, 13:58 |
|
sys.dm_db_index_physical_stats
|
|||
---|---|---|---|
#18+
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/ ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2021, 17:20 |
|
sys.dm_db_index_physical_stats
|
|||
---|---|---|---|
#18+
В параметрах бекапа, при установленной галке "Проверять целостность резервной копии". Я это имею ввиду. Данная галка добавляет к скрипту запись Код: sql 1.
И это именно проверка бекапа. Но не означает ли это, что если проверка бекапа успешна, то и рабочей базой все в порядке? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2021, 21:43 |
|
sys.dm_db_index_physical_stats
|
|||
---|---|---|---|
#18+
SERG1257, в sql server 2014 опции "расчитать контрольную сумму" в параметрах резервного копирования еще не было, а на исследуемом сервере как раз установлен 2014 ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2021, 21:49 |
|
sys.dm_db_index_physical_stats
|
|||
---|---|---|---|
#18+
В любом случае, регламентный checkdb() для рабочей базы планирую. Сейчас, все же, хочу понять, почему выборка из темы сообщения такая не быстрая, что на это влияет, hdd, ОЗУ, процессор, работа с базой? В скрипт дефрагментации добавил логирование. Так вот, ночью(с базой не работают), после полного бекапа выборка Код: sql 1. 2. 3. 4. 5. 6. 7. 8.
заняла всего 30 мин, после нее сама дефрагментация 2 часа, закончившись до начала работы с базой (отсечки в 8:00). Запустив эту же выборку в 10 утра (с базой уже работали), без дефрагментации, время выборки заняло 2ч30м. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2021, 22:18 |
|
sys.dm_db_index_physical_stats
|
|||
---|---|---|---|
#18+
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 ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2021, 23:27 |
|
sys.dm_db_index_physical_stats
|
|||
---|---|---|---|
#18+
SERG1257, Может не так выразился, в плане обслуживания, при добавлении элемента "Резервное копирование", в параметрах нет такой галки: ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 09:47 |
|
sys.dm_db_index_physical_stats
|
|||
---|---|---|---|
#18+
Еще один повод отказаться от планов обслуживания в пользу решения от Ola Hallengren 22411163 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 17:19 |
|
sys.dm_db_index_physical_stats
|
|||
---|---|---|---|
#18+
cad2206, авторесли проверка бекапа успешна, то и рабочей базой все в порядке С чего бы? Система проверить корректность контрольной суммы файла резервной копии, а не базы. Однако, единственной достоверной проверкой качества резервной копии является восстановление базы из резервной копии. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 21:23 |
|
|
start [/forum/topic.php?fid=46&msg=40121248&tid=1683991]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
116ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
others: | 233ms |
total: | 450ms |
0 / 0 |