First, the problem analysis
You have received a warning system sysaux table space utilization exceeds 90%, the table space usage is normal should not be so high, need to analyze the cause of the problem.
View sysaux table space occupied by the most part, is found to account for the largest AWR data, the amount of data to achieve 29G.
select OCCUPANT_NAME,OCCUPANT_DESC,SPACE_USAGE_KBYTES/1024 USAGE_MB
from V$SYSAUX_OCCUPANTS order by SPACE_USAGE_KBYTES desc;
This system usually load is low, Normally there are so many AWR data. Looking for a high system load contrast, found that the system AWR data only about 7G.
View sysaux table space occupies the largest space object name
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;
Pick a big table where the query data, found that there are as many snap_id data = 2 (current date has reached more than 80,000)
View dba_ash view and found that there snap_id = 1 data, and its corresponding time found is to create a basic db time, so since db creation, awr data have not been cleared.
View alert logs, and found no relevant error, due to the clean-up awr data by m00 * process responsible need to check whether there is a corresponding trace error. Examination revealed indeed, and every day.
View trace log content, is indeed found an error related operations Auto-Purge
Search mos documents found in full compliance with the case of Doc ID 17079301.8
The bug no workaround, only patch repair.
Second, the failure recovery
Mainly in two steps, first patch, the second is cleaning up old awr data. According to the online article, awr delete data cleaning is to clean, not only very long time, the archive relative to the amount produced by this small library is also very great, after the decision to communicate directly to truncate out too much base table.
1. Check OPatch version
$ORACLE_HOME/OPatch/opatch version2. Check the patch conflict
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./3. fight off server snapshots
- 1. the SELECT * from v $ Transaction check whether there is a long-term thing rollback
- 2. Stop listening lsnrctl STOP ( lsnrctl Status check)
- 3. Stop the database (about 5min )
alter system switch logfile; -- 执行三次。
alter system checkpoint; -- 执行三次。
shutdown immediate; -- 正常关闭数据库。
-- 检查数据库进程是否还存在 ps -ef |grep -i ora_- Stop server init 0
- Contact playing host group snapshot (completed in seconds)
- Start the server host group (first remove the boot from the start database)
4. patching
The following operating results for the test environment (about 1min , start with the library emperor Cuyo 2min )
Installation Inspection
5. Start the database recovery master-slave synchronization ( . 5 ~ 10min )
Main library
startup
lsnrctl startFrom the library
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;Verify that the synchronization status ok may notice service connection from the application, after re-enabled database boot from the start.
6. manual cleaning oversized WRH $ base table
According to Doc ID 2099998.1 document to delete statistics statements, several large tables need to delete 3000 Wan Dao 5500 million lines, too long and produce excessive archiving is best to use TRUNCATE . If necessary, back up your data, WRH $ _EVENT_HISTOGRAM table 62 -day data about 600 million lines, the amount is still large.
Statistics larger table is as follows:
truncate the following statement (50MB table above):
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;Also found another bug will lead to awr can not be cleaned, if the situation does not meet the description above, you can see
- WRH$_LATCH, WRH$_SYSSTAT, and WRH$_PARAMETER Consume the Majority of Space within SYSAUX ( Doc ID 2099998.1 )
- Bug 14084247 - ORA-1555 or ORA-12571 Failed AWR purge can lead to continued SYSAUX space use. In the case of Bug 14084247 has occurred, the step of manually Doc ID 2099998.1 can delete orphan rows be solved.
- http://blog.itpub.net/26736162/viewspace-2152868/
