서버 프로세스와 백그라운드 프로세스, read committed

그림으로 공부하는 오라클구조라는 책을 2회독 하고 있다. 체감상 내용을 정리하지 않으면 기억에 잘 남지 않는다고 느껴서, 책에서 새롭게 알게 된 내용을 기준으로 정리를 해보려고 한다. 

 

✅ 서버 프로세스와 백그라운드 프로세스의 구분

우선 DB는 멀티 프로세스이고, 이 여러 프로세스들은 크게 서버 프로세스와 백그라운드 프로세스로 나눠져 있다는 것을 처음 알았다. 멀티 프로세스까지는 예상했었는데, 프로세스별로 역할이 다른 줄은 몰랐다. 역할을 분리한 이유는 사용자의 요청을 효율적으로 처리하기 위해서라고 이해했다. 

 

모든 프로세스가 차례대로 SQL 문을 받아서 파싱하고, 최적인 것처럼 보이는 수행 계획을 짜고, 실행한 다음 그 결과를 디스크에 기록하고(여기서의 디스크는 로그 디스크이며 데이터 기록용 디스크가 아니다), 그 결과를 오라클 클라이언트에게 건네주면 안 되는 것은 아니다. 그러나 아래의 경우 비효율적이다. 

 

commit 된 결과를 로그 디스크에 기록하는 것은 ACID 원칙 중 Durability를 만족시키기 위해서 필요하다. 그러나 로그 디스크에 기록을 하게 되면 오라클 클라이언트는 그만큼의 시간을 더 기다려야 한다. 사실 데이터를 디스크에 기록하는 일은 오라클 클라이언트가 결과를 받는 것과는 상관이 없는 일이기 때문에 클라이언트 입장에서는 불필요한 대기 시간이 생긴다. 

 

이러한 경우 프로세스의 역할을 분리하면 문제를 쉽게 해결할 수 있다. 서버 프로세스는 클라이언트의 응대를 최우선으로 한다. 그리고 클라이언트의 응대와 직접적으로 연관되지 않은 작업들(SQL을 입력으로 받아 최적의 탐색 계획을 짜거나, 디스크에 데이터를 기록하는 작업들)은 다른 백그라운드 프로세스에 위임한다. 

 

물론 하나의 DBMS에서 서버 프로세스가 하나인 것은 아닐 것이다. 여러 개의 서버 프로세스와 여러 개의 백그라운드 프로세스가 같이 동작한다고 이해했다. 각 프로세스가 동시에 특정 row나 table의 데이터를 편집(CUD)하는 경우 등을 막기 위해서 적절한 lock이나 semaphore도 사용될 수 있을 것이다. (여기서부터는 추측이다)

 

✅ DBMS가 많이 사용하는 Isolation level은 Read Committed

트랜잭션들의 고립(isolation) 정도에 대해서는 오라클과 같은 대부분의 DBMS가 read committed level을 사용한다고 한다. Serializable이야 트랜잭션의 실행 효율이 떨어져서 안 쓴다고 쳐도, repeatable read level이 아니라는 것이 의외였다. (read committed에서는 unrepeatable read, phantom row 문제가 나타날 수 있다.) 4가지 level 중 read uncommitted를 논외로 한다면, 어떤 isolation level이 더 좋고 이런 문제가 아니라 효율성과 완벽한 고립의 tradeoff라고 한다. 많은 DBMS들이 효율적인 트랜잭션 처리를 위해서 read committed를 사용한다고 이해했다. 

 

❓ DBMS도 프로그램의 일종인 만큼 사용할 수 있는 데이터의 제한이 있을 것이다. 이 제한을 넘게 되면 어떻게 되나?

❓ Lock과 Latch의 차이점은 무엇일까? 책에서는 Latch를 Lock의 작은 조각으로 비유했는데, 이게 무슨 의미인지 모르겠다. 

❓ SQL문의 실행 계획은 공유 풀(프로세스 간에 공유되는 메모리) 안의 라이브러리 캐시 공간에 있다. 라이브러리 캐시에 실행 계획을 적재할 때에도 LRU와 같은 알고리즘을 통해서 판별할 수 있을까?

❓ 데이터가 어떻게 물리적으로 저장되는지를 지금까지 거의 생각해보지 않았었다... DB(오라클)의 논리 구조인 세그먼트, 익스텐트, 블록이 어떻게 데이터파일 안에 저장될까? 빈 공간을 감수하고 나누는 것일까? 그런데 그러다가 한 블록/익스텐트/세그먼트의 단위를 데이터가 침범해 버리면 또 어떻게 하려는 걸지 궁금하다.

❓ 또한 테이블에 컬럼을 추가하거나 삭제되는 경우도 있는데, 이 경우에는 데이터가 어떻게 관리되는 걸까?