Яка найкраща практика вимірювання фрагментації / відтворення продуктивності бази даних SQLServer та визначення часу дефрагментації таблиці баз даних SQLServer?
Мені найбільше цікаво дізнатися, що таке корисні показники та який рівень зниження продуктивності повинен викликати дефрагментацію.
Відповіді:
Я впевнений, що на це знайдуться цікаві відповіді, оскільки існує багато розбіжностей щодо того, які метрики слід переглянути. Я написав DBCC INDEXDEFRAG, SHOWCONTIG і розробив їх замінники на 2005 рік, а також написав вміст Books Online, тож я розкажу вам про свої погляди та поясню цифри в Books Online та майстра плану технічного обслуговування на 2005 рік, який я вибрав.
Дві найкращі показники, на які слід звернути увагу на фрагментацію індексу: 1) (2005) середня фрагментація у відсотках / (2000) логічна фрагментація сканування 2) (2005) середня щільність сторінки / (2000) середня байт вільна на сторінку
Вони однаково стосуються кластерних та некластеризованих індексів.
1 вимірює, наскільки є логічна фрагментація. Це коли логічний порядок сторінок на рівні аркушів індексу не відповідає фізичному порядку. Це заважає механізму зберігання даних робити ефективні перегляди під час сканування дальності. Таким чином, №1 впливає на ефективність сканування діапазону, а не на однотонну роботу.
2 - це вимірювання кількості витраченого простору на кожній сторінці на рівні аркуша індексу. Витрачений простір означає, що ви використовуєте більше сторінок для зберігання записів, а це означає більше дискового простору для зберігання індексу, більше вводу-виводу для читання індексу та більше пам'яті для зберігання сторінок у пам'яті в буферному пулі.
Пороги? Моє загальне правило - це менше 10% фрагментації, нічого не робити. 10-30%, зробіть АЛТЕР ІНДЕКС ... РЕОРГАНІЗУЙТЕ (2005) / DBCC INDEXDEFRAG (2000). Більше 30%, робіть ALTER INDEX ... REBUILD (2005) / DBCC DBREINDEX (2000). Це повні узагальнення, і порогові значення для вас будуть різними.
Щоб знайти порогові показники, зробіть деяке відстеження ефективності навантаження на рівні фрагментації та вирішіть, коли погіршення продуктивності занадто багато. У цей момент вам знадобиться адреса фрагментації. Існує акт збалансування між життям з фрагментацією та прийняттям ресурсного удару для його вилучення.
Я не торкався тут компромісів між двома методами видалення фрагментації, такі речі, як FILLFACTOR / PADINDEX, щоб спробувати пом’якшити фрагментацію та зробити менше дефрагментації, зміни схем / моделей доступу, щоб полегшити фрагментацію, або різні види планів обслуговування .
О, btw, я завжди рекомендую не турбуватися про фрагментацію в індексах, що мають менше 1000 сторінок. Це тому, що індекс, мабуть, в основному залишається в пам'яті (і тому, що люди просили номер, і я повинен був придумати його).
Докладніше про це ви можете прочитати в моїй статті TechNet Magazine щодо обслуговування баз даних на веб-сайті http://technet.microsoft.com/en-us/magazine/cc671165.aspx , у 2000 році про кращі практики щодо дефрагментації на основі індексів на основі 2000 року. http://technet.microsoft.com/en-us/library/cc966523.aspx та в моєму блозі під категорією Фрагментація за адресою http://www.sqlskills.com/BLOGS/PAUL/category/Fragmentation.aspx .
Я начебто на це відповів занадто, але це одна з моїх гарячих кнопок. Сподіваюся, це допомагає :-)