Прочитал статью, но остались вопросы

http://catalog.mista.ru/public/168314/

и так что имеем базу на Скуле, 14 гб, веслога 920 гб, нужно срезать лог, как это сделать?
по статье не понятно, как нужно сделать полный бекап, средствами Скуля или 1С(выгрузка в dt), после срезки, опять надо сделать полный бекап?
Что надо указывать в желаемый объем лога после архивирования(срезки) лога?
Или есть какие то другие варианты, что бы безболезненно и быстро?

и вопрос еще, что нужно донастроить, чтобы тип лога был полный, но сам обрезался и не рос в таких количествах?

ПыСы базу настраивал не я, дали то что есть

для полной модели восстановления задать в план обслуживания бэкап лога и шринк лога.. всё

(0) "по статье не понятно, как нужно сделать полный бекап, средствами Скуля или 1С(выгрузка в dt)," - dt - это не бекап и никогда таковым не являлся. Поэтому всё понятно.

от так сделай и забудь о размере лога (имя бд тока своё в скрипт воткни)
http://pics.rsh.ru/img/backUp_xoryv6cy.jpg

(3) Есть скрипт для шринка логов всех пользовательских БД?

(2) Что тебе понятно, я перестраховываюсь, выгрузив все базу, в то из чего я ее гарантрованно смогу поднятиь, как пока настроенны бек апы скуля, пока разбераюсь

(5) Гарантии восстановления никогда нет, даже если бекап проверен

(6) В том то и вопрос, что я понимаю что этим логом скоро упрусь, пытаюсь выяснить как максимально правильно это сделать,что ничего не запороть, я конечно выгружу базу, сделаю новую бд, разверну, что бы убедится что все сработает, потом буду колдовать

(5) >> то из чего я ее гарантированно смогу поднять.

Если база битая, то вероятность поднять из DT ниже, чем из бекапа СУБД.
А вообще гарантий не даёт ни один из способов архивирования. Для этого бекапы регулярно проверяют на разворачиваемость.
Но полноценным бекапом является именно бекап, сделанный средствами СУБД.

(0)Если боязно делать бакап, то можно отсоединить базу от sql server и заархивировать отдельно mdf и ldf.

(9) mdf , то понятно 14 гиг, куда не шло а вот ldf 920 гигов, я его наверно только копировать все выхи буду

(10) Зачем тебе его куда-то копировать?...
Ты вообще суть понимаешь того, что тебе нужно сделать?

(7) тебя скуль защитит сам, он ничего не выкинет нужного

1. Меняем модель восстановления на simple
2. В sql студии уменьшаем размер файла транзакций до необходимого минимума
3. Включаем обратно модель full
4. Настраиваем правильно периодический бэкап журнала транзакций

(13) Да, и всё это можно сделать не выгоняя пользователей, в горячем режиме

(13) (14) После "процедуры" надо сделать полный бекап, что бы бекапирование восстановилось?
(12) Ну расскажи, что мне нужно сделать?

(15) Да, сделать полный бэкап, и после него бэкапы транзакций будут восстановимыми. Обычно есть смысл планировать бэкап базы раз в сутки, и бэкап транзакций раз в полчаса-час в рабочее время.

(4) http://avecaes.blogspot.com/2018/08/blog-post.html

(15) полный бэкап и (3), 0 вроде не рекомендуют

судя по размеру базы - бэкапа давно не было )

(19) Бекапы делаются ежедневно, но только базы(без лога),настраивал не я, сча со всем этим разбираюсь...

(3) Если я воткну этот скрипт к существующей базе более ничего НЕ делая,после бекапа, файл лога автоматом сожмется?
(13) 2. В sql студии уменьшаем размер файла транзакций до необходимого минимума, какой необходимый минимум, бля базы в 14 гигов?

и еще есть- сжатие БД лога, там собственно выполняется крипт из (3) можно ли его выполнить на горячуюю?

