Последствия АРХИВЕЛОГ - PullRequest
       8

Последствия АРХИВЕЛОГ

3 голосов
/ 19 января 2011

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

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

Их ответ состоял в том, что было бы возможно, если бы мы решили включить ARCHIVELOG, что имело бы последствия для производительности.

Я совершенно незнаком с этим так же, как со способами резервного копирования.

Какие другие варианты вы, ребята, порекомендуете для резервного копирования моих схем более эффективным или, по крайней мере, не таким интенсивным способом простоя?

спасибо!

е.

1 Ответ

8 голосов
/ 19 января 2011

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

На производственных экземплярах обычно возникает требование НЕ потерять данные (это будет основной целью администратора баз данных). В этом случае аргумент о производительности является спорным, вы включите ARCHIVELOG, потому что это требование. Тогда вы можете создавать «горячие» резервные копии, они не сложнее, чем «холодные», если вы используете RMAN, они также не будут очищать кэш базы данных (повышая производительность). Вы можете использовать RMAN для создания инкрементных резервных копий (вместо полного резервного копирования), которые будут регистрировать изменения только с момента последнего резервного копирования.

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

...