Во-первых, анализ проблемы
Вы получили предупреждение системы SYSAUX использование табличного пространства превышает 90%, использование табличного пространства нормально не должна быть настолько высокой, необходимо проанализировать причину проблемы.
View SYSAUX табличного пространства занимают по большей части, находится на счет для крупнейших данных AWR, объем данных для достижения 29G.
select OCCUPANT_NAME,OCCUPANT_DESC,SPACE_USAGE_KBYTES/1024 USAGE_MB
from V$SYSAUX_OCCUPANTS order by SPACE_USAGE_KBYTES desc;
Эта система, как правило, нагрузка невелика, нормально так много данных AWR. Глядя на высокий контраст загрузки системы, обнаружил, что система AWR данные только о 7G.
View SYSAUX табличное пространство занимает самое большое пространство имен объектов
SELECT D.SEGMENT_NAME, D.SEGMENT_TYPE,SUM(BYTES)/1024/1024 SIZE_MB
FROM DBA_SEGMENTS D
WHERE D.TABLESPACE_NAME = 'SYSAUX'
GROUP BY D.SEGMENT_NAME, D.SEGMENT_TYPE
ORDER BY SIZE_MB DESC;
Выберите большую таблицу, в которой данные запроса, обнаружили, что есть так много данных snap_id = 2 (текущая дата достигли более 80000)
Посмотреть вид dba_ash и обнаружил, что там snap_id = данные 1, и соответствующее время нашли, чтобы создать основное время дб, так что с момента создания БД, AWR данные не были очищены.
Просмотр журналы предупреждений и не нашли соответствующую ошибки, из-за расчисткой AWR данных по m00 * процессу, отвечающая необходимости проверить, есть ли соответствующая ошибка трассировки. Исследование показало, на самом деле, и каждый день.
Содержание Просмотр журнала трассировки, действительно нашел операции, которые связаны об ошибке Auto-Purge
Поиск Mos найденные документы в полном соответствии со случаем Doc ID 17079301.8
Ошибка нет обходного пути, только патч ремонта.
Во-вторых, восстановление отказа
В основном в два этапа, первый патч, второй очистки старых данных AWR. Согласно статье онлайн, AWR удаление очистка данных является чистым, не только очень долгое время, архив относительно количества производимого этой небольшой библиотеки также очень велик, после того , как решение общаться непосредственно укоротить слишком много базовой таблицы.
1. Проверьте OPatch версию
$ORACLE_HOME/OPatch/opatch version2. Проверьте патч конфликта
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./3. отбиться серверами снимок
- 1. ВЫБОР * из V $ сделки проверки , есть ли долгосрочная вещь Откат
- 2. Остановка прослушивания LSNRCTL СТОП ( LSNRCTL Статус проверки)
- 3. Остановите базу данных (около 5 минут )
alter system switch logfile; -- 执行三次。
alter system checkpoint; -- 执行三次。
shutdown immediate; -- 正常关闭数据库。
-- 检查数据库进程是否还存在 ps -ef |grep -i ora_- Остановка сервера инициализации 0
- Контактная группа угощает снимок (завершен в секундах)
- Запустить сервер хост группы (сначала удалить загрузку из базы данных запуска)
4. латание
Следующие операционные результаты для тестовой среды (около 1 мин , начать с библиотекой императора Cuyo 2мин )
Установка Inspection
5. Запуск восстановления базы данных синхронизации ведущий-ведомый ( . 5 ~ 10 мин )
Главная библиотека
startup
lsnrctl startИз библиотеки
startup mount
lsnrctl start
--日志应用使用
alter database recover managed standby database disconnect;
--待所有redo日志应用完成后打开数据库
select value from v$dataguard_stats where name='apply lag';
alter database recover managed standby database cancel;
alter database open;
--此时可以采用实时日志应用
alter database recover managed standby database using current logfile disconnect from session parallel 4;Убедитесь в том, что состояние синхронизации нормально может заметить подключение службы из приложения, после повторной загрузки базы данных включены с самого начала.
6. ручная чистка негабаритный WRH $ базовой таблицы
В соответствии с Doc ID 2099998.1 документа на удаление отчетности статистики, несколько больших таблиц необходимо удалить 3000 Ван Dao 5500 миллионов линий, слишком долго , и производить чрезмерное архивирование лучше использовать TRUNCATE . При необходимости, резервное копирование данных, WRH $ _EVENT_HISTOGRAM таблица 62 -день данные о 600 млн строк, количество по - прежнему велико.
Статистика больше таблица выглядит следующим образом:
усечение следующее заявление (50MB таблицу выше):
truncate table WRH$_EVENT_HISTOGRAM;
truncate table WRH$_LATCH;
truncate table WRH$_PARAMETER;
truncate table WRH$_SQLSTAT;
truncate table WRH$_SYSSTAT;
truncate table WRH$_LATCH_MISSES_SUMMARY;
truncate table WRH$_SEG_STAT;
truncate table WRH$_ACTIVE_SESSION_HISTORY;
truncate table WRH$_SYSTEM_EVENT;
truncate table WRH$_SERVICE_STAT;
truncate table WRH$_ROWCACHE_SUMMARY;
truncate table WRH$_MVPARAMETER;
truncate table WRH$_SERVICE_WAIT_CLASS;
truncate table WRH$_DB_CACHE_ADVICE;
truncate table WRH$_SYSMETRIC_HISTORY;
truncate table WRH$_SYSMETRIC_SUMMARY;
truncate table WRH$_SGASTAT;
truncate table WRH$_RSRC_CONSUMER_GROUP;
truncate table WRH$_SYS_TIME_MODEL;
truncate table WRH$_WAITSTAT;
truncate table WRH$_OSSTAT;Также найдено другая ошибка приведет к AWR не может быть очищена, если ситуация не соответствует описанию выше, вы можете увидеть
- WRH $ _LATCH, WRH $ _SYSSTAT и WRH $ _PARAMETER Потребляйте большинство пространства в пределах SYSAUX (Doc ID 2099998,1)
- Ошибка 14084247 - ORA-1555 или ORA-12571 Ошибка AWR продувка может привести к дальнейшему использованию SYSAUX пространства. В случае Bug 14084247 произошло, шаг вручную Doc ID 2099998.1 может удалить сиротские строки быть решена.
- http://blog.itpub.net/26736162/viewspace-2152868/
