Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 снова LOG  [new]
not name
Guest
Доброго времени суток!
DBA нету, своими силами: добавили данных в базу, после, при ребилде индексов (cкрипты https://ola.hallengren.com) - вырос лог, место окончилось. Для решения проблемы, после экспериментов, в итоге, использовали команды:
BACKUP LOG my_db_name TO DISK= 'NUL:'
DBCC SHRINKFILE ('my_db_name' , 0, TRUNCATEONLY)

Место освободилось (сервер sql 2012/ full recorevery mode)

Два вопроса к гуру сайта, чтобы закрыть гештальт:
1) это не сильно вредно для базы?
2) почему после запуска стандартного бэкапа лога (опять же через https://ola.hallengren.com, а именно:
sqlcmd -E -S $(ESCAPE_SQUOTE(SRVR)) -d master -Q "EXECUTE [dbo].[DatabaseBackup] @Databases = 'USER_DATABASES', @Directory = N'D:\Backup', @BackupType = 'LOG', @Verify = 'Y', @CleanupTime = NULL, @CheckSum = 'Y', @LogToTable = 'Y'" -b
) -, скрипт -
DBCC SHRINKFILE ('my_db_name' , 0, TRUNCATEONLY)
сжимается лог на ~15 - 30%, а после BACKUP LOG my_db_name TO DISK= 'NUL:' на 80 % (приблизительно, но явно в несколько раз эффективнее)?
14 дек 15, 23:59    [18560266]     Ответить | Цитировать Сообщить модератору
 Re: снова LOG  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37069
not name
это не сильно вредно для базы?
Базе бекап лога или его отсутствие не вредно для базы. Вредно оно для тех, кто потом попытается из этих отсутствующих бэкапов что-то восстановить.
not name
почему после запуска стандартного бэкапа лога
Стандартный бэкап -- это команда backup, а не вызов какой-то левой процедуры.
not name
скрипт -
DBCC SHRINKFILE ('my_db_name' , 0, TRUNCATEONLY)
сжимается лог на ~15 - 30%, а после BACKUP LOG my_db_name TO DISK= 'NUL:' на 80 % (приблизительно, но явно в несколько раз эффективнее)?
Каша, мед, г..но и гвозди. Команда shrinkfile (файл лога) усекает лог, т.е. изменяет физический размер файла. Команда backup log не изменяет физичекий размер файла, но освобождает место в файле лога, которое было занято забэкапленным логом. Так что у вас там все-таки происходит?

Сообщение было отредактировано: 15 дек 15, 00:26
15 дек 15, 00:26    [18560337]     Ответить | Цитировать Сообщить модератору
 Re: снова LOG  [new]
MKDT
Guest
SHRINKFILE считается вредным
1. Много ресурсов потребляет при выполнении
2. Появляется фрагментация
3. После обрезания база снова начинает забирать свое - увеличение размера файла это доп. нагрузка, что плохо.
15 дек 15, 00:26    [18560338]     Ответить | Цитировать Сообщить модератору
 Re: снова LOG  [new]
felix_ff
Member

Откуда: Moscow
Сообщений: 1456
not name,

потому что смысл команд backup log и dbcc shirinkfile несколько разный

в первом случае у вас идет создание резервной копии части журнала транзакций с последующим усечением журнала.
принцип усечения описан тут: тынц


а касаемо dbcc shrinkfile - она сжимает файл данных посредством реорганизации данных из файла в файлы данных той же группы в которой есть сам файл.

также при сжатии файла данных журнала транзакций используется параметр определяющий степень сжатия файла данных
более подробно можно прочитать в справке BOL по самой инструкции
15 дек 15, 00:27    [18560345]     Ответить | Цитировать Сообщить модератору
 Re: снова LOG  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37069
MKDT
SHRINKFILE считается вредным
1. Много ресурсов потребляет при выполнении
2. Появляется фрагментация
3. После обрезания база снова начинает забирать свое - увеличение размера файла это доп. нагрузка, что плохо.

Первые два пункта вообще не по делу, ибо
https://msdn.microsoft.com/ru-ru/library/ms189493(v=sql.120).aspx
TRUNCATEONLY
Освобождает все свободное пространство в конце файла операционной системе, но не перемещает страницы внутри файла. Файл данных сокращается только до последнего выделенного экстента.
15 дек 15, 00:28    [18560348]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить