Nobody1111Есть у меня непонимание, можно ли бэкапить архивлоги на ленту бэкапным ПО по мере их появления, без задержки? Где-то аналогично передаче логов на стендбайный archivelog destination.
Стандартных способов сам не увидел.Насколько помню -- в Oracle7 можно было указать путь к протяжке в LOG_ARCHIVE_DEST. Естественно, эта протяжка ни для чего другого не использовалась
И запускался отдельный процесс для мониторинга конца ленты
Потом от этого отказались. Наверное, не спроста
Вот, например, CONTROLFILE AUTOBACKUP выполняется при изменении физической схемы БД, но только на диск (если настроен). На устройство SBT будет выполнено только в процессе бэкапа. Хотя казалось бы, почему бы и нет, благо все настройки есть
Nobody1111Если стандартно нельзя, то бэкап как средство сохранения данных крупно проигрывает DataGuard-у, так как by design может потерять порцию последних архивлогов вместе с потерей исходной базы.
Это вещи перпендикулярные и друг друга не заменяют.
Стендбай это HA -- т.е. возможность как можно быстрее продолжить работу в случае сбоя. Бэкап для этого как-то не очень подходит
Бэкап по определению содержит копию на какой-то момент в прошлом.

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

А ты когда какую-нибудь файлопомойку (там могут быть очень важные документы) бэкапишь, тоже на каждый чих (создание/изменение документа) бэкап запускаешь?

А что будет при потере оперативных логов?

Еще раз -- в чем принципиальная разница между бэкапом на ленту и архивацией на диск, 2 диска,...?

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

Лента в данном случае понятие условное. Имеется в виду какой-либо Backup Manager, а куда он реально отправляет данные -- дело десятое

Вот только беда еще в том, что тот самый Backup Manager обычно стоит неплохих денег и в конторе он один. И может в данный момент (переключение лога) банально быть занят -- бэкапить ту же файлопомойку, например

д0kВячеслав ЛюбомудровЛента в данном случае понятие условное. Имеется в виду какой-либо Backup Manager, а куда он реально отправляет данные -- дело десятое

Вот только беда еще в том, что тот самый Backup Manager обычно стоит неплохих денег и в конторе он один. И может в данный момент (переключение лога) банально быть занят -- бэкапить ту же файлопомойку, например

нормальные бекап менеджеры содержат промежуточный
дисковый пул , куда сбарасываю от клиентов то, что те бекапят , а потом
разбрасывают все по лентам этих клиентов.
не все клиенты могут бекапить-ресторить со скоростью работы драйва.
Политикой устанивливаются приоритеты для ресурсов бекапов-ресторов,
Нарпимер один или несколько приводов всегда находится в гарячем резерве ,
если вдруг кому то срочно потребуется отресториться ,
тогда клиенту презентуется драйв(ы) на прямую со вставленной туда нужной касетой.Вряд ли челы с такими решениями пасутся на SQL.RU
Разве только что поржать

По-поводу "промежуточного дискового пула" -- много лет назад натолкнулись на "неприятность" в EMC NetWorker 7.4 (древний конечно, но денег на проапгрейдить нам не дадут, удивятся) -- пока кто-то в этот пул пишет, прочитать из него другой сессией нельзя (хоть там и созданы "теневые" RO пулы). Т.е. создание тестовой из бэкапа ждет
Хотя, вроде, продукт Enterprise класса

Сейчас в одной библиотеке навернулась одна из двух протяжек, а она работает с физическими лентами и туда пишется бэкап всех БД (ибо на вторую библиотеку они уже не лезут) и тех ленточек, которые ежедневно отвозятся в другой офис. Опять же, с нее по-воскресеньям-понедельникам выполняется восстановление. От "stage"-пулов для нее давно отказались (и по-причинам, описаным выше и по лицензионным). Короче, ситуация, когда бэкап ждет несколько часов, чтоб получить доступ к ленточке стал ситуацией нередкой

Понятно, что сами себе злобные буратины, но вот так оно и бывает в небольших конторах

Самое смешное, что я не вижу разницы между архивлогом, забэкапленном на [специально выделенном] ленточном девайсе или отправленном через LOG_ARCHIVE_DEST_n на другой диск/контроллер/сайт.

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