1. Overview
SYSAUX table space is full, it will affect the login thing? It will affect the normal operation of the database? How to deal with it? Easy to think, to increase space, delete the space is consumed, the first business to resume production as the most important. For troubleshooting consume large SYSAUX space objects, no matter which version, all the same, to see if the store large business table, or individual middle of the table. For 12C, the more of a concern is: audit_trail parameter database audit whether the open, if the parameter value DB, the attention audsys components under a ausdsys mode, namely audsys.CLI_SWP lob segment SYS_LOB0000091784C00014 $ 459d3b9 $ 1 $ 1 table $$ size. If it is NONE, the 10G and 11G of the investigation and the same ideas to SYSAUX in the investigation of large objects.
2. Case Study
1, the backup check
In the daily backup maintenance which, from the result of the backup checks focus on the collection of discovery, archiving, backup multiple libraries fail.
2, check the archive log backup or full database backup output
3, library catalog audit_trail check parameter values = 'DB'.
4, see the alert log for the library:
5, see the consumption of large space objects SYSAUX table (section):
Which, lob audsys components segment accounted for 31.5G.
6, the user tries to use sys lob the corresponding segment table truncate:
Found sys user does not have permission.
7, using a stored procedure to perform cleanup:
begin
dbms_audit_mgmt.clean_audit_trail(
audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED,
use_last_arch_timestamp => FALSE);
end;
/
Appendix: Methods for cleaning up oracle official website provides, see:
https://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_audit_mgmt.htm#ARPLS65414
1>.exec DBMS_AUDIT_MGMT.SET_LAST_ARCHIVE_TIMESTAMP ( -
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, check table space sysaux release, audit adjustment parameters audit_trail parameter values = 'NONE'.
9, restart the database, archive backup multiple libraries back to normal.
3.SYSAUX table space description
Description 3.1SYSAUX table space official website
The SYSAUX tablespace is always created at database creation. The SYSAUX tablespace serves as an auxiliary tablespace to the SYSTEMtablespace. Because it is the default tablespace for many Oracle Database features and products that previously required their own tablespaces, it reduces the number of tablespaces required by the database. It also reduces the load on the SYSTEM tablespace.
You can specify only datafile attributes for the SYSAUX tablespace, using the SYSAUX DATAFILE clause in the CREATE DATABASE statement. Mandatory attributes of the SYSAUX tablespace are set by Oracle Database and include:
PERMANENT
READ WRITE
EXTENT MANAGMENT LOCAL
SEGMENT SPACE MANAGMENT AUTO
You cannot alter these attributes with an ALTER TABLESPACE statement, and any attempt to do so will result in an error. You cannot drop or rename the SYSAUX tablespace.
The size of the SYSAUX tablespace is determined by the size of the database components that occupy SYSAUX. See a list of allSYSAUX occupants. Based on the initial sizes of these components, the SYSAUX tablespace needs to be at least 240 MB at the time of database creation. The space requirements of the SYSAUX tablespace will increase after the database is fully deployed, depending on the nature of its use and workload. For more information on how to manage the space consumption of the SYSAUX tablespace on an ongoing basis, please refer to the"Managing the SYSAUX Tablespace"
3.2SYSAUX table space Chinese Brief
Oracle from 10G were introduced in some of the previous separate tablespaces or system tablespace database components are now created in the SYSAUX tablespace. By separating these components and functions, a load SYSTEM tablespace is reduced. Repeatedly creates a number of related objects and components SYSTEM table space debris problem caused avoided. If the SYSAUX table space is not available, the core database functions will remain in effect; use SYSAUX table space features will fail or limited functionality.
The main components of table space 3.3SYSAUX
View information statement SYSAUX table space components:
col Item For a30
col "Space Used(GB)" For a10
col Schema For a20
col "MoveProcedure" For a40
SELECT occupant_name"Item",
round(space_usage_kbytes/1024,3)"Space Used (MB)",
schema_name "Schema",
move_procedure "MoveProcedure"
FROM v$sysaux_occupants
ORDER BY 2 Desc;
The results of this script execution out include: the name of the stored procedure component, space consumed by components, and component object model for mobile use.
3.3.1 11G components
3.3.2 12C components
4. precautions SYSAUX table space is full of
Depending on the application sysaux table space, in 10G and 11G, if the supplement to sysaux after building a database once a data file, there is no table or individual manufacturing operations into the middle of the table, the table space to change slower growth, relatively stable.
4.1 Permissions prevention
The authority to prevent the production or individual users with the table into the SYSAUX table space.
1, when you create an account, the user can neither DEFAUL TABLESPACE is SYSAUX;
2, regardless of the production account or personal account, as little as possible to UNLIMITED TABLESPACE authorization to these users, or quota unlimited on SYSAUX, of course, based on the actual production of a given business.
4.2 Parameter prevention
For 12C, if no special needs, adjust parameter audit_trail to NONE and restart the database to take effect.
4.3 storage precautions
SYSAUX tablespace appropriately increased.
4.4 snapshots and statistical information retention policies to prevent
4.4.1 data retention policy adjustment statistics and snapshots
1, adjusted historical statistics retention time:
Hold time statistics, the default is 31 days, this modification is 7 days, after which statistics are automatically deleted.
sys@PROD>select dbms_stats.get_stats_history_retention from dual;
GET_STATS_HISTORY_RETENTION
---------------------------
31
2, modify the retention time statistics:
sys@PROD>exec dbms_stats.alter_stats_history_retention(10);
PL/SQL procedure successfully completed.
3, again to see the number of days reserved for historical statistics:
sys@PROD>select dbms_stats.get_stats_history_retention from dual;
GET_STATS_HISTORY_RETENTION
---------------------------
10
4.4.2 save time adjustment AWR snapshots
For example to 7 days (7 * 24 * 60), collected every hour, a retention time of the current system default of 8 days, one hour sampling time.
1, view the current snapshot retention time and acquisition cycle:
sys@PROD>col RETENTION for a20
sys@PROD>col SNAP_INTERVAL for a25
sys@PROD>select * from dba_hist_wr_control;
DBID SNAP_INTERVAL RETENTION TOPNSQL
---------- ------------------------- -------------------- ----------
338469376 +00000 01:00:00.0 +00008 00:00:00.0 DEFAULT
2, view the system's current MOVING_WINDOW_SIZE:
sys@PROD>select dbid,baseline_name,baseline_type,moving_window_size from dba_hist_baseline;
DBID BASELINE_NAME BASELINE_TYPE MOVING_WINDOW_SIZE
---------- ---------------------------------------------------------------- ------------- ------------------
338469376 SYSTEM_MOVING_WINDOW MOVING_WINDOW 8
3, try to adjust the AWR snapshot collection time 60 minutes and retention time of 7 days:
sys@PROD>begin
2 dbms_workload_repository.modify_snapshot_settings(
3 interval => 60,
4 retention => 10080,
5 topnsql => 50
6 );
7 end;
8 /
begin
*
ERROR at line 1:
ORA-13541: system moving window baseline size (691200) greater than retention (604800)
ORA-06512: at "SYS.DBMS_WORKLOAD_REPOSITORY", line 174
ORA-06512: at "SYS.DBMS_WORKLOAD_REPOSITORY", line 222
ORA-06512: at line 2
4, the first adjustment is less than the time window currently reserved:
sys@PROD>exec dbms_workload_repository.modify_baseline_window_size(7);
PL/SQL procedure successfully completed.
5, re-adjust the AWR snapshot collection time of 60 minutes and retention time of 7 days:
sys@PROD>begin
2 dbms_workload_repository.modify_snapshot_settings(
3 interval => 60,
4 retention => 10080,
5 topnsql => 50
6 );
7 end;
8 /
PL/SQL procedure successfully completed.
6, after the adjustment, to confirm retention time of AWR snapshots:
sys@PROD>select * from dba_hist_wr_control;
DBID SNAP_INTERVAL RETENTION TOPNSQL
---------- ------------------------- -------------------- ----------
338469376 +00000 01:00:00.0 +00007 00:00:00.0 50
5. Clean SYSAUX consume large spatial component content
5.1 AWR snapshots to clear space by deleting
1, see the snapshot of the current reserved SNAP_ID:
sys@PROD>select min(snap_id),max(snap_id) from dba_hist_snapshot;
MIN(SNAP_ID) MAX(SNAP_ID)
------------ ------------
2561 2570
2, several attempts to delete older snapshots, such as deleting five snapshots before most:
sys@PROD>exec dbms_workload_repository.drop_snapshot_range(low_snap_id =>2561,high_snap_id => 2561+4);
or:
exec dbms_workload_repository.drop_snapshot_range(2561,2565,338469376)；
3, see the snapshot of the current reserved SNAP_ID:
sys@PROD>select min(snap_id),max(snap_id) from dba_hist_snapshot;
MIN(SNAP_ID) MAX(SNAP_ID)
------------ ------------
2566 2570
If the snapshot retention than more, then delete the snapshot process, more consumption of CPU resources, slow, which will carry out the operation to delete the partition table WRH $ _ beginning. So when we are by looking at SNAP_ID, old snapshots have been deleted, but the size of the components inside sysaux not changed, still the original size, sysaux table space is not released. Next is to WRH $ _ related tables in the high-water recycling, harvested is to collect statistical information related tables.
4, delete old snapshots for high-water recycling, such as:
11:40:03 sys@PROD>ALTER TABLE SYS.WRH$_LATCH MODIFY PARTITION WRH$_LATCH_338469376_0 SHRINK SPACE;
Table altered.
Elapsed: 00:00:13.11
11:42:36 sys@PROD>ALTER TABLE SYS.WRH$_SQLSTAT MODIFY PARTITION WRH$_SQLSTA_338469376_0 SHRINK SPACE;
Table altered.
Elapsed: 00:00:12.55
5, or more of the high level of the recovery table:
alter table WRH$_SQLSTAT shrink space;
alter table WRH$_SYSSTAT shrink space;
alter table WRH$_SEG_STAT shrink space;
alter table WRH$_LATCH shrink space;
... ...
6, collect statistics on the recovery after the high water table:
execute dbms_stats.gather_table_stats(ownname => 'sys',tabname => 'WRH$_LATCH MODIFY',partname => 'WRH$_LATCH_338469376_0',DEGREE=>4);
execute dbms_stats.gather_table_stats(ownname => 'sys',tabname => 'WRH$_SQLSTAT',partname => 'WRH$_SQLSTA_338469376_0',DEGREE=>4);
5.2 by deleting outdated statistics to clear space
23:46:54 sys@PROD>exec dbms_stats.purge_stats(sysdate-6);
PL/SQL procedure successfully completed.
Elapsed: 00:00:06.70
alter table WRH$_SQLSTAT shrink space;
alter table WRH$_SYSSTAT shrink space;
alter table WRH$_SEG_STAT shrink space;
alter table WRH$_LATCH shrink space;
... ...
5.3 Delete part of the history table to clear space
Delete contracted for some historical statistics table, for example, remove the invalid record conversation history ASH table wrh $ _active_session_history
1, view invalid history record conversation:
SELECT COUNT(1) Orphaned_ASH_Rows
FROM wrh$_active_session_history a
WHERE NOT EXISTS
(SELECT 1
FROM wrm$_snapshot
WHERE snap_id = a.snap_id
AND dbid = a.dbid
AND instance_number = a.instance_number
);
2, delete invalid record conversation history:
DELETE FROM wrh$_active_session_history a
WHERE NOT EXISTS (SELECT 1
FROM wrm$_snapshot
WHERE snap_id = a.snap_id
AND dbid = a.dbid
AND instance_number = a.instance_number);
23392228 rows deleted.
SQL>commit;
3, recovery of high water:
alter table wrh$_active_session_history shrink space;
After harvested, it is to re-collect statistics on the table.
5.4 to clear space to the other space by moving the table portion of the assembly content
View from above of the assembly SYSAUX tablespace result, you can see the contents of the fields results MoveProcedure is provided a process of moving the stored contents of the component, then the parameter space of the object table stored procedure moves can be achieved, Of course, you can re-move back SYSAUX table space, the premise is to ensure that the target table space is sufficient. For example, the Logminer SYSAUX tablespace, tablespace users migrate to, reduction in back:
1, see the table space before the move:
2, to move Logminer tablespace users:
21:39:40 sys@PROD>exec SYS.DBMS_LOGMNR_D.SET_TABLESPACE('USERS');
PL/SQL procedure successfully completed.
3, Logminer assembly to move back SYSAUX tablespace:
22:07:55 sys@PROD>exec SYS.DBMS_LOGMNR_D.SET_TABLESPACE('SYSAUX');
PL/SQL procedure successfully completed.
supplement:
Then add Part 5: large sysaux space-consuming process, but also the cases often encountered before:
1. understand the purpose of each component sysaux table space, the most vulnerable should be room for growth following three components:
SM / ADVISOR: refers to the database sql tuning advisor, sql access advisor, ADDM tasks such as automatic maintenance of data generated
SM / AWR: AWR snapshot information, the spatial frequency depends on the retention time and generating snapshots
SM / OPTSTAT: historical versions of data for storage optimizer statistics.
2. Why have regular cleaning task, or there will be space abnormal growth?
A situation, there is data retention period, such as the default snapshot retention time of 31 days, after which the data will be MMON process automatically delete the database on a regular basis, but this process each time you run only five minutes, more than 5 minutes cleaning up task is interrupted, so the data clean-up may be unsuccessful or incomplete. This problem oracle provided in the new version of the patch, the large table into a partitioned table by day, clearing the way becomes clear case can not afford to truncate will not appear.
Case 2, the default retention period is too long, such as running log dba_scheduler_job_classes Task Scheduling default retention period is 1 million days.
3. How to deal with?
Generally do not use delete, and then shrink space in such a way to clean up the space, but call the cleanup function oracle own implementation, such as log cleanup task to run using DBMS_SCHEDULER.PURGE_LOG (); clean up all the statistics using dbms_stats.purge_stats (dbms_stats.PURGE_ALL );
to sum up
For the full SYSAUX database affected when, from the case currently experiencing, is that in the 12C for the database audit parameters audit_trail when the DB, the table space is full, a direct impact on user login database, 10G and 11G are not met by the impact of the situation. After some simulation test, 12C and 11G versions which, when audit_trail is NONE of time, SYSAUX full, will not affect the availability of the database. For other components SYSAUX table space, we need to explore more testing experimental area, clean up and move the contents of each component, roughly the same.
These are the personal experiences of a case, test results and some comments, if there any flaws or errors pointed out and hope that all the great God enlighten me, the next time, be supplemented improvement and learning.
Attachment:
New features 12C security audit:
Oracle Database 12c Security: New Unified Auditing
连接1：https://blogs.oracle.com/imc/oracle-database-12c-security:-new-unified-auditing
Connection 2: HTTPS: //www.cnblogs.com/shenfeng/p/oracle_12c_sysaux_clean.html
## 12C herein means that new features: two audit (standard audit and audit combined into a one kind of fine-grained audit) placed in the same a table