Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 И вновь продолжается бой! (Опять про усечение лога...)  [new]
emperor_bms
Member

Откуда:
Сообщений: 122
Сразу просьба больно не бить! Прочитал штук 30 веток на эту тему - а ответа на вопрос так и не нашел...
Все как у всех, лог вырос большим-пребольшим, 16 гигов. После бэкапа БД и лога, в нем 99% неиспользуемого места. Recovery model - Full. В момент поднятия БД из бекапа, Log Initial Size ставился 100Мб с приростом по 10%. После того как выполнилась команда dbcc indexdefrag лог вырос и initial size почему-то стал 17 218Мб.

select @@version
----------------------------
Microsoft SQL Server 2008 (RTM) - 10.0.1600.22 (X64) Jul 9 2008 14:17:44 Copyright (c) 1988-2008 Microsoft Corporation Standard Edition (64-bit) on Windows NT 6.0 <X64> (Build 6001: Service Pack 1)

dbcc sqlperf(logspace)
----------------------------
No active open transactions.

dbcc sqlperf(logspace)
----------------------------
Database Name Log Size (MB) Log Space Used (%) Status
TestDB 16141,37 0,8412065 0

dbcc shrinkfile ('ESPAR_ODASTAT_log',100, truncateonly)
---------------------------
DbId FileId CurrentSize MinimumSize UsedPages EstimatedPages
12 2 2066096 128 2066096 128
B "Messages":
Cannot shrink log file 2 (ESPAR_ODASTAT_log) because the logical log file located at the end of the file is in use.

dbcc loginfo ('testdb')
---------------------------
FileId FileSize StartOffset FSeqNo Status Parity CreateLSN
2 102563840 16822894592 53353 2 64 53348000018350100039

Это последняя строка, в ней статус=2 (еще статус 2 в начале, а потом сплошные нули), он значит что в последный виртуальный лог-файл активен. Из-за этого лог не шринкуется.

Вопросов несколько:
1. Как сделать последний виртуальный лог-файл неактивным?
2. Почему dbcc indexdefrag создает такой огромный лог?
3. Почему изменился initial size? Я думал что это величина неизменна. Задал ее в начале, лог растет а величина не меняется. Не так разве?
31 июл 09, 18:57    [7486402]     Ответить | Цитировать Сообщить модератору
 Re: И вновь продолжается бой! (Опять про усечение лога...)  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36808
1. Вопроса не понял.
2. Потому что он перелопачивает всю-всю базу, вот она в лог и лезет.
3. Потому что вы сделали автоматический прирост. Убирите его и Initial Size станет величиной постоянной. Правда, когда файл закончится, все будут отфутболены с соответствующей ошибкой.
31 июл 09, 19:04    [7486428]     Ответить | Цитировать Сообщить модератору
 Re: И вновь продолжается бой! (Опять про усечение лога...)  [new]
LenaV
Member

Откуда: USA
Сообщений: 6750
1. сделайте BACKUP LOG, DBCC SHRINKFILE пару раз подряд и лог ужмется.
1 авг 09, 00:26    [7487073]     Ответить | Цитировать Сообщить модератору
 Re: И вновь продолжается бой! (Опять про усечение лога...)  [new]
Last1Cmen
Member

Откуда:
Сообщений: 30210
перед такой массовой работой с базой рекомендуют преключать режим протоколирования в простой а затем обратно
1 авг 09, 01:44    [7487176]     Ответить | Цитировать Сообщить модератору
 Re: И вновь продолжается бой! (Опять про усечение лога...)  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36808
Last1Cmen
перед такой массовой работой с базой рекомендуют преключать режим протоколирования в простой а затем обратно
Кто это рекомендует такую, ммм, бестолковость?
1 авг 09, 01:59    [7487186]     Ответить | Цитировать Сообщить модератору
 Re: И вновь продолжается бой! (Опять про усечение лога...)  [new]
Last1Cmen
Member

Откуда:
Сообщений: 30210
Гавриленко Сергей Алексеевич, возможно я не так истолковал мануал к 2005 за ноябрь 2008... т.к. там в стратегии резервного копирования написано дословно следующее

автор
Полная модель восстановления может быть дополнена путем переключения на модель с неполным протоколированием перед выполнением массовых операций.



Электронная документация по SQL Server 2005 (Ноябрь 2008 г.)  
 
Введение в стратегию резервного копирования и восстановления в SQL Server  

