for flooders
:: Главная :: Решения :: Статьи :: Сайт М. Дроздова :: Файловый архив :: Книга по VFP 9 :: Русский Help Online :: OFF-LINE Форум
   Лисоводы   всех   стран,  объединяйтесь !!!  

Список Форумов  :: Не фоксом единым
  

MSSQL Администрирование
ВладимирС

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

Re: MSSQL Администрирование
sphinx

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

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


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


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


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

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


------------------
"Вы поступили правильно, мой друг, но, боюсь, совершили ошибку"..."(с)
Ratings: 0 negative/0 positive

Re: MSSQL Администрирование
Igor Korolyov

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


------------------
WBR, Igor
Ratings: 0 negative/0 positive

Re: MSSQL Администрирование
sphinx

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


------------------
"Вы поступили правильно, мой друг, но, боюсь, совершили ошибку"..."(с)
Ratings: 0 negative/0 positive

Re: MSSQL Администрирование
ssa

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


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




Исправлено: ssa, 01.05.20 22:37
Ratings: 0 negative/0 positive

Re: MSSQL Администрирование
ВладимирС

Сообщений: 1411
Дата: 02.05.20 09:49:01
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
...переиспользование места в журнале транзакций
Вот об этом бы где то почитать...


Исправлено: ВладимирС, 02.05.20 09:50
Ratings: 0 negative/0 positive

Re: MSSQL Администрирование
PaulWist

Сообщений: 13405
Дата: 02.05.20 12:55:45
ВладимирС
Но тут третья компания увидела, что на одном из серверов слишком сильно растет *.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

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

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

------------------
Лень - это неосознанная мудрость.
Ratings: 0 negative/0 positive

Re: MSSQL Администрирование
ВладимирС

Сообщений: 1411
Дата: 04.05.20 10:51:17

Re: MSSQL Администрирование
Гулин Федор
Автор

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

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



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

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

26.09.2020 23:58:47 exec: 0.05
Mem: 1.349 Mb

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