왜 Docker는 파일을 삭제해도 디스크 유휴 공간이 늘어나진 않는가? 배경: Spark와 Hadoop을 Docker로 구축하고 몇 주 지나면, ⦁ 처음: "C: 드라이브" - 100GB 여유 ⦁ 몇주 후: "C: 드라이브" - 20GB 남음 (경고) 문제의 원인: ⦁ Docker는 삭제한 데이터도 실제로 안 지워짐 ⦁ WSL2 디스크는 늘어나기만 하고 절대 안 줄어듬WSL2 디스크가 안 줄어드는 이유 ⦁ WSL2는 가상 디스크(ext4.vhdx) 사용✅ 파일 추가: 가상 디스크 자동 확장 (10GB -> 50GB) ✅ 파일 삭제: 가상 디스크 크기 그대로 (50GB 유지) -> 수동 압축 필요!이 글의 목적:✅ 안전하게 불필요한 Docker 파일 삭제✅ WSL2 디스크를 실제로 줄이..

왜 Oracle은 테이블을 지워도 용량이 안 줄어들까?PostgreSQL 사용자라면, 디스크 공간 정리는 수월하다:-- PostgreSQL: 테이블 삭제하면 디스크 공간 바로 반환DROP TABLE big_table;--> 로컬 디스크(C:) 유휴 용량 즉시 증가하지만 Oracle은 다르다:-- Oracle: 테이블 삭제해도 디스크 공간 그대로DROP TABLE big_table;--> 로컬 디스크(C:) 용량 변화 없음 -> ???왜 이런 차이가 발생하는가?PostgreSQL의 파일 관리 방식: ⦁ 테이블마다 개별 파일로 저장 ⦁ 테이블 삭제 시 해당 파일 자체를 삭제 ⦁ 디스크 공간 즉시 반환 Oracle의 파일 관리 방식: ⦁ 테이블스페이스(Tablespace) 라는 거대한 컨테이너 ..

왜 SQL 트레이스가 필요한가?'EXPLAIN PLAN'이 있지만, 이것만으로는 부족하다: 1. 예측 vs 실제: EXPLAIN PLAN은 예상 실행 계획일 뿐, 실제 수행 통계는 제공하지 않음 2. 대기 이벤트 미포함: 디스크 I/O 대기, 락 대기 등 실제 병목 지점을 알 수 없음 3. 누적 통계 부재: 여러 번 실행되는 쿼리의 평균/최대 성능을 추적 불가 이를 해결하는 것이 SQL 트레이스다: ⦁ 쿼리 실행 중 모든 활동을 로그 파일에 기록 ⦁ TKPROF 도구로 가독성 있는 리포트로 변환 ⦁ 실제 수행 시간, I/O 횟수, 대기 이벤트까지 상세 분석 SQL 트레이스 프로세스 개요1. 추적 시작 (ALTER SESSION SET SQL_TRACE = TRUE) ↓ 2. 쿼리..

上편에서는 5,300만 건 규모의 로그 데이터에서 ROWNUM페이징과 OFFSET/FETCH페이징의 성능을 비교했다.두 방식 모두 인덱스 없이는 수십 초의 응답 시간이 소요되었다. 下편에서는 복합 인덱스 설계와 Materialized View(MV)를 활용한 튜닝 방법을 다룬다.특히 조건 유무에 따라 어떤 전략이 효과적인지 실제 트레이스 결과로 검증한다.복합 인덱스 설계인덱스 생성 전략 : 대량 데이터에서 상대적으로 우수한 성능을 보인 ROWNUM페이징 쿼리를 기준으로 복합 인덱스를 설계한다.SELECT JOB_SN, JOB_DT, JOB_CTG, JOB_NM, INST_NM, ID, JOB_RSTFROM ( SELECT A.*, ROWNUM AS RN -- 내부 정렬된 결과에 ROWNUM을 순서대로..

웹에서 대량의 데이터를 조회할 때, 사용자는 수천만 건의 데이터를 한 번에 보지 않는다.대신 10건, 20건씩 페이지를 넘기며 필요한 정보를 찾는다. 이것이 바로 페이징(Paging)이다. 하지만 5천만 건 이상의 데이터에서 페이징 조회 쿼리를 잘못 구현하면, 단 10건을 조회하는데도 수십 초가 걸릴 수 있다. 이번 글에서는 5,300만 건의 로그 데이터를 대상으로 Oracle 페이징 쿼리의 성능 문제를 진단하고, 두 가지 페이징 방식을 비교 분석한다. 성능 검증 개요① 데이터 규모: 약 5,300만 건의 사용자 로그 데이터 (JOB_LOG_S212 테이블) 실습 데이터 : https://whats-your-etl.tistory.com/56② 시스템 로그 관리 페이지에서 사용자가 입력하는 조건에 따라 4..