Oracle Parellel Server (OPS)
1. 가용성 : 병원System 같이 절대적 가용성이 보장되야 하는 경우
2. 성능향상 : Data 및 업무상 Ownership의 분산이 되는 경우 유리함. 시스템간의 Lock 최소화. 시스템 자체를 OPS용으로 설계
3. 비용절감 : 기존 Server가 한계에 도달한 경우 더 큰 Server로의 교체가 아닌 비슷한 시스템을 추가하는 것으로 해결이 가능
System Global Area (SGA ; 공유 메모리 캐쉬)
Shared SQL Pool : 같은 SQL문에 대해서 SQL Parsing 과 Execution Plan을 만드는 과정을 제거
D/B Buffer Cache : Physical Disk I/O를 줄임
경합없는 조회
User 1이 UPDATE 문을 수행 중일 때 User 2가 같은 부분에 대해서 SELECT 했을 경우 값을 읽어올수 있다. 단, 이 데이터는 UPDATE하기 이전의 Data이다. 어떻게 이게 가능한 것일까 ? Oracle의 경우 Rollback Segment에 과거값을 저장해 놓는다. 그리고 Commit이 일어나기 전에는 그곳에서 값을 읽어온다. 이것을 Oracle Snapshot 이라고 한다. 가끔씩 Snapshot too old 라는 메세지를 볼 수가 있다. 이것은 Rollback Segment에서 값을 읽고 있을 때 Commit이 일어나서 RBS_TS에 해당 Data가 지워질 경우 나타난다. Snapshot too old 를 안일어나게는 할 수가 없다. 하지만 최소한으로 일어나게 할려면 Commit을 너무 자주하지 말고 작업을 다해놓고 한번에 Commit을 하면 줄일수는 있다.
Row-Level Locking
Oracle의 경우 Locking을 행단위로 가능하다. 그래서 같은 행을 같이 쓰지 않는 이상 Locking이 발생하지 않는다. Oracle의 Row-Level Locking은 아무리 많이 일으켜도 성능의 저하가 거의 없다. OS의 Lock을 사용하지 않는다고 한다. 반면 인포믹스는 Row-Level Lock을 하다가 너무 많은 경합이 일어나면 Page, Table 단위 Locking으로 올린다. 이 과정에서 동시에 2개의 Lock이 하나의 Lock으로 합쳐지면서 Deadlock도 빈번히 일어난다고 한다. Sybase 와 MS-SQL은 Page-Level Locking을 사용한다.
DBA의 중요한 역할중 하나는 Table의 Extent를 관리해야 한다. 1개의 Table이 물리적인 공간에 여러개의 쪼가리로 나눠져 있으면 그만큼 성능상에는 치명적이다. 그러므로 Table 생성시 Storage Parameter들의 설정은 무척 중요하다. Extent를 너무 크게 하면 사용하지 못하는 빈공간이 많아지고, 너무 작게하면 여러개의 쪼가리로 Table Data들이 저장되므로 성능이 안좋아진다.
CREATE TABLE TBL ...
TABLESPACE AA
INITIAL 100M NEXT 100M;
for update 경합의 해소
select for update 는 update를 항 목적으로 Lock을 걸어놓고 읽어오는 과정이다.
이 경우 잘못처리하면 오로지 하나의 Row만을 상대로 경합을 벌려서 정상적으로 동작하지 않을 수 있다.
이 경우 Cache에 Sequence를 하나 만들어서 해결이 가능하다.
1. 가용성 : 병원System 같이 절대적 가용성이 보장되야 하는 경우
2. 성능향상 : Data 및 업무상 Ownership의 분산이 되는 경우 유리함. 시스템간의 Lock 최소화. 시스템 자체를 OPS용으로 설계
3. 비용절감 : 기존 Server가 한계에 도달한 경우 더 큰 Server로의 교체가 아닌 비슷한 시스템을 추가하는 것으로 해결이 가능
System Global Area (SGA ; 공유 메모리 캐쉬)
Shared SQL Pool : 같은 SQL문에 대해서 SQL Parsing 과 Execution Plan을 만드는 과정을 제거
D/B Buffer Cache : Physical Disk I/O를 줄임
경합없는 조회
User 1이 UPDATE 문을 수행 중일 때 User 2가 같은 부분에 대해서 SELECT 했을 경우 값을 읽어올수 있다. 단, 이 데이터는 UPDATE하기 이전의 Data이다. 어떻게 이게 가능한 것일까 ? Oracle의 경우 Rollback Segment에 과거값을 저장해 놓는다. 그리고 Commit이 일어나기 전에는 그곳에서 값을 읽어온다. 이것을 Oracle Snapshot 이라고 한다. 가끔씩 Snapshot too old 라는 메세지를 볼 수가 있다. 이것은 Rollback Segment에서 값을 읽고 있을 때 Commit이 일어나서 RBS_TS에 해당 Data가 지워질 경우 나타난다. Snapshot too old 를 안일어나게는 할 수가 없다. 하지만 최소한으로 일어나게 할려면 Commit을 너무 자주하지 말고 작업을 다해놓고 한번에 Commit을 하면 줄일수는 있다.
Row-Level Locking
Oracle의 경우 Locking을 행단위로 가능하다. 그래서 같은 행을 같이 쓰지 않는 이상 Locking이 발생하지 않는다. Oracle의 Row-Level Locking은 아무리 많이 일으켜도 성능의 저하가 거의 없다. OS의 Lock을 사용하지 않는다고 한다. 반면 인포믹스는 Row-Level Lock을 하다가 너무 많은 경합이 일어나면 Page, Table 단위 Locking으로 올린다. 이 과정에서 동시에 2개의 Lock이 하나의 Lock으로 합쳐지면서 Deadlock도 빈번히 일어난다고 한다. Sybase 와 MS-SQL은 Page-Level Locking을 사용한다.
DBA의 중요한 역할중 하나는 Table의 Extent를 관리해야 한다. 1개의 Table이 물리적인 공간에 여러개의 쪼가리로 나눠져 있으면 그만큼 성능상에는 치명적이다. 그러므로 Table 생성시 Storage Parameter들의 설정은 무척 중요하다. Extent를 너무 크게 하면 사용하지 못하는 빈공간이 많아지고, 너무 작게하면 여러개의 쪼가리로 Table Data들이 저장되므로 성능이 안좋아진다.
CREATE TABLE TBL ...
TABLESPACE AA
INITIAL 100M NEXT 100M;
for update 경합의 해소
select for update 는 update를 항 목적으로 Lock을 걸어놓고 읽어오는 과정이다.
이 경우 잘못처리하면 오로지 하나의 Row만을 상대로 경합을 벌려서 정상적으로 동작하지 않을 수 있다.
이 경우 Cache에 Sequence를 하나 만들어서 해결이 가능하다.
댓글 없음:
댓글 쓰기