Фрагментация
Базы данных SQL Server, со временем подвергаются внутренней фрагментации. Это происходит когда записи со страниц базы данных удаляются, и место, которое они занимали, высвобождается. В конечном счете это место многократно используется, вследствие чего, страницы данных становятся физически фрагментированными, что может привести к увеличению операций ввода/вывода, особенно в случае сканирования таблицы, при котором читается много страниц данных одна за другой.
В SQL Server, есть несколько путей преодоления внутренней фрагментации. Один из этих методов состоит в том, чтобы использовать команду DBCC REINDEX для перестройки кластеризованных и некластеризованных индексов. После перестройки индексов, страницы данных становятся логически непрерывными, и дисковый ввод/вывод минимизирован. К сожалению, внутренняя фрагментация – это только лишь часть проблемы фрагментации. Выполнение DBCC REINDEX не сказывается на внешней фрагментации.
Внешняя фрагментация – это фрагментация физических файлов на дисках вашего сервера, которая может вызвать такое же большое количество ненужных операций ввода/вывода, как и внутренняя, если не больше. Ненужные операции ввода-вывода, приводят к снижению производительности SQL Server.
Базы данных SQL Server представляют собой большие файлы базы данных и журналов, для которых во время создания резервируется некоторый размер. Если при создании этих файлов на диске есть непрерывный, не занятый и достаточный по размеру отрезок, они не будут фрагментированы. Но если доступное свободное место не является непрерывным, то уже изначально база данных и журналы будут фрагментированы. Даже если первоначально база данных и журналы не фрагментированы, после их создания, они почти наверняка станут фрагментированными, поскольку база данных все время растет. Например, если Вы устанавливаете первоначальный размер базы данных равным 100 МБ, а файл журнала 10 МБ, и установили следующие параметры автоматического прироста файлов: до 5Гб файл данных и до 100 МБ файл журнала, внешняя фрагментация может быть большой. Каждый раз, когда файлы данных или журналов автоматически увеличиваются, появляется угроза внешней фрагментации.
Для устранения внешней фрагментации используется специализированная утилита операционной системы. Одним из самых популярных инструментов для дефрагментации файлов базы данных SQL Server является Deskeeper от Executive Software. Diskeeper существует уже много лет, и многие из Вас возможно уже знакомы с ним, и не только в работе с Windows, но и в работе с серверами печати. А вот что не известно многим DBA, так это то, что Deskeeper – лучший инструмент для устранения внешней фрагментации на их серверах с SQL Server. Работа утилиты по устранению внешней фрагментации, подобной Diskeeper, не реструктурирует внутреннее содержание файла, в отличие от DBCC REINDEX. После того как Diskeeper устранит фрагментацию файла, этот не фрагментированный файл будет точным дубликатом оригинала. Поскольку свободные места внутри базы данных у не фрагментированного файла от этой операции не исчезнут, Вам нужно будет время от времени проводить реиндексацию, устраняющую именно внутреннюю фрагментацию страниц данных и индексов.
Есть два типа внешней фрагментации с которой могут справиться утилиты, подобные Diskeeper: файловая фрагментация и фрагментация свободного пространства. Файловая фрагментация затрагивает файл на диске компьютера, когда физически файл лежит не одним куском, а поделен на несколько фрагментов, которые разбросаны по всему диску; в то время как фрагментация свободного пространства означает, что пустое место на диске не лежит одним большим куском, а также раздроблено на множество частей. Файловая фрагментация приводит к проблемам с доступом к данным файла, сохраненного на диске компьютера, в то время как фрагментация свободного пространства приводит к проблемам при создании новых файлов данных или при росте старых. Работа утилиты Diskeeper приводит к дефрагментации файлов данных и журналов, и таким образом, файл физически занимает непрерывное пространство в памяти, вместо того чтобы быть разбитым на части. Кроме того, утилита Diskeeper дефрагментирует свободное пространство за счет чего рост файлов данных или журналов вызывает лишь небольшую фрагментацию, либо не вызывает фрагментации вовсе. Но такое положение вещей не длится вечно. В итоге, фрагментация снова становится проблемой, и файлы данных и журналов необходимо снова дефрагментировать. В идеале дефрагментация должна выполняться регулярно.
Теперь еще кое-что, о чем Вы вероятно прежде не задумывались. Знаете ли вы какой эффект оказывает физическая фрагментация файла на SQL Server при пересоздании индекса? Другими словами, если вы не выполняете физическую дефрагментацию, но устраняете внутреннюю фрагментацию, станет ли это помехой для переиндексации? Да, это вполне может стать помехой. Поскольку физически файлы фрагментированы, и SQL Server потребуется намного больше времени для того чтобы восстановить индексы во фрагментированных файлах, чем в непрерывных файлах. Таким образом, прежде чем выполнять внутреннюю дефрагментацию, желательно было бы сначала выполнить физическую дефрагментацию. Это позволит уменьшить время пересоздания индекса, а также снизит количество операций ввода/вывода на сервере в течение процесса пересоздания индекса.
Помимо того что физическая фрагментация может иметь негативное влияние на производительность при работе с файлами данных и журналами SQL Server, необходимо помнить что есть и другие файлы, к которым SQL Server имеет доступ, это исполняемые файлы SQL Server, и файлы полнотекстовых индексов, если таковые используются. Таким образом, желательно дефрагментировать не только файлы данных и журналов, но и все файлы, расположенные на сервере, где запущен SQL Server.
Всеми перемещениями файлов при работе утилиты Diskeeper во время дефрагментации непосредственно управляет операционная система. Фактически, код операционной системы, выполняющий эту функцию, который первоначально был написан Executive Software, распределяет по приоритетам безопасности что может быть дефрагментировано, а что нет. Файлы SQL Server (например .LDF и .MDF) абсолютно безопасно дефрагментировать. Если в тот момент, когда Diskeeper посылает запрос операционной системе (посредством программного интерфейса – API) на перемещение файлов, ему попадутся файлы, которые не могут быть безопасно перемещены, он через них просто перескакивает без сообщений об ошибке или иных сигналов.
Как же узнать, что файлы вашего SQL Server физические фрагментированы? К счастью, это просто. Одной из функциональных возможностей Diskeeper является анализ фрагментации, с помощью которого можно посмотреть фрагментацию относящихся к SQL Server файлов. Как и дефрагментация, эта процедура может выполняться во время работы SQL Server.
Вам может показаться что будет трудно выбрать какое-то определенное расписание дефрагментации, поскольку разные базы данных могут различаться по степени фрагментации. На этот случай, в утилиту Diskeeper встроен динамический планировщик, который называется Smart Scheduling, и который определяет и автоматизирует соответствующие задания по дефрагментации. Также предусмотрена возможность ограничения времени работы и используемых ресурсов для задач дефрагментации, запускаемых под управлением Smart Scheduling.
Таким образом, несложно сделать вывод, что утилиты дефрагментации, подобные Diskeeper, могут помочь снизить внешнюю фрагментацию файлов на дисках, в то время как такие средства SQL Server, как оператор DBCC REINDEX, могут помочь в борьбе с внутренней фрагментацией страниц файлов SQL Server. Они могут работать вместе, гарантируя оптимальную производительность SQL Server.
Если имеются сомнения, просто установите Diskeeper и запустите его функцию анализа, это позволит Вам узнать, на сколько частей разбиты ваши файлы. Я уверен, что Вы будете очень удивлены полученными результатами. Я видел отчёты с сайтов, у которых файлы базы данных были разбиты более чем на 287000 частей!!!!
Статья взята с SQL-Server-Performance.Com © 2000 – 2004 SQL-Server-Performance.Com