Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Низкий уровень попадания запроса в кеш планов запросов.  [new]
МуМу
Member

Откуда:
Сообщений: 1134
У меня несколько вопросов.
Есть системная вьюха указывающая хендлы запросов , время создания и количество использования. Правильно утверждение что она отображает все планы выполнения? Какое нормальное количество планов запросов?( У меня количество записей не превышало приблизительно 150 т. записей.)

Теперь ближе к проблеме. Очень малый процент запросов попадает в кеш запросов. Соответственно возникает резонный вопрос, а много ли уходит накладных расходов на параметризацию и поиск в кеше? Можно ли вообще как то глобально сказать что нужно план гарантированно рассчитывать заново?(типа recompile) Зачем проводить поиск если известно заранее что его в кеше не будет!
Проблема в том что система генерирует новые временные таблицы и использует каждый раз новую временную таблицу. Соответственно планы каждый раз новые.
Может есть еще какие опции, которые помогут как то сгладить эту ситуацию?(в идеале что бы временная таблица независимо от названия бралась как некоторый параметр)
Заранее благодарю.
23 окт 13, 19:34    [15022868]     Ответить | Цитировать Сообщить модератору
 Re: Низкий уровень попадания запроса в кеш планов запросов.  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Сама ситуация интересна.

А времянки на основе какой задачи/подхода возникают?
Вот к примеру, почему нельзя использовать табличные переменные?
24 окт 13, 01:13    [15023723]     Ответить | Цитировать Сообщить модератору
 Re: Низкий уровень попадания запроса в кеш планов запросов.  [new]
SandalTree
Member

Откуда: Перехлёсток восьми батог
Сообщений: 28146
Параметризация и поиск в кэше существенно быстрее чем создание нового плана для сложного запроса.
Чем больше кэш и планов в нём тем лучше.


А временные таблицы одинаковые или разные?
24 окт 13, 02:19    [15023804]     Ответить | Цитировать Сообщить модератору
 Re: Низкий уровень попадания запроса в кеш планов запросов.  [new]
МуМу
Member

Откуда:
Сообщений: 1134
Проблема в том что временные таблицы каждый раз новые.(их генерирует сервер приложения) Например один раз #t1 а второй раз уже #t2. По структуре и вариантам объединений они имеют разумеется ограниченное количество комбинаций. Все было бы хорошо если бы можно было сказать SQL оптимизатору что параметризация проходит с заменой наименований всех временных таблиц на одно наименование #tХХХ. В этом случае проблема была бы решена. В текущем же случае практически каждый новый запрос имеет уникальный план и гарантированно не попадает в кеш. Хочется в этом случае хоть какой то профит получить. Есть еще варианты с шаманством(например имеется возможность управлять трафиком и даже изменять его), но этот вариант пока не рассматриваю.
24 окт 13, 08:15    [15023972]     Ответить | Цитировать Сообщить модератору
 Re: Низкий уровень попадания запроса в кеш планов запросов.  [new]
МуМу
Member

Откуда:
Сообщений: 1134
В этой ситуации есть еще один неприятный момент. Устаревание статистики приводит к крайне неприятным последствиям. А с другой стороны пересчет ее в рабочем режиме приводит к блокировкам.(все запросы гарантированно обращаются к таблицам статистики)
24 окт 13, 08:46    [15024043]     Ответить | Цитировать Сообщить модератору
 Re: Низкий уровень попадания запроса в кеш планов запросов.  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
МуМу
Проблема в том что временные таблицы каждый раз новые.(их генерирует сервер приложения) Например один раз #t1
Вы не ответили на мой вопрос. Я тут на форуме тусуюсь не ради бесплатной консультации.
Мне нужно знать реальные задачи, точнее подходы их решения, я очень много проектов перелопатил и у меня есть взгляд как нужно делать, и как нельзя. Но главное почему так.

Первый вопрос стоит, а правилен ли подход. Если да, то это не просто, вам костыль подсказать, а привлечь общество разрабов и направить к MS. Что бы и без костылей и у всех было хорошо.

Андестуд?

МуМу
Все было бы хорошо если бы можно было сказать SQL оптимизатору что параметризация проходит с заменой наименований всех временных таблиц на одно наименование #tХХХ.
И почему бы не поправить генератор кода в приложении?

