Сообщение Re[8]: [SQL Server] Анализ всех запросов к таблице от 14.07.2015 16:49
Изменено 14.07.2015 16:53 Somescout
Здравствуйте, Olaf, Вы писали:
O>Здравствуйте, Somescout, Вы писали:
S>>Здравствуйте, Olaf, Вы писали:
O>>> {Возможно "плохие" индексы writes > reads}
S>>Можете рассказать как с ними поступать? Есть несколько таких индексов, они вроде как слегка используются, но число записей на 2 порядка выше числа чтений.
O>Необходимо обратить особое внимание на такие индексы и при условии, что количество записей значительно больше нуля, а количество чтений равно нулю, данные индексы являются отличными кандидатами на удаление, но только после изучения, а где и как они могли бы применяться. Причины, по которым индекс не используется оптимизатором запросов для чтения, я бы обозначил три:
O>1. Индекс не так хорош, что бы решить проблему поиска данных в таблице и оптимизатор его игнорирует. Возможно, рядом есть более хороший кандидат для этих целей.
O>2. Бизнес-процесс построен таким образом, что данные пишутся, но никто их не читает (пережитки прошлого, рудименты и прочее)
O>3. Вы попали в интервал наблюдения, когда пользователи не читают данные или читают достаточно мало. А вот в квартальный отчет или годовой индекс выстреливает на все 100 и покрывает задачи бизнеса для подготовки данных.
O>На мой взгляд, разница в два порядка не такая большая, чтобы применять решение об удалении, даже если чтений нет совсем.
Конкретно для этой базы нагрузка равномерная и квартальных отчётов по ней не делается. Время работы SQL сервера несколько месяцев, так что статистика должна быть достаточной — если индекс не использовался несколько месяцев, значит он, с очень большой вероятностью, не будет использоваться никогда.
Можно ли на основе статистики использования индексов в таблице объективно выделить оптимального кандидата для кластерного индекса?
Т.е. сейчас для многих таблиц (считай для всех) сделан кластерный индекс по первичному ключу, который является GUID'ом. Как я понимаю, это может быть проблемой для больших и часто обновляемых таблиц — вставка строки происходит в произвольную часть таблицы и приводит к её пересортировке (точнее разбивке страницы), а выполнение запроса по более упорядоченному полю приводит к загрузке избыточного числа страниц в память. Субъективно я могу оценить, что в некоторых случаях лучше сделать кластерный индекс, например по дате (если записи добавляются в основном с возрастающей датой и тяжёлые запросы также делаются для определённого периода). Но есть ли объективные признаки что индекс нужно сделать кластерным?
Кроме того, для таблиц с кластерным индексом по GUID возможно имеет смысл изменить fillfactor. Будет ли он влиять на физическое размещение данных? Каким его стоит выставлять (пока мысль о 0.95-0.9)? Можно ли узнать (средний) размер строки таблицы в байтах если я захочу зарезервировать 3 средних строки на страницу?
O>Возвращаясь к вопросу DTA – а вы пробовали результат трассировки (или сам файл) сохранить в таблицу БД и уже ее использовать как источник для анализа?
Сегодня попробовал, всё равно падает. Есть подозрение что это из-за того что установлено несколько версий Management Tools.
O>Здравствуйте, Somescout, Вы писали:
S>>Здравствуйте, Olaf, Вы писали:
O>>> {Возможно "плохие" индексы writes > reads}
S>>Можете рассказать как с ними поступать? Есть несколько таких индексов, они вроде как слегка используются, но число записей на 2 порядка выше числа чтений.
O>Необходимо обратить особое внимание на такие индексы и при условии, что количество записей значительно больше нуля, а количество чтений равно нулю, данные индексы являются отличными кандидатами на удаление, но только после изучения, а где и как они могли бы применяться. Причины, по которым индекс не используется оптимизатором запросов для чтения, я бы обозначил три:
O>1. Индекс не так хорош, что бы решить проблему поиска данных в таблице и оптимизатор его игнорирует. Возможно, рядом есть более хороший кандидат для этих целей.
O>2. Бизнес-процесс построен таким образом, что данные пишутся, но никто их не читает (пережитки прошлого, рудименты и прочее)
O>3. Вы попали в интервал наблюдения, когда пользователи не читают данные или читают достаточно мало. А вот в квартальный отчет или годовой индекс выстреливает на все 100 и покрывает задачи бизнеса для подготовки данных.
O>На мой взгляд, разница в два порядка не такая большая, чтобы применять решение об удалении, даже если чтений нет совсем.
Конкретно для этой базы нагрузка равномерная и квартальных отчётов по ней не делается. Время работы SQL сервера несколько месяцев, так что статистика должна быть достаточной — если индекс не использовался несколько месяцев, значит он, с очень большой вероятностью, не будет использоваться никогда.
Можно ли на основе статистики использования индексов в таблице объективно выделить оптимального кандидата для кластерного индекса?
Т.е. сейчас для многих таблиц (считай для всех) сделан кластерный индекс по первичному ключу, который является GUID'ом. Как я понимаю, это может быть проблемой для больших и часто обновляемых таблиц — вставка строки происходит в произвольную часть таблицы и приводит к её пересортировке (точнее разбивке страницы), а выполнение запроса по более упорядоченному полю приводит к загрузке избыточного числа страниц в память. Субъективно я могу оценить, что в некоторых случаях лучше сделать кластерный индекс, например по дате (если записи добавляются в основном с возрастающей датой и тяжёлые запросы также делаются для определённого периода). Но есть ли объективные признаки что индекс нужно сделать кластерным?
Кроме того, для таблиц с кластерным индексом по GUID возможно имеет смысл изменить fillfactor. Будет ли он влиять на физическое размещение данных? Каким его стоит выставлять (пока мысль о 0.95-0.9)? Можно ли узнать (средний) размер строки таблицы в байтах если я захочу зарезервировать 3 средних строки на страницу?
O>Возвращаясь к вопросу DTA – а вы пробовали результат трассировки (или сам файл) сохранить в таблицу БД и уже ее использовать как источник для анализа?
Сегодня попробовал, всё равно падает. Есть подозрение что это из-за того что установлено несколько версий Management Tools.
Re[8]: [SQL Server] Анализ всех запросов к таблице
Здравствуйте, Olaf, Вы писали:
O>Здравствуйте, Somescout, Вы писали:
S>>Здравствуйте, Olaf, Вы писали:
O>>> {Возможно "плохие" индексы writes > reads}
S>>Можете рассказать как с ними поступать? Есть несколько таких индексов, они вроде как слегка используются, но число записей на 2 порядка выше числа чтений.
O>Необходимо обратить особое внимание на такие индексы и при условии, что количество записей значительно больше нуля, а количество чтений равно нулю, данные индексы являются отличными кандидатами на удаление, но только после изучения, а где и как они могли бы применяться. Причины, по которым индекс не используется оптимизатором запросов для чтения, я бы обозначил три:
O>1. Индекс не так хорош, что бы решить проблему поиска данных в таблице и оптимизатор его игнорирует. Возможно, рядом есть более хороший кандидат для этих целей.
O>2. Бизнес-процесс построен таким образом, что данные пишутся, но никто их не читает (пережитки прошлого, рудименты и прочее)
O>3. Вы попали в интервал наблюдения, когда пользователи не читают данные или читают достаточно мало. А вот в квартальный отчет или годовой индекс выстреливает на все 100 и покрывает задачи бизнеса для подготовки данных.
O>На мой взгляд, разница в два порядка не такая большая, чтобы применять решение об удалении, даже если чтений нет совсем.
Конкретно для этой базы нагрузка равномерная и квартальных отчётов по ней не делается. Время работы SQL сервера несколько месяцев, так что статистика должна быть достаточной — если индекс не использовался несколько месяцев, значит он, с очень большой вероятностью, не будет использоваться никогда.
Развивая тему тюнинга базы:
Можно ли на основе статистики использования индексов в таблице объективно выделить оптимального кандидата для кластерного индекса?
Т.е. сейчас для многих таблиц (считай для всех) сделан кластерный индекс по первичному ключу, который является GUID'ом. Как я понимаю, это может быть проблемой для больших и часто обновляемых таблиц — вставка строки происходит в произвольную часть таблицы и приводит к её пересортировке (точнее разбивке страницы), а выполнение запроса по более упорядоченному полю приводит к загрузке избыточного числа страниц в память. Субъективно я могу оценить, что в некоторых случаях лучше сделать кластерный индекс, например по дате (если записи добавляются в основном с возрастающей датой и тяжёлые запросы также делаются для определённого периода). Но есть ли объективные признаки что индекс нужно сделать кластерным?
Кроме того, для таблиц с кластерным индексом по GUID возможно имеет смысл изменить fillfactor. Будет ли он влиять на физическое размещение данных? Каким его стоит выставлять (пока мысль о 0.95-0.9)? Можно ли узнать (средний) размер строки таблицы в байтах если я захочу зарезервировать 3 средних строки на страницу?
O>Возвращаясь к вопросу DTA – а вы пробовали результат трассировки (или сам файл) сохранить в таблицу БД и уже ее использовать как источник для анализа?
Сегодня попробовал, всё равно падает. Есть подозрение что это из-за того что установлено несколько версий Management Tools.
O>Здравствуйте, Somescout, Вы писали:
S>>Здравствуйте, Olaf, Вы писали:
O>>> {Возможно "плохие" индексы writes > reads}
S>>Можете рассказать как с ними поступать? Есть несколько таких индексов, они вроде как слегка используются, но число записей на 2 порядка выше числа чтений.
O>Необходимо обратить особое внимание на такие индексы и при условии, что количество записей значительно больше нуля, а количество чтений равно нулю, данные индексы являются отличными кандидатами на удаление, но только после изучения, а где и как они могли бы применяться. Причины, по которым индекс не используется оптимизатором запросов для чтения, я бы обозначил три:
O>1. Индекс не так хорош, что бы решить проблему поиска данных в таблице и оптимизатор его игнорирует. Возможно, рядом есть более хороший кандидат для этих целей.
O>2. Бизнес-процесс построен таким образом, что данные пишутся, но никто их не читает (пережитки прошлого, рудименты и прочее)
O>3. Вы попали в интервал наблюдения, когда пользователи не читают данные или читают достаточно мало. А вот в квартальный отчет или годовой индекс выстреливает на все 100 и покрывает задачи бизнеса для подготовки данных.
O>На мой взгляд, разница в два порядка не такая большая, чтобы применять решение об удалении, даже если чтений нет совсем.
Конкретно для этой базы нагрузка равномерная и квартальных отчётов по ней не делается. Время работы SQL сервера несколько месяцев, так что статистика должна быть достаточной — если индекс не использовался несколько месяцев, значит он, с очень большой вероятностью, не будет использоваться никогда.
Развивая тему тюнинга базы:
Можно ли на основе статистики использования индексов в таблице объективно выделить оптимального кандидата для кластерного индекса?
Т.е. сейчас для многих таблиц (считай для всех) сделан кластерный индекс по первичному ключу, который является GUID'ом. Как я понимаю, это может быть проблемой для больших и часто обновляемых таблиц — вставка строки происходит в произвольную часть таблицы и приводит к её пересортировке (точнее разбивке страницы), а выполнение запроса по более упорядоченному полю приводит к загрузке избыточного числа страниц в память. Субъективно я могу оценить, что в некоторых случаях лучше сделать кластерный индекс, например по дате (если записи добавляются в основном с возрастающей датой и тяжёлые запросы также делаются для определённого периода). Но есть ли объективные признаки что индекс нужно сделать кластерным?
Кроме того, для таблиц с кластерным индексом по GUID возможно имеет смысл изменить fillfactor. Будет ли он влиять на физическое размещение данных? Каким его стоит выставлять (пока мысль о 0.95-0.9)? Можно ли узнать (средний) размер строки таблицы в байтах если я захочу зарезервировать 3 средних строки на страницу?
O>Возвращаясь к вопросу DTA – а вы пробовали результат трассировки (или сам файл) сохранить в таблицу БД и уже ее использовать как источник для анализа?
Сегодня попробовал, всё равно падает. Есть подозрение что это из-за того что установлено несколько версий Management Tools.