목차
1. 오라클 데이타베이스 구조
2. Oracle8i 새로운 기능 요약
3. 파티션된 테이블과 인덱스
4. Disk Contention의 줄이기
5. QUERY PERFORMANCE
2. Oracle8i 새로운 기능 요약
3. 파티션된 테이블과 인덱스
4. Disk Contention의 줄이기
5. QUERY PERFORMANCE
본문내용
s Guide를 참고하라.
2. object 생성시 모든 data에 충분한 크기의 extents를 제공하기 위한 storage parameter 값을 선택한다.
보다 큰 extent는 다음과 같은 이유에서 성능에 도움이 된다.
- 하나의 extent에 있는 block들은 인접(연속)해 있기 때문에 하나의 큰 extent는 여러개의 작은 extent들 보다 더 연속성을 가진다. Oracle은 여러개의 작은 extent를 읽어들이는데 필요한 것보다 큰 extent를 multi-block read로 읽어 들이는 것이 적게 걸린다.
- 큰 extent들을 가지는 segment들은 쉽게 확장되지 않는다.
그러나 하나의 큰 extent는 많은 연속된 block을 필요로 한다. Oracle은 이런 충분한 연속 공간을 찾는데 어려움이 있을 수 있다. 큰 extent를 적게 사용할 것인지, 작은 extent를 많이 사용할 것인지를 결정하기 위해서는 table들의 성장과 사용에 대한 계획에 따라 각각의 잇점과 결점을 고려해야 한다.
자동으로 datafile의 크기를 바꾸는 것 역시 dynamic extension을 야기시킨다. automatic extension의 사용을 피하기 위해선, 비교적 비활동적인 시간 동안에 datafile에 더 많은 공간을 수동적으로 할당해야 한다.
♣ Avoiding Dynamic Space Management in Rollback Segments
▶ Rollback segment의 크기는 성능에 영향을 미칠 수 있다. rollback segment의 크기는 rollback segment의 storage 매개변수 값들에 의해 알 수 있다. rollback segment들은 그 transaction에 필요한 rollback entry들을 저장할 만큼 충분히 커야한다. 다른 object와 마찬가지로 rollback segment에서의 dynamic space management도 피할 수 있다.
다음 절에 추천된 것들을 기반으로 적당한 크기의 rollback segment를 트랜잭션에 배정하기 위해 SET TRANSACTION 문장을 이용한다. 만약 사용자가 트랜잭션에 rollback segment를 배정하지 않으면 Oracle이 random하게 rollback segment를 선택한다.
Warning : 만약 같은 응용 프로그램의 복사본이 여러개 수행 중이라면, 모든 복사본의 트랜잭션들에게 같은 rollback segment를 배정하지 않도록 주의해야 한다. 이것은 rollback segment의 contention을 유도한다.
예제 : 다음 문장은 현 트랜잭션에 OLTP_13이라는 rollback segment를 배정하는 문장이다.
SET TRANSACTION USE ROLLBACK SEGMENT oltp_13
▶ For Long Queries
긴 query에 의해 동시에 select되는 데이타를 수정하는 트랜잭션에는 큰 rollback segment를 배정한다. 이런 query는 수정된 데이타의 read-consistent version을 재구성하기 위해 rollback segment를 액세스할 필요가 있다. 이런 rollback segment들은 query가 실행되는 동안 그 data에 대한 모든 rollback entry들을 가지고 있을 만큼 커야한다.
▶ For Long Transactions
많은 양의 데이타를 수정하는 트랜잭션에는 큰 rollback segment를 배정해야 한다. 큰 rollback segment는 이런 트랜잭션에 있어서 성능을 향상시킨다. 이런 트랜잭션은 큰 rollback entry를 생성한다. 만약 rollback entry가 rollback segment에 맞지 않는다면 Oracle은 이 segment를 확장시킨다. Dynamic extension은 성능을 저하시키기 때문에 될 수 있으면 피하는 것이 좋다.
▶ For OLTP Transactions
어떤 응용 프로그램은 online transaction processing을 수행한다. 이 OLTP 응용 프로그램은 각 트랜잭션들에서 적은 양의 데이타를 수정하는 것이 자주, 동시에 발생하는 것이 특징이다. 그들의 데이타가 동시에 query되지 않는다면 OLTP 트랜잭션에는 작은 크기의 rollback segment를 배정한다. 작은 rollback segment들은 재빨리 액세스될 수 있는 buffer cache에 저장되기 쉽다. 보통 OLTP rollback segment는 2개의 extents를 가진다. 이들 extent들은 각 10Kbyte에 가까운 크기를 가진다. contention을 피하기 위한 최상의 방법은 많은 rollback segment를 만들어 각 transaction에 하나씩 배정하는 것이다.
5. QUERY PERFORMANCE
☞ FULL TABLE SCAN을 보다 빠르게 하는 방법
db_file_multiblock_read_count 는 Full Table Scan 시에만 영향을 미치는 파라미터이다. 오라클의 최대 I/O 크기는 64KB 이므로 db_block_size*db_file_multiblock_read_count <= 64KB 이어야 한다. Index를 이용한 Query 인 경우에는 Full Table Scan 과는 상황이 달라진다. 이 때에는 db_block_
size의 설정이 중요하다. 오라클은 원하는 블럭 크기를 선택할 수 있으며 대부분의 유닉스 환경에서 최대 8KB(시퀀트는 16KB)까지 가능하다. 같은 크기의 B-tree Index 에서 블럭크기가 8KB 라면 2KB 인 경우 보다 거의 4배 빨리 데이타를 읽어들이게 된다.
한편 Index Block 의 Pctfree도 중요한 의미를 갖는데 이 값이 너무 크고 인덱스의 Entry Size 가 늘어나지 않으며 기존의 인덱스 값에 새로운 레코드가 더 이상 추가되지 않는다면 공간의 낭비가 심하게 되므로 적절한 값으로 설정해야 한다.
db_file_simultaneous_writes 파라미터는 인덱스의 재구성시 퍼포먼스에 별로 영향을 끼치지 않는다.
2. object 생성시 모든 data에 충분한 크기의 extents를 제공하기 위한 storage parameter 값을 선택한다.
보다 큰 extent는 다음과 같은 이유에서 성능에 도움이 된다.
- 하나의 extent에 있는 block들은 인접(연속)해 있기 때문에 하나의 큰 extent는 여러개의 작은 extent들 보다 더 연속성을 가진다. Oracle은 여러개의 작은 extent를 읽어들이는데 필요한 것보다 큰 extent를 multi-block read로 읽어 들이는 것이 적게 걸린다.
- 큰 extent들을 가지는 segment들은 쉽게 확장되지 않는다.
그러나 하나의 큰 extent는 많은 연속된 block을 필요로 한다. Oracle은 이런 충분한 연속 공간을 찾는데 어려움이 있을 수 있다. 큰 extent를 적게 사용할 것인지, 작은 extent를 많이 사용할 것인지를 결정하기 위해서는 table들의 성장과 사용에 대한 계획에 따라 각각의 잇점과 결점을 고려해야 한다.
자동으로 datafile의 크기를 바꾸는 것 역시 dynamic extension을 야기시킨다. automatic extension의 사용을 피하기 위해선, 비교적 비활동적인 시간 동안에 datafile에 더 많은 공간을 수동적으로 할당해야 한다.
♣ Avoiding Dynamic Space Management in Rollback Segments
▶ Rollback segment의 크기는 성능에 영향을 미칠 수 있다. rollback segment의 크기는 rollback segment의 storage 매개변수 값들에 의해 알 수 있다. rollback segment들은 그 transaction에 필요한 rollback entry들을 저장할 만큼 충분히 커야한다. 다른 object와 마찬가지로 rollback segment에서의 dynamic space management도 피할 수 있다.
다음 절에 추천된 것들을 기반으로 적당한 크기의 rollback segment를 트랜잭션에 배정하기 위해 SET TRANSACTION 문장을 이용한다. 만약 사용자가 트랜잭션에 rollback segment를 배정하지 않으면 Oracle이 random하게 rollback segment를 선택한다.
Warning : 만약 같은 응용 프로그램의 복사본이 여러개 수행 중이라면, 모든 복사본의 트랜잭션들에게 같은 rollback segment를 배정하지 않도록 주의해야 한다. 이것은 rollback segment의 contention을 유도한다.
예제 : 다음 문장은 현 트랜잭션에 OLTP_13이라는 rollback segment를 배정하는 문장이다.
SET TRANSACTION USE ROLLBACK SEGMENT oltp_13
▶ For Long Queries
긴 query에 의해 동시에 select되는 데이타를 수정하는 트랜잭션에는 큰 rollback segment를 배정한다. 이런 query는 수정된 데이타의 read-consistent version을 재구성하기 위해 rollback segment를 액세스할 필요가 있다. 이런 rollback segment들은 query가 실행되는 동안 그 data에 대한 모든 rollback entry들을 가지고 있을 만큼 커야한다.
▶ For Long Transactions
많은 양의 데이타를 수정하는 트랜잭션에는 큰 rollback segment를 배정해야 한다. 큰 rollback segment는 이런 트랜잭션에 있어서 성능을 향상시킨다. 이런 트랜잭션은 큰 rollback entry를 생성한다. 만약 rollback entry가 rollback segment에 맞지 않는다면 Oracle은 이 segment를 확장시킨다. Dynamic extension은 성능을 저하시키기 때문에 될 수 있으면 피하는 것이 좋다.
▶ For OLTP Transactions
어떤 응용 프로그램은 online transaction processing을 수행한다. 이 OLTP 응용 프로그램은 각 트랜잭션들에서 적은 양의 데이타를 수정하는 것이 자주, 동시에 발생하는 것이 특징이다. 그들의 데이타가 동시에 query되지 않는다면 OLTP 트랜잭션에는 작은 크기의 rollback segment를 배정한다. 작은 rollback segment들은 재빨리 액세스될 수 있는 buffer cache에 저장되기 쉽다. 보통 OLTP rollback segment는 2개의 extents를 가진다. 이들 extent들은 각 10Kbyte에 가까운 크기를 가진다. contention을 피하기 위한 최상의 방법은 많은 rollback segment를 만들어 각 transaction에 하나씩 배정하는 것이다.
5. QUERY PERFORMANCE
☞ FULL TABLE SCAN을 보다 빠르게 하는 방법
db_file_multiblock_read_count 는 Full Table Scan 시에만 영향을 미치는 파라미터이다. 오라클의 최대 I/O 크기는 64KB 이므로 db_block_size*db_file_multiblock_read_count <= 64KB 이어야 한다. Index를 이용한 Query 인 경우에는 Full Table Scan 과는 상황이 달라진다. 이 때에는 db_block_
size의 설정이 중요하다. 오라클은 원하는 블럭 크기를 선택할 수 있으며 대부분의 유닉스 환경에서 최대 8KB(시퀀트는 16KB)까지 가능하다. 같은 크기의 B-tree Index 에서 블럭크기가 8KB 라면 2KB 인 경우 보다 거의 4배 빨리 데이타를 읽어들이게 된다.
한편 Index Block 의 Pctfree도 중요한 의미를 갖는데 이 값이 너무 크고 인덱스의 Entry Size 가 늘어나지 않으며 기존의 인덱스 값에 새로운 레코드가 더 이상 추가되지 않는다면 공간의 낭비가 심하게 되므로 적절한 값으로 설정해야 한다.
db_file_simultaneous_writes 파라미터는 인덱스의 재구성시 퍼포먼스에 별로 영향을 끼치지 않는다.
추천자료
DBMS/DB MARKETING - 데이터베이스 마케팅의 이해와 적용사례에 대한 보고서
용어해설(구조해석)
에미터-베이스 접합구조와 온도변화에 따른 HBT의 DC및 AC 특성
자료구조
데이터베이스 시스템 개념과 아키텍처
자료구조의 개념 및 표현
인터넷광고와 데이터베이스 마케팅
STR-Tree : 계층 공간 분할을 이용한 다차원 정적 데이터 색인
[클리퍼][프로그래밍언어][프로그램언어][프로그래밍]프로그래밍언어(프로그램언어)의 발전 ...
[데이터통신][패킷교환]데이터통신(데이터커뮤니케이션)의 정의, 데이터통신(데이터커뮤니케...
데이터베이스 내 데이터 환경
데이터 베이스의 정의와 데이터 베이스 활용의 장단점
데이터베이스
[공공데이터] 공공데이터의 유형, 활용사례 및 활성화 방안 분석