DB2 Online Database Backup

Question

В настоящее время у меня есть база данных объемом более 200 ГБ, которая использует встроенное резервное копирование DB2 для ежедневного резервного копирования (и, надеюсь, не для восстановления - lol). Но поскольку для резервного копирования сейчас требуется более 2,5 часов, я ищу стороннюю Утилита резервного копирования и восстановления. Версия 8.2 FP 14 Но я скоро перейду на 9.1, и у меня также есть несколько баз данных 9.5 для резервного копирования и восстановления. Каковы лучшие инструменты, которые вы использовали для этой цели?

Спасибо!

Answer 1

На самом деле есть только два способа сделать резервное копирование, и, что более важно, восстановление выполняется быстрее: 1. резервное копирование данных и / или 2. иметь больший канал к носителю резервного копирования

Я думаю, что вы получили много предложений о том, как уменьшить объем данных, для которых вы создаете резервную копию. По сути, вы должны создавать стратегию резервного копирования, основанную на относительно нечастом полном резервном копировании и гораздо более частом резервном копировании измененных (с момента последнего полного резервного копирования) данных. Я рекомендую вам взглянуть на мастер "Сконфигурировать автоматическое обслуживание" в Центре управления DB2. Это поможет вам в создании автоматических резервных копий и других утилит, таких как REORG, которые Antonio предлагает. Такие вещи, как сжатие, очевидно, могут помочь, так как объем данных намного меньше. Однако не все редакции DB2 предлагают сжатие. Например, DB2 Express-C нет. Честно говоря, сжатие в базе данных объемом 200 ГБ в любом случае может не стоить того, и именно поэтому бесплатные СУБД, такие как DB2 Express-C , не предлагают сжатие.

Что касается открытия большего канала для вашей резервной копии, вы сначала должны решить, собираетесь ли вы сделать резервную копию на диск или на ленту. Существует большая разница в скорости (очевидно, диск намного быстрее). Во-вторых, DB2 может парализовать резервные копии. Таким образом, если у вас есть несколько устройств для резервного копирования, он будет одновременно выполнять резервное копирование на все из них, т. Е. Ваше затраченное время будет намного меньше в зависимости от того, сколько устройств вы должны использовать для решения проблемы. И снова Центр управления DB2 может помочь вам настроить его.

Answer 2

Прежде чем рассматривать сторонние инструменты, которые, я сомневаюсь, слишком помогли бы, я бы рассмотрел несколько оптимизаций.

1) Вы использовали REORG в своих таблицах и индексах? Это сократит информацию и минимизирует количество используемых страниц;

2) Если вы можете сделать резервную копию на нескольких дисках одновременно. Этого легко добиться, запустив db2 backup db mydb /mnt/disk1 /mnt/disk2 /mnt/disk3 ...

3) DB2 должна хорошо поработать над самонастройкой, но вы всегда можете поэкспериментировать с опциями WITH num_buffers BUFFERS, BUFFER buffer-size и PARALLELISM n. Но опять же, как правило, DB2 делает лучше самостоятельно;

4) Рассмотрите возможность выполнения ежедневного инкрементного резервного копирования и полного резервного копирования один раз по субботам или воскресеньям;

5) UTIL_IMPACT_PRIORITY и UTIL_IMPACT_LIM позволяют регулировать процесс резервного копирования, чтобы он не слишком сильно влиял на вашу обычную рабочую нагрузку. Это полезно, если ваша основная задача - не время как таковое, а производительность вашего сервера данных при резервном копировании;

6) Сжатие данных в DB2 9 действительно может творить чудеса, когда речь идет об уменьшении размеров данных, которые необходимо резервировать. Я видел очень впечатляющие результаты и очень рекомендую его, если вы можете перейти на версию 9.1 или, что еще лучше, 9.5.

Answer 3

Одна вещь, которая поможет, - перейти на DB2 версии 9 и включить сжатие. Размер резервной копии будет уменьшаться (до 70-80% на уровне таблицы), что должно сократить время резервного копирования. Конечно, если ваша база данных непрерывно растет, вы скоро столкнетесь с проблемами снова, но тогда вам подойдет архивирование данных.

Answer 4

Попробуйте High Performance Unload (HPU) - это был отдельный продукт от Infotel, теперь доступный как часть Optim data studio - размещение здесь https://www.ibm.com/developerworks/mydeveloperworks/blogs/idm/date/200910?lang=en

Answer 5

Сторонний пакет резервного копирования, вероятно, не сильно поможет вашей скорости. Убедитесь, что вы не выполняете полное резервное копирование каждые 2 часа - это, вероятно, первый шаг.

После этого посмотрите, куда вы записываете свою резервную копию. Это локальный диск, а не сетевой диск? Используются ли шпиндели для чего-то еще? Резервное копирование не требует большого количества операций поиска, но требует больших операций записи, поэтому вы, вероятно, захотите избежать RAID 5 и использовать большие размеры чередующихся полос, чтобы максимизировать пропускную способность.

Естественно, рано или поздно вам придется делать полное резервное копирование, но, надеюсь, вы сможете найти окно, когда нагрузка мала, и вы можете жить с более длительным периодом времени между резервными копиями. Выполняйте полное резервное копирование в течение 4–6 часов, когда обычные инкременты выключены, а затем делайте инкрементальные операции на основе этого в остальное время.

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

Answer 6

Я сомневаюсь, что вы можете ускорить процесс с помощью другого инструмента резервного копирования. Как упоминает Майк, вы можете добавить TSM в стек, но это вряд ли ускорит выполнение резервного копирования.

На вашем месте я бы посмотрел, где хранятся файлы резервных копий: они используют те же дисковые шпиндели, что и сама база данных? Если это так: посмотрите, можете ли вы сохранить файлы резервных копий в области хранения, которая не предназначена для доступа во время окна резервного копирования.

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

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

Answer 7

Это не «сторонний» продукт, но любой, кого я когда-либо видел при использовании DB2, использует Tivoli Storage Manager для хранения своих резервных копий базы данных.

Большинство магазинов настраивают ведение журнала архивов в TSM, поэтому вам нужно только делать «большую» резервную копию каждую неделю или около того.

Поскольку это также продукт IBM, вам не придется беспокоиться о его работе со всеми различными вариантами DB2, которые у вас есть.

Недостатком является то, что это продукт IBM. :) Не уверен, что это ($) имеет значение для вас.