Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
Yurgen3000 Member Откуда: Сообщений: 11 |
Не так давно столкнулся с проблемой колоссального роста database transaction log ldf - файлов в папке с базами. Решаю проблему так. БД (правый клик - Properties - Tasks - Shrink - File. Там выбираю LOG и в Reorganase page ставлю 0. Всё в порядке. Логи транзакций урезаются до 0. НО! Всё делаю вручную. Есть ли какой-то простой способ задать делать это автоматически, скажем раз в неделю путем какой-нибудь T-SQL задачи? |
7 ноя 18, 00:17 [21725987] Ответить | Цитировать Сообщить модератору |
Lepsik Member Откуда: glubinka Сообщений: 4256 |
Yurgen3000, Начните бэкапы делать раз в неделю для начала. Остальные проблемы будет решатся уже сами собой. |
7 ноя 18, 00:20 [21725989] Ответить | Цитировать Сообщить модератору |
Relic Hunter Member Откуда: AB Сообщений: 7481 |
Стыдно признаться, план обслуживание действительно не режет логи по-чемуто. За сим расчехляю скриптик.
|
|
7 ноя 18, 00:26 [21725992] Ответить | Цитировать Сообщить модератору |
Yurgen3000 Member Откуда: Сообщений: 11 |
Lepsik, Это всё есть и работает. Но логи он сжимать не хочет... |
7 ноя 18, 00:33 [21726001] Ответить | Цитировать Сообщить модератору |
Yurgen3000 Member Откуда: Сообщений: 11 |
Relic Hunter, Огромное спасибо! Завтра вкорячу, проверю. |
7 ноя 18, 00:35 [21726006] Ответить | Цитировать Сообщить модератору |
Lepsik Member Откуда: glubinka Сообщений: 4256 |
Еще не известно что за база у человека. может MSSQL 6.5 |
||
7 ноя 18, 00:42 [21726008] Ответить | Цитировать Сообщить модератору |
Yurgen3000 Member Откуда: Сообщений: 11 |
Lepsik, Да не, 2014 )) |
7 ноя 18, 00:49 [21726011] Ответить | Цитировать Сообщить модератору |
aleks222 Member Откуда: Сообщений: 1238 |
Стисняюсь спросить: смысл сего действа? Т.е. сервер будет расширять журналы, тредстартер уперто шринкать. Все при деле, все при работе. |
||
7 ноя 18, 05:58 [21726041] Ответить | Цитировать Сообщить модератору |
Yurgen3000 Member Откуда: Сообщений: 11 |
aleks222, А вы сами то не догадываетесь? Ну ок, поясню. Планы обслуживания настроены правильно, с очистками логов, вот только файлы транзакций с расширением *ldf находящиеся в одной папке с БД, упорно резаться не хотят. Почему скуль этого сам не делает, я не имею понятия. В итоге, день ото дня, эти файлы растут, как тесто на дрожжах, а место на ssd не резиновое. Приходится прибегать, как вы выразились, к "тредстартеру". |
7 ноя 18, 09:56 [21726141] Ответить | Цитировать Сообщить модератору |
Yurgen3000 Member Откуда: Сообщений: 11 |
Lepsik, Скрипт рабочий! Еще раз большущее спасибо. Проблема решена. Кстати в качестве совета, подскажите плз, как лучше задать периодичность урезания этих ldf-ок? На что это вообще влияет? Я выставил раз в сутки. Логика такая, что журнал транзакций в плане пишется раз в 1 час. с 9:00 до 19:00. А после бухглатерам эти транзакции не нужны. Логично ведь, что стоит очистка tr логов. Ну вот и также поставил ваш скриптик на очистку раз в сутки. Это нормально? |
7 ноя 18, 10:01 [21726157] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31783 |
Файлы базы - это как логический том на диске. Вы же не сжимаете и потом расширяете каждый день логические тома в ваших виндах? Почему то винды это автоматически делать не умеют, опять билли накосячил :-) |
||
7 ноя 18, 10:01 [21726158] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
Вы сами не догадываетесь, что вам пишут? Обрезание лога бесполезная операция и бывает у нормальных людей только редким исключением. + Приращение лога, это зануление всего куска диска, что и так затратная операция для системы и в добавок будет развлекать ваш ssd. + Лог работает "по кругу" в файле. И как этих людей пукскают что-то администрировать... |
||
7 ноя 18, 10:03 [21726164] Ответить | Цитировать Сообщить модератору |
Yurgen3000 Member Откуда: Сообщений: 11 |
TaPaK, Не надо умничать и дерзить! Терпеть этого не могу. Допускают так как платить другим за это нормально не хотят. Ибо администрирование SQL денег стоит. А руководство экономит во всем. А профиль этот не мой, я и не отрицаю. Я сетевик и микроэлетронщик. Скуль не моя специфика, но пришлось и в этом разбираться. Ибо банально не кому у нас. И здесь я спрашиваю совета. Вот вы раз такой профи, так вместо того, чтобы гнобить, посоветуйте, как правильно сделать и настроить по вашему опыту. А если не хотите, так и не надо умничать. |
7 ноя 18, 10:17 [21726183] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
Уже написали несоколько раз: шринковать лог не надо. Как ещё написать? Допускается только если "не штатно" взлетел размер (у меня было когда, например, провтыкали отвал бекапа лога) в иных случаех пользы нет, тем более вы сами пишете что он постоянно взлетает, и это он делает не от вредности. Бекапте лог чаще, разбирайтесь с длинными транзакциями ищите что его увеличивает, но резать - бесполезно |
||
7 ноя 18, 10:22 [21726191] Ответить | Цитировать Сообщить модератору |
Maxx Member [скрыт] Откуда: Сообщений: 24290 |
ТС - може просто модель востановления симпл влепите ? |
7 ноя 18, 10:31 [21726211] Ответить | Цитировать Сообщить модератору |
Yurgen3000 Member Откуда: Сообщений: 11 |
Maxx, Да, я уже думал в этом направлении. И рекомендации мелкомягких изучал. Это конечно решит мою проблему, но есть опасения определенные по восстановлению баз в случае чего. Симпл метод, это в принципе может быть чревато. Базы бухгалтерские. Базы большие. Ни дай бог... |
7 ноя 18, 10:35 [21726219] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
Yurgen3000,
1С? |
||
7 ноя 18, 10:37 [21726224] Ответить | Цитировать Сообщить модератору |
Yurgen3000 Member Откуда: Сообщений: 11 |
TaPaK, Да |
7 ноя 18, 10:43 [21726238] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31783 |
Шринк лога - это как манипуляции с разделами дисков. Это не штатная операция процесса эксплуатации системы, а некие нештатные, или даже аварийные действия админов. В нормально настроенной системе лог-файлы постоянны и не меняются. Yurgen3000, вам нужно посмотреть, в какой момент происходит расширение логов, возможно, в момент выполнения обслуживания базы. Может, нужно в это время добавить дополнительный бакап лога, что бы сбросить этот дополнительный кусок, появившийся из за обслуживания. Или, может, на самом деле у вас не делается бакап лога - вы не путаете бакап лога и бакап базы? |
||||
7 ноя 18, 10:44 [21726239] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
этих не спасти. |
||
7 ноя 18, 10:44 [21726241] Ответить | Цитировать Сообщить модератору |
Владислав Колосов Member Откуда: Сообщений: 8330 |
Yurgen3000, журналы растут потому, что должны расти, но вы можете контролировать их повторное использование. Если станете создавать резервные копии, то есть переносить протокол операций в другие файлы, то сервер сможет переиспользовать место в файле журнала, поскольку вы гарантируете резервным копирванием, что информация, нужная для восстановления не будет потеряна. |
7 ноя 18, 12:56 [21726614] Ответить | Цитировать Сообщить модератору |
Yurgen3000 Member Откуда: Сообщений: 11 |
Владислав Колосов, alexeyvg, Спасибо за ликбез и пояснения! Всё принято к сведению. Буду анализировать. |
7 ноя 18, 21:49 [21727440] Ответить | Цитировать Сообщить модератору |
L_argo Member Откуда: Сообщений: 1400 |
В случае аварии можно вернуться к нормальным данным с потерей в среднем 30минут работы. А также поднять базу на любое конкретное время (н-р для разбора полетов или восстановления убитого юзерами справочника) за последние 2-3дня. |
||
7 ноя 18, 22:55 [21727500] Ответить | Цитировать Сообщить модератору |
Все форумы / Microsoft SQL Server | ![]() |