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

Question

У меня есть хранилище данных db2 ese 9.7 non-dpf, использующее сжатие данных с 20 ТБ данных, которое получает 100 миллионов строк в день при нагрузках каждые 10 минут и еще один миллион в день при 50 000 импортах каждый день. Кроме того, существует небольшой объем транзакционных данных, связанных с двумя другими большими наборами данных.

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

Однако, похоже, что для оперативного резервного копирования табличных пространств требуется первоначальное автономное резервное копирование. И это проблема, даже если я могу перенаправить автономное резервное копирование в / dev / null, автономное резервное копирование займет около 48 часов простоя. Что недопустимо. И может потребоваться снова в какой-то момент в будущем.

В какой-то момент мы, вероятно, разделим это на 8+ разделов, и это помогло бы и этому, и сборкам индекса загрузки. Но это может не произойти какое-то время, и трудно оправдать задачи, которые не нужны в первую очередь.

РЕДАКТИРОВАТЬ. Причина, по которой мы изначально не использовали DPF, и почему это не является основной проблемой для наших запросов, состоит в том, что более 99% наших запросов попадают в сводные таблицы, а 1% - в глубину. Таблица с 3+ миллиардами строк в месяц почти всегда может использовать преимущества разбиения таблиц, MDC и индексов, чтобы сканировать только гораздо меньшее количество. Это приводит к тому, что традиционная эвристика, касающаяся количества данных на процессор, не всегда применима.

Есть ли способ обойти это требование автономного резервного копирования? Какие-нибудь сторонние инструменты, которые могут мне помочь? Любые другие предложения?

Answer 1

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

Обычно это относится к области использования разделенных зеркал или снимков науровень диска.Это, конечно, требует, чтобы ваша дисковая подсистема поддерживала эту функцию (если вы не используете программное обеспечение, такое как Veritas Volume Manager), И чтобы у вас была возможность фактически включить это.DB2 полностью поддерживает это, и это очень полезно.Я сделал это с помощью EMC Symmetrix и Clariion;но для этого требуется короткое «отключение», когда вы замораживаете ввод-вывод базы данных, чтобы выдать команды операционной системы для обработки разбивающихся зеркал.

В v9.5 DB2 добавила функцию Advanced Copy Services (ACS), который позволяет поставщикам хранилищ интегрироваться в команду BACKUP DATABASE.IBM поддерживает это с некоторыми из своих подсистем хранения, и NetApp также очень быстро добавила поддержку для этого.Довольно удивительно сказать «BACKUP DATABASE HUGEDB USE SNAPSHOT» и смотреть, как это занимает 10 секунд.А затем "ВОССТАНОВИТЬ БАЗУ ДАННЫХ HUGEDB ИСПОЛЬЗОВАТЬ SNAPSHOT, СДЕЛАННЫЕ НА отметка времени ".