1.概要
SYSAUX表スペースがいっぱいになる、それはログイン事に影響を与えるのだろうか？これは、データベースの正常な動作に影響を与えるのだろうか？それに対処するには？簡単には、考えてスペースを増やすために、スペースを削除し、最も重要なものとして生産を再開する最初の事業を消費しています。トラブルシューティングのために大規模なSYSAUX空間オブジェクトを消費し、関係なく、どのバージョン、すべて同じ、店舗大きなビジネステーブル、またはテーブルの個々の真ん中かどうかを確認します。図12（c）のために、より多くの懸念がある：AUDIT_TRAILパラメータデータベース監査開いたかどうか、パラメータ値DB、ausdsysモードで注目audsys成分、すなわちaudsys.CLI_SWP LOBセグメントSYS_LOB0000091784C00014 $ 459d3b9 $ 1 $ 1テーブルであれば$$サイズ。それは、ラージオブジェクトの調査でSYSAUXへの調査と同じ考えのNONE、10Gおよび11Gがない場合。
2.ケーススタディ
1、バックアップのチェック
バックアップチェックの結果から、アーカイブ、発見のコレクションに焦点を当てて、毎日のバックアップのメンテナンスでは、バックアップの複数のライブラリが失敗します。
2、アーカイブログのバックアップやデータベースのフルバックアップの出力をチェック
3、ライブラリカタログAUDIT_TRAILチェックパラメータ値= 'DB'。
4、ライブラリーのアラートログを参照してください。
図5は、大きなスペースの消費がSYSAUXテーブル（セクション）をオブジェクト参照します。
これは、部品部門audsysロブは31.5Gを占めました。
6、使用SYS LOBへのユーザ試行対応するセグメント・テーブル・TRUNCATE：
SYSが見つかり、ユーザーが権限を持っていません。
図7に示すように、クリーンアップを実行するストアドプロシージャを使用しました：
ベギン
DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL（
AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED、
USE_LAST_ARCH_TIMESTAMP => FALSE）。
終わり;
/
付録：Oracleの公式サイト提供をクリーンアップするための方法は、以下を参照してください。
https://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_audit_mgmt.htm#ARPLS65414
1> DBMS_AUDIT_MGMT.SET_LAST_ARCHIVE_TIMESTAMP（.exec -
AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED、 -
LAST_ARCHIVE_TIME => SYSDATE）。
2> .exec DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL（ -
AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED、 -
USE_LAST_ARCH_TIMESTAMP => TRUE）。
図8に示すように、チェックテーブルスペースSYSAUX放出、パラメータ値=「NONE」AUDIT_TRAIL監査調整パラメータ。
9、データベースを再起動し、正常に戻ってバックアップ複数のライブラリをアーカイブします。
3.SYSAUX表スペースの説明
説明3.1SYSAUX表スペースの公式サイト
SYSAUX表領域は、データベース作成時に必ず作成されます。SYSAUX表領域はSYSTEMtablespace補助表領域として機能します。それは以前に自分の表領域を必要な多くのOracle Databaseの機能および製品のデフォルトの表領域であるため、データベースで必要な表領域の数を減らします。また、SYSTEM表領域の負荷を軽減します。
あなたは、CREATE DATABASE文でSYSAUX DATAFILE句を使用して、SYSAUX表領域のみのデータファイルの属性を指定することができます。SYSAUX表領域の必須属性は、Oracle Databaseによって設定されており：
PERMANENT
読み書き
EXTENT経営管理論LOCAL
SEGMENT SPACE経営管理論AUTO
あなたは、ALTER TABLESPACE文を使用してこれらの属性を変更することはできませんし、そうしようとするとエラーになります。あなたは、落としたり、SYSAUX表領域の名前を変更することはできません。
SYSAUX表領域のサイズは、SYSAUXを占めるデータベース・コンポーネントのサイズによって決定されます。allSYSAUX乗員の一覧をご覧ください。これらのコンポーネントの初期サイズに基づいて、SYSAUX表領域は、データベースの作成時に少なくとも240メガバイトである必要があります。データベースが完全に展開された後、SYSAUX表領域の空き容量の要件は、その使用とワークロードの性質に応じて、増加します。継続的にSYSAUX表領域の領域消費を管理する方法の詳細については、「管理SYSAUX表領域」を参照してください。
3.2SYSAUX表スペースの中国ブリーフ
10GからのOracleは、以前別の表領域またはSYSTEM表データベースコンポーネントの一部に導入された今、SYSAUX表領域に作成されている。これらの構成要素および機能を分離することにより、負荷SYSTEM表領域が低減される。繰り返し関連するオブジェクトとコンポーネントの数を作成しますシステムテーブルスペースデブリの問題は回避引き起こしました。SYSAUX表スペースが使用できない場合は、コアデータベース機能は有効のままになり、使用SYSAUX表領域の機能が失敗したり、機能が限定されます。
表スペースの主なコンポーネント3.3SYSAUX
表示情報声明SYSAUX表スペースコンポーネント：
A30のためにコルアイテム
A10のCOL "使用領域（GB）"
A20のためにコルスキーマ
A40のためにコル「MoveProcedure」
SELECTは、 "アイテム" をoccupant_name
ラウンド（space_usage_kbytes / 1024,3） "使用済み領域（MB）"、
SCHEMA_NAME "スキーマ"、
move_procedure "MoveProcedure"
五$ SYSAUX_OCCUPANTS FROM
ORDER BY 2 DESC。
このスクリプトの実行結果が出含む：ストアドプロシージャコンポーネント、コンポーネントによって消費されるスペース、およびモバイル用途のためのコンポーネントオブジェクトモデルの名前。
3.3.1 11Gコンポーネント
3.3.2 12C成分
4.注意事項SYSAUX表スペースがいっぱいです
データファイルたら、データベースを構築した後SYSAUXへの補足場合は、アプリケーションSYSAUX表スペースに応じて、10Gおよび11Gに、何のテーブルまたは個々の製造業務は低成長、比較的安定を変更するには、テーブルの真ん中、テーブルスペースにはありません。
4.1権限の予防
SYSAUX表スペースにテーブルと生産や個々のユーザーを防止するための権限。
1、あなたがアカウントを作成するとき、ユーザーはどちらDEFAUL TABLESPACEはSYSAUXです。
かかわらず、生産アカウントまたは個人アカウントの、与えられた業務の生産実績に基づいて、もちろん、これらのユーザーにUNLIMITED TABLESPACE権限、またはSYSAUX上無制限のクォータ、にできるだけわずか2、。
4.2パラメータの予防
12Cの場合は、特別な必要がある場合は、NONEにパラメータAUDIT_TRAILを調整し、有効にするには、データベースを再起動します。
4.3保管上のご注意
SYSAUX表領域は適切に増加しました。
4.4スナップショットおよび防止するための統計情報の保持ポリシー
4.4.1データ保持ポリシーの調整の統計情報とスナップショット
1、履歴統計の保持時間を調整します：
ホールド時間の統計、デフォルトは31日です、この変更は、統計が自動的に削除された後7日、です。
PROD @ SYS>デュアルからdbms_stats.get_stats_history_retentionを選択します。
GET_STATS_HISTORY_RETENTION
---------------------------
31
2、保持時間の統計情報を変更します。
SYS @ PROD> execのdbms_stats.alter_stats_history_retention（10）。
PL / SQLプロシージャが正常に完了しました。
3、再び歴史統計のために予約の日数を表示するには：
PROD @ SYS>デュアルからdbms_stats.get_stats_history_retentionを選択します。
GET_STATS_HISTORY_RETENTION
---------------------------
10
時間調整AWRスナップショットの保存4.4.2
7日（7 * 24 * 60）に例えば、毎時間、8日の現在のシステムのデフォルトの保持時間を収集し、一時間は、時間をサンプリング。
1、現在のスナップショットの保持時間と取得サイクルを表示します。
SYS @ PROD> A20のためにコルRETENTION
SYS @ PROD>コルSNAP_INTERVAL A25について
SYS @ PROD> DBA_HIST_WR_CONTROLから選択*;
DBID SNAP_INTERVAL RETENTION TOPNSQL
---------- ------------------------- --------------- ----- ----------
3384693760万01：00：00.0 00008 00：00：00.0 DEFAULT
2、システムの現在のMOVING_WINDOW_SIZEを表示します。
PROD @ SYS> DBID、BASELINE_NAME、BASELINE_TYPE、DBA_HIST_BASELINEからmoving_window_sizeを選択します。
DBID BASELINE_NAME BASELINE_TYPE MOVING_WINDOW_SIZE
---------- ---------------------------------------- ------------------------ ------------- ------------- -----
338469376 SYSTEM_MOVING_WINDOW MOVING_WINDOW 8
3、AWRスナップショット収集時間60分と7日の滞留時間を調整してみてください。
PROD @ SYS>始めます
2 dbms_workload_repository.modify_snapshot_settings（
3間隔=> 60、
4保持=> 10080、
5 topnsql => 50
6）。
7 END;
8 /
ベギン
*
1行目でエラー：
ORA-13541：保持より大きいシステム移動窓ベースラインサイズ（691200）（604800）
ORA-06512： "SYS.DBMS_WORKLOAD_REPOSITORY" で、ライン174
ORA-06512： "SYS.DBMS_WORKLOAD_REPOSITORY" で、ライン222
ORA-06512：行で2
図4に示すように、第1の調整は、現在予約された時間窓よりも小さいです。
SYS @ PROD> execのdbms_workload_repository.modify_baseline_window_size（7）;
PL / SQLプロシージャが正常に完了しました。
5、7日の60分、保持時間のAWRスナップショット収集時間を再調整します。
PROD @ SYS>始めます
2 dbms_workload_repository.modify_snapshot_settings（
3間隔=> 60、
4保持=> 10080、
5 topnsql => 50
6）。
7 END;
8 /
PL / SQLプロシージャが正常に完了しました。
6、調整後、AWRスナップショットの確認保持時間に：
SYS @ PROD> DBA_HIST_WR_CONTROLから選択*;
DBID SNAP_INTERVAL RETENTION TOPNSQL
---------- ------------------------- --------------- ----- ----------
3384693760万01：00：00.0 00007 00：00：00.0 50
5.クリーンSYSAUXは、大きな空間的コンポーネントコンテンツを消費します
削除することによって、明確なスペースに5.1 AWRスナップショット
1、現在の予約SNAP_IDのスナップショットを参照してください。
; PROD> DBA_HIST_SNAPSHOTから選択分（snap_id）、MAX（snap_id）@ SYS
MIN（SNAP_ID）MAX（SNAP_ID）
------------ ------------
2561 2570
こうした最も前に5つのスナップショットを削除するなどの古いスナップショットを削除するには2、いくつかの試み：
SYS @ PROD> EXEC dbms_workload_repository.drop_snapshot_range（low_snap_id => 2561、high_snap_id => 2561 + 4）。
または：
EXEC dbms_workload_repository.drop_snapshot_range（2561,2565,338469376）。
3、現在の予約SNAP_IDのスナップショットを参照してください。
; PROD> DBA_HIST_SNAPSHOTから選択分（snap_id）、MAX（snap_id）@ SYS
MIN（SNAP_ID）MAX（SNAP_ID）
------------ ------------
2566 2570
以上のスナップショットの保持場合は、パーティションテーブルWRH $ _先頭を削除する操作を行いますCPUリソースのより多くの消費、遅いが、スナップショットプロセスを削除します。私たちはSNAP_IDを見て、あるときに、古いスナップショットが削除されているが、部品の大きさは、内部SYSAUXまだ元のサイズ、SYSAUX表スペースが解除されていない、変更されません。収穫高水のリサイクル、中次はWRH $にある_関連するテーブルの統計情報関連テーブルを収集することです。
次のような高水のリサイクルのための4、削除古いスナップショット、
PROD> ALTER TABLE SYS.WRH $ _LATCH MODIFY PARTITIONのWRH $ _LATCH_338469376_0シュリンクSPACE @午前11時40分03秒SYS。
テーブルが変更されました。
経過：00：00：13.11
PROD> ALTER TABLE SYS.WRH $ _SQLSTAT MODIFY PARTITIONのWRH $ _SQLSTA_338469376_0シュリンクSPACE @午前11時42分36秒SYS。
テーブルが変更されました。
経過：00：00：12.55
5、またはリカバリー・テーブルの高レベルのより：
ALTER TABLE WRH $ _SQLSTATはスペースを縮小。
ALTER TABLE WRH $ _SYSSTATはスペースを縮小。
ALTER TABLE WRH $ _SEG_STATはスペースを縮小。
ALTER TABLE WRH $ _LATCHはスペースを縮小。
... ...
6、高水位後の回復の収集統計：
DBMS_STATS.GATHER_TABLE_STATSスキーマ（ownname => 'SYS'、TABNAME => 'WRH $ _LATCH MODIFY' て、partname => 'WRH $ _LATCH_338469376_0'、DEGREE => 4）を実行します。
DBMS_STATS.GATHER_TABLE_STATSスキーマ（ownname => 'SYS'、TABNAME => 'WRH $ _SQLSTAT' て、partname => 'WRH $ _SQLSTA_338469376_0'、DEGREE => 4）を実行します。
明確な空間に時代遅れの統計情報を削除することによって、5.2
午後11時46分54秒SYS @ PROD> EXEC dbms_stats.purge_stats（SYSDATE-6）。
PL / SQLプロシージャが正常に完了しました。
経過：00：00：06.70
ALTER TABLE WRH $ _SQLSTATはスペースを縮小。
ALTER TABLE WRH $ _SYSSTATはスペースを縮小。
ALTER TABLE WRH $ _SEG_STATはスペースを縮小。
ALTER TABLE WRH $ _LATCHはスペースを縮小。
... ...
5.3明確なスペースに履歴テーブルの削除一部
削除し、いくつかの歴史的な統計情報テーブルのために契約し、例えば、無効なレコードの会話履歴ASHテーブルを削除WRH $ _active_session_history
1、無効な履歴記録の会話を表示します。
SELECT COUNT（1）Orphaned_ASH_Rows
WRH $ _active_session_history Aから
WHERE NOT EXISTS
（SELECT 1
WRM $ _snapshot FROM
WHERE snap_id = a.snap_id
AND DBID = a.dbid
AND INSTANCE_NUMBER = a.instance_number
）;
2、削除無効なレコードの会話履歴：
WRH $ _active_session_history AからDELETE
WHERE NOT EXISTS（1を選択
WRM $ _snapshot FROM
WHERE snap_id = a.snap_id
AND DBID = a.dbid
AND INSTANCE_NUMBER = a.instance_number）;
23392228行が削除されました。
SQL> COMMIT;
3、高い水の回収率：
$ _active_session_historyシュリンクスペースWRH ALTER TABLE。
収穫後は、テーブルの上に再収集の統計にあります。
アセンブリコンテンツのテーブル部を移動させることにより他の空間にスペースをクリアする5.4
アセンブリSYSAUX表領域の結果の上から見た図、あなたは、オブジェクトテーブルのパラメータ空間ストアドプロシージャの移動を達成することができる、MoveProcedureは、成分の記憶内容を移動させる方法が提供されるフィールド結果の内容を見ることができますもちろん、あなたが戻って再移動することができますSYSAUX表スペース、前提は、ターゲット表スペースが十分にあることを確認することです。例えば、のLogMiner SYSAUX表領域、表領域のユーザーはバックの減少、に移行します：
1、移動前のテーブルスペースを参照してください。
2、のLogMiner表領域のユーザーを移動するには：
夜9時39分40秒SYS @ PROD> execのSYS.DBMS_LOGMNR_D.SET_TABLESPACE（ 'USERS'）;
PL / SQLプロシージャが正常に完了しました。
3、LogMinerはアセンブリバックSYSAUX表領域を移動するには：
夜10時07分55秒SYS @ PROD> execのSYS.DBMS_LOGMNR_D.SET_TABLESPACE（ 'SYSAUX'）;
PL / SQLプロシージャが正常に完了しました。
彼は加えました：
大SYSAUXスペースのかかるプロセスを、だけでなく、場合によっては、多くの場合、前に発生しました：その後パート5を追加します。
1.各コンポーネントSYSAUX表領域の目的を理解し、最も脆弱な3つのコンポーネント、次の成長のための部屋のようになります。
SM / ADVISOR：データベースのSQLチューニングアドバイザ、SQLアクセスアドバイザ、このように生成されたデータの自動メンテナンスなどADDMタスクを指し、
SM / AWR：AWRスナップショット情報は、空間周波数は、保持時間と生成スナップショットに依存します
SM / OPTSTAT：ストレージ・オプティマイザ統計のためのデータの履歴バージョン。
2.なぜ定期的な清掃作業を持っている、またはスペース異常成長があるでしょうか？
状況は、このようなデータはMMONプロセスが自動的に定期的にデータベースを削除されるまでの31日間、デフォルトのスナップショットの保持時間として、データ保持期間があるが、このプロセスは、それぞれの時間はあなたが唯一の5分を実行して、タスクをクリーンアップ5分以上は中断され、そのデータは、クリーンアップの失敗または不完全な場合があります。日によって分割されたテーブルに新しいバージョンのパッチ、大きなテーブルで提供されるこの問題オラクルは、クリアケースになりは切り捨てに余裕がない道をクリアすると、表示されません。
ケース2、デフォルトの保存期間は、このようなログがタスクのスケジューリングデフォルトの保存期間は100万日であるdba_scheduler_job_classes実行しているとして、長すぎます。
3.どのように対処するには？
一般的には）削除を使用して、スペースをクリーンアップするようにスペースを縮小するが、DBMS_SCHEDULER.PURGE_LOGを（使用して実行するように、このようなログのクリーンアップタスクとして、クリーンアップ機能オラクル独自の実装を呼び出すことはありませんが、きれいなdbms_stats.purge_statsを使用して、すべての統計まで（dbms_stats.PURGE_ALL ）;
概要
完全SYSAUXのデータベースは、現在、経験した場合に、DB、表スペースが一杯になったときAUDIT_TRAILデータベース監査パラメータの12Cで、ユーザのログインデータベース、10Gおよび11Gに直接影響をすることによって満たされていないことである場合、影響を受けます状況の影響。AUDIT_TRAILは時間のNONEで、いくつかのシミュレーションテスト、12Cおよび11Gのバージョンの後、SYSAUXは、完全な、データベースの可用性に影響を与えません。他のコンポーネントSYSAUX表スペースのために、我々はより多くの探求、実験エリア、クリーンアップをテストして、ほぼ同じ各構成要素の内容を移動する必要があります。
不備や誤りが指摘し、すべての偉大な神は、次回私を啓発することを希望は、改善と学習を補足することがあれば、これらは、個人的な例経験、テスト結果といくつかのコメントです。
添付ファイル：
新12Cのセキュリティ監査を特徴：
Oracleデータベース12cのセキュリティ：新しい統合監査
连接1：https://blogs.oracle.com/imc/oracle-database-12c-security:-new-unified-auditing
接続2：HTTPS：//www.cnblogs.com/shenfeng/p/oracle_12c_sysaux_clean.html
## 12C本明細書で用いている新機能：同じに配置された2つの監査（ファイングレイン監査のいずれかの種類に合わせた標準監査および監査）テーブル