|
Состояние БД при усечении ЖТ
|
|||
---|---|---|---|
#18+
Друзья, мне периодически приходится производить усечение ЖТ. Я могу делать это как вручную днём, так и путём выполнения инструкции T-SQL (DBCC SHRINKFILE) в Плане обслуживания ночью. Но и днём, и ночью с БД работают люди. У меня вопрос - стоит ли опасаться потенциальной возможности того, что пользователи запустят в этот момент какую-то транзакцию и это плохо отразится на БД? Нужно ли переводить БД в режим SINGLE_USER или RESTRICTED _USER? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2020, 11:46 |
|
Состояние БД при усечении ЖТ
|
|||
---|---|---|---|
#18+
Rex12 Друзья, мне периодически приходится производить усечение ЖТ. Я могу делать это как вручную днём, так и путём выполнения инструкции T-SQL (DBCC SHRINKFILE) в Плане обслуживания ночью. Но и днём, и ночью с БД работают люди. У меня вопрос - стоит ли опасаться потенциальной возможности того, что пользователи запустят в этот момент какую-то транзакцию и это плохо отразится на БД? Нужно ли переводить БД в режим SINGLE_USER или RESTRICTED _USER? Но может просто не дать никакого эффекта, т.е. тупо не усечься. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2020, 11:52 |
|
Состояние БД при усечении ЖТ
|
|||
---|---|---|---|
#18+
L_argo Но может просто не дать никакого эффекта, т.е. тупо не усечься. Если будет какая-то транзакция в этот момент запущена? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2020, 11:57 |
|
Состояние БД при усечении ЖТ
|
|||
---|---|---|---|
#18+
Rex12 L_argo Но может просто не дать никакого эффекта, т.е. тупо не усечься. Если будет какая-то транзакция в этот момент запущена? Если vlf'ы в конце лога пока ещё активны по какой-то причине. Активная транзакция, бекап лога не прошел ещё, log reader при включенной репликации не прочитал ещё лог, AlwaysOn не передал весь лог на вторичные ноды, ну и всё в таком духе. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2020, 13:29 |
|
Состояние БД при усечении ЖТ
|
|||
---|---|---|---|
#18+
4es Если vlf'ы в конце лога пока ещё активны по какой-то причине. Активная транзакция, бекап лога не прошел ещё, log reader при включенной репликации не прочитал ещё лог, AlwaysOn не передал весь лог на вторичные ноды, ну и всё в таком духе. Иными словами, для безопасности лучше сделать так, чтобы пользователи в это время не имели доступа к базе? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2020, 15:13 |
|
Состояние БД при усечении ЖТ
|
|||
---|---|---|---|
#18+
Rex12 4es Если vlf'ы в конце лога пока ещё активны по какой-то причине. Активная транзакция, бекап лога не прошел ещё, log reader при включенной репликации не прочитал ещё лог, AlwaysOn не передал весь лог на вторичные ноды, ну и всё в таком духе. Иными словами, для безопасности лучше сделать так, чтобы пользователи в это время не имели доступа к базе? Безопасность тут не при чем, одновременная активная работа с данными и усечение журнала транзакций ничего не сломают. Просто сам процесс усечения, при некоторых условиях, может оказаться бесполезным, т.е. усечение не произойдет. А с какой целью проводятся эти самые периодические усечения журнала транзакций? Такие операции не должны быть на еженощной основе, т.к. в этом случае это мартышкин сизифов труд. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2020, 15:31 |
|
Состояние БД при усечении ЖТ
|
|||
---|---|---|---|
#18+
msLex А с какой целью проводятся эти самые периодические усечения журнала транзакций? Такие операции не должны быть на еженощной основе, т.к. в этом случае это мартышкин сизифов труд. автору всё не дают покоя журналы https://www.sql.ru/forum/1331488/obrezanie-zht-v-kontekste-plana-obsluzhivaniya ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2020, 15:52 |
|
Состояние БД при усечении ЖТ
|
|||
---|---|---|---|
#18+
msLex А с какой целью проводятся эти самые периодические усечения журнала транзакций? Только ради экономии места. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2020, 17:50 |
|
Состояние БД при усечении ЖТ
|
|||
---|---|---|---|
#18+
Rex12 msLex А с какой целью проводятся эти самые периодические усечения журнала транзакций? Только ради экономии места. Которое опять будет занято к следующей итерации этого усечения, а значит не под что другое вы его переиспользовать не сможете, т.к. в противном случае места не хватит уже для расширения лога. Я и говорю msLex это мартышкин сизифов труд ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2020, 17:56 |
|
Состояние БД при усечении ЖТ
|
|||
---|---|---|---|
#18+
Тем более, что увеличивается фрагментация дискового пространства. Rex12 msLex А с какой целью проводятся эти самые периодические усечения журнала транзакций? Только ради экономии места. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2020, 18:49 |
|
Состояние БД при усечении ЖТ
|
|||
---|---|---|---|
#18+
Rex12 msLex А с какой целью проводятся эти самые периодические усечения журнала транзакций? Только ради экономии места. Так усечение или сжатие? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2020, 23:21 |
|
Состояние БД при усечении ЖТ
|
|||
---|---|---|---|
#18+
Владислав Колосов Так усечение или сжатие? Усечение ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2020, 15:13 |
|
Состояние БД при усечении ЖТ
|
|||
---|---|---|---|
#18+
Rex12, Вам уже объяснили всю суть борьбы с ветряными мельницами. Ваша борьба с постоянно растущим фалом лога: а) вредна б) бесмыссленна Усекать лог имеет смысл только когда фактор роста файла имеет явно разовый характер. (к примеру обычно размер файла ~50 гигабайт и вы с какой то день приходите а у вас не 50 а 250 гигов отожрало, ночная масовая загрузка какого нибудь большого справочника была или индексы все в базе горе админ решил перестроить) Вы должны определиться с размером вашего "рабочего" лога, если вы налицо наблюдаете что у вас после усечения файл по краткосрочной динамике вырастает, дайте ему занять необходимый для него объем и зафиксируйте его для себя. если уже позже вы будете вылезать за его рамки тогда можно будет предпринимать дальнейшие шаги. А так у вас получается следующая ситуация (гипотетически я сейчас пофантазирую, диск у вас на котором лог 200 Гб): За неделю работы лог у вас вырастает к примеру до 100 Гб. В конце недели вы его режете до 1 Гб, и всю следующую неделю он опять набирает весь свой необходимый объем (тратя между прочим ресурсы на расширение файла) Представьте картину что к примеру кто нибудь положит файл объемом 160 Гб в течении недели. в таком случае у вас будет ситуация когда необходимое дальнейшее свободное место для роста лога будет занято и в конце недели вы получите не базу с логом в 100 Гб, а базу в состоянии read only. что лучше нерабочая база или невозможность занять какой то дисковый объем посторонней операцией? Бороться с ростом лога нужно не усечением, а изменением стратегии резервного копирования. Видите что растет лог? - чаще делайте бэкапы. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2020, 16:08 |
|
Состояние БД при усечении ЖТ
|
|||
---|---|---|---|
#18+
felix_ff Видите что растет лог? - чаще делайте бэкапы. Спасибо, Феликс! Но бэкапы делаются каждую ночь (полные). Каждый час в основное рабочее время - бэкап ЖТ. И ещё каждую ночь производится перестроение индекса, что и вызывает рост файла ЖТ, ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2020, 18:37 |
|
Состояние БД при усечении ЖТ
|
|||
---|---|---|---|
#18+
Rex12, Я бы на Вашем месте начал с поиска закономерностей роста лога. поснимал бы счетчики производительности на отрезке времени и посмотрел какая нагрузка вызывает рост лога. Если это операции обслуживания бд, опять таки надо задаться вопросом о необходимости настолько частого перестроения, возможен вариант что полезного выхлопа это дает относительно мало, а базу и сервер вы гоняете и в хвост и в гриву из-за этого. Просто брать и рубить с плеча может каждый, правда иногда администраторы не задаются при этом мыслью о таком ресурсе как срок службы физического железа и что определенные действия как раз сильно сокращают этот показатель, а когда подходит момент что целая полка с дорогостоящими SSD РАЗОМ умирает, начинаются вот эти вот "ой!" ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2020, 19:04 |
|
Состояние БД при усечении ЖТ
|
|||
---|---|---|---|
#18+
Rex12, при усечении не происходит никаких изменений для пользователя и физические размеры файлов не изменяются. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2020, 10:25 |
|
Состояние БД при усечении ЖТ
|
|||
---|---|---|---|
#18+
felix_ff опять таки надо задаться вопросом о необходимости настолько частого перестроения А как часто надо проводить такие перестроения? Достаточно ли будет делать это раз в неделю? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2020, 10:51 |
|
Состояние БД при усечении ЖТ
|
|||
---|---|---|---|
#18+
>А как часто надо проводить такие перестроения? Когда вы сможете замерить вред от фрагментации. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2020, 17:44 |
|
Состояние БД при усечении ЖТ
|
|||
---|---|---|---|
#18+
SERG1257 >Когда вы сможете замерить вред от фрагментации. А каковы критерии этого вреда? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2020, 18:17 |
|
Состояние БД при усечении ЖТ
|
|||
---|---|---|---|
#18+
Rex12, а после перестроения вы не делаете бэкап журнала? После выполнения бэкапа происходит автоматическое усечение, т.е.. освобождение VLF, ничего предпринимать больше не надо. При следующей переиндексации файл не будет расти. Фраза "мне периодически приходится производить усечение ЖТ" говорит о том, что вы под "усечением" можете понимать "сжатие" и путаете эти понятия. Так вот сжатие выполнять не надо, если поступившие записи в журнал своевременно переносятся в резервную копию. Если у вас выполняются какие-то разовые, нерегулярные задачи, которые приводят к увеличению файлов, тогда надо ограничить рост файлов с той целью, что "падение" операции не должно приводить к исчерпанию дискового пространства. Падение сервера и других приложений из-за нехватки диска - большее зло, чем откат транзакции по завершению места в журнале или базе. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2020, 18:44 |
|
Состояние БД при усечении ЖТ
|
|||
---|---|---|---|
#18+
Владислав Колосов а после перестроения вы не делаете бэкап журнала? Делаю. И именно после перестроения файл ЖТ становится становится по размеру сравним с файлом данных. Фраза "мне периодически приходится производить усечение ЖТ" говорит о том, что вы под "усечением" можете понимать "сжатие" и путаете эти понятия. Насколько я понимаю, вот этот скрипт делает именно усечение: DBCC SHRINKFILE (upp_log, 12) ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2020, 18:56 |
|
Состояние БД при усечении ЖТ
|
|||
---|---|---|---|
#18+
>А каковы критерии этого вреда? Внутренняя фрагментация - страницы не полные либо в результате удалений, либо в результате разбиений при переполнении. Итог лишние логические чтения (надо прочитать больше страниц для тех же строк). Кстати проверьте у вас fill factor стоит на нуле (или 100%), потому как если нет, то вы эту самую внутреннюю фрагментацию себе организуете. Внешняя фрагментация - в старые добрые времена когда деревья были большими а диски были реальными железными дисками то непоследовательность страниц приводила к лишним логическим чтениям. В новые злые времена в дисках уже ничего не крутится, а сами они чисто логическое понятие и что где крутится ведает только аллах или контроллер SAN Итого - если вы не можете замерить улучшение производительности после перестроений то зачем ее делать вообще. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2020, 18:59 |
|
|
start [/forum/topic.php?fid=46&fpage=39&tid=1685309]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
34ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
54ms |
get tp. blocked users: |
1ms |
others: | 12ms |
total: | 145ms |
0 / 0 |