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

У мене називається таблиця 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а tinyint. Ми просто відчуваємо, що у Брітні буде багато шлюбів, перш ніж все буде сказано і зроблено.

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

Як ми можемо обійти це?

Чи варто сказати "Ей, SQL Server. Я збираюся оновити цю колонку та збільшити її. Довірте мені цей SQL Server. Будь ласка, не заповнюйте журнал транзакцій, коли ви намагаєтесь перевірити все?"

Немає можливості сказати SQL Server не використовувати журнал транзакцій.

Що ви можете зробити, це встановити модель відновлення бази даних на SIMPLE, яка замінить старі записи журналу в міру необхідності місця. Однак ви не повинні робити це на своєму виробничому сервері, оскільки ви не зможете робити певні типи відновлення, наприклад, відновлення часу.

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

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

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

• Відкиньте будь-які сторонні ключі
• Створюйте нові таблиці за допомогою, intа неtinyint
• Переміщення рядків на партію 1000 (вставити їх у нову таблицю, видалити зі старої)
• Відкиньте старі таблиці
• Перейменуйте нові таблиці за допомогою старих імен, використовуючи sp_rename
• Відтворити іноземні ключі

pS Якщо журнал транзакцій великий ... перевірте модель відновлення. Якщо вашої моделі відновлення немає simple, скільки часу минуло з моменту останнього резервного копіювання журналу?