(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

(21) Ну поставь пару гигов, чтобы лишний раз не фрагментировался при авторасширении

(21)
да
да

Для начала определись, испытываешь ли ты потребность в бакапе журнала транзакций. Если нет, то нужно перевести базу в RECOVERY SIMPLE, один раз сделать шринк базы и все. Если да, то все описано в (13)

(22) не автоматом, а по скрипту, я это и имел ввиду
по скрипту, как показано в (3) можно сделать и так как я понял, оставляя 500 метров на лог
USE [upp_work]
GO
DBCC SHRINKFILE (N'upp_work_log' , 500)
GO
(25) Как определится в его потребности?


так с порядком действий я определился
Полный бекап, (13), (3), полный бекап, настройка бекапа базы раз в сутки, настройка бекапа файла транзакций раз в час(если не большого объема, 500 метров), раз часа в 4- если его сделать 2 гига

все а правильно понял ничего не упустил?
достаточно сделать только бекап базы(без бекапа лога)?

(26) "Как определится в его потребности?"
Если ты собираешься восстанавливать базу на любой момент времени - то бекап журнала нужен. Если тебе достаточно копии на момент бекапа - то журнал не нужен.

(26) "Как определится в его потребности?"
Бэкап лога делается очень быстро в отличие от бэкапа базы в целом, и в то же время позволяет восстановить базу на любой момент времени, присутствующий в бэкапах транзакций. При восстановлении происходит сначала восстановление последнего бэкапа базы, а потом последовательно накатываются все транзакции из бэкапов журнала транзакций, до нужного момента.

(28) Отлично, сколько фалов бекапа транзакций достаточно хранить, если
бекап БД раз сутки(стек 6 штук)
Файл транзакций 2 гига, бекап каждые 4 часа, (стек 8 шт будет достаточно? )

(29) А ты умеешь делать восстановление на любой момент? Тебе это может понадобиться?

(29) + (28)(27) спасибо за развернутые ответы, теперь все ясно
что сделает скрипт в (3) в отличии от
USE [upp_work]
GO
DBCC SHRINKFILE (N'upp_work_log' , 500)
GO
?
(30) Лучше иметь , чем не иметь, спеца по скулю всегда можно и за деньги пригласить, в случае какого нить пиздеса, но и сам освою, что уж там и не такие задачи поднимали

(29) Ну это сам решай, надо тебе восстанавливать ВЧЕРА на произвольный момент или достаточно СЕГОДНЯ.
(30) Да там сложного ничего нет, в студии той же правой кнопкой мыши на базе, задачи-восстановить, история бэкапов сама подтянется, если на том же сервере.

(31) кмк без транкейтонли операция может быть очень долгой и в регламент такое лучше не пихать

(33)а не надо  тогда  забекапить файл транзакции перед (3) транкейтонли ?

(17) Спасибо!

(34) Нет. Без транкейтонли будет _перемещение_ живых записей в начало файла, а это может быть куча ио, что для лога больно. И ио с логом вроде блокирующее для фиксирования транзакций. С ним не будет, но файл не пожмется до бебисайз, но бебисайз и не нужен при нормальной работе.

(31) Шринкать базу по расписанию - плохая идея.

(37) с транкейт хорошая

(36) а, я понял, на момент бекапа базы, мы уже имеем полную БД и ее архивируем, после это смело "прибиваем" файл транзакции, все равно в течении дня у нас есть копии транзакций(на всякий)
(37) почему? я так понял, что шринькать ее надо из 3, так как в (31) будет "больно" и возможно и долго

(38) А смысл? Если у тебя лог бэкапится, он транкейтится и потом перезаписывается циклически. И шринкать смысла нет. Установится некий размер и будет поддерживаться.

(1) Пардон, а накуа шринковать?

+(41) Шоб место освободить, которое было съедено после предыдущего бекапа?

(40) после тяжелых разовых операций он будет занимать неразумное количество места

(40) То есть делаем (13),даем логу 2 гига, настраиваем (16),(бекап лога раз 4 часа), Всё?

(43) )) после тяжелых, разовых..., а бекап-то предполагается делать каждый день...

(42) А не надо его освобождать. Оно всё равно используется новыми транзакциями. А будешь шринкать - получишь фрагментацию файла при росте, а оно надо?
(43) Вот после тяжелых разовых и шринкнуть до типичного размера. А по расписанию не надо.

(46) "фрагментацию файла при росте" - где вероятность того что этого уже нет?

(44) повесь (3) и лог сам с течением времени займёт сколько ему нужно, зачем насильничать
(46) ты, как ДБА, может и не узнать. А по расписанию удаление сплошного несегментированного куска в конце изи бризи

(47) Пусть оно есть, но зачем усугублять?)

(48) (3) уже подвесил, пока не вкючил, пока вс точно не определится, а то пока в последовательности и мера расходимся во мнениях

(50) просто наблюдай

(50) вс - это кто ?

(0) Про бэкапы и логи почитай лучше Спешурика: http://catalog.mista.ru/public/173494/

Если не знаешь, зачем тебе recovery mode "Full", то ставь Simple.

какая то галка еще нужна, разрешить быструю инициализацию нового места под лог и файлики при росте, или это ту олд

(52) *пока всё точно не определится,а то пока в последовательности и мерах расходимся во мнениях (пишу одним пальцем, обед) :)
(54) ога, стояла эта галка, которая раздула лог уже до 930 гиг

(55) нет) эта галка отменяет забивание нулями новых кусков, что долго

Давай уже покончим с этим, и так скрипты для каждой из баз в (3) я написал, после бекапа базы, их можно запускать одновременно или лучше последовательно?
переводим в симпле
Ограничиваем файл транзакций в 2 гига,
Перводим в фулл
Настраиваем бекап лога каждые 4 часа

я так правильно понял, этого все будет достаточно?

(57) После перевода в фулл нужно вроде сделать хотя бы один полный или дифф бакап, только потом можно будет сделать бакап журнала транзакций

(57) Неправильно ты понял. Почитай литературки сначала. И не ставь Full.

(57) ничего в симпл переводить не надо

(60) переводы симпл/фулл убираем из этой цепочки, и да я посмотрел, что меня сервак не ограничивает, органичить файл лога и при фулл
(59) фулл уже стоял до меня, тот кто это настраивал файлу лога дал размер на весь "кошелек", то есть на весь объем диска, причем для всех баз...

(61) Если ты ограничишь размер лога при full-модели, и не примешь действий к освобождению файла лога, то база просто упадёт при достижении макс. объёма лога.

Пространство в лог-файле освобождается при полном бэкапе.

(62) "Пространство в лог-файле освобождается при полном бэкапе."
Нет. При бэкапе журнала транзакций. При полном, то есть бэкапе текущего состояния базы, журнал транзакций не чистится и все чекпойнты остаются в неприкосновенности.

(63) тьфу... конечно же при бэкапе журнала.

(62) (63) (64) Вы меня окончатель запутали, что делать то?
Бекап файла транзакций уже сделать не могу, 920 гигов, места нет

(65) Не нужен тебе бэкап текущего журнала транзакций. Делай как в (13)