Т.е. вы отвечаете, что у вас вырожденный случай говнокода и нужно чтобы мы помогли костыль подобрать?
Ок.
24 окт 13, 16:07    [15027369]     Ответить | Цитировать Сообщить модератору
 Re: Низкий уровень попадания запроса в кеш планов запросов.  [new]
SandalTree
Member

Откуда: Перехлёсток восьми батог
Сообщений: 28146
Mnior
Т.е. вы отвечаете, что у вас вырожденный случай говнокода и нужно чтобы мы помогли костыль подобрать?
Ок.
Обычная ситуация, говнокодеры ускакали - не догонишь. Все шишки на ДБА.

Против лома нет приёма....


Могу предложить следующие стандартные варианты для ускорения (другой лом):
1. Разбить ТЕМПДБ на большее количество файлов, это поможет снизить блокировки.
2. Добавить памяти на сервер, это снизит ИО
3. Лог файл поставить на ССД
24 окт 13, 17:34    [15027913]     Ответить | Цитировать Сообщить модератору
 Re: Низкий уровень попадания запроса в кеш планов запросов.  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
ИМХО кто-то троллингом занимается.
24 окт 13, 22:40    [15029028]     Ответить | Цитировать Сообщить модератору
 Re: Низкий уровень попадания запроса в кеш планов запросов.  [new]
ScareCrow
Member

Откуда: Белый город
Сообщений: 17416
Mnior
ИМХО кто-то троллингом занимается.

1C да.
24 окт 13, 23:05    [15029094]     Ответить | Цитировать Сообщить модератору
 Re: Низкий уровень попадания запроса в кеш планов запросов.  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Mnior
ИМХО кто-то троллингом занимается.


Похоже... Понаблюдаем...
24 окт 13, 23:16    [15029120]     Ответить | Цитировать Сообщить модератору
 Re: Низкий уровень попадания запроса в кеш планов запросов.  [new]
МуМу
Member

Откуда:
Сообщений: 1134
Уважаемый(без всякой иронии) Mnior. Уверяю я задаю вопрос не ради праздного любопытства.
Система действительно 1С. К сожалению в некоторых случаях я задаю видимо риторические вопросы, но мне их не стыдно задавать,вдруг чего то упустил. К слову все чаще и чаще сталкиваюсь с ситуациями когда код править нет никакой возможности(не только для систем 1С). По общению с коллегами иностранцами, выясняется что у них это вообще типовая ситуация. Так что мне удивительно когда на столь уважаемом форуме идут упреки типа - вот написали гавнокод сами и разгребайте:)
25 окт 13, 09:42    [15029775]     Ответить | Цитировать Сообщить модератору
 Re: Низкий уровень попадания запроса в кеш планов запросов.  [new]
ScareCrow
Member

Откуда: Белый город
Сообщений: 17416
автор
Так что мне удивительно когда на столь уважаемом форуме идут упреки типа

это же россия. тут тебе всегда расскажут как ты не прав.

автор
когда код править нет никакой возможности

полная фигня. уж в самом запущенном случае собрать свой ODBC драйвер и перехватывать запросы на нём проблем нет.
25 окт 13, 17:45    [15033672]     Ответить | Цитировать Сообщить модератору
 Re: Низкий уровень попадания запроса в кеш планов запросов.  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
МуМу
Какое нормальное количество планов запросов?( У меня количество записей не превышало приблизительно 150 т. записей.)
Соответственно возникает резонный вопрос, а много ли уходит накладных расходов на параметризацию и поиск в кеше?
Много ли уходит расходов чтобы найти одну запись (или убедиться что ее там нет) в таблице из 150т. используя поиск по ключу? Так почему вы думаете что поиск запроса в кеше должен выполнятся как то по другому?

С другой стороны у вас память может забиваться планами, которые никогда больше не используются. Можно попробовать включить optimizing for adhoc workloads.

МуМу
Проблема в том что система генерирует новые временные таблицы и использует каждый раз новую временную таблицу. Соответственно планы каждый раз новые.
Даже если бы временные таблицы назывались одинаково все равно велика вероятность перекомпиляции. Это особенность временных таблиц.
25 окт 13, 20:09    [15034176]     Ответить | Цитировать Сообщить модератору
 Re: Низкий уровень попадания запроса в кеш планов запросов.  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
