MSSQL Администрирование | |
---|---|
ВладимирС Автор Сообщений: 1694 Дата регистрации: 03.11.2005 |
Блин... Кинули на администрирование MSSQL 2008.
Вижу на одном из серверов у БД LDF файл слишком большой: *.MDF - 26080Mb *.LDF - 69570Mb. Конечно произведу shrink... Но вопрос: А mssql сам как то может определять, что файл большой и надо бы произвести сжатие ? ![]() |
Re: MSSQL Администрирование | |
---|---|
sphinx Сообщений: 31888 Откуда: Каменск-Уральски Дата регистрации: 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!"(с) ![]() |
Re: MSSQL Администрирование | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Для начала почитать что такое файл журнала транзакций (transaction log), для чего он нужен. Потом чуть подробнее про режимы архивирования (backup models), и соответственно про переиспользование места в журнале транзакций. После правильной настройки режима архивирования (а именно регулярного создания резервных копий, включающих и журнал транзакций), уверен, проблема будет решена.
Для не-продакшн БД обычно имеет смысл переключиться в simple режим, там журнал не будет так сильно расти (потеря "наработанных за неделю данных" не критична для dev/test окружения, обычно там и так периодически БД обнуляется или заменяется на какую-то урезанную копию продуктивной БД). Конечно же есть всякие "специфические ситуации" - например мега-загрузки данных, когда за очень короткий период времени происходит многократная массированная модификация данных - там может потребоваться и "ручное управление" включающее сжатие БД. При обычное работе этого, как правило, не требуется. ------------------ WBR, Igor ![]() |
Re: MSSQL Администрирование | |
---|---|
sphinx Сообщений: 31888 Откуда: Каменск-Уральски Дата регистрации: 22.11.2006 |
Ну, я ванговал, что Игорь по делу...
------------------ "Veni, vidi, vici!"(с) ![]() |
Re: MSSQL Администрирование | |
---|---|
ssa Сообщений: 13085 Откуда: Москва Дата регистрации: 23.03.2005 |
И как это было определено? Только по размерам файлов и уверенности, что первый обязан быть больше второго? Цитата:Как обычно у тех, кто совершенно не разбирается в вопросе... Цитата:А зачем нужно это сжатие? С чего взяли, что оно нужно? Вот, изучите на досуге: Как перестать называть журнал транзакций SQL Server лог-файлом и прекратить борьбу за его размер ------------------ Лень - это неосознанная мудрость. Исправлено 1 раз(а). Последнее : ssa, 01.05.20 22:37 ![]() |
Re: MSSQL Администрирование | |
---|---|
ВладимирС Автор Сообщений: 1694 Дата регистрации: 03.11.2005 |
Спасибо что откликнулся. Предистория... Наша фирма от денег никогда не отказывается... Тут получилось, что перехватываем работу от других (что с моей точки зрения плохо, но я мелкая птичка, не мне судить верхушку). Получается, что нужно следить за администрированием более 40 серверов с MSSQL 2008R2 принятые от них. Для меня и передачи то и не было. Дали IP и логины с паролями. Все. На них крутятся боевые БД в режиме Full Recovery. Т.к. сервера старые, ну и как я понял перекидываются данные с этих серверов под новое ПО и на новые сервера, то получается задача: 1. добавить инфу на старых серверах. 2. перекинуть эту инфу на новые. Ну вот при задаче п.1 начался активный рост *.LDF файлов. Самое интересное, что за серверами, как за машинами, ответственна третья компания. Она их ведет и при необходимости расширяет HDD. Но тут третья компания увидела, что на одном из серверов слишком сильно растет *.LDF файл. Типа кричат, что больше добавлять HDD не собираются. А скорость заполнения диска высока и на выходных возможно его полное наполнение. Следовательно возможен конфликт. Я обратился к старому администратору. Он посоветовал shrink-нуть *.LDF файл. Посмотрел режим архивирования БД в SQL Agent... ежедневно в 01:00 полный BACKUP ...
А mssql сам как то может определять, что файл большой и надо бы произвести сжатие ? Да потому что вижу в опциях БД: Auto Shrink = True. Как я понимаю, видимо еще не наступил для mssql-я момент сжатия. Просто посоветоваться пришел... Вот об этом бы где то почитать... Исправлено 1 раз(а). Последнее : ВладимирС, 02.05.20 09:50 ![]() |
Re: MSSQL Администрирование | |
---|---|
PaulWist Сообщений: 14740 Дата регистрации: 01.04.2004 |
1. Если файл лога растёт и не останавливается, то скорее всего осталась открытая транзакция, которую надо либо завершить либо прибить. 2. Сам по себе большой лог транзакции может быть больше самой БД, например если производится перестроение индексов, обновляются статистики итд - это нормально, не нормально - это бесконечное разрастания лога. 3. Сам сервер не может определить, мало ли у приложения какие задачи, поэтому никак. ------------------ Есть многое на свете, друг Горацио... Что и не снилось нашим мудрецам. (В.Шекспир Гамлет) ![]() |
Re: MSSQL Администрирование | |
---|---|
ssa Сообщений: 13085 Откуда: Москва Дата регистрации: 23.03.2005 |
Вот пусть и шринкает сам. Если не шринкает - есть не закрытые транзакции. Цитата:Не правильно понял. Не создались нужные условия. Цитата:В приведенной мной ссылке. ------------------ Лень - это неосознанная мудрость. ![]() |
Re: MSSQL Администрирование | |
---|---|
ВладимирС Автор Сообщений: 1694 Дата регистрации: 03.11.2005 |
Хорошая статья. Спасибо... ![]() |
Re: MSSQL Администрирование | |
---|---|
Гулин Федор Сообщений: 4659 Откуда: Минск Дата регистрации: 24.10.2002 |
не могу на текущей работе залезть по ссылке
и не факт что в след. раз залезу сюда и конечно ssa в этих делах опытней но мне как то доводилсь часто шринкать лог (на DEV/TEST) при перегрузке полного дампа mysql в ms-sql через ssis пакет с 300+ контейнерами тупо потому что заканчивалось место на диске а выделять новое - надо было куда-то писать - а времени то и не было так как у меня было simple то я вставлял в жоб после заливки файла шринк лога и мне помогало подозреваю что если есть окно то можно в simple , shrink (причем не факт что надо по минимуму ) , и назад в фулл но тогда по моему нарушается возможность восстановления бакапов что не есть гут т.е на DEV/TEST это все безболезненно - а на проде надо аккуратно ![]() |
© 2000-2025 Fox Club  |