Day 27(oracle)

 

기본구조는 Instance와 Database로 구성 되어있다. Instance는 논리구조(Logical Structure)라고 하고 Database는 물리구조(Physical Structure)라고 한다. Instance는 메모리에 있고, Database는 물리적 저장매체에 있다.

 

DB에서 명령어 실행이 진행되는 과정은 'Day 25 ( Oracle12c 계정 생성 및 DBserver)'에 있는 shutdown, startup 과정을 보면 알수있다. 명령어 실행은 명령어가 sqlplus같은 userprocessor에서 문장을 실행하기 위해 ~; enter을 입력하면 userprocessor가 serverprocessor로 동작을 지시한다. 이를 통해 Instance를 메모리에 올리고 Database에 mount(접속)하고 Database를 연다.

serverprocessor는 메모리에서만 데이터를 읽어올때 '실행 계획 설립'작업을 실행한다. 1. 문장오타검사 2. 테이블, 컬럼이 실제로 있는지 dictionary에서 확인 3. 실행계획(excution plan)을 생성한다. 실행계획을 설립하고 수행하는 행위를 pasing이라고 한다. 그런데 같은 문장을 반복적으로 pasing하게 되면  리소스 낭비가 너무 심하기 때문에 실행했던 경험이 있는 문장은 기억했다가 추후에 pasing없이 바로 수행하게 된다. pas율은 문장을 수행하는데 얼마나 pasing 하는 지를 비율로 나타낸값이다. 통상 0.2%이상이다. sql injection은 pasing율로 알수있는데 pasing율이 높다는것은 반복적인 문장을 계속 불러온다는 의미고 성느이 안좋다고 할수있다 구조가 정확해서 pasing율이 낮게 되면 sql injection 당하지 않는다.

 

 

먼저 Database파트를 보면 Datafile, Controlfile, Redologfile로 구성되어있다.

Datafile은 CREATE한 모든 데이터가 입력되어 있다.

Redologfile은 데이터를 변경시키는 작업(tranjection)을 수행시간, 완료시간, 적용시간, 수행한 계정등의 정보를 전부 기록해놓은 파일이다. 보통 redo의 의미는 이전에 수행했던 작업을 다시 수행하는 것이고 undo는 작업을 취소하는 의미이다. Redologfile은 무한히 저장이 불가능 하므로 용량이 정해져있는데 수용용량이 넘어서게되면 Archivedlogfile로 데이터가 이동하고 Redologfile은 비워진다. Archivedlogfile은 Systembackup수행할때 Backup이 완료되었을때만 그 이전 데이터를 삭제한다. 따라서 Redologfile을 참고해서 데이터 복구가 가능하다.

Controlfile은 Datafile과 Redologfile에 비해 상대적으로 용량이 매우 적다. 하지만 사용자 대신에 시스템을 이용해 Datafile과 Redologfile의 위치나 상태를 파악하고 이를 이용해 데이터 저장이나 수정 정보등을 저장하는데 사용한다. 만약 Controlfile이 손상된다면 DB자체를 사용할 수 없게 된다.

 

Instance파트를 살펴보겠다. Instance는 serverprocessor에서 startup시 생성되고 메모리 위에서 처리하기 때문에 튜닝에서 주로 다룬다. Instance는 SGA(System Global Area)와 BackGroundProcessor로 구성된다. 먼저 BackGroundProcessor를 보면 굉장히 많은데 크게 PMON, SMON, DBWR, LGWR, CKPT, 기타로 나눌 수 있다. 명칭을 읽는 발음이 정확해야 Oracle에 관해 소통하는데 문제가 없다. PMON(피몬), SMON(에스몬), DBWR(디비라이터), LGWR(로그라이터), CKPT(체크포인트)라고 읽는다. 디비라이터는 DBWn, DBW0등으로 작성가능한데 프로세서를 어러개 사용할때 사용하는 명칭이다.

 

