まず、問題分析
あなたは警告システムSYSAUX表領域の使用率が90％を超えると、問題の原因を分析する必要がそれほど高くてはならない、表領域の使用量が正常で受けています。
ビュー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データがあり、通常は低いです。高いシステム負荷のコントラストを探し、発見しただけ7Gに関するシステムAWRデータ。
ビュー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（現在の日付が80,000以上に達している）として存在していることが判明し、大きなテーブルを選択してください
ビューdba_ashビューとそれに対応する時間FOUNDはとてもDB作成するので、AWRデータがクリアされていない、基本的なDB時間を作成することがsnap_id = 1つのデータ、及びであることがわかりました。
ビューのアラートログ、およびM00によってクリーンアップAWRデータによる該当エラー、*対応するトレースエラーがあるかどうかを確認するプロセス責任の必要性は認められませんでした。検査は確かに明らかにし、毎日。
表示トレースログの内容、実際にエラー関連操作自動パージを発見されました
モスドキュメントを検索ドキュメントIDの場合に完全に準拠してい17079301.8
バグなしの回避策、唯一のパッチ修理。
第二に、障害回復
主に2つの段階、最初のパッチでは、第二は、古いAWRデータをクリーンアップしています。オンラインの記事によると、AWR削除データクリーニングは、意思決定があまりにも多くのベーステーブルを切り捨てることで直接通信した後、この小さなライブラリーによって生成される量とアーカイブの相対は、また非常に素晴らしいですが、清潔で、非常に長い時間ではないだけにあります。
1.チェックOPatchのバージョン
$ORACLE_HOME/OPatch/opatch versionパッチの競合を確認してください2。
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./サーバーのスナップショットオフ3.戦い
- 1. V $トランザクションからSELECT * 長期のもののロールバックがあるかどうかをチェック
- 2.停止リスニング LSNRCTLのSTOP （LSNRCTLステータス・チェック）
- 3.ストップデータベース（約5分）
alter system switch logfile; -- 执行三次。
alter system checkpoint; -- 执行三次。
shutdown immediate; -- 正常关闭数据库。
-- 检查数据库进程是否还存在 ps -ef |grep -i ora_- 停止サーバー のinit 0
- 問い合わせプレイホストグループのスナップショット（秒で完了）
- サーバーのホストグループを開始します（最初のスタートデータベースからのブートを削除します）
4.パッチ適用
テスト環境のために、以下のオペレーティング結果（約1分、ライブラリ皇帝クヨで始まる2分）
インストールの検査
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;同期ステータスいることを確認し、[OK]をした後、アプリケーションからサービス接続する場合があり、スタートからの再有効化データベースの起動。
6.手動クリーニング特大WRHの$のベーステーブル
よると、 ドキュメントID 2099998.1 にドキュメントの削除統計文、いくつかの大きなテーブルがする必要が3000の削除ワンダオ5500のあまりにも長い間、万行をし、過度のアーカイブが使用するのが最善です生み出すTRUNCATE 。必要であれば、あなたのデータ、WRH $ _EVENT_HISTOGRAMバックアップテーブル62 について日間のデータを600 量は依然として大きい、万行。
次のように統計大きなテーブルには、次のとおりです。
次の文（50メガバイトのテーブルの上を）切り捨てます。
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内のスペースの大半を消費（ドキュメントID 2099998.1）
- バグ14084247 - ORA-1555またはORA-12571の失敗AWRパージを継続SYSAUX領域の使用につながることができます。バグ14084247の場合に発生した、手動でドキュメントID 2099998.1のステップは、行が解決されるオーファン削除することができます。
- http://blog.itpub.net/26736162/viewspace-2152868/
