Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Распухание лог-файлов
|
|||
|---|---|---|---|
|
#18+
На сервере распухают файлы логов. При этом бэкап логов на ленту выполняется каждые 4-ре часа TSM-кой. Шринкование лога, запускаемое из Job-а помогает только в случае если выполняется относительно быстро сразу после бэкапа. Иначе файл лога может шринкануться частично (например через минуту он шринканулся с 30 GB до 8GB) или не шринкануться вообще. Хотелось бы понять что именно делается не так... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2019, 18:27 |
|
||
|
Распухание лог-файлов
|
|||
|---|---|---|---|
|
#18+
KtoToGdeНа сервере распухают файлы логов. При этом бэкап логов на ленту выполняется каждые 4-ре часа TSM-кой. Шринкование лога, запускаемое из Job-а помогает только в случае если выполняется относительно быстро сразу после бэкапа. Иначе файл лога может шринкануться частично (например через минуту он шринканулся с 30 GB до 8GB) или не шринкануться вообще. Хотелось бы понять что именно делается не так... проверьте модель восстановления базы - соответствует ли она требованиям по аварийному восстановлению может ее надо раз в неделю бекапить? если модель верная, то следующее: - увеличить частоту бекапов лога до требуемой по сценарию аварийного восстановления либо в соответствии с реальной нагрузкой на лог и типом транзакций (много коротких / немного длинных) во втором случае увеличение частоты не особо поможет - перестать резать лог - это борьба с ветряными мельницами и искусственное замедление выполняющихся транзакций (задержка на отращивание лога и его обнуление) - установить размер лога в соответствии с реальной нагрузкой рекомендую проверить заполненность лога сразу после бекапа - может у вас там репликация, лог шиппинг, зеркало и т.п. и получатель не успевает за источником команды на проверку (на выбор, в зависимости от версии сиквела): Код: sql 1. 2. 3. 4. 5. 6. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2019, 18:48 |
|
||
|
Распухание лог-файлов
|
|||
|---|---|---|---|
|
#18+
KtoToGdeШринкование лога, запускаемое из Job-а помогает только в случае если выполняется относительно быстро сразу после бэкапа. Иначе файл лога может шринкануться частично (например через минуту он шринканулся с 30 GB до 8GB) или не шринкануться вообще. Хотелось бы понять что именно делается не так...Относитесь к лог (или дата) файлам базы как к дискам. Вы же не меняете размеры дисков после каждого добавления/удаления файлов? Вот и для лог файла так же - выберите правильный размер, правильное расписение бакапов, соотнесите расписание с обслуживанием базы, с другими тяжёлыми операциями, и никогда его не шринкуйте. Ещё изучите вашу стсему бакапов, и посмотрите на модель восстановления, а то, может, у вас и бакапов лога нету. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2019, 21:17 |
|
||
|
Распухание лог-файлов
|
|||
|---|---|---|---|
|
#18+
KtoToGde, Лог это лог. Лог всех событий вашей базы с момента бекапа (при полной модели). Насколько у вас лог с бекапа распухает - столько данных меняется. Прикиньте объемы данных для начала. Если есть четкое несоответствие, то смотрите на транзакции, что там происходит. Может откатов много или ещё каких лишних операций. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2019, 00:29 |
|
||
|
|
start [/forum/topic.php?fid=46&tid=1687848]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
57ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
30ms |
get tp. blocked users: |
1ms |
| others: | 262ms |
| total: | 390ms |
| 0 / 0 |
