В настоящее время я использую базу данных Oracle 11g на RHEL5. Моя база данных генерирует много архивных журналов в день, даже если в базе данных небольшое количество изменений (около 500 транзакций в день). Я также проверяю размер своего файла данных (табличное пространство пользователей); его размер увеличивается примерно на 20 МБ в день, но архивный журнал генерирует от 5 до 10 ГБ в день.
Может ли кто-нибудь сказать мне, что вызывает эту проблему? Есть какие-то решения, чтобы проверить, почему он генерирует больше в архиве? Как его уменьшить?
Наилучшие пожелания,
Сариф
Возможно, стоит посмотреть на временные метки в файлах и посмотреть, равномерно ли они распределены или вы получаете группу, сгенерированную за один раз (возможно, соответствующую некоторой пакетной активности).
Запрос, подобный следующему, покажет вам текущие сеансы, генерирующие повтор.
select s.sid, n.name, s.value, sn.username, sn.program, sn.type, sn.module
from v$sesstat s
join v$statname n on n.statistic# = s.statistic#
join v$session sn on sn.sid = s.sid
where name like '%redo entries%'
order by value desc;
Если у вас есть лицензия на AWR, вы также можете посмотреть таблицы истории.
Каков общий размер базы данных? Я подозреваю, что некоторые большие таблицы усекаются и перезагружаются с очень похожими данными на ежедневной основе.
Как предложено в другой поток, вы можете использовать LogMiner, чтобы узнать, какие транзакции регистрируются:
http://www.oracle.com/technology/oramag/oracle/05-jul/o45dba.html
UPDATE
операторы не обязательно изменяют размер таблицы или строки, но должны фиксироваться при повторном выполнении, что и определяет размер архивных журналов.
Незавершенные транзакции - те, которые откатываются - не вносят постоянных изменений в базу данных, но по-прежнему генерируют повтор.
Табличная активность DML, которая вызывает обновление индексов (много ли делает приложение DELETE
ing и INSERT
ing?) также вызывают обновление индексов, как и UPDATE
операторы, которые изменяют индексированные столбцы.
Короче говоря, измерение размера архивного журнала - это мера активности изменений, а рост - это другой и часто не связанный показатель. Что вы можете сделать, это запросить ALL_TAB_MODIFICATIONS
чтобы точно показать, насколько заняты ваши таблицы с точки зрения записи с момента последнего анализа, как в 10g +, все таблицы автоматически отслеживаются на предмет активности DML.
Обновление материализованного представления может привести к большому количеству повторов. Просто мысль.
Простое решение этой проблемы -
1) Настройка отслеживания изменений блоков в Oracle для ускорения инкрементного резервного копирования
http://download.oracle.com/docs/cd/B28359_01/backup.111/b28270/rcmbckba.htm # BRADV8125
2) Запустите инкрементное резервное копирование уровня 1 БД и архивных журналов (например, 2 раза в день) с добавлением следующей строки в конец сценария RMAN:
DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE -2';
If RMAN significantly reduces the query run speed of your database, you can add to the BACKUP DATABASE string this keywords: DURATION 1:00 PARTIAL MINIMIZE LOAD
Where, 1:00 - time 1 hour for which should be backed up.