Автоматический шринк журнала транзакций и перевод базы в простой режим восстановления.
Предыстория
На SQL сервере развернуто порядка 100 тестовых баз. Разворачивают в основном рабочие базы с режимом восстановления "Полный" и периодически забывая переводить в "Простую". В связи с чем на сервере стали занимать много мест журналы транзакций. Вначале шринк журнала проходил руками, но потом это надоело и я решил это немного автоматизировать. Написал скрипт, который, пробегаясь по всем базам, кроме системных, переводит каждую в "Простой" режим восстановления и делает шринк журнала. Скрипт повесил на задание, для автоматического выполнения по расписанию.
----------------------------------------------------------
-- СЛУЖЕБНЫЕ ПЕРЕМЕННЫЕ
declare @db_name nvarchar(100) --имя базы данных
declare cursor_size_srv cursor for
--выбираем все базы кроме системных
SELECT name AS DBName
FROM sys.databases
where name not in ('master','msdb','model','tempdb')
ORDER BY Name;
-- Цикл по всем базам, попавшим в выборку
OPEN cursor_size_srv
FETCH NEXT FROM cursor_size_srv INTO @db_name
WHILE (@@FETCH_STATUS=0)
BEGIN
-- База данных из цикла
exec ('declare @logname nvarchar(100)
USE [' + @db_name + ']
SELECT @logname = name FROM sys.database_files where type = 1
ALTER DATABASE ' + @db_name + ' SET RECOVERY SIMPLE
DBCC SHRINKFILE (@logname , 10, TRUNCATEONLY)')
-- Следующая база данных
FETCH NEXT FROM cursor_size_srv INTO @db_name
END
CLOSE cursor_size_srv
DEALLOCATE cursor_size_srv
----------------------------------------------------------
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Будет забавно, когда потеряете часть данных, а ваша модель восстановления не позволит восстановить их.
Ну и куда же без курсора и выполнения каждой команды сразу после её генерации… Сгенерировать 1(один) скрипт и его исполнить намного сложнее…
(2)Журнал режется на тестовых базах, а там не так страшно потерять данные
(3)Согласен, можно сгенерировать один скрипт и разом его выполнить
Автор, конечно, молодец, что выложил свой скрипт.
Но позволю себе также показать и свои скрипты на эту тему:
(с фильтром по имени базы и отправкой электронного сообщения)
(8)Ну вот, оказывается был готовый вариант. Появился бы он раньше…
А вашу статью про индексы я уже применил к своим базам
«Разворачивают в основном рабочие базы с режимом восстановления Полный и периодически забывая переводить в Простую» — ну глупость же, расплата за нее — падение производительности рабочей базы в самый неподходящий момент (по закону бутерброда). Если не знаете «зачем нужен бэкап журнала?» и/или не делаете бэкап журнала, то не включайте «режим восстановления»=Полный, оно вам что мертвому массаж, вам нужен «режим восстановления»=простой.
(10) у нас тестовые базы работают на отдельном сервере и на производительность рабочей базы ни как не влияют