2.1 오라클의 역활 이미지
오라클을 '창고 업자'라고 가정하자. 창고 업자란 고객의 짐을 받아서 맡아주고, 짐을 창고에 보관하고, 고객의 요청에 따라 짐을 고객에게 돌려주는 업무를 하는 회사이다.
오라클을 포함한 DBMS(데이터베이스 관리 시스템)도 기본적인 동작은 '데이터를 짐처럼 맡아서 보관하고, 요구에 따라 데이터를 반환한다'라는 점에서 꽤 비슷하다.
칼럼
DBMS를 사용한 애플리케이션에 관해서
"시스템에서 데이트베이스는 어떤 식으로 사용되고 있는 걸까?"
- '데이터베이스는 데이터를 보관하는 장소로 사용되고 있으며, 애플리케이션이 데이터를 보관하고(또는 변경하거나 꺼내고) 싶을때 사용한다'. 애플리케이션은 업무 처리나 화면 처리를 수행한다. 애플리케이션은 이러한 작업들을 처리하다가 '이 데이터가 필요하다'라고 생각한 시점이 되면 DB에 접근해서 데이터를 꺼내 온다. 애플리케이션도 변수의 형태로 데이터를 보관할 수는 있지만, 이는 어디까지나 메모리에 임시로 저장하고 사용하는 것이다. 그래서 일반적으로 애플리케이션이나 프로세스 간에 데이터를 공유할 수 없다. 따라서 종류가 많고 크기가 큰 데이터를 취급하는 시스템에서는 데이터베이스를 만들어 데이터관리를 맡긴다.
"연구 논문이나 책들을 읽어 보면 오라클은 SQL문을 수행하기 위해 SQL*Plus라고 하는 것을 사용하는 듯한데, 이를 애플리케이션이 사용해도 괜찮을 걸까?"
- '실제 시스템에서 애플리케이션이 SQL*Plus를 직접 사용하는 일은 거의 없다'. 실제로 대부분의 시스템에서 애플리케이션은 JDBC(Java DataBase Connectivity)나 ODP.NET(Oracle Data Provider for .NET), Pro*C(오라클에서 사용하는 C언어 프리 컴파일러) 같은 것을 통해 오라클에서 SQL문을 수행한다. SQL*Plus는 대부분 데이터베이스의 관리(테이블이나 인덱스의 생성 및 사람이 수동으로 직접 데이터를 검색하는 작업 등)를 위해서 사용한다.(단, 예외 사항으로 스크립트 안에 포함해 배치 처리 등에 사용하는 떄도 있다.)
리스트 2.1 자바에서 데이터베이스 사용하기
.
.
업무 처리 코드
.
.
여기서 데이터베이스의 데이터가 필요해짐
.
.
Connection conn = DriverManager.getConnection(url,user,pwd); --여기서 DBMS에 연결함
Statement st = conn.createStatement();
ResultSet rs = st.executeQuery("SELECT no, name FROM test WHERE ...");
-- 11번줄 코드 부분에 의해 SQL문이 DBMS에 전달됨.
-- DBMS는 SQL문을 받으면 처리해서 결과를 애플리케이션에 반환하며, 그 결과는 왼쪽의 ResultSet에 보관됨.
-- 이후 애플리케이션은 이 ResultSet의 데이터를 사용해서 업무 처리나 화면 처리를 수행함
.
.
가져온 데이터를 이용해서 업무 처리 재개
.
.
업무 처리가 계속됨
.
.
2.2 데이터베이스의 데이터는 모두의 것
2.2.1 실제 모습에 가까운 오라클의 이미지
오라클에게 각종 프로그램(SQL*Plus를 포함)은 고객이라고 볼 수 있으며, 오라클은 SQL문과 그 결과의 데이터를 프로그램과 송수신한다. DBMS인 오라클은 해당 데이터를 디스크에 저장하고 관리한다. 고객인 각종 프로그램은 여러 개 존재할 수 있으며, 의뢰를 받는 입장인 오라클의 프로세스도 여러 개 존재한다. 이 '여러 개'라는 개념은 DBMS를 이해하는 데 있어서 매우 중요하다.
데이터베이스를 사용하지 않는 애플리케이션의 프로그래밍에서는 각각의 프로세스가 자신이 가진 변수(데이터)를 처리하는 것이 일반적이다. 같은 프로그램이 여러 개 실행되었다 하더라도 실제로 변수는 개개의 프로그램마다 존재하기 떄문에 프로세스간의 간섭을 신경을 쓸 필요가 없다. 따라서 다른 프로그램을 고려하지 않고 데이터를 원하는 대로 건드려도 문제가 없다. 여러분도 프로그래밍할 떄는 변수에 Lock를 건다든가, '다른 사람이 사용하고 있어서 이 변수는 사용하지 못할 수도 있어'와 같은 생각을 해본 적은 없었을 것이다.(단, 멀티스레드 프로그램은 제외한다.)
하지만 데이터베이스에서는 여러 프로세스나 사용자가 하나의 데이터베이스(데이터 집합)에 접근하기 때문에 다른 사용자나 애플리케이션을 신경 쓰지 않을 수 없다.
- 일반적인 프로그램에서의 데이터 취급
같은 프로그램을 여러 개 실행했다고 해도 OS상에서는 다른 프로세스이므로 변수 A도 여러 개 존재하며, 독립되어 있다. 따라서 가넙을 할 수도, 데이터를 덮어쓰는 일도 없으며, 다른 프로그램의 변수를 보는 것도 할 수 없다.
- 데이터베이스에서의 데이터 취급
접근하는 프로세스가 각각 다르다고 하더라도 데이터베이스에서는 데이터를 하나로 관리하고 있으므로, 다른 사람이 변경한 데이터를 볼 수 있다. 또한, 반대로 다른 사람에게 데이터를 보여주는 것도 가능하다. 그리고 같은 이름을 가진 테이블을 계정마다 만들 수는 있지만, 일반적으로 동일한 여러개의 테이블을 만들어 사용하지는 않는다.(테이블을 계정이나 프로세스별로 사용하면 안 된다는 의미는 아니다.)
예를들어 주문 이력이라고 하는 테이블(데이터)이 있고, 크기는 10GB이며, 이 테이블을 사용하는 사용자가 100명이 있다. 주문 이력 테이블을 사용하는 데 서로 간섭을 일으키지 않도록 100명분 X 10GB의 데이터를 가지고 있어야 할 필요가 있을까? 또한, 사용자가 오퍼레이터라고 한다면 입력한 주문 테이터를 다른 오퍼레이터가 볼 수 없다고 해도 상관이 없을까?
이런 부분에서 알 수 있듯이, 기본적으로 데이터베이스에는 데이터를 중복으로 보관하지 않으며, 보관해서도 안 된다.(무결성의 법칙) 기본적으로 '여러 사용자나 프로그램이 데이터베이스의 데이터를 공유하고 있다'라고 생각하는 것이 중요하다.
칼럼
'프로세스'와 '스레드'란?
프로세스는 실행 중인 상태에 있는 프로그램을 의미한다. 실행 중인 상태이기 떄문에 메모리나 자원을 가지고 있다. 다르게 표현하자면 실체화(materialiation)했다고 할 수 있다. 프로세스를 다르게 비유하자면 프로그램을 따라서 일하는 난쟁이(작은 사람)와 같다. 유닉스(UNIX)상에 프로그램이 여러 개 실행되어 있다고 해도 그것들을 각각 다른 사람(프로세스)이므로 CPU가 여러 개 있다면 동시에 처리할 수 있다.
이에 비해 스레드는 프로세스 내에 존재하는 실행 단위를 말한다. 하나의 프로세스 안에서 병렬로 작업을 처리하고 싶을 떄 사용한다. 어느 쪽이든 병렬로 처리하기 위한 구조이지만, 가장 다른 점은 부하의 크기와 메모리를 공유하는지의 여부이다. 프로세스는 각자 독립적으로 수행되어 자원을 독자적으로 사용하므로 부하가 크고, 메모리를 공유하지 않는다. 스레드는 한 프로세스 안에서 수행되므로 부하가 적지만 스레드끼리 메모리를 공유하므로 주의해서 사용해야 한다.
2.2.2 엑셀과 DBMS의 차이
초급 독자에게는 데이터를 관리한다는 관점에서 보면 엑셀이나 DBMS가 하는 일이 비슷해 보일 수도 있다. 하지만 '여러 사용자가 관리한다'라는 관점에서 엑셀과 DBMS를 비교해보자.
엑셀은 하나의 PC에서 장동하며, 단일 사용자가 사용하는 것이다. 여러 명의 사용자가 동시에 사용할 수 없다. 엑셀 최신 버전에서는 여러 사용자가 동시에 작업하는 기능도 생겼지만, 엑셀 문서 하나를 수천 명, 수만 명이 동시에 작업하는 일은 비현실적이다. 그에 비해 DBMS는 다수의 사용자나 애플리케이션이 데이터를 공유한다는 전제로 만들어져 있어서 많은 사용자가 데이터를 동시에 검색하거나 변경할 수 있다. 또한, 다수의 사용자가 동시에 데이터를 처리하는 경우에는 사용자의 실수로 데이터가 손상되지 않도록 처리하는 Lock이라는 장치를 가지고 있다.
예를 들자면, '이제부터 데이터를 변경할 테니 다른 사람은 데이터를 변경할 수 없게 하겠다'라든지, 'Lock이 걸린 데이터를 조작하려고 하면 Lock이 풀릴 떄까지 기다린다' 와 같은 방식이다.
주문 이력 테이블(DBMS의 Lock)
1. 서울점의 청구 금액을 변경합시다(로우에 Lock을 겁니다)
2. 서울점의 고객명을 변경합시다. 조금 걸리는군요(Lock을 해제할때까지 조금 대기합니다)
3. 서울점외에는 바로 변경할 수 있습니다.
- 데이터의 보호를 위해서 같은 로우의 작업은 조금 대기하지만, 그 이외의 로우는 기다리지 않고 변경 잡업을 수행할 수 있음(※ Lock이 걸려는 있어도 데이터를 변경하지 않으므로 조회할 수도 있음)
주문 이력 파일.xlsx(엑셀의 파일 잠금)
1. 서울점의 청구 금액을 변경합시다(액셀 파일을 잠급니다)
2. 서울점의 고객명을 변경합시다. 조금 걸리는군요(잠금을 해제할 떄까지 조금 대기합니다)
3. 다른 지점도 변경해야 되는데 언제 파일을 쓸 수 있으려나요
- 엑셀은 DBMS와 개념이 다르기 떄문에 여러 명이 작업하면 대기해야 할 수도 있음
2.3 오라클이 여러 개의 프로세스로 구성된 이유
오라클은 어째서 여러 개의 프로세스로 구성되어 있을까? 굳이 여러 개가 아니라 한 개만으로 구성돼도 상관없지 않았을까? 이미 눈치를 채셨겠지만 그 이유중 한 가지는 다중 처리를 위함이다. SQL 처리는 길게는 몆 시간이 이상이 걸리는 경우도 있다. 현재 사용자가 작업을 하는 동안 다른 사용자는 아무 작업도 하지 못하고 마냥 기달릴 수는 없을 것이다. 또한, 1장에서 설명한 바와 같이 디스크는 메모리 액세스에 비해서 속도가 매우 느리다(메모리는 나노초 단위인 것에 비해 디스크는 밀리초 단위). CPU와 같은 자원을 속도가 느린 I/O가 반복되고 있는 동안에 방치하는 것은 매우 아까우므로('자원을 쉬게 하는 것은 매우 아깝다'라는 발상은 PC에는 존재하지 않는 사고방식이다.) 가능하다면 I/O가 반복되는 그 순간에는 다른 SQL 처리를 하는 것이 효율적이다.
여러분은 병렬로 일을 처리하려고 할 때 어떻게 하나요? 아마도 명령어든 프로그램이든 동시에 여러 개를 실행할 것이라 생각한다. 여러 개를 실행한다는 의미는 일반적으로 OS상에서 작업을 처리할 때 여러 개의 프로세스를 사용하는 것을 말한다. 오라클 역시 여러 개의 프로세스를 실행하는 방식으로 병렬 처리를 사용한다.(윈도우는 여러 개의 프로세스가 아니라 멀티스레드로 병렬 처리한다. 이후에 나오는 내용을 윈도우에 적용하고자 한다면 '프로세스'를 '스레드'라고 바꿔서 읽으면 된다.) 단, 오라클은 같은 프로세스가 여러 개 작동하는 것이 아니다. 실은 다른 역활을 가진 여러 가지 프로세스가 존재하고 있다. 리스트 2.2는 오라클이 동작하고있는 유닉스상에서 ps 명령어를 실행한 결과이다.
리스트 2.2 ps 명령어의 결과(발췌)
oracle 5099 1 0 18:03 ? 00:00:00 ora_pmon_ORCL -- 코드 1~8은 백그라운드 프로세스라고 불리는 프로세스들(일부)
oracle 5133 1 0 18:03 ? 00:00:00 ora_dbw0_ORCL
oracle 5135 1 0 18:03 ? 00:00:00 ora_lgwr_ORCL
oracle 5137 1 0 18:03 ? 00:00:00 ora_ckpt_ORCL
oracle 5141 1 0 18:03 ? 00:00:00 ora_smon_ORCL
oracle 5231 1 0 18:03 ? 00:00:00 ora_tt00_ORCL
oracle 5233 1 0 18:03 ? 00:00:00 ora_arc0_ORCL
oracle 5237 1 0 18:03 ? 00:00:00 ora_arc1_ORCL
oracle 7307 7140 0 06:34 pts/2 00:00:00 sqlplus as sysdba -- 코드 9, 12은 SQL*Plus(오라클 클라이언트)가 두개
oracle 7308 7307 0 06:34 ? 00:00:00 oracleORCL -- 코드 10, 13은 SQL문을 실제로 처리하는 서버 프로세스가 두개
(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
oracle 7309 7284 0 06:34 pts/1 00:00:00 sqlplus
oracle 7310 7309 0 06:34 ? 00:00:00 oracleORCL
(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
공유 서버(shared server)라는 구성을 사용하지 않으면 오라클 클라이언트 하나당 서버 프로세스 하나가 대응한다. 현실에서 비유하면 고객 한 명마다 담당자가 배정되는 모습이라 낭비로 보일 수도 있지만, 오라클은 클라이언트에서 SQL문이 전달되지 않으면 CPU를 거의 소비하지 않으므로 메모리 이외의 자원은 거의 사용하지 않는다.
칼럼
자원이 아깝다고 생각하는 것
본문에서 '자원(CPUI)을 쉬게 하는 것은 매우 아깝다'는 사고방식을 설명하였다만, 이런 생각 자체가 전문가가 가지고 있는 중요한 관점 중 하나이다. 애플리케이션을 만들 떄 우리는 원할하게 작동하면서 빠른 응답 속도를 원할 것이다. 하지만 자원(CPU, I/O 그리고 메모리 등의 한정된 자원)의 소비량이 적을수록 좋다는 점을 생각하며 애플리케이션을 만들어야겠지만, 실제로 실천하는 것은 매우 어렵다.
시스템 구축(System Intergration, SI) 프로젝트 등에서 애플리케이션을 만들 떄는 주로 PC에서 코딩하며, 첫 테스트는 보통 PC나 테스트 서버에서 수행한다. 이때 다른 프로그램은 작동하고 있지 않기 떄문에 SQL문의 수행 시간이 3초였고, 그중 CPU를 사용한 시간이 3초를 차지하더라도 문제가 되는 부분은 없다. 애플리케이션을 만든 사람 역시 실행 시간의 대부분이 CPU 시간이었다는 것을 눈치채지 못할 것이다. 하지만 컷 오버(cut-over, 개발 종료 후 신규 시스템 운영 시작) 직후나 성능 테스트 단계에서 복잡한 업무가 다양하게 유입되기 시작하면 성능이 매우 좋지 않은 상황에 직면하게 될 것이다. 아무리 오라클의 프로세스를 늘려 SQL문을 동시에 처리한다고 해도, 그것을 처리할 CPU는 한정되어 있기 떄문이다. 따라서(테스트 단계가 아닌) 운영 현장에서는 자원 부족으로 인한 장애가 자주 일어난다.
일을 할 떄 개인 노트북(PC)을 받아서 업무를 처리한다고 가정하면, 여러 사람이 한 대의 노트북을 번갈아 사용하면서 일을 하지는 않을 것이다. 따라서 노트북을 사용하지 않는 시간이 있더라도 '아깝게 왜 사용을 안 하지?'라는 생각을 하지는 않을 거다. 그래서 초급자의 경우는 함께 사용해야 하는 자원이라는 관점을 놓치고 개발 장비에서 정상적으로 수행되니, 운영 시스템에서도 이상이 없을 것이라 간주하기 쉽다. 그러므로 이 분야에 종사하는 분이라면 전문가답게 스스로의 일을 제대로 해내기 위해서라도 자원을 효율적으로 사용해야 한다는 점을 꼭 기억하자.
2.4 서버 프로세스와 백그라운드 프로세스의 역활
2.4.1 백그라운드 프로세스의 일
오라클은 두 가지 프로세스로 구성되어 있다.
- 서버 프로세스(SQL문을 처리하는 프로세스)
- 백그라운드 프로세스(주로 서버 프로세스를 지원하는 프로세스
백그라운드 프로세스(일부)와 역활
ora_dbwX_XXXXXX --'DBWR(DataBase WRiter)'이라고 부름. 데이터를 디스크에 기록함
ora_lgwr_XXXXXX --'LGWR(LoG WRiter)'이라고 부름. 로그(데이터 변경 이력)를 디스크에 기록함
ora_pmon_XXXXXX --'PMON(Process MONitor)'이라고 부름. 프로세스를 감시하고, 프로세스에 장애(비정상 종료 등)를 발견했을 때 정리하는 역활을 함
ora_arcX_XXXXXX --'ARCH(ARCHiver)'라고 부름. 로그 데이터를 아카이브(장기 보관하기 위해 별도의 파일로 보관)함
-- XXXXXX에는 데이터베이스를 식별하는 SID라는 ID가 들어감
-- X에는 0과 1같은 프로세스의 수를 표현하는 숫자가 들어감
- 오라클 클라이언트(자바, C/C#/VB, SQL*Plus 등)
- 서버 프로세스 : SQL문을 처리함. 바꿔 말하면, 오라클 클라이언트에게 서비스를 직접 제공하는 프로세스
- 백그라운드 프로세스 : 서버 프로세스와는 다르며, 오라클 클라이언트에게 서비스를 직접 제공하지는 않음. 전면에 나서지 않는 지원 스태프에 해당하는 프로세스
고객에 해당하는 오라클 클라이언트와 오라클 클라이언트의 요청(SQL문)을 처리(서비스)하는 서버 프로세스가 존재한다.
오라클 클라이언트는 서버 프로세스와 통신(대화)한다. 따라서 서버 프로세스는 일반적인 회사에서 말하는 '고객 담당'에 해당한다. 그리고 고객 담당을 지원하는 각종 지원 스태프(백그라운드 프로세스)가 창고 업자인 오라클에도 있다.
2.5 각 프로세스가 수행하는 처리
오라클에서 수행하는 주요 처리는 다음과 같다.
1. SQL문의 수신
2. SQL문의 파싱(어떤 테이블에 어떻게 접근해야 하는지 생각하는 작업(일종의 컴파일이라고 생각하자. DBMS는 SQL문을 아무런 처리 없이 그냥 실행하지는 못한다.))
3. 데이터 읽기(디스크에서 읽어온다)
4. 데이터 기록(디스크에 기록한다)
5. SQL문의 결과 회신
6. 로그 기록(데이터의 변경 로그를 디스크에 기록)
7. 각종 정리(프로세스의 비정상 종료로 인한 아무도 사용하지 않는 Lock의 해제 등)
8. 로그 보관(아카이브)
여기서 떠올렸으면 하는 것은 '고객을 최우선으로 생각하는 영업 담당자'의 모습이다. 이 영업 담당자는 고객을 위해 스스로 업무를 수행하며, 고객과 관련이 없는 업무는 일절 수행하지 않는 모습을 보여준다. 어떤 회사든지 이런 영업 담당자가 한명 정도는 있을 것이다.
서버 프로세스는 서비스를 수행하는 프로세스이며, 오라클은 SQL문을 빠르게 처리하려고 한다. 따라서 서버 프로세스는 고객을 최우선으로 생각하는 영업 담당자처럼 업무를 수행한다.
SQL문의 결과를 회신하는 데 필요한 처리
1. SQL문 수신
2. SQL문 분석 : 어떤 테이블의 데이터를 어떻게 처리하면 좋을까?
3. 데이터 읽기
5. 결과 회신
- 공유 서버 구성에서 1과 5는 서버 프로세스와느 별도의 프로세스가 수행한다.
오라클은 SQL문을 수신하지 않으면 작업을 처리하지 않으며, 파싱(parsing)이라고 불리는 절차를 거치지 않으면 어떤 테이블에 접근해야 하는지조차 알 수 없다. 당연히 디스크에서 데이터를 읽어오지 않으면 데이터를 처리할 수 없다. 또한, 겨우 처리하더라도 마지막에 데이터나 결과를 오라클 클라이언트에게 전달하지 않으면 종료할 수 없다. 더욱이 4의 데이터 기록은 SQL문의 결과를 회신하는 것과는 상관없으며, 시간을 의미 없이 사용하기 떄문에 불필요하다고 볼 수 있다 이렇게 SQL문의 결과를 회신하는 데 불필요한 작업은 다른 사람(다른 프로세스)에게 맡겨버리면 된다.
앞에서 설명했던 대로 데이터를 디스크에 기록하는 일은 DBWR(데이터베이스 라이터)이 수행해준다. 고객을 최우선으로 생각하고 업무를 하는 영업 담당자를 대신해서 뒤처리를 해주는 것과 같다. 서버 프로세스가 디스크에서 데이터를 읽어오기는 하지만 기록은 하지 않는 이유가 이런 부분에서 기인한 것이다.
결과를 회신하기 전에 데이터를 디스크에 기록해버리면?
1. SQL문 수신
2. SQL문 분석
3. 데이터 읽기
4. 기록 중 : 오라클 클라이언트에게는 읽어온 데이터를 회신할 수 있지만, 데이터의 기록을 먼저 합시다
- 앞에서 설명했던 것처럼 디스크는 작업을 처리하는 데 시간이 많이 소요된다(1회에 10밀리초나 20밀리초). 따라서 디스크에 데이터를 기록하면, 오라클 클라이언트는 그만큼 기다려야 한다.
SQL의 결과를 회신하는데 필요한 것은 서버 프로세스가 수행하고, 그 이외의 것은 백그라운드 프로세스가 수행한다는 것을 알 수 있다.('원칙적'이라고 쓰여 있듯이 다소의 예외는 있다.)
용어
포어그라운드 프로세스(foreground process)
서버 프로세스를 말한다. 백그라운드와 반대의 의미를 가진 서버 프로세스는 이렇게 불리기도 한다. 단, 이 용어는 현장에서 사용되기보다는 오라클에서 사용하는 도구(툴)들 내에 표시되는 용어로 사용되고 있다.
예전에는 '새도 프로세스;라고도 불리었지만, 최근에는 많이 사용되지 않는다.
2.6 요약
- 데이터베이스는 모두 공유해서 사용한다.
- 애플리케이션이나 SQL*Plus 같은 오라클 클라이언트가 여러 개 존재하고, 여러 개의 SQL문이 오라클에 전달된다.
- 오라클 위에서 여러 개의 SQL문이 동시에 동작하고 있다(PC에서의 엑셀과는 다르다)
- 서버 프로세스는 SQL문의 결과를 가능하면 빠르게 회신하기 위한 일을 한다(고객을 최우선으로 영업한다)
- 서버 프로세스를 도와주는 백그라운드 프로세스가 존재한다(지원 스태프)
오라클 아키텍처를 이해하기 위한 세 가지 키워드중 이번장에는 그중 '병렬 처리를 가능케 하고 높은 처리량을 실현한다.'와 '응답 시간(response time)을 중시한다.'이 두 가지가 포함되어 있다.
Q1. 튜닝할 떄는 어떤 프로세스를 봐야 할까요?
A1. 우선 먼저 살펴보아야 할 것은 실제로 작업을 처리하는 서버 프로세스이다. 백그라운드 프로세스는 서버 프로세스를 방해하지 않는 한 볼 필요는 없다.
Q2. OS에서 확인해보니 서버 프로세스가 디스크에서 대량으로 읽어오는 것이 판명되었습니다. 이것을 '문제가 있다'고 말할 수 있을까요?
A2. 문제가 있다고 말할 수는 없습니다. 서버 프로세스는 디스크에서 데이터를 읽어오는 일을 하므로 읽어온다는 것 자체를 이상이라고 할 수 없습니다. 나머지는 SQL문(의뢰 내용)을 보았을 때 데이터를 대량으로 읽는 것이 타당한지 아닌지 조사해야 할 것입니다.
칼럼
오라클 RAC란?
RAC란 Real Application Clusters의 약자로서, 오라클 클러스트웨어(Clusterware)를 활용한 오라클 데이터베이스의 클러스터 기술을 말한다. 간단하게 말하면 여러 개의 서버상에 가동된 인스턴스를 하나의 데이터베이스처럼 사용할 수 있다. 여러 개의 서버로 구성되어 있지만 데이터의 일관성을 유지하기 위해 스토리지는 함께 사용한다.
일반적으로 여러 대의 인스턴스로 구성한 것을 RAC 구성, 한 개의 인스턴스로 구성한 것을 싱글 구성이라고 부른다.
일반적인 HA(High Availability. 고가용성) 구성과 비교해서 RAC 구성이 가진 특징은 각 서버가 액티브(active)/스탠바이(standby)가 아닌 액티브/액티브 구성이므로 서버의 CPU나 메모리 같은 자원을 100% 활용할 수 있다는 점이다. 즉, 두 대 이상의 저렴한 서버가 비싼 서버 한 대 보다 강력하게 동작한다. 그러므로 사용 가능한 자원이라면 모두 사용하는 것이 이득일것이다.
그리고 장애와 관련된 가용성 역시 향상된다. 한 개의 인스턴스에 장애가 발생하더라도 남은 인스턴스로 작업을 처리할 수 있기 떄문에 지속적인 운영이 가능하다.
또한, RAC를 구성하는 서버를 추가/삭제할 수도 있다. 서버를 추가한다는 것은 CPU와 메모리를 추가하는 것에 상응하며, 당연히 가용성도 향상된다. 아울러 시스템 요건의 변화에 따라 유연하게 대응할 수 있다는 점도 매력적이다.
감이 좋으신 독자분꼐서는 '스토리지를 함께 사용하기 떄문에 변경 정보는 디스크에 기록될 떄까지 다른 서버에서 확인할 수 없는 것이 아닌가?'라고 생각할 수도 있다. 하지만, RAC는 메모리에 캐시되어 있는 블록을 서버 간에 공유하므로 디스크의 I/O를 기다릴 필요없이 데이터의 일관성을 유지할 수 있는 구조를 가지고 있다.
- 인스턴스는 클러스터웨어를 통해 데이터를 항시 연동하고 있음
'DB > Oracle' 카테고리의 다른 글
[Oracle] Oracle Data Pump 와 SQL*Loader (0) | 2022.10.17 |
---|---|
[Oracle] 원격 데이터베이스 Application Architecture (0) | 2022.10.14 |
[Oracle] Chapter 1. I/O와 디스크의 관계 (0) | 2022.10.09 |
[Oracle] Oracle Server 내부로의 여행_Server Architecture (0) | 2022.09.27 |
[Oracle] Oracle 응용 예제(OE) with XML (1) | 2022.09.26 |