Дек 122014
 

Режим FORCE LOGGING нужно обязательно устанавливать на каждой вновь созданной базе, чтобы исключить проведение нелогируемых операций. Это абсолютно необходимо для нормальной работы DataGuard, репликации и успешного восстановления из резервных копий. Но бывают базы (обычно это хранилища данных), на которых ведётся обработка больших объёмов данных, потеря которых некритична (эти данные берутся, например, из других источников, и в случае потери их можно восстановить за приемлемое время, не прибегая к полному восстановлению из бэкапа). В таком случае было бы удобно отключить режим FORCE LOGGING на некоторых табличных пространствах, чтобы получить выигрыш в скорости обработки и уменьшить объём генерации redo-логов.
Проблема в том, что когда FORCE LOGGING включён на уровне всей БД, параметры логирования для отдельных табличных пространств игнорируются. Если же FORCE LOGGING на уровне базы отключить, чтобы создать табличное пространство для временных данных (не путать с temporary tablespace), то весьма велик риск при создании нового табличного пространства забыть явно включить для него FORCE LOGGING, и заметить это слишком поздно.
Решение - небольшой триггер, который не даст совершить подобную ошибку. Рассмотрим пример отключения FORCE LOGGING на одном из табличных пространств: Continue reading »

Июл 202011
 

Рассмотрим практический пример восстановления резервного сервера после длительного простоя. Ситуация такова (см. картинку ниже): в серверной, где он стоял, отключилось электричество. Будем считать, что отключилось оно надолго, например, на неделю. Когда электроснабжение восстановили, появилась возможность активировать Standby, да только за неделю на основной базе накопилось множество архивных логов, и "догнать" standby до актуального состояния непросто. Continue reading »

Фев 212011
 

Если на основном сервере в параметре log_archive_dest_n указана опция delay с ненулевым значением, то при выполнении операций, создающих большой объём redo (например, удаление или вставка большого количества данных в таблицы, импорт, пересекционирование крупных таблиц, etc.), возможна ситуация, при которой за этот временной промежуток нагенерится такое количество логов, что заполнится файловая система для их хранения и база остановится. Самое неприятное, что RMAN не бэкапит логи, которые ещё не были применены на standby-сервере.

Решение проблемы:

Continue reading »

Фев 072011
 

Параметр force_logging влияет на количество информации об изменениях в БД, попадающей в redo logs. Отключение этого режима позволит повысить производительность некоторых операций, например, создание/изменение индексов, загрузку данных с помощью SQL*Loader, изменение таблиц (ALTER TABLE…), и некоторых других, а также уменьшит объём redo.

Проблемы появятся, если мы попытаемя создать standby - сервер для основной базы, на которой отключён этот режим. В таком случае, на резервную БД попадут не все изменения, и при switchover/failover запросто можно получить базу с повреждёнными данными, восстановление которых может быть нетривиальной задачей.

Поэтому перед созданием standby надо включить этот режим: Continue reading »