[url=онлайн]ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.ru/udb9/html/eb41a031-ad9d-445e-8aad-d41c62c75aa1.htm[/url]
1 авг 09, 11:30    [7487312]     Ответить | Цитировать Сообщить модератору
 Re: И вновь продолжается бой! (Опять про усечение лога...)  [new]
Last1Cmen
Member

Откуда:
Сообщений: 30210
вот так
1 авг 09, 11:30    [7487315]     Ответить | Цитировать Сообщить модератору
 Re: И вновь продолжается бой! (Опять про усечение лога...)  [new]
Нектотам
Guest
Last1Cmen
вот так

Не так. Модель с неполным протоколированием - это bulk-logged, а simple - это "простая".
Отключение логов в самый ответственный момент - не лучшая идея, конечно же. :)
1 авг 09, 11:41    [7487322]     Ответить | Цитировать Сообщить модератору
 Re: И вновь продолжается бой! (Опять про усечение лога...)  [new]
Last1Cmen
Member

Откуда:
Сообщений: 30210
:) ну за саму идею ничего не скажу (насчет simple ошибочка вышла признаю) но сам перевод в эту модель перед "оцветсвенным" моментом а не во время конечно... можно в план обслуживания вставить
1 авг 09, 11:44    [7487327]     Ответить | Цитировать Сообщить модератору
 Re: И вновь продолжается бой! (Опять про усечение лога...)  [new]
Нектотам
Guest
Last1Cmen,

Ну а для дефрагментации индекса разницы между full и bulk-logged не должно быть.
Не так уж много операций, которые минимально протоколируются в bulk-logged. Полное перестроение индекса (ALTER INDEX REBUILD) к таким относится, а дефрагментация - нет. Нафига тогда переключаться?
Подробности тут
1 авг 09, 11:54    [7487339]     Ответить | Цитировать Сообщить модератору
 Re: И вновь продолжается бой! (Опять про усечение лога...)  [new]
Last1Cmen
Member

Откуда:
Сообщений: 30210
Нектотам спасибо за объяснение

кстати а что означает

автор
Инструкция DBCC DBREINDEX является устаревшей, поэтому следует избегать ее использования в новых приложениях.


как же так - делать теперь не реиндексацию а перестроение индексов ? тогда и в неполное протоколирование будет увеличивать лог конкретно

пысы... я чего спрашиваю... у меня после 4х дней ночного обслуживания (с реиндексом и бекапом но без перестроения и шринка) в режиме полного протоколирования базы сами размером в 40 гб "скушали" логами все 260 гиг диска логов и соответсвенно "положили" сам скл

пока урезал их до минимума и переключился в режим simple... вот и думаю как бы скрестить полное с тем чтоб не так лог рос
1 авг 09, 12:19    [7487351]     Ответить | Цитировать Сообщить модератору
 Re: И вновь продолжается бой! (Опять про усечение лога...)  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36808
Last1Cmen
Нектотам спасибо за объяснение

кстати а что означает

автор
Инструкция DBCC DBREINDEX является устаревшей, поэтому следует избегать ее использования в новых приложениях.


как же так - делать теперь не реиндексацию а перестроение индексов ? тогда и в неполное протоколирование будет увеличивать лог конкретно

пысы... я чего спрашиваю... у меня после 4х дней ночного обслуживания (с реиндексом и бекапом но без перестроения и шринка) в режиме полного протоколирования базы сами размером в 40 гб "скушали" логами все 260 гиг диска логов и соответсвенно "положили" сам скл

пока урезал их до минимума и переключился в режим simple... вот и думаю как бы скрестить полное с тем чтоб не так лог рос
Наверное, там же и написано, какой инструкцией следует пользоваться вместо DBREINDEX.
1 авг 09, 14:11    [7487427]     Ответить | Цитировать Сообщить модератору
 Re: И вновь продолжается бой! (Опять про усечение лога...)  [new]
Нектотам
Guest
Last1Cmen
Нектотам спасибо за объяснение

кстати а что означает

автор
Инструкция DBCC DBREINDEX является устаревшей, поэтому следует избегать ее использования в новых приложениях.


как же так - делать теперь не реиндексацию а перестроение индексов ? тогда и в неполное протоколирование будет увеличивать лог конкретно

пысы... я чего спрашиваю... у меня после 4х дней ночного обслуживания (с реиндексом и бекапом но без перестроения и шринка) в режиме полного протоколирования базы сами размером в 40 гб "скушали" логами все 260 гиг диска логов и соответсвенно "положили" сам скл

