Вручну встановити розмір файлу журналу після зменшення SQL Server 2008 R2

Я стаю дещо мимовільним DBA на роботі в цей момент і мені дуже потрібна допомога в чомусь.

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

Моя проблема полягає в тому, що я не хочу, щоб файл журналу скорочувався ні до чого, і перший ранок понеділка постійно рости. Я маю приблизну оцінку щодо того, яким повинен бути файл (приблизно 20% бази даних), і я хотів би встановити це з початку роботи, щоб забезпечити якомога більше суміжного простору. Це лише випадок зміни "Початкового розміру" у Властивості бази даних -> Файли? Я б також здогадався, що для того, щоб це відбулося, база даних повинна бути в автономному режимі?

Спасибі заздалегідь

Просто скорочуйтеся до того, що, на вашу думку, є оптимальним розміром. Не використовуйте інтерфейс користувача, просто зробіть це - скажімо, 200 Мб - це ваш оптимальний розмір:

USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);

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

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

Управління файлами може бути повністю онлайн-операцією. У вас є два шляхи, залежно від потреби зберегти інформацію журналу для цілей відновлення:

Точне відновлення часу не потрібне

1. Перетворити базу даних на SIMPLEвідновлення. Виконайте контрольну точку для запису транзакцій на диск.
2. Зрівняти колоду.
3. Змініть розмір журналу до відповідного розміру.

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

Здійснено за допомогою:

ALTER DATABASE [foo] 
SET RECOVERY SIMPLE;

CHECKPOINT;

DBCC SHRINKFILE (foo_log,0);

ALTER DATABASE [foo]
MODIFY FILE (NAME=foo_log,SIZE=8000MB,MAXSIZE=UNLIMITED,FILEGROWTH=1000MB);

--Optional if you want the database in full recovery mode 
--for point in time recovery going forward
ALTER DATABASE [foo] 
SET RECOVERY FULL;

Потрібно вказати час відновлення

Найбільшим підключенням буде те, що ви не можете зменшити свій журнальний файл минулого свого активного сегменту VLF. Щоб побачити це, ви можете використовувати DBCC LOGINFOв контексті бази даних. Будь-який сегмент зі статусом = 2 активний. Щоб очистити активні сегменти, вам потрібно буде виконати резервну копію журналу транзакцій, коли в цьому сегменті зараз немає активних транзакцій. Ваші кроки:

1. Запустіть резервну копію журналу транзакцій.
2. Стисніть файл. (Ідеально вирівнюйте, але якщо ваша база даних активна, це буде важко зробити).
3. Повторюйте кроки 1 і 2, поки ваш журнал не набере відповідного розміру, в ідеалі як можна менше.
4. Змініть розмір журналу до відповідного розміру.

Здійснено за допомогою:

BACKUP LOG [foo] TO DISK='<Location of t-log backup>';

DBCC SHRINKFILE (foo_log,0);

--Repeat the above until your log file is small "enough"

ALTER DATABASE [foo]
MODIFY FILE (NAME=foo_log,SIZE=8000MB,MAXSIZE=UNLIMITED,FILEGROWTH=1000MB);

Деякі додаткові ресурси, щоб зрозуміти, що тут відбувається:

• Моделі відновлення SQL Server

• Рекомендації Кімберлі Тріппа

• Контрольні пункти бази даних

Насправді ні, база даних не повинна бути в автономному режимі, щоб зменшити журнал. І я скажу, що це, мабуть, один із небагатьох випадків, коли скорочення колоди - це гарна ідея. Ви можете встановити початковий розмір, але було б простіше зробити зменшення і сказати, щоб він зменшився до певного розміру.

USE [DBName]
GO
DBCC SHRINKFILE (N'LogName' , SizeInMg)
GO

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

На додаток до відповіді Аарона про простий режим , ви могли запланувати 2 (або більше) диференціальних резервних копій на день, таким чином зменшуючи вікно втрати даних вашої роботи з базою даних, зберігаючи простий режим.