문서유형ㅣ장애해결
분야ㅣ모니터링/점검
적용제품버전ㅣTibero 7.2.3
문서번호ㅣTMOTS027
현상
Extent Allocation을 autoalloc으로 설정한 상태에서 데이터의 추가와 drop/truncate 작업이 반복될 경우, 데이터 파일 내 공간이 점점 단편화되는 문제가 발생할 수 있습니다.
이러한 단편화로 인해 시간이 지남에 따라 점점 더 큰 extent를 할당받기 어려워지고, 시스템은 점점 더 작은 extent로 줄여가며 재시도하게 됩니다. 이 과정에서 성능 저하가 발생할 수 있습니다.
예를 들어, 거래 로그를 저장하고 주기적으로 삭제하는 업무 등에서 이러한 문제가 나타날 수 있습니다.
원인
- extent 할당 방식이 autoalloc으로 설정되어 있는 경우 (기본값)
- 주기적으로 segment의 create/insert와 drop/truncate가 반복되는 경우
이 때 autoalloc 방식으로 할당된 작은 크기의 extent들이 공간 내에 조각나게 되며, 이러한 단편화가 점진적으로 누적되어 문제를 유발합니다.
참고
truncate나 drop이 거의 발생하지 않고, 한 번 만들어진 segment를 계속 확장하면서 사용하는 경우에는 해당 문제가 발생하지 않습니다.
실제로 undo tablespace에서도 동일한 문제가 발생한 바 있으며, 이에 따라 undo segment의 할당 방식을 uniform으로 강제하도록 변경한 이력이 있습니다.
sys.log [2025-09-10T21:45:44.285286] [TXT-209] [I] can't extend tablespace TS #3(USR) [2025-09-10T21:45:44.285294] [FRM-205] [I] THROW. ec=ERROR_TX_CANT_ALLOC_EXT(-21004) [ No more extent available in tablespace 'USR'. ] (sql_id:99sjcprmyz8sv, sub_sql_id:99sjcprmyz8sv, csr_id:108702, user:TIBERO, ap_module:(null), program:conn_DPI, host:ys) [tx_ts.c:1672:ts_extend] [2025-09-10T21:45:44.285301] [FRM-209] [I] THROW. ec=ERROR_TX_CANT_ALLOC_EXT(-21004) [ No more extent available in tablespace 'USR'. ] (sql_id:99sjcprmyz8sv, sub_sql_id:99sjcprmyz8sv, csr_id:108973, user:TIBERO, ap_module:(null), program:conn_DPI, host:ys) [tx_ts.c:1672:ts_extend] [2025-09-10T21:45:44.285390] [FRM-194] [I] THROW. ec=ERROR_TX_CANT_ALLOC_EXT(-21004) [ No more extent available in tablespace 'USR'. ] (sql_id:99sjcprmyz8sv, sub_sql_id:99sjcprmyz8sv, csr_id:109139, user:TIBERO, ap_module:(null), program:conn_DPI, host:ys) [tx_ts.c:1672:ts_extend] [2025-09-10T21:45:44.285440] [FRM-215] [I] THROW. ec=ERROR_TX_CANT_ALLOC_EXT(-21004) [ No more extent available in tablespace 'USR'. ] (sql_id:99sjcprmyz8sv, sub_sql_id:99sjcprmyz8sv, csr_id:122137, user:TIBERO, ap_module:(null), program:conn_DPI, host:ys) [tx_ts.c:1672:ts_extend] [2025-09-10T21:45:44.285704] [FRM-204] [I] THROW. ec=ERROR_TX_CANT_ALLOC_EXT(-21004) [ No more extent available in tablespace 'USR'. ] (sql_id:99sjcprmyz8sv, sub_sql_id:99sjcprmyz8sv, csr_id:108837, user:TIBERO, ap_module:(null), program:conn_DPI, host:ys) [tx_ts.c:1672:ts_extend] [2025-09-10T21:45:44.285720] [FRM-198] [I] THROW. ec=ERROR_TX_CANT_ALLOC_EXT(-21004) [ No more extent available in tablespace 'USR'. ] (sql_id:99sjcprmyz8sv, sub_sql_id:99sjcprmyz8sv, csr_id:108531, user:TIBERO, ap_module:(null), program:conn_DPI, host:ys) [tx_ts.c:1672:ts_extend] Tablespace 조회 SEGMENT_NAME SEGMENT_TYPE MB ------------ ------------ ---- DPI_TEST TABLE 3088 1 row selected. TABLESPACE_NAME TOTAL_GB USED_GB FREE_GB USED_PCT --------------- -------- ------- ------- -------- UNDO .13 .13 0 99.9 SYSTEM .1 .09 0 97.19 SYSSUB .06 .05 .01 78.98 USR 31.96 3.02 28.94 9.44 |
해결
사전 예방
- 해당 업무가 단편화를 유발할 가능성이 있는 경우, 초기부터 tablespace의 extent management를 uniform 64M 등으로 설정하시는 것을 권장드립니다.
- 또는 uniform으로 설정한 별도의 tablespace를 신규로 생성한 후, 점진적으로 이관하는 방식도 고려할 수 있습니다.
사후 조치
- 이미 단편화가 진행된 이후에는, 전체 데이터를 drop하고 새로 부어넣는 방법 외에는 적절한 해결 방법이 없습니다.
참고진단 방법
- TPR에서 Workload Stats (Time-based) 항목 중 sgmt alloc ext time이 insert time대비 2-30% 이상 많게는 90%이상 차지하는 경우
- dba_free_space 뷰를 조회한 결과 row 수가 매우 많고 각 row별 block count, size byte가 작을 때
(16block, 128K가 대부분)- Workload Stats (Time-based) 항목 중 sgmt alloc ext from datafile time의 비율이 높고 (2-30% 이상 많게는 90%이상) size(alloc fail count) 값이 num(datafile을 돌면서 alloc 수행 횟수)에 근접할 경우
- DBA_FREE_SPACE view를 조회하여 연속된 blocks 확인
# BLOCK_ID부터 연속된 블록이 BLOCKS만큼 존재하며 전체크기는 BYTES # SQL> select * from dba_free_space; TABLESPACE_NAME FILE_ID BLOCK_ID BYTES BLOCKS RELATIVE_FNO -------------------- ---------- ---------- ---------- ---------- ------------ SYSTEM 0 12775 262144 32 0 USR 2 7 1048576 128 2 SYSSUB 3 22567 7864320 960 3 SYSSUB 3 23751 2883584 352 3 SYSSUB 3 24279 1835008 224 3 SYSSUB 3 27415 3276800 400 3 SYSSUB 3 27879 3801088 464 3 SYSSUB 3 30103 4718592 576 3 SYSSUB 3 31127 4587520 560 3 ... 중략 ... 32 rows selected. SQL>