пока урезал их до минимума и переключился в режим simple... вот и думаю как бы скрестить полное с тем чтоб не так лог рос

А бэкапы-то какие? Полные или только бэкапы логов? Если бэкапы логов делались, то может транзакция какая висит или с репликацией проблемы?
1 авг 09, 18:32    [7487695]     Ответить | Цитировать Сообщить модератору
 Re: И вновь продолжается бой! (Опять про усечение лога...)  [new]
Last1Cmen
Member

Откуда:
Сообщений: 30210
Нектотам, полные... транзакций нет точно т.к. в то время в базе не работают а сам бекап настроен в планировщике обслуживния так что я сомневюсь что был запущен до окончания работы предидущих процедур (по истории вроде всё последовательно)

если REBUILD использовать то очень долго (порядка 3х часов)
2 авг 09, 00:55    [7488108]     Ответить | Цитировать Сообщить модератору
 Re: И вновь продолжается бой! (Опять про усечение лога...)  [new]
emperor_bms
Member

Откуда:
Сообщений: 122
Гавриленко Сергей Алексеевич
1. Вопроса не понял.
2. Потому что он перелопачивает всю-всю базу, вот она в лог и лезет.
3. Потому что вы сделали автоматический прирост. Убирите его и Initial Size станет величиной постоянной. Правда, когда файл закончится, все будут отфутболены с соответствующей ошибкой.

1. Странно что вопрос непонятен. Своими словами: не секрет, что физический файл лога SQL "разбивает" на энное количество виртуальных. Они могут быть активными или нет. При этом процедура "сжатия" лога "обрезает" неактивные виртуальные файлы с конца. Поэтому если последний вирт. файл помечен как активный - никакого сжатия не произойдет, о чем скуль честно рапортует: Cannot shrink log file 2 (ESPAR_ODASTAT_log) because the logical log file located at the end of the file is in use.
2. Теперь понятно, спасибо!
3. И что что я сделал автоматический прирост? Initial size это ж, если я не ошибаюсь, "исходный (начальный) размер", до которого судя по документации и должен сжаться лог. Точнее так: это минимальный размер лог-файла до которого тот может сжаться. А если я уберу авто-увеличение, то накой мне тогда вообще что либо сжимать? Размер файла будет неизменным...

LenaV
1. сделайте BACKUP LOG, DBCC SHRINKFILE пару раз подряд и лог ужмется.

Мягко говоря странный совет... А если после пары раз не ужимается? Повторить 5 раз? 10? 150?

Last1Cmen
перед такой массовой работой с базой рекомендуют преключать режим протоколирования в простой а затем обратно

Хм.. может это конечно и вариант, но на мой взгляд это не решение проблемы. Лог может вырасти и просто от активной работы с базой, что тогда?
3 авг 09, 11:40    [7490018]     Ответить | Цитировать Сообщить модератору
 Re: И вновь продолжается бой! (Опять про усечение лога...)  [new]
emperor_bms
Member

Откуда:
Сообщений: 122
Прошу прощения, не виртуалные лог-файлы, а логические...
3 авг 09, 11:42    [7490029]     Ответить | Цитировать Сообщить модератору
 Re: И вновь продолжается бой! (Опять про усечение лога...)  [new]
Glory
Member

Откуда:
Сообщений: 104760
Попробуйте сменить модель на простую и обратно
3 авг 09, 11:48    [7490050]     Ответить | Цитировать Сообщить модератору
 Re: И вновь продолжается бой! (Опять про усечение лога...)  [new]
emperor_bms
Member

Откуда:
Сообщений: 122
Glory
Попробуйте сменить модель на простую и обратно

Ну видимо другого способа нет, ибо только так смог победить проблему. Однако все-таки остается непонятным, почему такая ситуация возникает...
3 авг 09, 13:46    [7490769]     Ответить | Цитировать Сообщить модератору
 Re: И вновь продолжается бой! (Опять про усечение лога...)  [new]
фывфсв
Guest
TRUNCATEONLY
Выделяет все свободное пространство в конце файла операционной системе, но не перемещает страниц внутри файла. Файл данных сокращается только до последнего выделенного экстента.

Аргумент target_size не обрабатывается, если указан аргумент TRUNCATEONLY.

Аргумент TRUNCATEONLY применим только к файлам данных.
14 окт 09, 10:34    [7782797]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить