데이터 관리에 있어 대게 두 가지 의견이 상충됩니다. 하나는 데이터 변경에 대한 유연한 공간확보이고, 다른 하나는 잉여공간의 관리 입니다. 예를 들어 100개의 데이터를 배열에 담아야 한다면 여러분은 배열의 크기를 어떻게 설정하시겠습니까? 혹은 어떤 방법을 사용해서 자료구조를 만드시겠습니까? 100개의 데이터가 줄어들수도, 늘어날수도, 변경될 수도 있다면 더 깊게 고민해봐야 할 것입니다.
아래는 오라클이 사용하는 데이터 구조입니다. 작은 단위에서 큰 단위로 흘러가고 있습니다.
물리구조 : Block -> Data File
논리구조 : Block(물리) -> Oracle Block -> Extent -> Segment -> Table Space
Block
위 스크린샷만 이해하면 이번 챕터를 졸업한 것 입니다. 블록의 크기는 2KB, 4KB, 8KB 등으로 설정 되며, 내부에는 관리용 공간과 데이터 저장공간을 분리하여 사용합니다. 특히 데이터를 저장할 때는 여분의 공간을 비워 데이터 변경에 대해 유연함을 확보하고 있습니다.
Extent
여러개의 블록은 하나의 익스텐트를 구성합니다(그림 ‘오라클 자료구조’ 하단 참조). 익스텐트는 ‘연속된 블록’의 집합이라는 것이 중요합니다. 블록 내부에는 빈 공간이 존재하지만 블록을 연속적으로 관리함으로 인해 불필요한 I/O를 줄일 수 있습니다. 또한 각 익스텐트의 첫 위치와 블록의 개수만 파악해도 데이터를 관리할 수 있어 최소한의 관리정보를 유지하게 됩니다.
#####Segment
세그먼트는 넓은 의미에서는 설명하면 여러 익스텐트의 집합이지만, 좁은 의미에서는 테이블이나 인덱스가 관리되는 공간으로 사용됩니다. 따라서 사용자가 직접적인 조작이 가능하며(Ex 테이블의 생성과 삭제) 이에 따라 세그먼트를 관리하는 테이블 스페이스의 공간이 변화하게 됩니다. 또한 데이터를 정렬하는 세그먼트, 과거 데이터를 보관하는 세그먼트 등도 존재합니다. 테이블의 정보가 서로 다른 테이블 스페이스에 나눠 기록될 수 없듯, 세그먼트는 하나의 테이블 스페이스에 속하게 됩니다.
Table Space
연관되어 있는 세그먼트의 집합입니다. 리두, 언두 세그먼트를 관리하는 테이블 스페이스, 데이터를 관리하는 테이블 스페이스, 데이터베이스를 관리하는 테이블 스페이스 등 다양한 형태로 나눠져 있습니다. 실제 물리적인 파일(.dbf .ora 등)은 테이블스페이스와 대응이 됩니다.
테이블스페이스 + 리두 로그 파일 + 컨트롤파일 = 데이터베이스
결론
오라클의 자료구조는 ‘최소한의 공간 낭비로 최대의 데이터의 유연성을 확보하는 것’에 초점을 두었다고 생각합니다. 책에는 ROW ID에 대한 설명, 실제로 테이블 스페이스부터 만드는 과정 들이 포함되어 있지만 결국, 오라클 자료구조가 어떻게 동작하는지 설명하기 위한 수단에 지나지 않습니다. 블록부터 테이블 스페이스까지의 개념을 이해하면 해당 챕터를 이해했다고 생각해도 됩니다.
오늘도 어김없이 감사합니다 ;)