|
Обрезание ЖТ в контексте Плана обслуживания
|
|||
---|---|---|---|
#18+
Друзья, у меня есть План обслуживания, в контексте которого предполагается обрезание ЖТ. Необходимость обрезания продиктована тем, что после перестроения индекса файл ЖТ вырастает до размеров, сопоставимых с размером файла данных (133Гб и 104Гб). ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2020, 12:14 |
|
Обрезание ЖТ в контексте Плана обслуживания
|
|||
---|---|---|---|
#18+
Инструкция T-SQL выглядит следующим образом: USE UPP_test_3 GO ALTER DATABASE UPP_test_3 SET RESTRICTED_USER GO ALTER DATABASE UPP_test_3 SET RECOVERY SIMPLE GO DBCC SHRINKFILE (upp_log, 12) GO ALTER DATABASE UPP_test_3 SET RECOVERY FULL GO ALTER DATABASE UPP_test_3 SET MULTI_USER GO Сама по себе она отлично срабатывает. Но в составе Плана обслуживания стопорится на строке SET RESTRICTED_USER. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2020, 12:22 |
|
Обрезание ЖТ в контексте Плана обслуживания
|
|||
---|---|---|---|
#18+
Вопрос - почему скрипт не работает в составе Плана обслуживания? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2020, 12:23 |
|
Обрезание ЖТ в контексте Плана обслуживания
|
|||
---|---|---|---|
#18+
Rex12, Касательно обрезания - зачем обрезать, если он при реиндексе снова отрастёт? Этим вы только замедляете процесс реиндекса. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2020, 12:24 |
|
Обрезание ЖТ в контексте Плана обслуживания
|
|||
---|---|---|---|
#18+
Rex12 Инструкция T-SQL выглядит следующим образом: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
Сама по себе она отлично срабатывает. Но в составе Плана обслуживания стопорится на строке SET RESTRICTED_USER. зачем это всё делать? особенно переключение full->simple->full? если уж необходимо лог обрезать, то делайте так: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2020, 12:26 |
|
Обрезание ЖТ в контексте Плана обслуживания
|
|||
---|---|---|---|
#18+
komrad Касательно обрезания - зачем обрезать, если он при реиндексе снова отрастёт? В том-то и дело! Поэтому обрезание предполагается делать каждую ночь. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2020, 12:30 |
|
Обрезание ЖТ в контексте Плана обслуживания
|
|||
---|---|---|---|
#18+
komrad зачем это всё делать? особенно переключение full->simple->full? В режиме FULL обрезание ЖТ НЕВОЗМОЖНО. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2020, 12:32 |
|
Обрезание ЖТ в контексте Плана обслуживания
|
|||
---|---|---|---|
#18+
Rex12 В режиме FULL обрезание ЖТ НЕВОЗМОЖНО. капслок повеселил :) В режиме full обрезание лога возможно после log backup. Посмотрите команду dbcc loginfo() и колонку Status - когда там 2, этот vlf занят, а когда 0 - он пустой. Обрезаются пустые vlf с конца. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2020, 12:40 |
|
Обрезание ЖТ в контексте Плана обслуживания
|
|||
---|---|---|---|
#18+
Rex12 komrad Касательно обрезания - зачем обрезать, если он при реиндексе снова отрастёт? В том-то и дело! Поэтому обрезание предполагается делать каждую ночь. не уловил логику поясните? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2020, 12:41 |
|
Обрезание ЖТ в контексте Плана обслуживания
|
|||
---|---|---|---|
#18+
komrad В режиме full обрезание лога возможно после log backup. Спасибо за подсказку! Сейчас проверю на тестовой базе. Но тогда по-любому нужно базу переводить в RESTRICTED_USER, потому что ночью пользователи тоже работают. И могут совершить транзакции во время обрезания лога. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2020, 12:48 |
|
Обрезание ЖТ в контексте Плана обслуживания
|
|||
---|---|---|---|
#18+
Rex12 komrad В режиме full обрезание лога возможно после log backup. Спасибо за подсказку! Сейчас проверю на тестовой базе. Но тогда по-любому нужно базу переводить в RESTRICTED_USER, потому что ночью пользователи тоже работают. И могут совершить транзакции во время обрезания лога. Restricted_user не нужен обрезается только пустая часть лога так поясните, зачем вы обрезаете лог? какая причина (кроме "страшного" размера)? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2020, 12:50 |
|
Обрезание ЖТ в контексте Плана обслуживания
|
|||
---|---|---|---|
#18+
komrad не уловил логику поясните? С удовольствием! Ежедневное ночное перестроение индекса раздувает файл ЖТ. Поэтому логично его обрезать не отходя от кассы в рамках этого же плана обслуживания. Утром приходит на работу основная часть пользователей, журнал уже обрезан. И сильно не растёт до момента выполнения ночного Плана обслуживания. И так по кругу. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2020, 12:53 |
|
Обрезание ЖТ в контексте Плана обслуживания
|
|||
---|---|---|---|
#18+
komrad так поясните, зачем вы обрезаете лог? какая причина (кроме "страшного" размера)? Это основная причина. На сервере мало места, однако :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2020, 12:55 |
|
Обрезание ЖТ в контексте Плана обслуживания
|
|||
---|---|---|---|
#18+
Rex12 komrad не уловил логику поясните? С удовольствием! Ежедневное ночное перестроение индекса раздувает файл ЖТ. Поэтому логично его обрезать не отходя от кассы в рамках этого же плана обслуживания. Утром приходит на работу основная часть пользователей, журнал уже обрезан. И сильно не растёт до момента выполнения ночного Плана обслуживания. И так по кругу. Так он у вас ночью всё равно вырастет. Зачем насиловать его туда-сюда? Тем более не понятно, зачем вам вообще Full recovery model, если, по всей видимости, бекапы лога вы не делаете. А если и делаете, то после перевода в Simple цепочка рушится и становится бесполезной. Если БД будет в Simple модели, после завершения реиндекса место в логе освободится для переиспользования. Да, файл останется того же размера, но внутри будет куча места для работы. Либо, как уже написали, делать бекапы лога и не трогать recovery model, оставив её в Full. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2020, 12:58 |
|
Обрезание ЖТ в контексте Плана обслуживания
|
|||
---|---|---|---|
#18+
Rex12 komrad не уловил логику поясните? С удовольствием! Ежедневное ночное перестроение индекса раздувает файл ЖТ. Поэтому логично его обрезать не отходя от кассы в рамках этого же плана обслуживания. Утром приходит на работу основная часть пользователей, журнал уже обрезан. И сильно не растёт до момента выполнения ночного Плана обслуживания. И так по кругу. Еще раз: зачем его обрезать, если он 1) отрастает в течение дня, 2) отрастает ночью при перестройке индекса? Для чего делать эту бесполезную и вредную работу? Вредна он тем, что на время прироста лога и пользователи, и план обслуживания ждут окончания процесса прироста. То есть, получают искусственную задержку. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2020, 13:05 |
|
Обрезание ЖТ в контексте Плана обслуживания
|
|||
---|---|---|---|
#18+
4es зачем вам вообще Full recovery model, если, по всей видимости, бекапы лога вы не делаете. Делаю, это критически важно. А если и делаете, то после перевода в Simple цепочка рушится и становится бесполезной. Дело в том, что после обрезания ЖТ и перевода БД в режим FULL делается полный бэкап, и образуется новая цепочка. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2020, 13:06 |
|
Обрезание ЖТ в контексте Плана обслуживания
|
|||
---|---|---|---|
#18+
Rex12 komrad так поясните, зачем вы обрезаете лог? какая причина (кроме "страшного" размера)? Это основная причина. На сервере мало места, однако :-) вот! с этого и надо было начинать. посмотрите решение по реиндексу и обновлению статистики от Ola Hallengren у меня сильное подозрение, что ваш план обслуживания "перелопачивает" больше чем нужно уменьшите объем работ - уменьшите и прирост лога https://ola.hallengren.com/sql-server-index-and-statistics-maintenance.html ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2020, 13:11 |
|
Обрезание ЖТ в контексте Плана обслуживания
|
|||
---|---|---|---|
#18+
komrad Еще раз: зачем его обрезать, если он 1) отрастает в течение дня, 2) отрастает ночью при перестройке индекса? Для чего делать эту бесполезную и вредную работу? Только ради свободного места на диске. Вредна она тем, что на время прироста лога и пользователи, и план обслуживания ждут окончания процесса прироста. То есть, получают искусственную задержку. Основной прирост происходит ночью, когда количество пользователей минимально. Иными словами, вы вообще не рекомендуете трогать ЖТ? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2020, 13:11 |
|
Обрезание ЖТ в контексте Плана обслуживания
|
|||
---|---|---|---|
#18+
Rex12 komrad Еще раз: зачем его обрезать, если он 1) отрастает в течение дня, 2) отрастает ночью при перестройке индекса? Для чего делать эту бесполезную и вредную работу? Только ради свободного места на диске. Место ради места? чтобы глаз радовало или оно нужно для других приложений/процессов? В текущей конфигурации вашего джоба это место нужно логу. Rex12 Вредна она тем, что на время прироста лога и пользователи, и план обслуживания ждут окончания процесса прироста. То есть, получают искусственную задержку. Основной прирост происходит ночью, когда количество пользователей минимально. Иными словами, вы вообще не рекомендуете трогать ЖТ? рекомендую: 1) оставить его в покое 2) проанализировать кол-во VLF в нем и, при необходимости, уменьшить кол-во путем укрупнения VLF. Это ускорит recovery базы при старте сиквела и при восстановлении базы. У вас дисковая подсистема на каких дисках? SSD? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2020, 13:31 |
|
Обрезание ЖТ в контексте Плана обслуживания
|
|||
---|---|---|---|
#18+
komrad У вас дисковая подсистема на каких дисках? SSD? На обычных, не SSD. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2020, 13:40 |
|
Обрезание ЖТ в контексте Плана обслуживания
|
|||
---|---|---|---|
#18+
komrad рекомендую: 1) оставить его в покое 2) проанализировать кол-во VLF в нем и, при необходимости, уменьшить кол-во путем укрупнения VLF. Это ускорит recovery базы при старте сиквела и при восстановлении базы. Спасибо! ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2020, 13:41 |
|
Обрезание ЖТ в контексте Плана обслуживания
|
|||
---|---|---|---|
#18+
авторЕжедневное ночное перестроение индекса раздувает файл ЖТ.Чисто ради эксперимента - не делайте этого день другой. И если не увидите разницу, то зачем платить больше. Если же у вас зуд что-то делать - делайте CHECKDB, перебирайте статистику, и делайте бакап логов чаще. Все теме же скриптами от Ola ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2020, 17:10 |
|
|
start [/forum/topic.php?fid=46&msg=40024529&tid=1685334]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
59ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
59ms |
get tp. blocked users: |
2ms |
others: | 293ms |
total: | 460ms |
0 / 0 |