SQL Server, как обойти заполнение журнала транзакций при обновлении столбца до типа int

18

У меня называется таблица SQL Server 2005, BRITTNEY_SPEARS_MARRIAGESи она имеет следующие столбцы:

MarrigeId tinyint, 
HusbandName varchar(500),
MarrigeLength int

Теперь у меня есть другой стол BRITTNEY_SPEARS_MARRIAGE_STORIES

StoryId int, 
MarriageId tinyint, 
StoryText nvarchar(max)

Проблема в том, что мы хотим обновить MarrigeIdстолбец intиз a tinyint. Мы просто чувствуем, что у Бритни будет много браков, прежде чем все будет сказано и сделано.

Теперь в BRITTNEY_SPEARS_MARRIAGE_STORIESтаблице 18 миллионов строк (эй, у девушки есть некоторые проблемы), поэтому, когда мы собираемся сделать обновление, журнал транзакций заполняется, и наша коробка SQL Server умирает.

Как мы можем обойти это?

Можно ли в любом случае сказать: «Эй, SQL Server, я собираюсь обновить этот столбец и увеличить его. Поверьте мне на этом SQL Server. Пожалуйста, не заполняйте журнал транзакций, пока вы пытаетесь все проверить?»

sql-server sql-server-2005 transaction-log

— codingguy3000
источник

7

Нет никакого способа сказать SQL Server не использовать журнал транзакций.

Что вы можете сделать, так это установить для модели восстановления базы данных значение SIMPLE, которое будет перезаписывать старые записи журнала по мере необходимости. Однако вы не должны делать это на своем производственном сервере, потому что вы не сможете выполнять определенные типы восстановлений, например, восстановление на определенный момент времени.

В качестве альтернативы вы можете установить размер файла журнала транзакций больше - в качестве ненаучного практического правила я бы позаботился о том, чтобы либо A) в вашем журнале транзакций было как минимум примерно в 1,5 раза больше свободного места, чем размер таблицы или B) что ваш журнал транзакций может автоматически перерасти на диск, на котором по крайней мере примерно столько свободного места на диске.

Вы можете освободить место в журнале транзакций, сделав резервную копию журнала. Если вас не интересует содержимое журнала, выбросьте файл. Ярлык для этого есть BACKUP LOG <Your Database Name> TO DISK = 'NUL:'. Опять же, не делайте этого на рабочем сервере, если вы абсолютно не уверены, что понимаете последствия.

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

— Дейв Маркл
источник

5

Бросьте любые внешние ключи
Создать новые таблицы с intвместоtinyint
Переместите строки на 1000 партий (вставьте их в новую таблицу, удалите из старой)
Оставьте старые таблицы
Переименуйте новые таблицы в старые имена, используя sp_rename
Воссоздать внешние ключи

pS Если у вас большой журнал транзакций ... проверьте модель восстановления. Если у вас нет модели восстановления simple, сколько времени прошло с момента последнего резервного копирования журнала?

— Andomar
источник

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

— HLGEM

@HLGEM: Вы правы, я только что прочитал статью Пола Рэндала на эту тему. Впрочем, неожиданно, если бы вы делали только полные резервные копии, ваш журнал продолжал бы расти.

— Andomar