Як зменшити розмір файлу журналу SQL Server

Я не можу зрозуміти, як зменшити розмір файлу PDF у базах даних.

DBA каже, що я повинен використовувати backup log dbname with truncate_only

І хоча це виглядає так, що він виконаний правильно в SQL Query Analyzer, файл ldf все ще перевищує 2 Гб.

** Роз'яснення на основі деяких коментарів та деяких відповідей нижче. *** Конкретна база, про яку йдеться, - це база даних на моєму ноутбуці, і я використовую її лише для процесів розробки. Файл журналу зростає до того, що, як виглядає, викликає повний диск. Виробничий ризик не пов'язаний. Я розумію, що метод у запитанні, яке я запитував, і відповідь, яку я прийняв, є ризикованою у виробничому середовищі. *

sql-server log-files shrink

— Рон Туфін
джерело

напевно це повторюване питання?

— JamesRyan

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

— Рон Туффін

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

— JamesRyan

Відповідь дуже залежить від варіанту відновлення бази даних: простий чи повний?

— Річард

Дякую за уточнення, Рон. Оскільки це база даних розробників, ви захочете змінити модель відновлення на SIMPLE, а також зменшити файл журналу, інакше проблема не повториться.

— BradC

Відповіді:

О, жах! Будь ласка, перестаньте говорити людям, що вони повинні скорочувати свої файли журналів!

Якщо ви потрапили в цю ситуацію, то надзвичайно вірогідний один із таких випадків:

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

Відповідь на кожне із них:

Якщо (1), тоді переключіть базу даних у простий режим
If (2), тоді заплануйте регулярне резервне копіювання журналу
If (3), а потім виправте заплановані резервні копії журналу
If (4), тоді просто не робіть цього :) Натомість зробіть працювати меншими партіями.

Зауважте, що НІКОЛІ з них не вимагає використання (застарілого) "dbname журналу резервного копіювання з truncate_only"

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

DBCC SHRINKFILE ('log logical name', 2000)

Завжди вказуйте розумний кінцевий розмір, інакше він зменшиться до майже 0, і наступного разу, коли це буде потрібно, доведеться витратити час на його зростання.

— БредК
джерело

його занадто погано прийнята відповідь була так швидкою. Це одне з питань, які я використовую, щоб вилучити адміністраторів SQL під час інтерв'ю. Якщо вони повернуться із резервним копієм з truncate_only, що рахується як 2 удари від бити.

— Джим Б

Я згоден, що це абсолютно останнє, що потрібно зробити, зменшити файл. Правильне обслуговування утримує від цього необхідність. Але як тільки він великий, і ти хочеш, щоб він був меншим, ти повинен його скоротити. Однак при скороченні файлу краще скоротити файл якомога менше, а потім збільшити файл до потрібного розміру з кроком 8 Гб. Це оптимізує кількість VLF-файлів у файлі. Див - sqlskills.com/BLOGS/KIMBERLY/post / ... .

— Брайан Найт

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

— Джим Б

після виконання "резервного копіювання з truncate_only" вам слід видати наступну команду, щоб зменшити

dbcc SHRINKFILE (logfilename,shrink_tosize)

напр

dbcc SHRINKFILE (mydatabase_Log,512)

— Мані
джерело

Сценарій, який ви написали вище, позначатиме вміст журналу для повторного використання. Дотримуйтесь цього сценарію за допомогою:

USE <database>;

DBCC SHRINKFILE (<log logical file name>)

Це скоротить це для вас.

— Брайан Найт
джерело