Очистка процедурного кэша sql
Внимание! Данный форум является модерируемым.
Для получения к нему доступа необходимо зарегистрироваться или авторизоваться на сайте.
Регламентное обслуживание базы данных "Рестарт", оптимизация работы баз данных, проверки на ошибки и общее сокращение времени выпольнения скриптов
Любая база данных нуждается в регулярном обслуживании. Особенно если она достигает достаточно большого объема или содержит транзакции за большой период.
Т.к. Рестарт в качестве СУБД использует Microsoft SQL Server, то и обслуживание баз может производиться его же средствами.
Если же у вас стоит бесплатная версия (SQL Express, по умолчанию входящий в дистрибутив), то придется запускать процедуру обслуживания вручную.
Физически это выражается в запуске 4-х скриптов. Что вам для этого понадобится:
- Архив
- Обновление статистик;
- Очистка процедурного кэша;
- Дефрагментация индексов;
- Реиндексация индексов;
ВНИМАНИЕ: текст третьего скрипта имеет вид: sp_msforeachtable N'DBCC INDEXDEFRAG (RestartMain, ''?'')', где RestartMain это название базы данных. Если у вас другое название, то укажите его в скрипте.
Время выполнения скриптов зависит только от размеров БД и может достигать нескольких десятков минут. Будьте терпеливы и не прерывайте процесс принудительно.
В обязательном порядке перед запуском скриптов сделайте бэкап базы данных.
Автоматическое обслуживание бд. Создаем 4 текстовых файла: первый допустим назовем "statAndcache.sql" тоесть обновление статистик и процедурного кеша с текстом внутри
exec sp_updatestats
DBCC FREEPROCCACHE
Второй reindex.sql реиндексация индексов с текстом:
sp_msforeachtable N'DBCC DBREINDEX (''?'')'
Третий назовем backupANDtrans.sql где делается бекап и дефрагментация индексов с текстом
ALT ER DATABASE [restartmain] SET RECOVERY SIMPLE
DBCC SHRINKFILE (N'restartmain_log' , 128, TRUNCATEONLY )
ALT ER DATABASE [restartmain] SET RECOVERY FULL
--
BACKUP DATABASE [restartmain]
TO DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup\pos.bak'
WITH NOFORMAT, NOINIT, NAME = N'restartmain_full_backup',
SKIP, NOREWIND, NOUNLOAD, STATS = 10
где restartmain — это название БД, а TO DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup\pos.bak это путь куда будут сохранятся бекапы (можете указать свой путь)
И наконец четвертый файл где у нас будут запускаться предыдущие три файла, назовем его optimpiz.bat с текстом внутри
sqlcmd -S term1\restart -U sa -P rarus -d restartmain -i "C:\backupANDtrans.sql"
sqlcmd -S term1\restart -U sa -P rarus -d restartmain -i "C:\statANDcashe.sql"
sqlcmd -S term1\restart -U sa -P rarus -d restartmain -i "C:\reindex.sql"
где term1 название компьютера где БД, restartmain название БД — (если у вас отличное от этого, меняйте на свое)
Потом в стандартном Виндовс планировщике создаем задание на выполнение файла optimiz.bat с указанием времени и дней когда оно у нас будет выполняться.
P.S Все файлы "кидаем" в одно место, допустим на диск С:\
Виталий продемонстрировал один из способов замены стандартных "планов обслуживания", отсутствующих в бесплатной поставке MS SQL Server. Спасибо за подробную инструкцию! Попробую использовать в работе.
Удаляет все элементы из кэша планов, удаляет заданный план из кэша планов с помощью указания дескриптора плана или дескриптора SQL либо удаляет все записи кэша, связанные с указанным пулом ресурсов.
DBCC FREEPROCCACHE не очищает статистику выполнения для хранимых процедур, скомпилированных в собственном коде. Кэш процедур не содержит сведения о хранимых процедурах, скомпилированных в собственном коде. Все статистические данные выполнения, полученные при выполнении процедур, появятся в динамических административных представлениях (DMV) статистики выполнения: sys.dm_exec_procedure_stats (Transact-SQL) и sys.dm_exec_query_plan (Transact-SQL).
Наборы результатов
Аргументы
( < plan_handle | sql_handle | pool_name > )
plan_handle уникально идентифицирует план запроса для запущенного пакета, план которого хранится в кэше планов. Аргумент plan_handle имеет тип varbinary(64), и его можно получить из следующих объектов DMO:
sql_handle представляет дескриптор SQL очищаемого пакета. Аргумент sql_handle имеет тип varbinary(64), и его можно получить из следующих объектов DMO:
pool_name представляет имя пула ресурсов Resource Governor. Аргумент pool_name имеет тип sysname и может быть получен с помощью запроса к динамическому административному представлению sys.dm_resource_governor_resource_pools.
Чтобы связать группу рабочей нагрузки Resource Governor с пулом ресурсов, запросите динамическое административное представление sys.dm_resource_governor_workload_groups. Чтобы получить сведения о группе рабочей нагрузки для сеанса, запросите динамическое административное представление sys.dm_exec_sessions.
COMPUTE
Очистка кэша планов запросов в каждом вычислительном узле. Это значение по умолчанию.
ALL
Очистка кэша планов запросов в каждом вычислительном узле и в управляющем узле.
Начиная с версии SQL Server 2016 (13.x);, для очистки кэша процедур (планов) для базы данных в области действия служит инструкция ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE .
Метаданные для Azure Synapse Analytics и Система платформы аналитики (PDW)
При выполнении команды DBCC FREEPROCCACHE в системное представление sys.pdw_exec_requests добавляется новая строка.
Д. Предоставление разрешения на выполнение DBCC FREEPROCCACHE
В приведенном ниже примере имени для входа David предоставляется разрешение на выполнение DBCC FREEPROCCACHE.
Removes all elements from the plan cache, removes a specific plan from the plan cache by specifying a plan handle or SQL handle, or removes all cache entries associated with a specified resource pool.
DBCC FREEPROCCACHE does not clear the execution statistics for natively compiled stored procedures. The procedure cache does not contain information about natively compiled stored procedures. Any execution statistics collected from procedure executions will appear in the execution statistics DMVs: sys.dm_exec_procedure_stats (Transact-SQL) and sys.dm_exec_query_plan (Transact-SQL).
Metadata for Azure Synapse Analytics and Analytics Platform System (PDW)
A new row is added to the sys.pdw_exec_requests system view when DBCC FREEPROCCACHE is run.
A. Clearing a query plan from the plan cache
The following example clears a query plan from the plan cache by specifying the query plan handle. To ensure the example query is in the plan cache, the query is first executed. The sys.dm_exec_cached_plans and sys.dm_exec_sql_text dynamic management views are queried to return the plan handle for the query.
The plan handle value from the result set is then inserted into the DBCC FREEPROCACHE statement to remove only that plan from the plan cache.
Here is the result set.
Комментарии
Инструкция DBCC FREEPROCCACHE используется для аккуратной очистки кэша планов. Очистка кэша процедур (планов) приводит к исключению всех планов. В результате при выполнении входящих запросов будет компилироваться новый план, а не использоваться существующий план из кэша.
SQL Server has encountered %d occurrence(s) of cachestore flush for the '%s' cachestore (part of plan cache) due to 'DBCC FREEPROCCACHE' or 'DBCC FREESYSTEMCACHE' operations.
Следующие операции по перенастройке также очищают кэш процедур:
- доступ к счетчику контейнеров проверки кэша
- доступ к квоте кэша проверки
- clr enabled
- стоимостный порог для параллелизма
- cross db ownership chaining
- память для создания индекса
- максимальная степень параллелизма
- max server memory
- max text repl size
- максимальное количество рабочих потоков
- min memory per query
- min server memory
- ограничение стоимости регулятора запросов
- ожидание запроса
- remote query timeout
- user options
Примеры: SQL Server
Remarks
Use DBCC FREEPROCCACHE to clear the plan cache carefully. Clearing the procedure (plan) cache causes all plans to be evicted, and incoming query executions will compile a new plan, instead of reusing any previously cached plan.
This can cause a sudden, temporary decrease in query performance as the number of new compilations increases. For each cleared cachestore in the plan cache, the SQL Server error log will contain the following informational message:
SQL Server has encountered %d occurrence(s) of cachestore flush for the '%s' cachestore (part of plan cache) due to 'DBCC FREEPROCCACHE' or 'DBCC FREESYSTEMCACHE' operations.
This message is logged every five minutes as long as the cache is flushed within that time interval.
The following reconfigure operations also clear the procedure cache:
- access check cache bucket count
- access check cache quota
- clr enabled
- cost threshold for parallelism
- cross db ownership chaining
- index create memory
- max degree of parallelism
- max server memory
- max text repl size
- max worker threads
- min memory per query
- min server memory
- query governor cost limit
- query wait
- remote query timeout
- user options
Examples: Azure Synapse Analytics and Analytics Platform System (PDW)
A. Очистка плана запроса из кэша планов
В следующем примере план запроса очищается из кэша планов путем указания дескриптора плана запроса. Чтобы обеспечить наличие запроса-образца в кэше планов, сначала выполните следующий запрос. Динамические административные представления sys.dm_exec_cached_plans и sys.dm_exec_sql_text запрашиваются для возврата дескриптора плана соответствующего запроса.
Затем значение дескриптора плана из результирующего набора вставляется в инструкцию DBCC FREEPROCACHE для удаления из кэша планов именно этого плана.
Examples: SQL Server
Permissions
Applies to: SQL Server, Analytics Platform System (PDW)
- Requires ALTER SERVER STATE permission on the server.
Applies to: Azure Synapse Analytics
- Requires membership in the DB_OWNER fixed server role.
Syntax
Syntax for SQL Server:
Syntax for Azure Synapse Analytics and Analytics Platform System (PDW):
To view Transact-SQL syntax for SQL Server 2014 and earlier, see Previous versions documentation.
A. Освобождение неиспользуемых записей кэша из кэша пула регулятора ресурсов
В следующем примере показывается, как очищать кэши, выделенные указанному пулу ресурсов регулятора ресурсов.
Arguments
( < plan_handle | sql_handle | pool_name > )
plan_handle uniquely identifies a query plan for a batch that has executed and whose plan resides in the plan cache. plan_handle is varbinary(64) and can be obtained from the following dynamic management objects:
sql_handle is the SQL handle of the batch to be cleared. sql_handle is varbinary(64) and can be obtained from the following dynamic management objects:
pool_name is the name of a Resource Governor resource pool. pool_name is sysname and can be obtained by querying the sys.dm_resource_governor_resource_pools dynamic management view.
To associate a Resource Governor workload group with a resource pool, query the sys.dm_resource_governor_workload_groups dynamic management view. For information about the workload group for a session, query the sys.dm_exec_sessions dynamic management view.
WITH NO_INFOMSGS
Suppresses all informational messages.
COMPUTE
Purge the query plan cache from each Compute node. This is the default value.
ALL
Purge the query plan cache from each Compute node and from the Control node.
Starting with SQL Server 2016 (13.x), the ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE to clear the procedure (plan) cache for the database in scope.
Разрешения
Требует разрешения ALTER SERVER STATE на сервере.
Результирующие наборы
General Remarks for Azure Synapse Analytics and Analytics Platform System (PDW)
Multiple DBCC FREEPROCCACHE commands can be run concurrently. In Azure Synapse Analytics or Analytics Platform System (PDW), clearing the plan cache can cause a temporary decrease in query performance as incoming queries compile a new plan, instead of reusing any previously cached plan.
DBCC FREEPROCCACHE (COMPUTE) only causes SQL Server to recompile queries when they are run on the Compute nodes. It does not cause Azure Synapse Analytics or Analytics Platform System (PDW) to recompile the parallel query plan that is generated on the Control node. DBCC FREEPROCCACHE can be cancelled during execution.
Б. Освобождение записей из кэшей после прекращения их использования
В следующем примере используется предложение MARK_IN_USE_FOR_REMOVAL, чтобы освободить записи из всех текущих кэшей, когда записи становятся неиспользуемыми.
Регламентные операции на уровне СУБД для MS SQL Server
Инструкция по выполнению регламентных операций на уровне СУБД.
Информация применима к клиент-серверному варианту "1С:Предприятия 8" при использовании СУБД MS SQL Server.
Общие сведения
Одной из часто встречающихся причин неоптимальной работы системы является неправильное или несвоевременное выполнение регламентных операций на уровне СУБД. Особенно важно выполнять эти регламентные процедуры в крупных информационных системах, которые работают под значительной нагрузкой и обслуживают одновременно большое количество пользователей. Специфика таких систем в том, что обычных действий, выполняемых СУБД автоматически (на основании настроек) оказывает недостаточно для эффективной работы.
Если в работающей системе наблюдаются какие-либо симптомы проблем с производительностью, следует проверить, что в системе правильно настроены и регулярно выполняются все рекомендуемые регламентные операции на уровне СУБД.
Выполнение регламентных процедур должно быть автоматизировано. Для автоматизации этих операций рекомендуется использовать встроенное средства MS SQL Server: Maintenance Plan. Существуют так же другие способы автоматизации выполнения этих процедур. В настоящей статье для каждой регламентной процедуры дан пример ее настройки при помощи Maintenance Plan для MS SQL Server 2005.
Для MS SQL Server рекомендуется выполнять следующие регламентные операции:
Рекомендуется регулярно контролировать своевременность и правильность выполнения данных регламентных процедур.
Обновление статистик
MS SQL Server строит план запроса на основании статистической информации о распределении значений в индексах и таблицах. Статистическая информация собирается на основании части (образца) данных и автоматически обновляется при изменении этих данных. Иногда этого оказывается недостаточно для того, что MS SQL Server стабильно строил наиболее оптимальный план выполнения всех запросов.
В этом случае возможно проявление проблем с производительностью запросов. При этом в планах запросов наблюдаются характерные признаки неоптимальной работы (неоптимальные операции).
Для того, чтобы гарантировать максимально правильную работу оптимизатора MS SQL Server рекомендуется регулярно обновлять статистики базы данных MS SQL.
Для обновления статистик по всем таблицам базы данных необходимо выполнить следующий SQL запрос:
Обновление статистик не приводит к блокировке таблиц, и не будет мешать работе других пользователей. Статистика может обновляться настолько часто, насколько это необходимо. Следует учитывать, что нагрузка на сервер СУБД во время обновления статистик возрастет, что может негативно сказаться на общей производительности системы.
Оптимальная частота обновления статистик зависит от величины и характера нагрузки на систему и определяется экспериментальным путем. Рекомендуется обновлять статистики не реже одного раза в день .
Приведенный выше запрос обновляет статистики для всех таблиц базы данных. В реально работающей системе разные таблицы требуют различной частоты обновления статистик. Путем анализа планов запроса можно установить, какие таблицы больше других нуждаются в частом обновлении статистик, и настроить две (или более) различных регламентных процедуры: для часто обновляемых таблиц и для всех остальных таблиц. Такой подход позволит существенно снизить время обновления статистик и влияние процесса обновления статистики на работу системы в целом.
Настройка автоматического обновления статистик (MS SQL 2005)
Запустите MS SQL Server Management Studio и подключитесь к серверу СУБД. Откройте папку Management и создайте новый план обслуживания:
Создайте субплан (Add Subplan) и назовите его «Обновление статистик». Добавьте в него задачу Update Statistics Task из панели задач:
Настройте расписание обновления статистик. Рекомендуется обновлять статистики не реже одного раза в день. При необходимости частота обновления статистик может быть увеличена.
Настройте параметры задачи. Для этого следует два раза кликнуть на задачу в правом нижнем углу окна. В появившейся форме укажите имя базу данных (или несколько баз данных) для которых будет выполняться обновление статистик. Кроме этого вы можете указать для каких таблиц обновлять статистики (если точно неизвестно, какие таблицы требуется указать, то устанавливайте значение All).
Обновление статистик необходимо проводить с включенной опцией Full Scan.
Сохраните созданный план. При наступлении указанного в расписании срока обновление статистик будет запущено автоматически.
Очистка процедурного КЭШа
Оптимизатор MS SQL Server кэширует планы запросов для их повторного выполнения. Это делается для того, чтобы экономить время, затрачиваемое на компиляцию запроса в том случае, если такой же запрос уже выполнялся и его план известен.
Возможна ситуация, при которой MS SQL Server, ориентируясь на устаревшую статистическую информацию, построит неоптимальный план запроса. Этот план будет сохранен в процедурном КЭШе и использован при повторном вызове такого же запроса. Если Вы обновили статистику, но не очистили процедурный кэш, то SQL Server может выбрать старый (неоптимальный) план запроса из КЭШа вместо того, чтобы построить новый (более оптимальный) план.
Таким образом, рекомендуется всегда после обновления статистик очищать содержимое процедурного КЭШа.
Для очистки процедурного КЭШа MS SQL Server необходимо выполнить следующий SQL запрос:
Этот запрос следует выполнять непосредственно после обновления статистики. Соответственно, частота его выполнения должна совпадать с частотой обновления статистики.
Настройка очистки процедурного КЭШа (MS SQL 2005)
Поскольку процедурный КЭШ необходимо очищать при каждом обновлении статистики, данную операцию рекомендуется добавить в уже созданный субплан «Обновление статистик». Для этого следует открыть субплан и добавить в его схему задачу Execute T-SQL Statement Task. Затем следует соединить задачу Update Statistics Task стрелочкой с новой задачей.
В тексте созданной задачи Execute T-SQL Statement Task следует указать запрос «DBCC FREEPROCCACHE»:
Дефрагментация индексов
При интенсивной работе с таблицами базы данных возникает эффект фрагментации индексов, который может привести к снижению эффективности работы запросов.
Рекомендуется регулярное выполнение дефрагментации индексов. Для дефрагментации всех индексов всех таблиц базы данных необходимо использовать следующий SQL запрос (предварительно подставив имя базы):
sp_msforeachtable N'DBCC INDEXDEFRAG (, ''?'')'
Дефрагментация индексов не блокирует таблицы, и не будет мешать работе других пользователей, однако создает дополнительную нагрузку на SQL Server. Оптимальная частота выполнения данной регламентной процедуры должна подбираться в соответствии с нагрузкой на систему и эффектом, получаемым от дефрагментации. Рекомендуется выполнять дефрагментацию индексов не реже одного раза в неделю.
Возможно выполнение дефрагментации для одной или нескольких таблиц, а не для всех таблиц базы данных.
Настройка дефрагментации индексов (MS SQL 2005)
В ранее созданном плане обслуживания создайте новый субплан с именем «Дефрагментация индексов».Добавьте в него задачу Reorganize Index Task:
Задайте расписание выполнения для задачи дефрагментации индексов. Рекомендуется выполнять задачу не реже одного раза в неделю, а при высокой изменчивости данных в базе еще чаще – до одного раза в день.
Настройте задачу, указав базу данных (или несколько баз данных) и выбрав необходимые таблицы. Если точно неизвестно, какие таблицы следует указать, то устанавливайте значение All.
Реиндексация таблиц базы данных
Реиндексация таблиц включает полное перестроение индексов таблиц базы данных, что приводит к существенной оптимизации их работы. Рекомендуется выполнять регулярную переиндексацию таблиц базы данных. Для реиндексации всех таблиц базы данных необходимо выполнить следующий SQL запрос:
sp_msforeachtable N'DBCC DBREINDEX (''?'')'
Реиндексация таблиц блокирует их на все время своей работы, что может существенно сказаться на работе пользователей. В связи с этим реиндексацию рекомендуется выполнять во время минимальной загрузки системы.
После выполнения реиндексации нет необходимости делать дефрагментацию индексов.
Настройка реиндексации таблиц (MS SQL 2005)
В ранее созданном плане обслуживания создайте новый субплан с именем «Реиндексация». Добавьте в него задачу Rebuild Index Task:
Задайте расписание выполнения для задачи реиндексирования таблиц. Рекомендуется выполнять задачу во время минимальной нагрузки на систему, не реже одного раза в неделю.
Настройте задачу, указав базу данных (или несколько баз данных) и выбрав необходимые таблицы. Если точно неизвестно, какие таблицы следует указать, то устанавливайте значение All.
Контроль выполнения регламентных процедур на уровне СУБД
Необходимо осуществлять регулярный контроль выполнения регламентных процедур на уровне СУБД. Ниже приведен пример контроля выполнения плана обслуживания для MS SQL Server 2005.
Откройте созданный вами план обслуживания и выберите из контекстного меню пункт «View History»:
Откроется окно с протоколом выполнения всех заданных регламентных процедур.
Успешно выполненные задачи и задачи, выполненные с ошибками, будут помечены соответствующими иконками. Для задач, выполненных с ошибками, доступна подробная информация об ошибке.
Примеры: Azure Synapse Analytics и Система платформы аналитики (PDW)
B. Clearing all plans from the plan cache
The following example clears all elements from the plan cache. The WITH NO_INFOMSGS clause is specified to prevent the information message from being displayed.
Result Sets
When the WITH NO_INFOMSGS clause is not specified, DBCC FREEPROCCACHE returns: "DBCC execution completed. If DBCC printed error messages, contact your system administrator."
Remarks
SQL Server has encountered %d occurrence(s) of cachestore flush for the '%s' cachestore (part of plan cache) due to 'DBCC FREEPROCCACHE' or 'DBCC FREESYSTEMCACHE' operations.
E. Granting Permission to run DBCC FREEPROCCACHE
The following example gives the login David permission to run DBCC FREEPROCCACHE.
Удаляет все неиспользуемые элементы из всех кэшей. Компонент Компонент SQL Server Database Engine заранее автоматически очищает неиспользуемые элементы кэша в фоновом режиме, освобождая память для текущих записей. Но можно использовать эту команду, чтобы вручную удалить неиспользуемые записи из каждого кэша или из указанного кэша пула Resource Governor.
Limitations and Restrictions for Azure Synapse Analytics and Analytics Platform System (PDW)
DBCC FREEPROCCACHE can not run within a transaction. DBCC FREEPROCCACHE is not supported in an EXPLAIN statement.
Б. Очистка всех планов из кэша планов
Разрешения
Применимо к: SQL Server, Система платформы аналитики (PDW)
- Требует разрешения ALTER SERVER STATE на сервере.
Применимо к: Azure Synapse Analytics
- Необходимо членство в предопределенной роли сервера DB_OWNER.
В. Очистка всех записей кэша, связанных с пулом ресурсов
В следующем примере очищаются все записи кэша, связанные с указанным пулом ресурсов. Сначала запрашивается представление sys.dm_resource_governor_resource_pools для получения значения аргумента pool_name.
Ограничения для Azure Synapse Analytics и Система платформы аналитики (PDW)
Команда DBCC FREEPROCCACHE не может выполняться в рамках транзакции. Команда DBCC FREEPROCCACHE не поддерживается в инструкции EXPLAIN.
Общие замечания касательно Azure Synapse Analytics и Система платформы аналитики (PDW)
Несколько команд DBCC FREEPROCCACHE могут выполняться одновременно. В Azure Synapse Analytics или Система платформы аналитики (PDW) очистка кэша планов может приводить к временному снижению производительности обработки запросов, так как для входящих запросов компилируется новый план, а не используется существующий план из кэша.
Команда DBCC FREEPROCCACHE (COMPUTE) приводит к перекомпиляции запросов сервером SQL Server только в том случае, если они выполняются в вычислительных узлах. Она не приводит к тому, что Azure Synapse Analytics или Система платформы аналитики (PDW) перекомпилируют план параллельных запросов, созданный в управляющем узле. Команду DBCC FREEPROCCACHE можно отменить во время выполнения.
Примеры
Аргументы
( 'ALL' [,pool_name ] )
Ключевое слово ALL указывает все поддерживаемые кэши.
Аргумент pool_name указывает кэш пула регулятора ресурсов. Освобождены будут только записи, связанные с этим пулом. Чтобы получить список доступных имен пулов, выполните следующую команду.
Большинство, но не все, кэши можно освободить по отдельности с помощью этой команды.
MARK_IN_USE_FOR_REMOVAL
Асинхронно освобождает текущие используемые элементы из соответствующих кэшей после того, как они перестают использоваться. Новые элементы, созданные в кэше после выполнения DBCC FREESYSTEMCACHE WITH MARK_IN_USE_FOR_REMOVAL, не будут затронуты.
D. DBCC FREEPROCCACHE Basic Syntax Examples
The following example removes all existing query plan caches from the Compute nodes. Although the context is set to UserDbSales, the Compute node query plan caches for all databases will be removed. The WITH NO_INFOMSGS clause prevents informational messages from appearing in the results.
The following example has the same results as the previous example, except that informational messages will show in the results.
When informational messages are requested and the execution is successful, the query results will have one line per Compute node.
Синтаксис
Синтаксис для SQL Server:
Синтаксис для Azure Synapse Analytics и :Система платформы аналитики (PDW)
Ссылки на описание синтаксиса Transact-SQL для SQL Server 2014 и более ранних версий, см. в статье Документация по предыдущим версиям.
C. Clearing all cache entries associated with a resource pool
The following example clears all cache entries associated with a specified resource pool. The sys.dm_resource_governor_resource_pools view is first queried to obtain the value for pool_name.
Синтаксис
Ссылки на описание синтаксиса Transact-SQL для SQL Server 2014 и более ранних версий, см. в статье Документация по предыдущим версиям.
Г. Примеры базового синтаксиса DBCC FREEPROCCACHE
Читайте также: