Мое понимание операции восстановления SQL состоит в том, что требуется полное резервное копирование, а также все инкрементные резервные копии, выполняемые с тех пор.
Я также понимаю, Log Shippingчто он использует задание SQL для резервного копирования журнала транзакций, который затем восстанавливается на другом экземпляре SQL.
Предположительно, любые резервные копии, выполняемые интегрированным решением (VDP, Networker и т. Д.), Не знают о резервных копиях, выполняемых Log Shipping. Это, по-видимому, приводит к разрыву невосстанавливаемой цепи. Является ли общепринятым разумом возвращаться к резервным копиям на уровне файлов при использовании Log Shipping, или я что-то неправильно понял по пути?
Доставка журналов использует ведение журналов транзакций и отправляет транзакции на другой сервер, который имеет базу данных в режиме ожидания с запланированным заданием, которое запускает и просматривает эти транзакции и применяет те, которые не были применены в тот момент, которые были скопированы с экземпляра первичного сервера БД. , Пока вы не делаете что-то, чтобы разорвать цепочку журналов, все должно быть хорошо, используя другой метод резервного копирования на первичном сервере в сочетании с доставкой журналов. Обычно необходимо выполнить одноразовое полное восстановление на вторичном сервере LS, а затем начать применять журналы от LS.
—
Сок Pimp IT
@PimpJuiceIT Мы используем SQL 2012, наши инкрементные резервные копии усекают журнал базы данных. Предположительно это желательно? Разве наш журнал не будет расти бесконечно иначе?
—
Деррик Мёллер
Прочитайте мой ответ здесь: dba.stackexchange.com/questions/127297/… и посмотрите, не поможет ли это вам. Если у вас есть огромные транзакции, которые увеличивают и увеличивают файл журнала, то этот файл транзакций БД LDF не вернет использованное пространство, пока вы не сократите его. Когда транзакции завершены, пространство внутри файла LDF может использоваться другими транзакциями. Если вы продолжаете усекать журнал БД, то резервное копирование доставки журналов может стать кошмаром, в противном случае вам нужно рассчитать время восстановления в режиме ожидания вторичной БД.
—
Сок Pimp IT
@PimpJuiceIT Мы активно не сокращаем журнал транзакций, это относительно фиксированный размер. Время от времени оно сокращается после технического обслуживания, но не во время «нормальной работы». Допустим, журнал увеличивается на 1 ГБ / час и резервируется каждые два часа. С усечением я полагаю, что журнал будет использовать те же 2 ГБ дискового пространства бесконечно, без усечения я предполагаю, что журнал будет расти каждый час? На данный момент у нас нет вторичного LS, мы оцениваем его как решение для группы доступности AlwaysOn в качестве базы данных отчетов, и я пытаюсь понять ограничения LS.
—
Деррик Мёллер
Понятно ... нет ничего лучше, чем попытать человека, поэтому, если у вас есть возможность на самом деле настроить его и протестировать, чтобы подтвердить, какое решение работает лучше всего, я предлагаю просто попытаться выяснить, какое из них работает, как и что для ваших конкретных потребностей и среды. Если вы завершите журналы транзакций с настройкой LS, неактивная часть транзакции файла журнала будет доступна для повторного использования в этой точке. Если вы настраиваете на каждые 15 минут дамп транзакции, то, например, каждые 15 минут. Я никогда не использовал AlwaysOn лично, но LS отлично подходит для отчетов и DR в моем опыте.
—
Сок Pimp IT