Метод для нахождения ненужных индексов операционной базы данных SQL Server?
Для клонирования диска все, что действительно необходимо сделать, указывают ввод и вывод к dd:
dd if=/dev/hdb of=/image.img
Конечно, удостоверьтесь, что у Вас есть верные полномочия читать непосредственно из/dev/hdb (я рекомендовал бы работать как корень), и что/dev/hdb не смонтирован (Вы не хотите копировать, в то время как диск изменяется - монтирующийся, поскольку только для чтения также приемлемо). Однажды завершенный, image.img будет клоном байта для байта всего диска.
Существует несколько недостатков к использованию dd для клонирования дисков. Во-первых, dd скопирует Ваш весь диск, даже вакуум, и, если сделано на большом диске может привести к чрезвычайно большому файлу изображения. Во-вторых, dd не обеспечивает абсолютно никаких признаков прогресса, которые могут быть печальными, потому что копия занимает много времени. В-третьих, если Вы копируете это изображение в другие диски (снова, с помощью dd), они должны быть столь же большими или больше, чем исходный диск, все же Вы не сможете использовать любое дополнительное пространство, которое Вы можете иметь на целевом диске, пока Вы не изменяете размер своих разделов.
Можно также сделать прямой диск к дисковой копии:
dd if=/dev/hdb of=/dev/hdc
но Вы все еще подвергаетесь вышеупомянутым ограничениям относительно свободного пространства.
Насколько проблемы или глюки идут, dd, по большей части, делает превосходное задание. Однако только что у меня был жесткий диск, который собирался перестать работать, таким образом, я использовал dd, чтобы попытаться скопировать, какая информация я мог от него, прежде чем он умер полностью. Было затем изучено, что dd не обрабатывает ошибки чтения очень хорошо - было несколько секторов на диске, который dd не мог считать, заставив dd сдаваться и останавливать копию. В то время, когда я не мог найти способ сказать dd продолжаться несмотря на обнаружение с ошибкой чтения (хотя появляется, как будто это действительно имеет ту установку), таким образом, я провел довольно мало времени, вручную указывающего пропуск, и стремитесь скачкообразно двинуться по нечитабельным разделам.
Я потратил решения для исследования некоторого времени этой проблемы (после того, как я выполнил задачу), и я нашел программу названной ddrescue, который, согласно сайту, работает как dd, но продолжает читать, даже если это встречается с ошибкой. Я на самом деле никогда не использовал программу, но это достойно рассмотрения, особенно если диск, с которого Вы копируете, стар, который может иметь поврежденные секторы, даже если система кажется прекрасной.
Я вижу милый небольшой сценарий T-SQL здесь (http://blog.sqlauthority.com/2008/02/11/sql-server-2005-find-unused-indexes-of-current-database/) для показа неиспользованных индексов, которые должны работать на SQL Server 2005. Другой http://aspadvice.com/blogs/ssmith/archive/2008/03/31/Find-Unused-SQL-2005-Indexes-for-Current-DB.aspx здесь, также.
Похоже, что dm_db_index_usage_stats является ключом ко всему этому. Крутой! (См. http://msdn.microsoft.com/en-us/library/ms188755.aspx, я собираюсь, должны пойти посмотреть на некоторые производственные базы данных, которые я создал теперь для наблюдения то, на что похожа эта статистика. (улыбка)
Править: Некоторый очень хороший addt'l фон здесь: http://blogs.msdn.com/craigfr/archive/2008/10/30/what-is-the-difference-between-sys-dm-db-index-usage-stats-and-sys-dm-db-index-operational-stats.aspx
-
1You' ре на правильном пути здесь, но имеет в виду это решение (DMV' s только работают в SQL 2005 или выше), – SQLChicken 4 June 2009 в 18:10
-
2Хорошая вещь плакат, который спрашивают о SQL Server 2005 / 2008 затем, а? улыбка – Evan Anderson 4 June 2009 в 18:55
-
3Lol хороший звонок, пропущенный, что один. – SQLChicken 4 June 2009 в 19:12
Несколько вещей принять во внимание об использовании sys.dm_db_index_usage_stats:
- Вывод только содержит индексы, которые использовались с прошлого раза была запущена база данных. Когда база данных является завершением работы, все записи от кэша в оперативной памяти информации для той базы данных удалены. Точно так же кэш не переживает мгновенный перезапуск. Нет никакого способа вручную очистить записи для конкретной базы данных, не перезапуская базу данных. Различные статьи, на которые ссылаются в первом ответе (и также на моем блоге), описывают, как получить вывод неоднократно, чтобы сделать анализ временного ряда.
- Обязательно протестируйте Ваш весь деловой цикл. Вы не хотите удалять индекс, это используется для отчета конца месяца или запроса генерального директора, даже при том, что это может быть заманчиво для.
- Удостоверьтесь, что Вы понимаете различные количества и что они имеют в виду прежде, чем принять решение на том, используется ли индекс с пользой или просто сохраняется за счет.
Надеюсь, это поможет.
PS Еще одна вещь для других, читающих это и задающихся вопросом, существует ли эквивалентный метод для SQL Server 2000 - нет, мы (как я был в команде в то время) только, добавила возможность на 2005 вперед.
У нас есть статья Wiki в SQLServerPedia со сценарием, чтобы сделать это плюс учебное видео о том, как использовать его:
Один для нахождения индексов, не используясь:
http://sqlserverpedia.com/wiki/Find_Indexes_Not_In_Use
И другой для нахождения индексов необходимо добавить:
-
1Проголосовавший для противостояния отрицательному голосованию w/o причина. Плюс видео учебные руководства всегда полезны. – SQLChicken 4 June 2009 в 18:09
-
2Спасибо Брент! I' m читающий это по моему мобильному телефону, таким образом, я can' t проверяют видео в данный момент. Это учебное руководство касается только, как найти недостающие индексы или также ненужные? – splattne 4 June 2009 в 18:29
-
3Doh! Извините за это я отправил неправильную ссылку. Я добавил другую ссылку для той, которую Вы хотели. There' s учебное руководство при пропавших без вести индексов и учебного руководства на ненужных индексах, и я вставил неправильный, ха-ха-ха. – Brent Ozar 4 June 2009 в 19:07
попробуйте оставленное присоединение на выбор * от Sys.dm_db_index_usage_stats. Вы видите, которые никогда не затрагивались. Удостоверьтесь, что они были вокруг достаточно долго, хотя, работая это за новым индексом было создано, может не быть время достаточно....
Также будьте осведомленными индексами, может не использоваться сегодня, но в качестве увеличений размера данных, их считает лучшей ставкой оптимизатор. Обычно с маленькими (новыми) таблицами оптимизатор будет всегда сканировать, но начнет искать, когда число строк увеличится выше переломного момента
Dave J.
Править: Evan победил меня к нему, но он - пятно на.
Редактирование 2: исправленный совет, забыл, что антисоединение укусило!
Я сделал некоторый связанный с индексом запрос, и я показал это в своем блоге (http://dbalink.wordpress.com/2008/11/09/how-to-finding-index-usage-stats-with-dmv-in-tsql/)
Примите во внимание, что SQL Server не знает Вашего бизнеса. Это не знает, какие бизнес-тактические и стратегические решения Ваша компания приняла, делает и сделает.
Это означает, что индекс, отсутствующий сегодня, не может быть релевантным завтра, или это может стать более релевантным. Та же логика относится к индексам, которые находятся под используемым или не используются вообще.
Когда SQL Server RTM'd, я записал свои собственные сценарии для просматривания и создания отчетов - на таблицах DM и мысли об автоматизации их действия. Один взгляд на недостающий индекс сообщает, где SQL Server просил все остальные столбцы таблицы быть добавленным, поскольку столбцы "Include" на индексе для таблицы с очень динамическим контентом были средством устрашения, я не должен был автоматизировать процесс.
Я все еще использую свои сценарии, но я применяю бизнес-решения своей компании к тому, что я делаю - Что-то, что я могу сделать в меньшей компании.
Как всегда, знайте свои данные, знайте свой бизнес, знайте направление своего бизнеса.