<

IT: Шринк(обрезка) лога транзакций MS SQL 2008/2012

Войти
  1. Kigo_Kigo

    21-10-2019 10:59

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

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

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

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

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

  2. Ёпрст

    21-10-2019 11:03

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

  3. Fish

    21-10-2019 11:05

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

  4. Ёпрст

    21-10-2019 11:06

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

  5. Случайный прохожий

    21-10-2019 11:12

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

  6. Kigo_Kigo

    21-10-2019 11:16

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

  7. Cyberhawk

    21-10-2019 11:37

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

  8. Kigo_Kigo

    21-10-2019 11:54

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

  9. unregistered

    21-10-2019 12:03

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

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

  10. Креатив

    21-10-2019 12:09

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

  11. Kigo_Kigo

    21-10-2019 12:32

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

  12. unregistered

    21-10-2019 12:45

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

  13. Йохохо

    21-10-2019 12:49

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

  14. Провинциальный 1сник

    21-10-2019 12:50

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

  15. Провинциальный 1сник

    21-10-2019 12:50

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

  16. Kigo_Kigo

    21-10-2019 13:44

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

  17. Провинциальный 1сник

    21-10-2019 13:48

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

  18. Ёпрст

    21-10-2019 13:54

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

  19. Йохохо

    21-10-2019 13:58

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

  20. mikecool

    21-10-2019 14:39

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

  21. Kigo_Kigo

    21-10-2019 14:41

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