:: Не фоксом единым
MSSQL Администрирование
ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005
Блин... Кинули на администрирование MSSQL 2008.
Вижу на одном из серверов у БД LDF файл слишком большой:
*.MDF - 26080Mb
*.LDF - 69570Mb.
Конечно произведу shrink...
Но вопрос: А mssql сам как то может определять, что файл большой и надо бы произвести сжатие ?
Ratings: 0 negative/0 positive
Re: MSSQL Администрирование
sphinx

Сообщений: 31166
Откуда: Каменск-Уральски
Дата регистрации: 22.11.2006
Володя, привет!
Я не работаю с MSSQL, просто решил погуглить проблему. Может что-то пригодится.

На cyberforum.ru писали, что нужно настроить задание в SQL Agent.


Параметры автоматического увеличения и сжатия в SQL Server
support.microsoft.com


Почему вы не должны сжимать ваши файлы данных (тут есть примеры, сживать-то может и надо, но важно понять когда и КАК. Ну и источник ХАБР...).
habr.com


Методы борьбы с увеличением размера баз в связке MS SQL + 1С:Предприятие
alexeistar.blogspot.com

P.S. Готовый рецепт может дать Игорь Королев, он работал с MSSQL.


------------------
"Veni, vidi, vici!"(с)
Ratings: 0 negative/0 positive
Re: MSSQL Администрирование
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
Для начала почитать что такое файл журнала транзакций (transaction log), для чего он нужен. Потом чуть подробнее про режимы архивирования (backup models), и соответственно про переиспользование места в журнале транзакций. После правильной настройки режима архивирования (а именно регулярного создания резервных копий, включающих и журнал транзакций), уверен, проблема будет решена.
Для не-продакшн БД обычно имеет смысл переключиться в simple режим, там журнал не будет так сильно расти (потеря "наработанных за неделю данных" не критична для dev/test окружения, обычно там и так периодически БД обнуляется или заменяется на какую-то урезанную копию продуктивной БД).
Конечно же есть всякие "специфические ситуации" - например мега-загрузки данных, когда за очень короткий период времени происходит многократная массированная модификация данных - там может потребоваться и "ручное управление" включающее сжатие БД. При обычное работе этого, как правило, не требуется.


------------------
WBR, Igor
Ratings: 0 negative/0 positive
Re: MSSQL Администрирование
sphinx

Сообщений: 31166
Откуда: Каменск-Уральски
Дата регистрации: 22.11.2006
Ну, я ванговал, что Игорь по делу...


------------------
"Veni, vidi, vici!"(с)
Ratings: 0 negative/0 positive
Re: MSSQL Администрирование
ssa

Сообщений: 12999
Откуда: Москва
Дата регистрации: 23.03.2005
ВладимирС
Вижу на одном из серверов у БД LDF файл слишком большой:
И как это было определено? Только по размерам файлов и уверенности, что первый обязан быть больше второго?
Цитата:
Конечно произведу shrink...
Как обычно у тех, кто совершенно не разбирается в вопросе...
Цитата:
Но вопрос: А mssql сам как то может определять, что файл большой и надо бы произвести сжатие ?
А зачем нужно это сжатие? С чего взяли, что оно нужно?
Вот, изучите на досуге: Как перестать называть журнал транзакций SQL Server лог-файлом и прекратить борьбу за его размер


------------------
Лень - это неосознанная мудрость.




Исправлено 1 раз(а). Последнее : ssa, 01.05.20 22:37
Ratings: 0 negative/0 positive
Re: MSSQL Администрирование
ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005
Igor Korolyov
Для начала почитать что такое файл журнала транзакций (transaction log), для чего он нужен. Потом чуть подробнее про режимы архивирования (backup models), и соответственно про переиспользование места в журнале транзакций. После правильной настройки режима архивирования (а именно регулярного создания резервных копий, включающих и журнал транзакций), уверен, проблема будет решена.
Для не-продакшн БД обычно имеет смысл переключиться в simple режим, там журнал не будет так сильно расти (потеря "наработанных за неделю данных" не критична для dev/test окружения, обычно там и так периодически БД обнуляется или заменяется на какую-то урезанную копию продуктивной БД).
Конечно же есть всякие "специфические ситуации" - например мега-загрузки данных, когда за очень короткий период времени происходит многократная массированная модификация данных - там может потребоваться и "ручное управление" включающее сжатие БД. При обычное работе этого, как правило, не требуется.
Спасибо что откликнулся.
Предистория...
Наша фирма от денег никогда не отказывается...
Тут получилось, что перехватываем работу от других (что с моей точки зрения плохо, но я мелкая птичка, не мне судить верхушку).
Получается, что нужно следить за администрированием более 40 серверов с MSSQL 2008R2 принятые от них.
Для меня и передачи то и не было. Дали IP и логины с паролями. Все.
На них крутятся боевые БД в режиме Full Recovery.
Т.к. сервера старые, ну и как я понял перекидываются данные с этих серверов под новое ПО и на новые сервера, то получается задача:
1. добавить инфу на старых серверах.
2. перекинуть эту инфу на новые.
Ну вот при задаче п.1 начался активный рост *.LDF файлов.
Самое интересное, что за серверами, как за машинами, ответственна третья компания. Она их ведет и при необходимости расширяет HDD.
Но тут третья компания увидела, что на одном из серверов слишком сильно растет *.LDF файл.
Типа кричат, что больше добавлять HDD не собираются. А скорость заполнения диска высока и на выходных возможно его полное наполнение. Следовательно возможен конфликт.
Я обратился к старому администратору. Он посоветовал shrink-нуть *.LDF файл.
Посмотрел режим архивирования БД в SQL Agent... ежедневно в 01:00 полный BACKUP ...
...BACKUP DATABASE @name TO DISK = @fileName WITH COMPRESSION...
Почему задал вопрос:
А mssql сам как то может определять, что файл большой и надо бы произвести сжатие ?
Да потому что вижу в опциях БД: Auto Shrink = True.
Как я понимаю, видимо еще не наступил для mssql-я момент сжатия.
Просто посоветоваться пришел...

