Перемещение базы данных TEMPDB
TEMPDB представляет собой системную базу данных Microsoft SQL Server, в которой хранятся временные таблицы, созданные как самим сервером, так и пользователями. Эта база данных создается заново при каждом перезапуске Microsoft SQL Server. По умолчанию размер этой базы данных неограничен и увеличение его осуществляется при необходимости автоматически, порциями по 10% от текущего размера TEMPDB. Однако эти параметры могут быть переопределены пользователем. По умолчанию, минимальный размер этой базы данных, который устанавливается при старте Microsoft SQL Server, определяется размером системной базы данных MODEL. Очистка журнала транзакций в этой базе данных производится автоматически, при этом удаляются только неактивные записи журнала транзакций.
При работе 1С:Предприятия 8 в режиме клиент-сервер широко используются временные таблицы . Кроме того, TEMPDB используется Microsoft SQL Server при выполнении запросов, использующих операторы GROUP BY , UNION , DISTINCT и т.п.
Проблема
В процессе работы 1С:Предприятия 8 возможно значительное увеличение размера базы данных TEMPDB. Если размер диска, на котором расположена база данных TEMPDB, окажется недостаточным, работа 1С:Предприятия 8 может завершиться аварийно.
Решение
Если эта проблема проявляется регулярно, то рекомендуется переместить TEMPDB на другой диск большего размера.
Эту операцию можно выполнить следующим способом:
- определить логические имена файлов базы данных TEMPDB (колонка «NAME» результата выполнения процедуры). Для этого нужно в Query Analyzer выполнить следующую команду:
USE tempdb GO EXEC sp_helpfile GO
- изменить месторасположение файлов базы данных TEMPDB с помощью команды ALTER DATABASE . Для этого нужно в Query Analyzer выполнить следующую последовательность команд:
USE master GO ALTER DATABASE tempdb MODIFY FILE (NAME = tempdev, FILENAME = 'Новый_Диск:\Новый_Каталог\tempdb.mdf') GO ALTER DATABASE tempdb MODIFY FILE (NAME = templog, FILENAME = 'Новый_Диск:\Новый_Каталог\templog.ldf') GO
- Перезапустить Microsoft SQL Server.
Более подробное описание и рекомендации по использованию этих команд можно найти в документации по Microsoft SQL Server.
Устранение ошибок tempdb в выделенном пуле SQL
В выделенном пуле SQL база данных tempdb используется для временных таблиц и промежуточного пространства для перемещения данных (например, перемещений перетасовки, обрезки), сортировки, загрузки, разлива памяти и других операций. Кроме того, незафиксированная транзакция в одном сеансе, взаимодействующая с базой данных tempdb, не позволит журналу очистить все остальные сеансы, что приведет к заполнению файлов журнала. Так как база данных tempdb является общим ресурсом, большое потребление пространства базы данных tempdb может привести к сбою запросов других пользователей и эскалации, чтобы предотвратить создание новых подключений.
Что делать, если не удается подключиться к выделенному пулу SQL?
Если у вас нет существующих подключений для выявления проблемных подключений или запросов, единственным способом устранения невозможности создания нового подключения является приостановка и возобновление или масштабирование выделенного пула SQL. Это действие приведет к прекращению пользовательских транзакций, которые привели к этой проблеме, и повторно создаст базу данных tempdb при перезапуске службы.
Примечание: Обязательно предоставьте службе дополнительное время для отмены всех выполняемых транзакций, так как выполнение операций приостановки и масштабирования в этом сценарии может занять больше времени, чем обычно.
Устранение неполадок с полными файлами данных tempdb
Шаг 1. Определение запроса, который заполняет базу данных tempdb
Убедитесь, что вы определили запрос, который заполняет базу данных tempdb во время выполнения запроса, если вы не реализовали компонент ведения журнала в платформе ETL или аудит выделенных инструкций пула SQL. В большинстве случаев, не всегда, самый длительный запрос, выполняемый в течение периода времени, в течение которого возникла проблема, является причиной ошибок, вызванных тем, что база данных tempdb не занимает места. Выполните следующий запрос, чтобы получить список длительных запросов:
SELECT TOP 5 * FROM sys.dm_pdw_exec_requests WHERE status = 'running' ORDER BY total_elapsed_time desc; Когда у вас есть достаточно подозрительный запрос, попробуйте один из следующих вариантов:
- Завершите инструкцию .
- Попытайтесь предотвратить дальнейшее использование пространства базы данных tempdb любой другой рабочей нагрузкой, чтобы средство длительного выполнения удаляло выполнение.
Шаг 2. Предотвращение повторения
После определения и выполнения действий с ответственным запросом рассмотрите возможность реализации мер по устранению неполадок, чтобы предотвратить повторение проблемы. В следующей таблице показаны способы устранения наиболее распространенных причин полных ошибок базы данных tempdb:
| Причина | Описание | Устранение рисков |
|---|---|---|
| Плохой распределенный план | Распределенный план, созданный для данного запроса, может непреднамеренно привести к перемещению данных с высокой частотой в результате плохой статистики таблицы. | Обновите статистику для соответствующих таблиц и убедитесь, что она поддерживается по регулярному расписанию. |
| Плохая работоспособность кластеризованного индекса columnstore (CCI) | Он потребляет пространство базы данных tempdb из-за разлива памяти. | Перестройте ccis и убедитесь, что они поддерживаются по регулярному расписанию. |
| Крупные транзакции | Большой объем инструкций CREATE TABLE AS SELECT (CTAS) или INSERT SELECT заполняет базу данных tempdb во время операций перемещения данных. | Разбейте инструкцию CTAS или INSERT SELECT на несколько небольших транзакций. |
| Недостаточное выделение памяти | Запросы с недостаточным объемом выделенной памяти (через класс ресурсов или группу рабочей нагрузки) могут перетекать в tempdb . | Выполняйте запросы с большим классом ресурсов или группой рабочей нагрузки с большим количеством ресурсов. |
| Запросы к внешней таблице конечных пользователей | Запросы к внешним таблицам не являются оптимальными для запросов конечных пользователей, так как подсистеме необходимо считывать весь файл tempdb перед обработкой данных. | Загрузите данные в постоянную таблицу, а затем направьте туда запросы пользователей. |
| Недостаточно общих ресурсов | Вы можете обнаружить, что выделенный пул SQL близок к максимальной емкости tempdb во время высокой активности. | Рассмотрите возможность масштабирования выделенного пула SQL в сочетании с любой из описанных выше мер. |
Устранение неполадок с полными файлами журнала транзакций tempdb
Журнал транзакций tempdb обычно заполняется только в том случае, если клиент или пользователь:
- Открывает явную транзакцию, но никогда не выдает или COMMIT ROLLBACK .
- Наборы IMPLICIT_TRANSACTION = ON (особенно для клиентов И средств JDBC, использующих функции автозавершение).
Шаг 1. Определение открытых транзакций
Проблемные подключения могут быть от клиентов, которые имеют открытую транзакцию, но находятся в состоянии «Простой». Выполните следующий запрос, чтобы определить этот сценарий:
SELECT * FROM sys.dm_pdw_exec_sessions WHERE is_transactional = 1 AND status = 'Idle'; Примечание. Не все подключения, возвращаемые в результате этого запроса, обязательно проблематичны. Выполните запрос по крайней мере дважды с более чем 15 минут между выполнением и посмотрите, какие подключения сохраняются в этом состоянии.
Шаг 2. Устранение и предотвращение проблемы
Определив, какие клиенты проводят открытые транзакции, обратитесь к пользователям, чтобы изменить один или оба варианта:
- Конфигурация драйвера (например, для параметра JDBC AutoCommit значение off , которое задает IMPLICIT_TRANSACTIONS = ON )
- Поведение нерегламентированных запросов (например, неправильное выполнение BEGIN TRAN без COMMIT / ROLLBACK )
Кроме того, можно создать автоматизированный процесс для периодического обнаружения этого сценария и завершения любых потенциально проблемных сеансов.
Ресурсы
- Запросите sys.dm_pdw_errors динамического административного представления на наличие ошибок.
Сжатие базы данных tempdb
В этой статье рассматриваются различные методы, которые можно использовать для сжатия tempdb базы данных в SQL Server.
Для изменения размера tempdb можно использовать любой из следующих методов. Первые три варианта описаны в этой статье. Если вы хотите использовать SQL Server Management Studio, следуйте инструкциям в статье «Сжатие базы данных».
| Метод | Требуется перезагрузка? | Дополнительные сведения |
|---|---|---|
| ALTER DATABASE | Да | Предоставляет полный контроль над размером файлов по умолчанию tempdb ( tempdev и templog ). |
| DBCC SHRINKDATABASE | No | Работает на уровне базы данных. |
| DBCC SHRINKFILE | No | Позволяет сжимать отдельные файлы. |
| SQL Server Management Studio | No | Сжатие файлов базы данных с помощью графического пользовательского интерфейса. |
Замечания
По умолчанию tempdb база данных настроена для автоматического увеличения по мере необходимости. Таким образом, эта база данных может неожиданно увеличиться до размера, превышающего требуемый размер. tempdb Большие размеры базы данных не влияют на производительность SQL Server.
При запуске tempdb SQL Server повторно создается с помощью копии model базы данных и tempdb сбрасывается до последнего настроенного размера. Настроенный размер — это последний явный размер, заданный с помощью операции изменения размера файла, например ALTER DATABASE для использования MODIFY FILE параметра или DBCC SHRINKFILE DBCC SHRINKDATABASE инструкций. Таким образом, если вам не придется использовать различные значения или получить немедленное разрешение в большой tempdb базе данных, можно ожидать следующего перезапуска службы SQL Server, чтобы уменьшить размер.
Вы можете уменьшить tempdb время выполнения tempdb действий. Однако могут возникнуть другие ошибки, такие как блокировка, взаимоблокировка и т. д., которые могут предотвратить сжатие. Таким образом, чтобы убедиться, что сжатие tempdb успешно выполнено, рекомендуется сделать это, пока сервер находится в однопользовательском режиме или при остановке всех tempdb действий.
SQL Server записывает только достаточно сведений в tempdb журнале транзакций для отката транзакции, но не для повторного выполнения транзакций во время восстановления базы данных. Эта функция повышает производительность инструкций INSERT в tempdb . Кроме того, вам не нужно регистрировать данные для повторного выполнения транзакций, так как tempdb создается повторно при каждом перезапуске SQL Server. Поэтому у него нет транзакций для отката или отката.
Дополнительные сведения об управлении и мониторинге tempdb см. в разделе «Планирование емкости» и «Мониторинг tempdb».
Использование команды ALTER DATABASE
Эта команда работает только в логических файлах tempdev по умолчанию tempdb и templog . Если в нее добавляются tempdb дополнительные файлы, их можно сжать после перезапуска SQL Server в качестве службы. Все tempdb файлы создаются повторно во время запуска. Однако они пусты и могут быть удалены. Чтобы удалить дополнительные файлы, tempdb используйте ALTER DATABASE команду с параметром REMOVE FILE .
Для этого метода требуется перезапустить SQL Server.
- Остановите SQL Server.
- В командной строке запустите экземпляр в минимальном режиме конфигурации. Для этого выполните следующие шаги.
- В командной строке перейдите в папку, в которой установлен SQL Server (замените и в следующем примере):
cd C:\Program Files\Microsoft SQL Server\MSSQL.\MSSQL\Binnsqlservr.exe -s -c -f -mSQLCMDsqlservr -c -f -mSQLCMDЗаметка -f Параметры -c вызывают запуск SQL Server в минимальном режиме конфигурации с tempdb размером 1 МБ для файла данных и 0,5 МБ для файла журнала. Параметр -mSQLCMD запрещает любому другому приложению, кроме sqlcmd , принимать однопользовательское подключение.
ALTER DATABASE tempdb MODIFY FILE (NAME = 'tempdev', SIZE = ); ALTER DATABASE tempdb MODIFY FILE (NAME = 'templog', SIZE = );Использование команды DBCC SHRINKDATABASE
DBCC SHRINKDATABASE получает параметр target_percent . Это требуемый процент свободного места в файле базы данных после того, как база данных сократилась. При использовании DBCC SHRINKDATABASE может потребоваться перезапустить SQL Server.
-
Определите пространство, которое в настоящее время используется tempdb с помощью хранимой sp_spaceused процедуры. Затем вычислите процент свободного пространства, которое осталось для использования в качестве параметра DBCC SHRINKDATABASE . Это вычисление основано на требуемом размере базы данных.
Заметка В некоторых случаях может потребоваться выполнить sp_spaceused @updateusage = true пересчет пространства, используемого и для получения обновленного отчета. Дополнительные сведения см. в разделе sp_spaceused (Transact-SQL).
DBCC SHRINKDATABASE (tempdb, '');В команде DBCC SHRINKDATABASE tempdb есть ограничения. Целевой размер файлов данных и журналов не может быть меньше, чем размер, указанный при создании базы данных, или меньше последнего размера, который был явно задан с помощью операции изменения размера файла, такой как ALTER DATABASE этот MODIFY FILE параметр. Другим ограничением DBCC SHRINKDATABASE является вычисление target_percentage параметра и его зависимость от текущего пространства, используемого.
Использование команды DBCC SHRINKFILE
DBCC SHRINKFILE Используйте команду для сжатия отдельных tempdb файлов. DBCC SHRINKFILE обеспечивает большую гибкость, чем DBCC SHRINKDATABASE из-за того, что его можно использовать в одном файле базы данных, не затрагивая другие файлы, принадлежащие той же базе данных. DBCC SHRINKFILE target_size получает параметр. Это требуемый окончательный размер файла базы данных.
- Определите требуемый размер основного файла данных (), файла журнала ( tempdb.mdf templog.ldf ) и дополнительных файлов, добавленных tempdb в . Убедитесь, что пространство, используемое в файлах, меньше или равно требуемому целевому размеру.
- Подключитесь к SQL Server с помощью SQL Server Management Studio, Azure Data Studio или sqlcmd, а затем выполните следующие команды Transact-SQL для определенных файлов базы данных, которые требуется уменьшить. Замените нужным размером:
USE tempdb; GO -- This command shrinks the primary data file DBCC SHRINKFILE (tempdev, ''); GO -- This command shrinks the log file, examine the last paragraph. DBCC SHRINKFILE (templog, ''); GOПреимущество DBCC SHRINKFILE заключается в том, что он может уменьшить размер файла до размера, который меньше исходного размера. Вы можете получить DBCC SHRINKFILE данные или файлы журналов. Невозможно сделать базу данных меньше размера model базы данных.
Ошибка 8909 при выполнении операций сжатия
Если tempdb используется и если вы пытаетесь сжать его с помощью DBCC SHRINKDATABASE команд или DBCC SHRINKFILE команд, вы можете получать сообщения, похожие на следующие, в зависимости от используемой версии SQL Server:
Server: Msg 8909, Level 16, State 1, Line 1 Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 0 (type Unknown), page ID (6:8040) contains an incorrect page ID in its page header. The PageId in the page header = (0:0).Эта ошибка не указывает на реальную коррупцию tempdb . Однако могут возникнуть другие причины повреждения физических данных, такие как ошибка 8909, и что эти причины включают проблемы подсистемы ввода-вывода. Таким образом, если ошибка возникает вне операций сжатия, следует выполнить дополнительные исследования.
Хотя сообщение 8909 возвращается приложению или пользователю, выполняющему операцию сжатия, операции сжатия не завершаются ошибкой.
См. также
- Рекомендации по настройке автоувеличения и автосжатия в SQL Server
- Файлы и файловые группы базы данных
- sys.databases (Transact-SQL)
- sys.database_files (Transact-SQL)
Далее
- Сжатие базы данных
- DBCC SHRINKDATABASE (Transact-SQL)
- DBCC SHRINKFILE (Transact-SQL)
- Удаление файлов данных или журнала из базы данных
- Сжатие файла
Инструкция: MS SQL shrink/сжатие базы TempDB без перезапуска SQL Server
Как бы много нам не было известно — мы всё равно всегда готовы изучать всё новое. В этой статье я покажу вам как выполнить сжатие временной базы данных TempDB без остановки работающего экземпляра MS SQL Server и при этом не зная ни количества файлов, ни их имена в БД TempDB.
Давайте разберемся что же это? И зачем так необходимо?
При работе 1С:Предприятия в клиент-серверном варианте интенсивно используются временные таблицы. Эти таблицы хранятся в системной базе данных TempDB. В процессе работы временная база данных может значительно увеличиваться в размерах и привести к заполнению всего диска.
Причиной увеличения размера базы данных TempDB, как правило, является невозможность автоматической очистки журнала транзакций и повторного использования свободного пространства из-за наличия активных транзакций, использующих объекты этой базы данных. Неограниченный рост может вызвать проблемы, связанные с сервером, вплоть до остановки MS SQL Server. В результате — недоступность баз. Что в свою очередь вызовет остановку в работе всех пользователей 1С использующих базы на этом сервере.
Так вот, чтобы не допустить ничего подобного и ужасного следует выполнить следующие основные действия по уменьшению размера базы данных TempDB до требуемой величины:
1. Перезапустить MS SQL Server. В этом случае размер базы данных TempDB будет установлен по умолчанию.
2. Сжать базу данных TempDB.
3. Уменьшить размер отдельных файлов.
4. Переместить базу данных TempDB на диск большего размера.
Решил я эту задачу путем уменьшения размера отдельных файлов.
Но для начала немного вводной информации. Временная база данных является системной базой данных, которая используется как для системных, так и для прикладных задач. Вот часть из них:
- Выполнение запросов с инструкциями ORDER BY, GROUP BY или операторами множеств (UNION, INTERSECT, EXCEPT).
- Создание временных таблиц и табличных переменных (например в 1С часто используют #t, #t1 и т.п.).
- Создание и обновление индексов.
- Использование табличных функций.
- Использование триггеров.
- Использование больших объектов (varchar(max), nvarchar(max), varbinary(max), text, ntext, image, xml) как параметров или переменных.
- Выполнение скриптов с использованием курсоров типа static или keyset.
- Уровень изоляции транзакций с версионностью (SNAPSHOT).
- Выполнение команды DBCC CHECK.
- Использование Database mail.
Также TempDB хранит много временной (кешированной) информации, которая используется для ускорения запросов.
Если место в TempDB уже освободилось, то для освобождения места на диске можно выполнить ее сжатие (shrink). Сделать это можно в SSMS студии:
Здесь вы можете убедиться, что сжатие tempdb не похоже на сжатие любой другой базы данных. Вероятней всего операция shrink не привела к уменьшению файла БД, значит необходимо очистить различные кэш сервера и повторить shrink.
Важно. Все перечисленные ниже операции удаляют все виды кеш, что влияет на производительность сервера, пока они не будут восстановлены SQL Server. Помимо этого все будет удалено из буферов и записано на диск. Это доп. нагрузка на подсистему ввода/вывода. После этого можно сжать файлы, что влияет на производительность чтения/записи. И наконец, все процессы, которые запрашивают данные, должны будут извлечь данные из подсистемы ввода/вывода в буферы. Это значительно влияет на производительность системы в целом. Не выполняйте операции без крайней необходимости!
Вначале хотелось бы напомнить про самый простой способ. Если не используется производственная среда (например, среда разработки), то лучше всего перезапустить службу SQL Server. Это вернет tempdb к его размеру по умолчанию. Но если нет возможности перезапуска службы? В таком случае необходимо сжать TempDB без остановки MS SQL. Для этого используются следующие команды T-SQL:
CHECKPOINT;
GO
DBCC DROPCLEANBUFFERS;
GOНа практике TempDB состоит из нескольких файлов. На различных серверах их название и кол-во отличаются см. Рис1 и Рис2.
Рисунок 1
Рисунок 2
Как же выполнить DBCC SHRINKFILE заранее, не зная кол-ва файлов и их имена в TempDB?
Проще всего обратится не к имени файла, а к его порядковому номеру в базе. Это демонстрирует листинг кода скрипта. Скрипт формирует текст T-SQL для выполнения из командной строки, в результате выполнения которого получаются команды вида:
USE [tempdb]
CHECKPOINT
DBCC DROPCLEANBUFFERS WITH NO_INFOMSGS
DBCC FREEPROCCACHE WITH NO_INFOMSGS
DBCC FREESYSTEMCACHE (‘ALL’) WITH NO_INFOMSGS
DBCC FREESESSIONCACHE WITH NO_INFOMSGS
DBCC SHRINKDATABASE ([tempdb]) WITH NO_INFOMSGS
DBCC SHRINKFILE (1,64) WITH NO_INFOMSGS
DBCC SHRINKFILE (2,64) WITH NO_INFOMSGS
DBCC SHRINKFILE (3,64) WITH NO_INFOMSGS
DBCC SHRINKFILE (4,64) WITH NO_INFOMSGS
DBCC SHRINKFILE (5,64) WITH NO_INFOMSGS
DBCC SHRINKFILE (6,64) WITH NO_INFOMSGS
DBCC SHRINKFILE (7,64) WITH NO_INFOMSGS
DBCC SHRINKFILE (8,64) WITH NO_INFOMSGS
DBCC SHRINKFILE (9,64) WITH NO_INFOMSGSОбратите внимание, что в тексте нет инструкции GO. GO не является ключевым словом T-SQL, это инструкция SQL Server Management Studio, позволяющая разделять отдельные конструкции в скрипте. Параметр WITH NO_INFOMSGS просто подавляет все информационные сообщения.
Листинг скрипта:
/* сжатие tempdb */ SET NOCOUNT ON; SET XACT_ABORT ON; SET ARITHABORT ON; SET QUOTED_IDENTIFIER ON; DECLARE @cmd VARCHAR(1000), @dbid int, @file_id int, @name nvarchar(128), @dbname sysname, @sizeTempDB int; SET @dbname='tempdb' SET @sizeTempDB = 64; --размер до которого будем сжимать IF OBJECT_ID('tempdb..#tmpdbFile') IS NOT NULL BEGIN DROP TABLE #tmpdbFile END --создаем и заполняем таблицу с именами логических файлов CREATE TABLE #tmpdbFile (id int IDENTITY(1,1), [dbid] int, [file_id] int, [name] sysname, [dbname] sysname, isdone bit); INSERT INTO #tmpdbFile ([dbid], [file_id], [name], [dbname], [isdone]) SELECT s_mf.database_id, s_mf.[file_id], s_mf.[name], d.name, 0 FROM sys.databases d Left JOIN sys.master_files s_mf ON d.database_id = s_mf.database_id WHERE db_name(s_mf.database_id) = @dbname --and (s_mf.size * 8.0 / 1024) >= @sizeTempDB ORDER BY s_mf.[file_id]; SELECT @cmd='' SELECT @cmd = @cmd + char(13) + char(10) + 'USE [' + @dbname + ']' SELECT @cmd = @cmd + char(13) + char(10) + '' --Создаем checkpoint, чтобы сбросить на диск кешированные индексы и буферы страницы данных SELECT @cmd = @cmd + char(13) + char(10) + 'CHECKPOINT' SELECT @cmd = @cmd + char(13) + char(10) + 'DBCC DROPCLEANBUFFERS WITH NO_INFOMSGS' --Чистим кеш хранимых процедур: SELECT @cmd = @cmd + char(13) + char(10) + 'DBCC FREEPROCCACHE WITH NO_INFOMSGS' --Очищаем остальные типы кешей: SELECT @cmd = @cmd + char(13) + char(10) + 'DBCC FREESYSTEMCACHE (''ALL'') WITH NO_INFOMSGS' --Чистим кеш сессий: SELECT @cmd = @cmd + char(13) + char(10) + 'DBCC FREESESSIONCACHE WITH NO_INFOMSGS' --Cжимаем базу tempdb: SELECT @cmd = @cmd + char(13) + char(10) + 'DBCC SHRINKDATABASE ([' + @dbname + ']) WITH NO_INFOMSGS' --Формируем команды на сжатие файлов IF (SELECT COUNT(id) FROM #tmpdbFile) > 0 BEGIN WHILE (SELECT COUNT(id) FROM #tmpdbFile WHERE isdone = 0) > 0 BEGIN SELECT TOP 1 @dbname = [dbname], @dbid = [dbid], @file_id = [file_id], @name = [name] FROM #tmpdbFile WHERE isdone = 0 SELECT @cmd = @cmd + char(13) + char(10) + 'DBCC SHRINKFILE (' + CONVERT(varchar(2),@file_id) + ',' + cast(@sizeTempDB as nvarchar) +') WITH NO_INFOMSGS' UPDATE #tmpdbFile SET isdone = 1 WHERE [dbid] = @dbid AND name = @name END END; --print (@cmd); exec (@cmd); IF OBJECT_ID('tempdb..#tmpdbFile') IS NOT NULL BEGIN DROP TABLE #tmpdbFile END GOВ большинстве случаев достаточно выполнить только DBCC FREEPROCCACHE, что позволит сжать базу данных TempDB (т.е. нет необходимости в выполнении DBCC DROPCLEANBUFFERS; DBCC FREESYSTEMCACHE (‘ALL’); DBCC FREESESSIONCACHE)
В результате выполнения скрипта мы получаем сжатый до возможного (но не меньше указанного нами) размера файлы базы TempDB:
Дисковое пространство освободилось, MS SQL Server продолжает работать, у пользователей не было прерывания в работе. И это главное! Пользователи работают, а администратору есть над чем задуматься — почему же так вырос TempDB. Какие действия (осознанные или неосознанные) привели к росту базы? Надо разбираться. Но это совсем другая задача, решение которой требует более детальной проработки.
- В командной строке перейдите в папку, в которой установлен SQL Server (замените и в следующем примере):