Программное обеспечение для резервного копирования SQL (VDP) и доставка журналов

227
Derrick Moeller

Мое понимание операции восстановления SQL состоит в том, что требуется полное резервное копирование, а также все инкрементные резервные копии, выполняемые с тех пор.

Я также понимаю, Log Shippingчто он использует задание SQL для резервного копирования журнала транзакций, который затем восстанавливается на другом экземпляре SQL.

Предположительно, любые резервные копии, выполняемые интегрированным решением (VDP, Networker и т. Д.), Не знают о резервных копиях, выполняемых Log Shipping. Это, по-видимому, приводит к разрыву невосстанавливаемой цепи. Является ли общепринятым решением возвращаться к резервным копиям на уровне файлов при использовании Log Shipping, или я что-то не так понял по пути?

0
Доставка журналов использует ведение журналов транзакций и отправляет транзакции на другой сервер, который имеет базу данных в режиме ожидания с запланированным заданием, которое запускает и просматривает эти транзакции и применяет те, которые не были применены в тот момент, которые были скопированы с экземпляра первичного сервера БД. , Пока вы не делаете что-то, чтобы разорвать цепочку журналов, все должно быть хорошо, используя другой метод резервного копирования на первичном сервере в сочетании с доставкой журналов. Обычно необходимо выполнить одноразовое полное восстановление на вторичном сервере LS, а затем начать применять журналы от LS. Pimp Juice IT 6 лет назад 0
@PimpJuiceIT Мы используем SQL 2012, наши инкрементные резервные копии усекают журнал базы данных. Предположительно, это желательно? Разве наш журнал не будет расти бесконечно иначе? Derrick Moeller 6 лет назад 0
Прочитайте мой ответ здесь: https://dba.stackexchange.com/questions/127297/how-does-a-transaction-log-backup-deal-with-active-log/127302#127302 и посмотрите, пояснит ли это для вас , Если у вас есть огромные транзакции, которые увеличивают и увеличивают файл журнала, то этот файл транзакций БД LDF не вернет использованное пространство, пока вы не сократите его. После завершения транзакций пространство внутри файла LDF может использоваться другими транзакциями. Если вы продолжаете усекать журнал БД, то резервное копирование доставки журналов может стать кошмаром, в противном случае вам нужно рассчитать время восстановления в режиме ожидания вторичной БД. Pimp Juice IT 6 лет назад 0
@PimpJuiceIT Мы активно не сокращаем журнал транзакций, это относительно фиксированный размер. Время от времени оно сокращается после технического обслуживания, но не во время «нормальной работы». Допустим, журнал увеличивается на 1 ГБ / час и резервируется каждые два часа. С усечением я полагаю, что журнал будет использовать те же 2 ГБ дискового пространства бесконечно, без усечения я предполагаю, что журнал будет расти каждый час? На данный момент у нас нет вторичного LS, мы оцениваем его как решение по сравнению с группой доступности AlwaysOn в качестве базы данных отчетов, и я пытаюсь понять ограничения LS. Derrick Moeller 6 лет назад 0
Понятно ... нет ничего лучше, чем попытать человека, поэтому, если у вас есть возможность на самом деле настроить его и протестировать, чтобы подтвердить, какое решение работает лучше всего, я предлагаю просто попытаться выяснить, какое из них работает, как или что-то для ваших конкретных потребностей и среды. Если вы завершаете журналы транзакций с настройкой LS, неактивная часть транзакции файла журнала будет доступна для повторного использования в этой точке. Если вы настраиваете на каждые 15 минут дамп транзакции, то, например, каждые 15 минут. Я никогда не использовал AlwaysOn лично, но LS отлично подходит для отчетов и DR в моем опыте. Pimp Juice IT 6 лет назад 0
В одной среде .... У меня были задания резервного копирования и копирования LS, выполняемые раз в 15 минут, я полагаю. Затем на вторичной стороне для DR мы сделали ночное восстановление LS, чтобы применить файлы TRN к БД. Для отчетности мы делали один раз в ночь в 20:00 или около того, и все знали, что данные отчетов отстали на 24 часа, что было найдено в этой бизнес-среде, и к 20:00 все производственные данные БД были к тому времени введены, и бизнес был закрыт. В дополнение к этому, я также настроил задание полного резервного копирования (из prod), чтобы скопировать сжатый файл BAK на вторичный общий ресурс на случай необходимости восстановления на вторичном. Pimp Juice IT 6 лет назад 0

0 ответов на вопрос

Похожие вопросы