581. 테이블 스페이스 (Tablespace) 시스템 용량 분산 관리 물리 파일 그룹핑

⚠️ 이 문서는 데이터베이스 관리자(DBA)가 수천만 건의 데이터가 쌓이는 거대한 오라클(Oracle)이나 DB2 시스템을 운영할 때, "모든 데이터를 C 드라이브 폴더 하나에 쑤셔 넣으면 하드디스크가 꽉 차서 DB 전체가 뻗거나, 검색 속도가 끔찍하게 느려지는 대참사"를 막기 위해, 데이터의 종류(인덱스, 회원, 로그)에 따라 저장될 물리적 하드디스크(SSD, HDD)의 위치를 다르게 지정하여 저장 공간(I/O)을 분산시키고 관리의 효율성을 극대화하는 '테이블 스페이스(Tablespace)' 아키텍처를 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 논리적인 '테이블'들과 물리적인 하드디스크 '데이터 파일(.dbf)'들 사이를 이어주는 **중간 완충 지대(가상의 서랍장)**다. 개발자는 이 서랍장에 테이블을 던져 넣고, DBA는 이 서랍장이 꽉 차면 뒤쪽에 새로운 하드디스크를 무한정 이어 붙여준다.
  2. 가치: "자주 쓰는 결제 테이블은 비싸고 빠른 SSD(C 드라이브) 서랍장에, 1년에 한 번 보는 백업 로그 테이블은 값싸고 느린 HDD(D 드라이브) 서랍장"에 나누어 보관함으로써 기업의 스토리지 비용(TCO)을 아끼고 디스크 입출력(I/O) 병목 현상을 완벽하게 찢어발긴다(분산).
  3. 기술 체계: 오라클 기준으로 딕셔너리가 들어가는 SYSTEM, 임시 정렬 시 쓰는 TEMP, 데이터 변경 전 과거 모습을 저장하는 UNDO, 그리고 사용자의 진짜 데이터가 들어가는 USERS 등 여러 개의 테이블 스페이스로 철저히 역할이 분리되어 굴러간다.

Ⅰ. C드라이브 몰빵의 붕괴: 왜 공간을 쪼개야 하는가?

하드디스크 하나에 모든 테이블을 구겨 넣는 자는 I/O 지옥을 맛본다.

  1. 물리적 파일 병목 (I/O Contention):
    • 디스크 1개에 회원, 주문, 인덱스 테이블을 몽땅 때려 박았다 치자.
    • 주문이 터지는 순간 회원 정보도 읽고 인덱스도 업데이트하느라 하드디스크 바늘(헤드) 하나가 이리 뛰고 저리 뛰다 과부하로 뻗어버린다 (디스크 경합).
  2. 테이블 스페이스(Tablespace)의 등판:
    • DBA는 디스크를 C, D, E 세 개를 샀다.
    • 가상의 서랍장(테이블 스페이스)을 2개 만든다. [TS_MEMBER] 서랍장은 C 드라이브에 연결하고, [TS_ORDER] 서랍장은 D 드라이브에 연결한다.
    • 개발자가 테이블을 만들 때 CREATE TABLE 주문 (...) TABLESPACE TS_ORDER; 라고 꼬리표를 붙인다.
    • 이제 주문 데이터는 무조건 D 드라이브에만 저장된다. 회원(C 드라이브)과 주문(D 드라이브)이 물리적으로 완벽히 찢어졌기 때문에, 동시에 쿼리가 들어와도 디스크 두 개가 병렬로 쾌적하게 윙윙 돌아가는(I/O 분산) 기적이 일어난다.

📢 섹션 요약 비유: 테이블 스페이스는 물류 창고의 '가상 구역(Zone)'입니다. 사장님(DBA)은 A구역은 1번 창고(C 드라이브)에, B구역은 2번 창고(D 드라이브)에 연결해 둡니다. 택배기사(개발자)는 하드디스크가 어딨는지 몰라도 됩니다. 그냥 "이 냉동 만두(테이블)는 B구역(테이블 스페이스)에 놔둬!"라고만 툭 던지면, 알아서 2번 창고에 예쁘게 저장되어 두 창고의 지게차가 엉키지 않고 쌩쌩 돌아가는 교통 통제 시스템입니다.

Ⅱ. 용량의 마술: 꽉 찬 서랍장에 마법의 주머니 달기

