system表空間不足的問題分析(二) (r8筆記第5天)
今天收到一條不太起眼的報警郵件，大體內容是某個表空間的空間有些緊張了。大體內容如下：
Tablesapce: CMBI_SNZG_DATA: 92.2% [Warning!]
根據這個資訊，很明顯是需要新增資料檔案了，但是同時還有一個警告就是磁碟空間也告警了，那麼這個看起來簡單的問題得好好琢磨琢磨了，其實是幾件事，一件 是做一些資料清理，釋放部分表空間，甚至可以通過釋放資料檔案的空間來進一步釋放磁碟空間，第二件是給表空間告警的表空間新增資料檔案。
首先檢視資料庫中的使用者佔有的資料量的情況,可以看到佔用率比較靠前的幾個使用者。而這次報警的是第三個使用者CMBI_SNZG.
USERNAME Default TBS TEMP TBS CREATED Size (Mb)
------------------------------ --------------- --------------- ------------------- ------------
CMBI_MIN CMBI_MIN_DATA TEMP_NEW 2014-06-03 10:37:16 253,624
BIDATA BIDATA_DATA TEMP_NEW 2012-10-17 11:56:00 226,679
CMBI_SNZG CMBI_SNZG_DATA TEMP_NEW 2014-08-08 18:21:54 213,879
OWNER SEGMENT_NAME SEGMENT_TYPE SIZE_MB
------------------------------ ------------------------------ ------------------ ----------
CMBI_SNZG M_START_LOG TABLE 160
CMBI_SNZG IND_M_ONLINE_LOG INDEX 168
CMBI_SNZG IND_M_SDKSTART_LOG INDEX 520
CMBI_SNZG M_ONLINE_LOG TABLE 1472
CMBI_SNZG M_SDKSTART_LOG TABLE 3392
CMBI_SNZG IND_M_GAMEEVENT_LOG INDEX 22463
CMBI_SNZG M_GAMEEVENT_LOG TABLE 185619Tablespace STA M A Init Total MB Free MB Used MB LrgstMB MaxExt %Fr A
SYSAUX OLN L S 64K 51,030 4,039 46,991 1,005 2147483645 8 *
SYSTEM OLN L S 64K 14,400 565 13,835 498 2147483645 4 *OWNER SEGMENT_NAME SIZE_MB
------- ------------------------------------- ----------
SYS WRH$_SQL_PLAN 54
SYS SYS_LOB0000006331C00004$$ 57
SYS I_WRI$_OPTSTAT_H_OBJ#_ICOL#_ST 72
SYS WRH$_SQLSTAT 107
SYS WRM$_SNAPSHOT_DETAILS 234
SYS WRM$_SNAPSHOT_DETAILS_INDEX 280
SYS WRH$_LATCH_CHILDREN_PK 15950
SYS WRH$_LATCH_CHILDREN 28309
可以使用下面的語句進行一個簡單的驗證，發現大多數資料都來自於awr.
SQL> SELECT occupant_name "Item",
2 space_usage_kbytes / 1048576 "Space Used (GB)",
3 schema_name "Schema",
4 move_procedure "Move Procedure"
5 FROM v$sysaux_occupants
6* ORDER BY 2 desc
SQL> /
Item pace Used (GB) Schema Move Procedure
---------------------------------- -------- ----------------------------------------------------------------
SM/AWR 45.0463257 SYS
SM/OPTSTAT .176513672 SYS
SM/ADVISOR .16973877 SYS
XDB .153869629 XDB XDB.DBMS_XDB.MOVEXDB_TABLESPACE
SDO .07220459 MDSYS MDSYS.MOVE_SDO
EM .04486084 SYSMAN emd_maintenance.move_em_tblspc
SQL> select dbms_stats.get_stats_history_retention from dual;
GET_STATS_HISTORY_RETENTION
---------------------------
31那麼佔用空間較大的段是哪幾個呢？發現都是清一色來自WRH$_LATCH_CHILDREN
SQL> SELECT *
2 FROM (SELECT SEGMENT_NAME,
3 PARTITION_NAME,
4 SEGMENT_TYPE,
5 BYTES/1024/1024
6 FROM DBA_SEGMENTS
7 WHERE TABLESPACE_NAME = 'SYSAUX'
8 ORDER BY 4 DESC)
9* WHERE ROWNUM <= 10
SQL> /
SEGMENT_NAME PARTITION_NAME SEGMENT_TYPE BYTES/1024/1024
------------------------------ ------------------------------ ------------------ ---------------
WRH$_LATCH_CHILDREN WRH$_LATCH__723611991_53068 TABLE PARTITION 3343
WRH$_LATCH_CHILDREN WRH$_LATCH__723611991_53692 TABLE PARTITION 3046
WRH$_LATCH_CHILDREN WRH$_LATCH__723611991_52588 TABLE PARTITION 3014
WRH$_LATCH_CHILDREN WRH$_LATCH__723611991_52904 TABLE PARTITION 2895
WRH$_LATCH_CHILDREN WRH$_LATCH__723611991_54009 TABLE PARTITION 2891
WRH$_LATCH_CHILDREN WRH$_LATCH__723611991_53864 TABLE PARTITION 2551
WRH$_LATCH_CHILDREN WRH$_LATCH__723611991_53260 TABLE PARTITION 2540
WRH$_LATCH_CHILDREN WRH$_LATCH__723611991_52760 TABLE PARTITION 2535
WRH$_LATCH_CHILDREN WRH$_LATCH__723611991_53548 TABLE PARTITION 2530
WRH$_LATCH_CHILDREN WRH$_LATCH__723611991_53404 TABLE PARTITION 2524對於這部分資料可以做一些簡單的解讀，它的分割槽設定還是有一定的規律，分割槽會根據db_id和snap_id來組合生成對應的分割槽名稱。
比如DB_ID為：
SQL> select DBID from v$database;
DBID
----------
723611991
對應的快照為：
DB_NAME BEGIN_SNAP END_SNAP SNAPDATE LVL DURATION_MINS DBTIME
--------- ---------- ---------- ------------------------------ ---------- ------------- ----------
BIDB 54009 54010 07 Feb 2016 00:00 2 29 1
54010 54011 07 Feb 2016 00:30 2 30 0
如果對於v$latch_children有一些影響，可以從statspack找到一些資訊，statspack的幫助文件中是這麼描述設定的收集資訊的等級，level 6的部分有這麼一段描述。
6.2. Time Units used for Performance Statistics
Oracle now supports capturing certain performance data with millisecond and
microsecond granularity.
Views which include microsecond timing include:
- v$session_wait, v$system_event, v$session_event (time_waited_micro column)
- v$sql, v$sqlarea (cpu_time, elapsed_time columns)
- v$latch, v$latch_parent, v$latch_children (wait_time column)
- v$sql_workarea, v$sql_workarea_active (active_time column)
其中v$latch_children赫然在列。那麼這種情況可能是怎麼造成的呢，這部分統計資訊是不是過於詳細了。可以通過引數statistics來做進一步驗證。
SQL> show parameter statis
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
optimizer_use_pending_statistics boolean FALSE
statistics_level string ALL
timed_os_statistics integer 60
timed_statistics boolean TRUE
奇怪的是這個等級竟然不是預設的TYPICAL而是ALL,難怪這部分的資訊佔用的資料空間會格外大。
檢視備庫的設定資訊，做一個簡單的對比和驗證。
SQL> show parameter statistics
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
optimizer_use_pending_statistics boolean FALSE
statistics_level string TYPICAL
timed_os_statistics integer 0
timed_statistics boolean TRUE
所以這個問題就很顯而易見了，就是收集統計資訊的等級為ALL導致生成了大量的統計資訊資料。可以把資料庫修改為TYPICAL的模式就可以了。
SQL> alter system set statistics_level=typical;
System altered.
好了一個潛在的問題已經解決了，這部分的空間也可以手工刪除，更多細節不再贅述。
對於AWR還有一些資料值得參考，那就是快照的生成頻率和保留時長。目前的配置為：
SQL>select *from dba_hist_wr_control
DBID SNAP_INTERVAL RETENTION TOPNSQL
---------- ------------------------------ --------------------------------------------------------------------------- ----------
723611991 +00000 00:30:00.0 +00030 00:00:00.0 DEFAULT可以適當縮短保留時長，生成快照的頻率也可以降低。
exec dbms_workload_repository.modify_snapshot_settings(interval=>60,retention=>14*24*60);
DBID SNAP_INTERVAL RETENTION TOPNSQL
---------- ------------------------------ --------------------------------------------------------------------------- ----------
723611991 +00000 01:00:00.0 +00014 00:00:00.0 DEFAULT所以通過這些設定可以釋放出一部分寶貴的空間，當然也就可以轉換為新增的資料檔案大小了。最後把這些空間釋放了之後，再新增一個數據檔案，這個問題就暫時告一段落，至少可以在節後再進一步做更多的處理了。 關於第一篇，可以參見：system表空間不足的問題分析