Визначення місця на диску після видалення поля таблиці


16

Я запускаю sql 2008 r2, і db працював нормально і швидко протягом останніх 3 років, поки близько 3 місяців тому ми додали поле ntext у дуже активну та використану таблицю. Тепер ми починаємо виходити з серверного простору через величезний розмір цієї таблиці.

Я читав, що скорочуючись, ми не хочемо втрачати індексацію db, оскільки вона працювала швидко роками, і ми не хочемо отримувати роздробленість.

Ми вирішили видалити це поле та всі його значення: Чи є спосіб видалити поле ntext та всі його значення та звільнити простір, не видаляючи індексацію, не зменшуючи, не втрачаючи продуктивність db?

Я додаю вихідний запит розміру db, щоб показати вам розширення розміру за останні 5 місяців.

введіть тут опис зображення

Відповіді:


12

Ми вирішили видалити це поле та всі його значення: Чи є спосіб видалити поле ntext та всі його значення та звільнити простір, не видаляючи індексацію, не зменшуючи, не втрачаючи продуктивність db?

Я б рекомендував використовувати (від BOL:)

DBCC CLEANTABLE
(
    { database_name | database_id | 0 }
    , { table_name | table_id | view_name | view_id }
    [ , batch_size ]
)
[ WITH NO_INFOMSGS ]

DBCC CLEANTABLE повертає простір після скидання стовпця змінної довжини. Стовпець змінної довжини може бути одним із таких типів даних: varchar, nvarchar, varchar (max), nvarchar (max), varbinary, varbinary (max), текст, ntext, image, sql_variant та xml. Команда не повертає пробіл після того, як стовпець стовпця фіксованої довжини не вдається.

!! ОБЕРЕЖНО !! ( використовуйте ретельний розмір партії - доцільно використовувати цей параметр, якщо ваша таблиця масивна) :

DBCC CLEANTABLE працює як одна або кілька транзакцій. Якщо розмір партії не вказаний, команда обробляє всю таблицю за одну транзакцію, а таблиця під час операції виключно блокується . Для деяких великих таблиць довжина однієї транзакції та необхідний простір журналу можуть бути занадто великими. Якщо вказаний розмір партії, команда виконує серію транзакцій, кожна з яких включає вказану кількість рядків. DBCC CLEANTABLE не можна запустити як транзакцію всередині іншої транзакції.

Ця операція повністю зареєстрована.

Просте докор докаже, що DBCC CLEANTABLEце краще, ніж SHRINKING (і не хвилюйтесь про фрагментацію :-)

-- clean up
drop table dbo.Test

-- create test table with ntext column that we will drop later
create table dbo.Test (
    col1 int
    ,col2 char(25)
    ,col3 ntext
    );

-- insert  1000 rows of test data
declare @cnt int;

set @cnt = 0;

while @cnt < 1000
begin
    select @cnt = @cnt + 1;

    insert dbo.Test (
        col1
        ,col2
        ,col3
        )
    values (
        @cnt
        ,'This is a test row # ' + CAST(@cnt as varchar(10)) + 'A'
        ,REPLICATE('KIN', ROUND(RAND() * @cnt, 0))
        );
end

введіть тут опис зображення

введіть тут опис зображення

--drop the ntext column
ALTER TABLE dbo.Test DROP COLUMN col3 ;

введіть тут опис зображення

введіть тут опис зображення

--reclaim the space from the table
-- Note that my table is only having 1000 records, so I have not used a batch size
-- YMMV .. so find a maintenance window and you an appropriate batch size 
-- TEST TEST and TEST before implementing in PROD.. so you know the outcome !!
DBCC CLEANTABLE('tempdb', 'dbo.Test') ;

введіть тут опис зображення

введіть тут опис зображення


Після того як ви виконали команду DBCC CLEANTABLE, вам потрібно повторно побудувати кластерний індекс у випадку, якщо таблиця має такий, щоб повернути простір. ALTER INDEX IndexName ON YourTable REBUILD;
Містер ТА

6

Здебільшого я згадую серію блогу Пола Рендалла " Всередині блоку двигуна зберігання ".

Єдиний спосіб повернути невикористаний простір з файлів баз даних у SQLServer - це використання команди DBCC SHRINK, яка перерозподіляє дані у вільних сторінках файлів баз даних, а після вилучення їх з глобальної карти загального виведення видаляє їх з файлу бази даних. Ця операція повільна, створює фрагментацію всередині бази даних і ще повільніше при роботі зі сторінками LOB, оскільки вони зберігаються як пов'язані списки у файлах бази даних.

Оскільки ви скидаєте стовпець NTEXT, вам доведеться почекати, поки процес очищення привидів не впустить дані, перш ніж скорочуватися.

Тепер маючи багато вільного простору у файлах баз даних, ви справді не принесите шкоди, якщо у вас є дисковий простір, резервне копіювання забезпечить вільний простір у файлах.

Якщо ви абсолютно хочете зменшити файли, ви можете створити нову групу файлів з базою даних і зробити її за замовчуванням, а потім перемістити таблиці в нову файлову групу, але це може зайняти час і спричинити час простою. Я використовував техніку, яку тут пояснив Боб Пусатері з хорошими результатами.


чи зменшить простір процес прибирання привидів, або також буде потрібно зменшення?
користувач1021182

вам завжди доведеться скорочуватися, процес очищення видаляє лише виділені сторінки, але не видаляє їх з файлів бази даних
Spörri

1
@ Spörri Since you are dropping the NTEXT column you will have to wait for the ghost cleanup process to drop the data before shrinking.Будь ласка, дивіться мою відповідь . Ви можете використовувати DBCC CLEANTABLEдля звільнення місця.
Кін Шах

4

Ви хочете зменшити файли баз даних через те, що вам потрібний простір для інших баз даних / файлів БД, що не належать до цього файлу, або через те, що у вас виникають проблеми з нестачею місця в цій базі даних?

Якщо це друге, то, можливо, у вас не буде такої великої проблеми, як ви думаєте. Якщо я маю рацію, ваша проблема полягає в тому, коли база даних повинна зростати, щоб отримати додатковий простір для нових даних. Після того, як ви вилучите стовпець, весь простір, зайнятий цим стовпцем, буде звільнений, щоб нові рядки були додані до таблиць у базі даних. Це означає, що до зростання вашої бази даних буде довше. У той же час я отримаю трохи додаткового місця для вашого накопичувача даних. Більшість баз даних з часом зростає, і приємно мати здоровий запас вільного місця на диску.


у нас на дисковому просторі залишилось лише 10 Гб, і він також закінчиться через кілька днів. ми видалили все, що ми могли вилучити з сервера, використали очищення та зупинили оновлення Windows, а також видалили всі та очистили winxs, тепер ми повинні зменшити розмір файлу db
user1021182

Знову ж таки, пам’ятайте, що як тільки ви видалите додатковий стовпець, зростання БД припиниться на деякий час, поки ви заповните новий простір, який ви звільнили. Якщо ваша БД все ще зростає після цього моменту, вам буде абсолютно необхідний додатковий дисковий простір для вашої бази даних. Можливо, додайте новий диск на свій сервер.
Кеннет Фішер

0

Я б створив дзеркальну таблицю без порушника, скопіював би всі дані в цю таблицю, видалив оригінал та перейменував би дзеркальну таблицю.


у цьому випадку всі індекси також потрібно буде підготувати
user1021182

так, будь-які індекси, що впливають на таблицю, потрібно буде скасувати та відтворити також .... також стосується інших об'єктів, на які посилається таблиця, наприклад: тригери
ardochhigh
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.