|
Шринк(обрезка) лога транзакций MS SQL 2008/2012 | ☑ | ||
---|---|---|---|---|
0
Kigo_Kigo
21.10.19
✎
10:59
|
Прочитал статью, но остались вопросы
http://catalog.mista.ru/public/168314/ и так что имеем базу на Скуле, 14 гб, веслога 920 гб, нужно срезать лог, как это сделать? по статье не понятно, как нужно сделать полный бекап, средствами Скуля или 1С(выгрузка в dt), после срезки, опять надо сделать полный бекап? Что надо указывать в желаемый объем лога после архивирования(срезки) лога? Или есть какие то другие варианты, что бы безболезненно и быстро? и вопрос еще, что нужно донастроить, чтобы тип лога был полный, но сам обрезался и не рос в таких количествах? ПыСы базу настраивал не я, дали то что есть |
|||
1
Ёпрст
21.10.19
✎
11:03
|
для полной модели восстановления задать в план обслуживания бэкап лога и шринк лога.. всё
|
|||
2
Fish
21.10.19
✎
11:05
|
(0) "по статье не понятно, как нужно сделать полный бекап, средствами Скуля или 1С(выгрузка в dt)," - dt - это не бекап и никогда таковым не являлся. Поэтому всё понятно.
|
|||
3
Ёпрст
21.10.19
✎
11:06
|
от так сделай и забудь о размере лога (имя бд тока своё в скрипт воткни)
http://pics.rsh.ru/img/backUp_xoryv6cy.jpg |
|||
4
Случайный прохожий
21.10.19
✎
11:12
|
(3) Есть скрипт для шринка логов всех пользовательских БД?
|
|||
5
Kigo_Kigo
21.10.19
✎
11:16
|
(2) Что тебе понятно, я перестраховываюсь, выгрузив все базу, в то из чего я ее гарантрованно смогу поднятиь, как пока настроенны бек апы скуля, пока разбераюсь
|
|||
6
Cyberhawk
21.10.19
✎
11:37
|
(5) Гарантии восстановления никогда нет, даже если бекап проверен
|
|||
7
Kigo_Kigo
21.10.19
✎
11:54
|
(6) В том то и вопрос, что я понимаю что этим логом скоро упрусь, пытаюсь выяснить как максимально правильно это сделать,что ничего не запороть, я конечно выгружу базу, сделаю новую бд, разверну, что бы убедится что все сработает, потом буду колдовать
|
|||
8
unregistered
21.10.19
✎
12:03
|
(5) >> то из чего я ее гарантированно смогу поднять.
Если база битая, то вероятность поднять из DT ниже, чем из бекапа СУБД. А вообще гарантий не даёт ни один из способов архивирования. Для этого бекапы регулярно проверяют на разворачиваемость. Но полноценным бекапом является именно бекап, сделанный средствами СУБД. |
|||
9
Креатив
21.10.19
✎
12:09
|
(0)Если боязно делать бакап, то можно отсоединить базу от sql server и заархивировать отдельно mdf и ldf.
|
|||
10
Kigo_Kigo
21.10.19
✎
12:32
|
(9) mdf , то понятно 14 гиг, куда не шло а вот ldf 920 гигов, я его наверно только копировать все выхи буду
|
|||
11
unregistered
21.10.19
✎
12:45
|
(10) Зачем тебе его куда-то копировать?...
Ты вообще суть понимаешь того, что тебе нужно сделать? |
|||
12
Йохохо
21.10.19
✎
12:49
|
(7) тебя скуль защитит сам, он ничего не выкинет нужного
|
|||
13
Провинциальный 1сник
21.10.19
✎
12:50
|
1. Меняем модель восстановления на simple
2. В sql студии уменьшаем размер файла транзакций до необходимого минимума 3. Включаем обратно модель full 4. Настраиваем правильно периодический бэкап журнала транзакций |
|||
14
Провинциальный 1сник
21.10.19
✎
12:50
|
(13) Да, и всё это можно сделать не выгоняя пользователей, в горячем режиме
|
|||
15
Kigo_Kigo
21.10.19
✎
13:44
|
(13) (14) После "процедуры" надо сделать полный бекап, что бы бекапирование восстановилось?
(12) Ну расскажи, что мне нужно сделать? |
|||
16
Провинциальный 1сник
21.10.19
✎
13:48
|
(15) Да, сделать полный бэкап, и после него бэкапы транзакций будут восстановимыми. Обычно есть смысл планировать бэкап базы раз в сутки, и бэкап транзакций раз в полчаса-час в рабочее время.
|
|||
17
Ёпрст
21.10.19
✎
13:54
|
||||
18
Йохохо
21.10.19
✎
13:58
|
(15) полный бэкап и (3), 0 вроде не рекомендуют
|
|||
19
mikecool
21.10.19
✎
14:39
|
судя по размеру базы - бэкапа давно не было )
|
|||
20
Kigo_Kigo
21.10.19
✎
14:41
|
(19) Бекапы делаются ежедневно, но только базы(без лога),настраивал не я, сча со всем этим разбираюсь...
|
|||
21
Kigo_Kigo
22.10.19
✎
10:06
|
(3) Если я воткну этот скрипт к существующей базе более ничего НЕ делая,после бекапа, файл лога автоматом сожмется?
(13) 2. В sql студии уменьшаем размер файла транзакций до необходимого минимума, какой необходимый минимум, бля базы в 14 гигов? и еще есть- сжатие БД лога, там собственно выполняется крипт из (3) можно ли его выполнить на горячуюю? |
|||
22
Йохохо
22.10.19
✎
10:10
|
(21) не автоматом, а по скрипту
"DBCC SHRINKFILE не сжимает файл не более, чем это нужно для хранимых данных. Например, если в файле данных, размер которого составляет 10 МБ, используется 7 МБ, инструкция DBCC SHRINKFILE со значением аргумента target_size, равным 6, сжимает файл только до 7 МБ, а не до 6 МБ." https://docs.microsoft.com/ru-ru/sql/t-sql/database-console-commands/dbcc-shrinkfile-transact-sql?view=sql-server-ver15 |
|||
23
Провинциальный 1сник
22.10.19
✎
10:15
|
(21) Ну поставь пару гигов, чтобы лишний раз не фрагментировался при авторасширении
|
|||
24
Ёпрст
22.10.19
✎
10:24
|
(21)
да да |
|||
25
oleg_km
22.10.19
✎
10:28
|
Для начала определись, испытываешь ли ты потребность в бакапе журнала транзакций. Если нет, то нужно перевести базу в RECOVERY SIMPLE, один раз сделать шринк базы и все. Если да, то все описано в (13)
|
|||
26
Kigo_Kigo
22.10.19
✎
10:45
|
(22) не автоматом, а по скрипту, я это и имел ввиду
по скрипту, как показано в (3) можно сделать и так как я понял, оставляя 500 метров на лог USE [upp_work] GO DBCC SHRINKFILE (N'upp_work_log' , 500) GO (25) Как определится в его потребности? так с порядком действий я определился Полный бекап, (13), (3), полный бекап, настройка бекапа базы раз в сутки, настройка бекапа файла транзакций раз в час(если не большого объема, 500 метров), раз часа в 4- если его сделать 2 гига все а правильно понял ничего не упустил? достаточно сделать только бекап базы(без бекапа лога)? |
|||
27
ДенисЧ
22.10.19
✎
10:49
|
(26) "Как определится в его потребности?"
Если ты собираешься восстанавливать базу на любой момент времени - то бекап журнала нужен. Если тебе достаточно копии на момент бекапа - то журнал не нужен. |
|||
28
Провинциальный 1сник
22.10.19
✎
10:50
|
(26) "Как определится в его потребности?"
Бэкап лога делается очень быстро в отличие от бэкапа базы в целом, и в то же время позволяет восстановить базу на любой момент времени, присутствующий в бэкапах транзакций. При восстановлении происходит сначала восстановление последнего бэкапа базы, а потом последовательно накатываются все транзакции из бэкапов журнала транзакций, до нужного момента. |
|||
29
Kigo_Kigo
22.10.19
✎
10:54
|
(28) Отлично, сколько фалов бекапа транзакций достаточно хранить, если
бекап БД раз сутки(стек 6 штук) Файл транзакций 2 гига, бекап каждые 4 часа, (стек 8 шт будет достаточно? ) |
|||
30
ДенисЧ
22.10.19
✎
10:55
|
(29) А ты умеешь делать восстановление на любой момент? Тебе это может понадобиться?
|
|||
31
Kigo_Kigo
22.10.19
✎
10:58
|
(29) + (28)(27) спасибо за развернутые ответы, теперь все ясно
что сделает скрипт в (3) в отличии от USE [upp_work] GO DBCC SHRINKFILE (N'upp_work_log' , 500) GO ? (30) Лучше иметь , чем не иметь, спеца по скулю всегда можно и за деньги пригласить, в случае какого нить пиздеса, но и сам освою, что уж там и не такие задачи поднимали |
|||
32
Провинциальный 1сник
22.10.19
✎
10:58
|
(29) Ну это сам решай, надо тебе восстанавливать ВЧЕРА на произвольный момент или достаточно СЕГОДНЯ.
(30) Да там сложного ничего нет, в студии той же правой кнопкой мыши на базе, задачи-восстановить, история бэкапов сама подтянется, если на том же сервере. |
|||
33
Йохохо
22.10.19
✎
11:07
|
(31) кмк без транкейтонли операция может быть очень долгой и в регламент такое лучше не пихать
|
|||
34
Kigo_Kigo
22.10.19
✎
11:26
|
(33)а не надо тогда забекапить файл транзакции перед (3) транкейтонли ?
|
|||
35
Случайный прохожий
22.10.19
✎
11:30
|
(17) Спасибо!
|
|||
36
Йохохо
22.10.19
✎
11:35
|
(34) Нет. Без транкейтонли будет _перемещение_ живых записей в начало файла, а это может быть куча ио, что для лога больно. И ио с логом вроде блокирующее для фиксирования транзакций. С ним не будет, но файл не пожмется до бебисайз, но бебисайз и не нужен при нормальной работе.
|
|||
37
Провинциальный 1сник
22.10.19
✎
11:39
|
(31) Шринкать базу по расписанию - плохая идея.
|
|||
38
Йохохо
22.10.19
✎
11:41
|
(37) с транкейт хорошая
|
|||
39
Kigo_Kigo
22.10.19
✎
11:41
|
(36) а, я понял, на момент бекапа базы, мы уже имеем полную БД и ее архивируем, после это смело "прибиваем" файл транзакции, все равно в течении дня у нас есть копии транзакций(на всякий)
(37) почему? я так понял, что шринькать ее надо из 3, так как в (31) будет "больно" и возможно и долго |
|||
40
Провинциальный 1сник
22.10.19
✎
11:44
|
(38) А смысл? Если у тебя лог бэкапится, он транкейтится и потом перезаписывается циклически. И шринкать смысла нет. Установится некий размер и будет поддерживаться.
|
|||
41
xXeNoNx
22.10.19
✎
11:47
|
(1) Пардон, а накуа шринковать?
|
|||
42
xXeNoNx
22.10.19
✎
11:52
|
+(41) Шоб место освободить, которое было съедено после предыдущего бекапа?
|
|||
43
Йохохо
22.10.19
✎
11:53
|
(40) после тяжелых разовых операций он будет занимать неразумное количество места
|
|||
44
Kigo_Kigo
22.10.19
✎
11:53
|
(40) То есть делаем (13),даем логу 2 гига, настраиваем (16),(бекап лога раз 4 часа), Всё?
|
|||
45
xXeNoNx
22.10.19
✎
11:54
|
(43) )) после тяжелых, разовых..., а бекап-то предполагается делать каждый день...
|
|||
46
Провинциальный 1сник
22.10.19
✎
11:54
|
(42) А не надо его освобождать. Оно всё равно используется новыми транзакциями. А будешь шринкать - получишь фрагментацию файла при росте, а оно надо?
(43) Вот после тяжелых разовых и шринкнуть до типичного размера. А по расписанию не надо. |
|||
47
xXeNoNx
22.10.19
✎
11:56
|
(46) "фрагментацию файла при росте" - где вероятность того что этого уже нет?
|
|||
48
Йохохо
22.10.19
✎
11:56
|
(44) повесь (3) и лог сам с течением времени займёт сколько ему нужно, зачем насильничать
(46) ты, как ДБА, может и не узнать. А по расписанию удаление сплошного несегментированного куска в конце изи бризи |
|||
49
Провинциальный 1сник
22.10.19
✎
11:57
|
(47) Пусть оно есть, но зачем усугублять?)
|
|||
50
Kigo_Kigo
22.10.19
✎
11:59
|
(48) (3) уже подвесил, пока не вкючил, пока вс точно не определится, а то пока в последовательности и мера расходимся во мнениях
|
|||
51
Йохохо
22.10.19
✎
12:00
|
(50) просто наблюдай
|
|||
52
Ёпрст
22.10.19
✎
12:01
|
(50) вс - это кто ?
|
|||
53
ADirks
22.10.19
✎
12:02
|
(0) Про бэкапы и логи почитай лучше Спешурика: http://catalog.mista.ru/public/173494/
Если не знаешь, зачем тебе recovery mode "Full", то ставь Simple. |
|||
54
Йохохо
22.10.19
✎
12:04
|
какая то галка еще нужна, разрешить быструю инициализацию нового места под лог и файлики при росте, или это ту олд
|
|||
55
Kigo_Kigo
22.10.19
✎
12:09
|
(52) *пока всё точно не определится,а то пока в последовательности и мерах расходимся во мнениях (пишу одним пальцем, обед) :)
(54) ога, стояла эта галка, которая раздула лог уже до 930 гиг |
|||
56
Йохохо
22.10.19
✎
12:14
|
(55) нет) эта галка отменяет забивание нулями новых кусков, что долго
|
|||
57
Kigo_Kigo
22.10.19
✎
12:17
|
Давай уже покончим с этим, и так скрипты для каждой из баз в (3) я написал, после бекапа базы, их можно запускать одновременно или лучше последовательно?
переводим в симпле Ограничиваем файл транзакций в 2 гига, Перводим в фулл Настраиваем бекап лога каждые 4 часа я так правильно понял, этого все будет достаточно? |
|||
58
oleg_km
22.10.19
✎
12:20
|
(57) После перевода в фулл нужно вроде сделать хотя бы один полный или дифф бакап, только потом можно будет сделать бакап журнала транзакций
|
|||
59
ADirks
22.10.19
✎
12:23
|
(57) Неправильно ты понял. Почитай литературки сначала. И не ставь Full.
|
|||
60
Ёпрст
22.10.19
✎
12:23
|
(57) ничего в симпл переводить не надо
|
|||
61
Kigo_Kigo
22.10.19
✎
12:27
|
(60) переводы симпл/фулл убираем из этой цепочки, и да я посмотрел, что меня сервак не ограничивает, органичить файл лога и при фулл
(59) фулл уже стоял до меня, тот кто это настраивал файлу лога дал размер на весь "кошелек", то есть на весь объем диска, причем для всех баз... |
|||
62
ADirks
22.10.19
✎
12:32
|
(61) Если ты ограничишь размер лога при full-модели, и не примешь действий к освобождению файла лога, то база просто упадёт при достижении макс. объёма лога.
Пространство в лог-файле освобождается при полном бэкапе. |
|||
63
Провинциальный 1сник
22.10.19
✎
12:34
|
(62) "Пространство в лог-файле освобождается при полном бэкапе."
Нет. При бэкапе журнала транзакций. При полном, то есть бэкапе текущего состояния базы, журнал транзакций не чистится и все чекпойнты остаются в неприкосновенности. |
|||
64
ADirks
22.10.19
✎
12:41
|
(63) тьфу... конечно же при бэкапе журнала.
|
|||
65
Kigo_Kigo
22.10.19
✎
12:55
|
(62) (63) (64) Вы меня окончатель запутали, что делать то?
Бекап файла транзакций уже сделать не могу, 920 гигов, места нет |
|||
66
Провинциальный 1сник
22.10.19
✎
12:59
|
(65) Не нужен тебе бэкап текущего журнала транзакций. Делай как в (13)
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |