У мене залишилося лише 2 Гб, тому мені потрібно видалити цю таблицю історії. Ця таблиця тепер порожня, але дисковий простір бази даних не звільнений. А файл бази даних - 320 Гб.
Відповіді:
Якщо ви посилаєтесь на фактичне споживання файлів бази даних на об'єм, то SQL Server не обробляє це автоматично . Тільки тому, що ви видалили дані з бази даних, це не означає, що файли баз даних зменшаться, щоб відповідати лише існуючим даним.
Те, що ви б шукали, якщо вам доведеться набрати простір на гучності, було б скорочено конкретний файл DBCC SHRINKFILE. Варто відзначити декілька найкращих практик відповідно до цієї документації:
Кращі практики
Враховуйте наступну інформацію, коли ви плануєте зменшити файл:
Операція скорочення є найбільш ефективною після операції, яка створює багато невикористаного простору, наприклад, обрізання таблиці або операція з випаданням таблиці.
Більшість баз даних потребують вільного місця для регулярних щоденних операцій. Якщо ви скорочуєте базу даних неодноразово і помічаєте, що розмір бази даних знову збільшується, це вказує на те, що простір, який було скорочено, потрібно для регулярних операцій. У цих випадках багаторазове скорочення бази даних є марною операцією.
Операція скорочення не зберігає стан фрагментації індексів у базі даних і, як правило, збільшує фрагментацію до певної міри. Це ще одна причина не повторно скорочувати базу даних.
Стискайте кілька файлів у одній базі даних послідовно, а не одночасно. Суперечка в системних таблицях може спричинити затримки через блокування.
Також зверніть увагу:
DBCC SHRINKFILEоперації можна зупинити в будь-якій точці процесу, а будь-яка завершена робота зберігається.
Напевно є кілька речей, які слід враховувати, роблячи це, і я рекомендую вам поглянути на повідомлення в блозі Пола Рандала про те, що відбувається, коли ви робите цю операцію.
Першим кроком, безумовно, було б перевірити, скільки місця та вільного місця ви насправді можете замінити, а також використаний простір у файлі (файлах):
use AdventureWorks2012;
go
;with db_file_cte as
(
select
name,
type_desc,
physical_name,
size_mb =
convert(decimal(11, 2), size * 8.0 / 1024),
space_used_mb =
convert(decimal(11, 2), fileproperty(name, 'spaceused') * 8.0 / 1024)
from sys.database_files
)
select
name,
type_desc,
physical_name,
size_mb,
space_used_mb,
space_used_percent =
case size_mb
when 0 then 0
else convert(decimal(5, 2), space_used_mb / size_mb * 100)
end
from db_file_cte;Це нормальна поведінка, коли ви врізаєте таблицю, яка передбачає видалення понад 128 розширень, як за «Книги в Інтернеті»
Коли ви скидаєте або відновлюєте великі індекси, або відміняєте або обрізаєте великі таблиці, Механізм баз даних відкладає фактичні розстановки сторінок та пов'язані з ними блокування, поки не відбудеться транзакція. Ця реалізація підтримує як автокомісію, так і явні транзакції в середовищі багатокористувача, і застосовується до великих таблиць та індексів, які використовують більше 128 розширень.
Механізм баз даних уникає блоків розподілу, необхідних для викидання великих об'єктів, розділяючи процес на дві окремі фази: логічну та фізичну.
На логічній фазі існуючі одиниці розподілу, використовувані таблицею або індексом, позначаються для розстановки та блокуються до завершення транзакції. При зниженому кластерному індексі рядки даних копіюються та переміщуються до нових одиниць розподілу, створених для зберігання, або відновленим кластерним індексом, або купою. (У разі відновлення індексу рядки даних також сортуються.) Коли відбувається відкат, потрібно повернути лише цю логічну фазу.
Фізична фаза настає після здійснення транзакції. Одиниці розподілу, позначені для розселення, фізично скидаються партіями. Ці краплі обробляються всередині коротких транзакцій, які відбуваються на задньому плані, і не потребують великої кількості замків.
Оскільки фізична фаза настає після здійснення транзакції, місце для зберігання таблиці або індексу все ще може бути недоступним. Якщо цей простір необхідний для розростання бази даних до завершення фізичної фази, двигун бази даних намагається відновити простір з одиниць розподілу, позначених для угоди. Щоб знайти простір, який зараз використовуються цими розподільними одиницями, скористайтеся поданням каталогу sys.allocation_units.
Відкладені операції падіння не звільняють виділений простір негайно, і вони вносять додаткові накладні витрати в двигун бази даних. Тому таблиці та індекси, що використовують 128 або менших розширень, скидаються, усічуються та відновлюються так само, як і в SQL Server 2000. Це означає, що як логічна, так і фізична фази відбуваються до здійснення транзакції.
Вам доведеться почекати, і, звичайно, вам доведеться вручну зменшити файл, щоб повернути простір, також варто згадати, що скорочення викликає логічну фрагментацію, і його слід уникати, якщо ваша потреба не є серйозною. Вам доведеться дещо збалансувати між скороченням і фрагментацією. Краще запитати себе, чи фактично зменшення може вирішити питання, враховуючи сценарій, коли дані знову зростуть.
Використовуйте нижче запит, щоб перевірити, скільки вільного місця в базі даних
SELECT name ,size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0 AS AvailableSpaceInMB
FROM sys.database_files;На додаток до відповідей Тома і Шенкі, якщо ваша база даних містить дані LOB / BLOB, DBCC SHRINKFILE може не працювати. Якщо це так, то у вас є два варіанти, залежно від того, ви можете брати базу даних в автономному режимі чи ні. Якщо ви можете взяти базу даних в автономному режимі, вам потрібно буде скопіювати дані та скопіювати їх назад, щоб видалити порожній простір. Ви можете зробити це одним із наступних дій:
Якщо ви не можете взяти базу даних в автономному режимі, ви можете використовувати команду DBCC SHRINKFILE за допомогою параметра EMPTYFILE .
Деталі щодо офлайнової копії: http://support.microsoft.com/kb/324432/en-us
Поточна інформація для параметра EMPTYFILE http://msdn.microsoft.com/en-us/library/ms189493(v=sql.105).aspx