SGA는 Shared Pool(쉐어드풀), DataBase Buffer Cache(데이터베이스버퍼캐시), Redolog Buffer(리두로그버퍼), Java Pool(자바풀), Large Pool(대용량풀) 5가지로 구성된다. 이중 Shared Pool(쉐어드풀), DataBase Buffer Cache(데이터베이스버퍼캐시), Redolog Buffer(리두로그버퍼)에만 초점을 둘 것이다.

먼저 데이터베이스버퍼캐시는 일종의 작업장으로 생각할 수 있다. commit을 해도 리두로그에는 남지만 수정된 데이터가 물리매체에 저장되는지 메모리에서만 저장된것인지는 알 수 없다. Oracle 8i까지는 어디에 저장되는지 확인이 가능했지만 그 이후 버전에서는 무결성을 해칠 수 있기 때문에 알 수 없다. 매번 데이터파일을 불러올 수 없기 때문에 데이터베이스버퍼캐시에 데이터를 올려놓는다. 그리고 serverprocessor가 데이터를 요청할 때 마다 데이터파일에서 불러오는 것이 아니라 데이터베이스버퍼캐시에서 불러오는것이다. 만약 데이터베이스버퍼캐시에서 데이터를 검색하는 것을 get한다고 한다. 그리고 검색한 데이터와 일치하는 데이터가 있다면 hit이라고 하고 일치하는 데이터가 없다면 miss라고 한다. miss가 되면 데이터파일에서 데이터베이스버퍼캐시로 데이터를 가져온다. 따라서 get당 hit비율이 높은것이 효율이 높기때문에 좋다.

리두로그버퍼는 리두로그엔트리를 시간순서에 따라 저장하는 곳인데, 리두로그엔트리는 트렌젝션의 모음이라고 볼수있다. 리두로그버퍼에 있는 정보가 commit시 리두로그파일로 이동하게 되고, rollback시 undo되지만 rollback한 내용은 남는다. 따라서 리두로그파일에 저장이 되어야 최종적으로 데이터가 수정되는 것이고, 저장되지 않았다면 수정되지 않은것이다.

 

<참조>
Oracle을 포함한 모든 DB들은 실제 물리매체에 문제가 생겨도 즉각적으로 알수없고 시간이 지난후에 알게된다. 실제 물리적 저장매체의 이상유무를 점검하기 위해서는 DB를 죽여야 한다. 추후에 DB에 문제가 생겨서 발생하는 비용보다 사전에 일정시간 DB를 죽이고 점검한 후 다시 살리는 비용이 저렴하고 대처가 가능하기 때문이다.

버퍼와 캐쉬의 가장 큰 차이점은 저장된 데이터를 순차적으로 접근할 수 있는지, 원하는 데이터에 직접 접근할 수 있는지 이다.
버퍼는 두개의 장치간에 데이터 전송을 할때 두 장치간, 또는 네트워크의 상태로 인한 속도차이 때문에 발생하는 데이터 전송 문제를 극복하기 위한 장치다. 예를 들어 하나의 장치는 전송속도가 빠르고 다른 하나는 전송속도가 느리다면 빠른 장치는 데이터를 빨리 보내려고 하지만 느린 장치가 데이터를 빨리 받지 못하기 때문에 빠른 장치도 느린 장치의 속도에 맞춰야 한다. 하지만 버퍼가 있다면 빠른 장치는 빠른 속도로 버퍼에 데이터를 전송해 놓고, 다른일을 할 수 있다. 느린 장치는 버퍼에 있는 데이터를 순서대로(First In First Out)으로 받으면 된다.
캐쉬는 최근에 사용한 데이터나 자주 사용되는 데이터를 임시로 저장해 두었다가 필요할때 꺼내어 쓰기위한 저장공간이다. 자주쓰는 데이터들을 고속의 메모리에 저장해두고 필요시마다 꺼내 쓰기때문에 컴퓨터에서 가장 느려터진 저장공간인 하드디스크에 접근할 필요가 없기때문에 빠른 작업을 가능하게 한다.