Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
24.10.2001, 07:30
|
|||
|---|---|---|---|
Использование WITH RECOMPILE |
|||
|
#18+
Привет Всем! Насколько правильно использовать при вызове каждой процедуры параметер WITH RECOMPILE ? Объясню ситуацию - имеется сервер с большим количеством процедур-отчетов (~200 сейчас и до 400 в будущем). Написание процедур и сопровождение таблиц осуществляются разными людьми. А так как по BOL-У " As a database is changed by such actions as adding indexes or changing data in indexed columns, the original query plans used to access its tables should be optimized again by recompiling them . This optimization happens automatically the first time a stored procedure is run after Microsoft® SQL Server™ 2000 is restarted. It also occurs if an underlying table used by the stored procedure changes. But if a new index is added from which the stored procedure might benefit, optimization does not automatically happen (until the next time the stored procedure is run after SQL Server is restarted). " Будет ли правильным обязать всех программистов запускать хранимые процедуры с WITH RECOMPILE ? А как отразиться постоянная перестройка плана выполнения каждой процедуры на производительности сервера (~50 пользователей) ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
24.10.2001, 12:39
|
|||
|---|---|---|---|
|
|||
Использование WITH RECOMPILE |
|||
|
#18+
Объевлять хранимую с with recompile imho смысла нет т.к. перестраивать план выполнения процедуры нужно только после обновления статистик сервера.Я в таком случае делаю следующее пишу задачу которая обновляет статистики(либо перестраивает) по наиболее критичным таблицам и после этого для этих таблиц вызываю sp_recomple - для всех хранимых процедур и триггеров использующих данные таблицы при следующем вызове автоматически будет перестроен план выполнения ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
24.10.2001, 12:52
|
|||
|---|---|---|---|
Использование WITH RECOMPILE |
|||
|
#18+
Именно только статистик ? В BOL-е ведь упоминаются индексы. Ну а если такая ситуация. Администратор базы собирает трассу выполнения запросов(скажем за 2-3 дня) через Profiler, затем на ее основании получает рекомендации от Index Tuning Wizard-а и строит/удаляет индексы/статистику у нескольких таблиц. Но откуда администратор знает какие именно процедуры (из 200 возможных) используют эти таблицы (не анализруя код конечно)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
24.10.2001, 16:20
|
|||
|---|---|---|---|
|
|||
Использование WITH RECOMPILE |
|||
|
#18+
я ставлю WITH RECOMPILE в процедурах отчетных у меня процедуры используют псевдовременные таблицы ака TABLE_123 (постоянное имя + SPID), что однозначно идентифицирует таблицу с пользователем В зависимости от параметров отчета набор данных в этой входной таблице может колебаться от 1 до 40000, соответственно эта таблица участвует в куче соединений внутри процедуры. Перед вызовом делаю на этой таблице кучу индексов и update statistics. Без WITH RECOMPILE планы нехороший сервер строил одни и теже, несмотря на большое различие количества данных во входной таблице. С WITH RECOMPILE все стало как по нотам. Кстати, если количество во входной таблице 1, добавляю ветку запроса с параметром, но к сожалению, времени все перелопачивать нет. кстати, при использовании в качестве входных таблиц временных (#), ничего подобного не происходило, тупой scan, QA показывает таблицу в красном (потеряна статистика) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=46&mobile=1&tid=1825211]: |
0ms |
get settings: |
5ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
35ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
24ms |
get tp. blocked users: |
1ms |
| others: | 232ms |
| total: | 319ms |
| 0 / 0 |