"테이블이 100GB를 넘었는데, 내 하드디스크는 50GB짜리밖에 없으면 어떡하죠?"

  1. 논리와 물리의 1:N 관계:
    • 엄청난 장점이다. 하나의 테이블 스페이스(논리 서랍장) 뒤에는 **여러 개의 물리적 데이터 파일(.dbf)**을 무한정 덧붙일 수 있다.
  2. 무중단 증설 (Add Datafile):
    • TS_ORDER 서랍장에 연결해 둔 50GB짜리 D 드라이브가 다 차버렸다.
    • 서비스가 마비될 위기에서 DBA는 당황하지 않고 100GB짜리 E 드라이브를 하나 더 사 온다.
    • 콘솔에 ALTER TABLESPACE TS_ORDER ADD DATAFILE 'E:\order_data02.dbf' SIZE 100G; 라고 단 한 줄 쳐준다.
    • 끝이다. 개발자는 테이블 이름이나 코드를 단 한 글자도 고칠 필요가 없다. 50GB짜리 주문 테이블은 이제 자연스럽게 D 드라이브와 E 드라이브 양쪽으로 찢어져서 저장되기 시작한다.

📢 섹션 요약 비유: 서랍(테이블 스페이스)에 옷(데이터)을 넣다가 꽉 찼습니다. 보통은 서랍장을 부수고 더 큰 걸 사 와야 하지만(테이블 이전의 고통), 오라클의 테이블 스페이스는 마치 '마법의 도라에몽 주머니'와 같아서, 서랍장 뒤통수에 구멍을 뚫고 새 쇼핑백(새로운 물리 디스크)을 테이프로 딱 붙여주기만 하면, 사용자는 밖에서 똑같은 서랍을 열고 끝도 없이 옷을 쑤셔 넣을 수 있는 무한 확장의 마법을 제공합니다.

Ⅲ. 시스템의 장기들: 4대 필수 테이블 스페이스

사용자 데이터만 저장하는 게 아니다. DB도 숨을 쉬려면 폐와 위장이 필요하다.

  1. SYSTEM (시스템 테이블 스페이스) - 뇌와 호적부:
    • DB의 뇌다. 여기에는 개발자가 만든 테이블 구조, 유저 비밀번호, 권한 등 DB가 살아가는 데 필요한 **'데이터 딕셔너리(Data Dictionary, 메타데이터)'**가 저장된다.
    • 이 서랍장이 꽉 차거나 깨지면 DB 전체가 그 자리에서 즉사(Shutdown)한다. 일반 유저의 데이터를 절대 여기에 섞어 넣으면 안 된다.
  2. TEMP (임시 테이블 스페이스) - 도마와 연습장:
    • 수천만 건의 데이터를 ORDER BY 하거나 GROUP BY 할 때, RAM(메모리) 용량이 부족하면 DB는 이 TEMP 디스크 공간에 데이터를 잠깐 부어놓고 쓱싹쓱싹 정렬(Sorting)을 한다.
    • 연산이 끝나면 자동으로 내용물이 깨끗하게 싹 지워지는 1회용 연습장이다.
  3. UNDO (언두 테이블 스페이스) - 타임머신과 롤백:
    • 트랜잭션이 생명인 DB의 필수품이다. 누군가 UPDATE를 치면, 변경되기 직전의 옛날 과거 데이터를 몰래 이 UNDO 서랍장에 킵(Keep)해둔다.
    • 나중에 변심해서 ROLLBACK을 외치면 여기서 과거 데이터를 꺼내 원상 복구시키며, 남들이 현재 UPDATE 중인 데이터를 조회하려고 할 때 임시로 옛날 데이터를 보여줘서 락(Lock) 없이 읽기 일관성(Read Consistency)을 보장해 주는 심장이다.
  4. USERS (유저 테이블 스페이스) - 민간인 거주지:
    • 우리가 짜는 진짜 업무용 회원, 결제 테이블이 들어가는 기본 민간인 거주 구역이다. 필요에 따라 업무별로 수십 개로 쪼개서 분양한다.

📢 섹션 요약 비유: 테이블 스페이스는 식당 구조와 같습니다. SYSTEM은 사장님의 '영업 허가증과 금고'가 있는 절대 출입 금지구역입니다. TEMP는 요리사가 양파를 다질 때 임시로 쓰는 '도마(연습장)'라 요리가 끝나면 씻어서 비워둡니다. UNDO는 찌개에 소금을 잘못 넣었을 때 시간을 되돌릴 수 있는 '과거 요리 백업 냉장고'입니다. 마지막으로 USERS는 손님들이 앉아서 진짜 돈을 내고 밥을 먹는 '홀(영업 공간)'입니다. 이 네 공간이 섞이지 않고 완벽히 분리되어야만 1급 미슐랭(오라클 DB) 식당이 돌아갑니다.