МуМу
В этой ситуации есть еще один неприятный момент. Устаревание статистики приводит к крайне неприятным последствиям. А с другой стороны пересчет ее в рабочем режиме приводит к блокировкам.(все запросы гарантированно обращаются к таблицам статистики)
А это как относится к первоначальной проблеме?

Тут только два варианта:
1. Выключить автоматическое обновление и делать пересчет вручную в нерабочее время, но я бы не советовал так делать.
2. Включить асинхронное обновление статистики.
25 окт 13, 20:11    [15034182]     Ответить | Цитировать Сообщить модератору
 Re: Низкий уровень попадания запроса в кеш планов запросов.  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
ScareCrow
Mnior
ИМХО кто-то троллингом занимается.
1C да.
Надо в правилах написать, что если вопрос касается 1C, то обязательно ставить префикс в название топика.

Видимо у каждого DBA должна быть заметочка в резюме. "Поддержку баз для 1С не предлагать".


Чтоб потом появились предложения: "Нужен DBA для 1C, ПЛАЧУ МНОГО!!!".
Как-то двусмысленно получилось.
25 окт 13, 23:46    [15035102]     Ответить | Цитировать Сообщить модератору
 Re: Низкий уровень попадания запроса в кеш планов запросов.  [new]
МуМу
Member

Откуда:
Сообщений: 1134
Насчет статистики интересная тема. По ней у меня несколько вопросов.
Во первых пересчет без full scan стал часто ошибаться.(автопересчет стоит на свойствах базы) Хочется отдельно понять почему?
Можно ли при пересчете с full scan явно управлять количеством ядер? Уровень параллелизма стоит 1, а при пересчете распределял все равно по большому количеству ядер. Признаюсь правда MAX DOP явно при вызове конструкции не ставил.

Блокировка при пересчете статистики возникает в момент замены таблицы статистики старой на новую. Казалось бы немного по времени? Но описанном выше вырожденном случае практически все запросы обращаются к таблице статистики и учитывая их высокую интенсивность получаются блокировки. Как вариант из области фантастики к основным запросам явно привязывать план выполнения в момент пересчета статистики. Тогда конкретная таблица статистики в момент пересчета не будет никого блокировать. На самом деле техническая возможность существует, у нас написан своего рода ODBC драйвер(прокси).То есть замену запросов на лету делать можно. Быстрый парсер тоже реализован, проблема в том что неясно , можно ли привязывать план запроса к запросу у которого временная таблица отличается по наименованию? Да и трудоемко все это.
Практически сейчас кроме того что пересчет делать отдельно по каждой статистике(что бы уменьшить время блокировки) а не целиком по таблице в голову ничего не приходит.
Насчет асинхронного пересчета статистики не совсем понял, что это такое?
26 окт 13, 10:30    [15035756]     Ответить | Цитировать Сообщить модератору
 Re: Низкий уровень попадания запроса в кеш планов запросов.  [new]
МуМу
Member

Откуда:
Сообщений: 1134
Повторюсь насчет асинхронного пересчета статистики. Что это такое? (теоретически делать репликационную, порционную вставку и т.п. было бы интересно, дали бы инструмент придумали бы)
28 окт 13, 23:22    [15043565]     Ответить | Цитировать Сообщить модератору
 Re: Низкий уровень попадания запроса в кеш планов запросов.  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
МуМу
Повторюсь насчет асинхронного пересчета статистики. Что это такое?
На гугле забанили чтоли?
асинхронного пересчета статистики
29 окт 13, 01:43    [15043900]     Ответить | Цитировать Сообщить модератору
 Re: Низкий уровень попадания запроса в кеш планов запросов.  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
МуМу
Во первых пересчет без full scan стал часто ошибаться.(автопересчет стоит на свойствах базы) Хочется отдельно понять почему?
Потому что статистика основанная на неполном наборе данных не может быть идеальной по определению.

МуМу
Можно ли при пересчете с full scan явно управлять количеством ядер? Уровень параллелизма стоит 1, а при пересчете распределял все равно по большому количеству ядер. Признаюсь правда MAX DOP явно при вызове конструкции не ставил.
Вроде нет такой опции у команды UPDATE STATISTICS.

