Утверждение места на диске после удаления поля таблицы

Я использую sql 2008 r2, и БД работала хорошо и быстро в течение последних 3 лет, пока 3 месяца назад мы не добавили поле ntext в очень активную и использованную таблицу. Теперь мы начинаем выходить из серверного пространства из-за огромного расширяющегося размера этой таблицы.

Я читал, что сжимаясь, мы не хотим терять индексацию БД, потому что она работала быстро в течение многих лет, и мы не хотим, чтобы фрагментация продолжалась.

Мы решили удалить это поле и все его значения: есть ли способ удалить поле ntext и все его значения и освободить пространство без удаления индексации, без сжатия, без потери производительности дБ?

Я прилагаю вывод запроса размера базы данных, чтобы показать увеличение размера за последние 5 месяцев.

Мы решили удалить это поле и все его значения: есть ли способ удалить поле ntext и все его значения и освободить пространство без удаления индексации, без сжатия, без потери производительности дБ?

Я бы порекомендовал использовать (от 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') ;

По большей части я ссылаюсь на серию блогов Пола Рэндалла « Внутри движка хранения »

Единственный способ вернуть неиспользуемое пространство из файлов базы данных в SQLServer - это использовать команду DBCC SHRINK, которая перераспределяет данные на страницах файлов базы данных, освобождая их, и после удаления их из карты Global Allcation удаляет их из файла базы данных. Эта операция медленная, создает фрагментацию в базе данных и еще медленнее при работе со страницами больших объектов, поскольку они хранятся в виде связанных списков в файлах базы данных.

Поскольку вы отбрасываете столбец NTEXT, вам придется подождать, пока процесс очистки призрака удалит данные, прежде чем сжиматься.

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

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

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

Если это второе, то у вас может не быть такой большой проблемы, как вы думаете. Если я прав, ваша проблема в том, когда база данных должна расти, чтобы получить дополнительное пространство для новых данных. После удаления столбца все пространство, занимаемое этим столбцом, будет освобождено для добавления новых строк в таблицы в базе данных. Это означает, что пройдет больше времени, прежде чем ваша база данных будет расти. В то же время я бы получил дополнительное место для вашего диска с данными. Большинство баз данных со временем увеличиваются, и неплохо иметь здоровый запас свободного места на диске.

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