Igor Korolyov
...переиспользование места в журнале транзакций
Вот об этом бы где то почитать...


Исправлено 1 раз(а). Последнее : ВладимирС, 02.05.20 09:50
Ratings: 0 negative/0 positive
Re: MSSQL Администрирование
PaulWist

Сообщений: 14601
Дата регистрации: 01.04.2004
ВладимирС
Но тут третья компания увидела, что на одном из серверов слишком сильно растет *.LDF файл.
Типа кричат, что больше добавлять HDD не собираются. А скорость заполнения диска высока и на выходных возможно его полное наполнение. Следовательно возможен конфликт.
Я обратился к старому администратору. Он посоветовал shrink-нуть *.LDF файл.
Посмотрел режим архивирования БД в SQL Agent... ежедневно в 01:00 полный BACKUP ...
...BACKUP DATABASE @name TO DISK = @fileName WITH COMPRESSION...
Почему задал вопрос:
А mssql сам как то может определять, что файл большой и надо бы произвести сжатие ?
Да потому что вижу в опциях БД: Auto Shrink = True.
Как я понимаю, видимо еще не наступил для mssql-я момент сжатия.
Просто посоветоваться пришел...


1. Если файл лога растёт и не останавливается, то скорее всего осталась открытая транзакция, которую надо либо завершить либо прибить.

2. Сам по себе большой лог транзакции может быть больше самой БД, например если производится перестроение индексов, обновляются статистики итд - это нормально, не нормально - это бесконечное разрастания лога.

3. Сам сервер не может определить, мало ли у приложения какие задачи, поэтому никак.


------------------
Есть многое на свете, друг Горацио...
Что и не снилось нашим мудрецам.
(В.Шекспир Гамлет)
Ratings: 0 negative/0 positive
Re: MSSQL Администрирование
ssa

Сообщений: 12999
Откуда: Москва
Дата регистрации: 23.03.2005
ВладимирС
Почему задал вопрос:
А mssql сам как то может определять, что файл большой и надо бы произвести сжатие ?
Да потому что вижу в опциях БД: Auto Shrink = True.
Вот пусть и шринкает сам. Если не шринкает - есть не закрытые транзакции.
Цитата:
Как я понимаю, видимо еще не наступил для mssql-я момент сжатия.
Не правильно понял. Не создались нужные условия.
Цитата:
Просто посоветоваться пришел...

Igor Korolyov
...переиспользование места в журнале транзакций
Вот об этом бы где то почитать...
В приведенной мной ссылке.

------------------
Лень - это неосознанная мудрость.
Ratings: 0 negative/0 positive
Re: MSSQL Администрирование
ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005
Хорошая статья. Спасибо...
Ratings: 0 negative/0 positive
Re: MSSQL Администрирование
Гулин Федор

Сообщений: 4633
Откуда: Минск
Дата регистрации: 24.10.2002
не могу на текущей работе залезть по ссылке
и не факт что в след. раз залезу сюда
и конечно ssa в этих делах опытней
но мне как то доводилсь часто шринкать лог (на DEV/TEST)
при перегрузке полного дампа mysql в ms-sql
через ssis пакет с 300+ контейнерами
тупо потому что заканчивалось место на диске а выделять новое - надо было куда-то писать - а времени то и не было
так как у меня было simple то я вставлял в жоб после заливки файла шринк лога и мне помогало

подозреваю что если есть окно
то можно в simple , shrink (причем не факт что надо по минимуму ) , и назад в фулл
но тогда по моему нарушается возможность восстановления бакапов что не есть гут
т.е на DEV/TEST это все безболезненно - а на проде надо аккуратно
Ratings: 0 negative/0 positive


Извините, только зарегистрированные пользователи могут оставлять сообщения в этом форуме.

On-line: 7 (Гостей: 7)

© 2000-2024 Fox Club 
Яндекс.Метрика