МуМу
Блокировка при пересчете статистики возникает в момент замены таблицы статистики старой на новую. Казалось бы немного по времени? Но описанном выше вырожденном случае практически все запросы обращаются к таблице статистики и учитывая их высокую интенсивность получаются блокировки.
Это при ручном пересчете статистики? Звучит как фантастика. Очень сомневаюсь, что замена таблицы статистики будет иметь хоть какой то импакт на запросы.
А если при автоматическом, то все запросы просто тупо ждут, когда посчитается статистика.

МуМу
На самом деле техническая возможность существует, у нас написан своего рода ODBC драйвер(прокси).То есть замену запросов на лету делать можно. Быстрый парсер тоже реализован, проблема в том что неясно , можно ли привязывать план запроса к запросу у которого временная таблица отличается по наименованию? Да и трудоемко все это.
Велосипед изобретаем?
29 окт 13, 02:23    [15043957]     Ответить | Цитировать Сообщить модератору
 Re: Низкий уровень попадания запроса в кеш планов запросов.  [new]
МуМу
Member

Откуда:
Сообщений: 1134
Интересно, как можно написать так много текста и при этом передать ноль полезной информации:)
Предлагаю не заниматься софистикой и философией, предлагаю ответить на вполне конкретные вопросы.(если не лень и принципы позволят;))
Можно ли управлять количеством потоков(ядер соответственно) при расчете статистики?
Можете ли привести максимально подробный алгоритм расчета выборки по full scan?
Еще раз повторю вопрос про асинхронный расчет статистики(дайте точную ссылку будьте добры)
Насчет влияния на запросы , можно ваше определения (ручной, автоматический, синхронный) расчета статистики?
(Влиять в вырожденных случаях будут, есть нагрузочные тесты которые это подтверждают. )
29 окт 13, 02:56    [15043977]     Ответить | Цитировать Сообщить модератору
 Re: Низкий уровень попадания запроса в кеш планов запросов.  [new]
МуМу
Member

Откуда:
Сообщений: 1134
Опечатка в прошлом посте. Синхронный нужно заменить на асинхронный.
29 окт 13, 03:01    [15043980]     Ответить | Цитировать Сообщить модератору
 Re: Низкий уровень попадания запроса в кеш планов запросов.  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
МуМу
Предлагаю не заниматься софистикой и философией, предлагаю ответить на вполне конкретные вопросы.(если не лень и принципы позволят;))
Если тому, кому это больше всех надо даже лень перейти по ссылке...

МуМу
Можно ли управлять количеством потоков(ядер соответственно) при расчете статистики?
Скорее всего нет. Команда пересчета статистики такой синтакисис не поддерживает или мне об этом неизвестно.

МуМу
Можете ли привести максимально подробный алгоритм расчета выборки по full scan?
Алгоритм расчета статистики? Как из многомилионной таблицы получить 200 значений? Нет, не могу. Насколько мне известно, майкрософт не разглашает подобной информации, да и зачем оно надо, там одна математика.

МуМу
Еще раз повторю вопрос про асинхронный расчет статистики(дайте точную ссылку будьте добры)
http://technet.microsoft.com/ru-ru/library/ms190397.aspx Поиск по AUTO_UPDATE_STATISTICS_ASYNC

МуМу
Насчет влияния на запросы , можно ваше определения (ручной, автоматический, синхронный) расчета статистики?
При автоматическом: если в момент компиляции запроса выясняется что статистика устарела, то прежде чем продолжится компиляция статистика должна быть пересчитана. Если в этот момент несколько запросов обращаются к этой таблице, то все они будут ждать пока первый процесс пересчитает статистику. Для очень больших таблиц, даже SAMPLE SCAN может выполнятся прилично долго, и запросы будут отваливаться по таймауту.

При ручном, пересчет статистики не должен оказывать особого влияния на выполняющиеся запросы, не считая конечно большого количества чтений с таблицы. Какие именно именно блокировки происходят в момент заменты таблицы статистики я не знаю, но не думаю что это должно оказывать хоть какое либо влияние, потому что если блокировка и происходит, то только метаданных.

Про асинхронный написано выше по ссылке.
МуМу
(Влиять в вырожденных случаях будут, есть нагрузочные тесты которые это подтверждают. )
Было бы интересно посмотреть на ваши тесты.
29 окт 13, 22:11    [15049261]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить