성능 Guidelines
디스크를 설치하여 데이터베이스 성능을 향상시킬 수
있습니다.
기본 성능 규칙은 다음과 같습니다:
위의 테이블은 기본 디스크 구성요소와 백그라운드 프로세스의 I/O 처리능력을 나타냅니다.
Guidelines
각 데이터베이스는 다음에 대하여 지정된 테이블스페이스를
보유하고 있어야 합니다:
대부분의 생산 데이터베이스는 이것보다 더 많은 테이블스페이스를 갖고 있지만 중요한 원칙은 정리작업 및
백업 목적을 위해 다른 유형의 데이터를 다른 용도로 분리시켜야 하는 것입니다.
SYSTEM 테이블스페이스에는 SYS가 소유하는 데이터 딕셔너리 객체만 포함되어
있습니다. 다른 어떠한 사용자도 이 테이블스페이스에 객체를 생성할 능력을 가져서는 안됩니다.
패키지와 데이터베이스 트리거와 같은
내장 객체는 데이터 딕셔너리의 일부를 형성한다는
사실을 명심하십시오.
롤백 세그먼트는 롤백 세그먼트 테이블스페이스를 독점으로 사용해야 합니다.
롤백 세그먼트에 관한
장은 롤백 세그먼트 구성 및 튜닝에서 상세하게 다루어질 것입니다.
사용자를 생성할 때, 사용자가 필요로 하는 모든 디스크 정렬
작업에 대해서 임시 테이블스페이스를 할당하십시오. 이들 정렬 영역은 다른 데이터베이스 객체와 분리되어야 합니다. 사용자가 임시 테이블스페이스를
갖고 있지 않다면, 모든 정렬 영역이 SYSTEM 테이블스페이스를 사용합니다. 정렬 튜닝에 관한 장에서는 임시 테이블스페이스의 구성에 관해 보다
상세하게 다루고 있습니다.
테이블과 인덱스는 종종 동시에 삽입되고 읽혀지기 때문에, 별도의 테이블스페이스에서 분리되어야 합니다.
예를 들어, LONG나 LOB 데이터 유형(예를 들어, BLOB와 CLOB)을 포함하는 모든 테이블은 별도의 테이블스페이스에
놓여야 합니다.
Guidelines
일반적으로, 과부화된 디스크에서 활동을 감소시키기
위해서는 과도하게 액세스되는 파일 중 하나 이상을 활동이 많지 않은 디스크로 이동시키십시오.
리두 로그 파일은 LGWR 프로세스에
의해 연속적으로 기록됩니다. 리두 로그 파일을 다른 활동이 전혀 없거나 읽기 및 쓰기 빈도가 낮은 디스크에 놓으십시오. 백그라운드 프로세스 LGWR은 동시 활동이
없을 경우 훨씬 더 빠르게 기록할 수 있습니다.
여러 사용자가 동시에 큰 테이블에 액세스할 경우, 별도의 데이터 파일과 디스크에 스트라이핑하는
것이 경합을 줄이는데 도움이 될 수 있습니다. 이 주제는 다음 섹션에서 논의될 것입니다.
데이터베이스 파일을 포함하는 디스크에서
오라클과 관련없는 I/O는 삭제하도록 하십시오. 이렇게 하는 것이 리두 로그 파일에 최적으로 액세스하는데 도움이 되고, 동적인 성능 뷰
V$FILESTAT를 통해 그러한 디스크 상의 모든 데이터 파일 활동을 감시할 수 있습니다.
운영체제 스트라이핑
현재 사용중인 운영체제가 스트라이핑을 허용할 수도
있습니다. 따라서 연속적인 단일 파일처럼 보이는 것은 실제로 여러 장치에 분산되어 있는 것입니다. 예를 들어, 논리적 볼륨 관리자와 같은
운영체제 스트라이핑 소프트웨어를 사용할 수 있습니다.
오라클 블록 크기와 DB_FILE_MULTIBLOCK_READ_COUNT
초기화 파라미터에 따라 적합한 스트라이프 사이즈를 선택하십시오.
UNIX에서 가장 일반적인 종류의 스트라이핑 파일 시스템은
RAID(Redundant Array of Inexpensive Disks)입니다. 여러 다른 레벨의 RAID 스트라이핑 기능은 여러 등급의
안전성 검사 능력을 내장하고
있습니다.
수동 스트라이핑
여러 파일로
만들어져 각기 별도의 디스크에 놓이도록 테이블스페이스를 생성할 수 있습니다. 그런 다음, 테이블과 인덱스를 생성하여 이 여러 파일에
분산시킵니다.
다음과 같이 스트라이핑 작업을 수행할 수 있습니다.
스트라이핑 사용
운영체제 시스템이 스트라이핑 기능을 제공할 경우, 일반적으로 이
기능을 사용해야 합니다. 스트라이프의 크기에 대해 생각할 필요가 있는데, 스트라이프 크기는 보통
DB_FILE_MULIBLOCK_READ_COUNT에 대해 설정한 값의 배수입니다 (다음 섹션을
보십시오).
DB_FILE_MULIBLOCK_READ_COUNT * DB_BLOCK_SIZE와 비슷한(또는 그 이하의) 스트라이프
넓이로 OS 스트라이프된 데이터베이스
파일로 2개 이상의 디스크에 액세스할 때 각 오라클 읽기에 대해 2회 이상의 물리적 읽기를 할 것입니다.
수동으로 행하는 스트라이핑은 노력 소모적인 작업이라는 사실을 명심하십시오. 오라클은 연속으로 생성한 extent를 채웁니다.
특정 시간에, 하나의 extent는 “매우 활동적”이지만 다른 extent들은 덜 활동적입니다. 현재 병렬 질의를 사용하고 많은 전체 테이블
스캔 작업을 하고 있다면, 수동 스트라이핑이 유용할 것입니다.
다른 많은 튜닝 이슈처럼, 데이터 사용 방법에 대해 잘 알고 있을
때에만 올바른 선택을 할 수 있습니다.
|
“table scans (long tables)”와 “table scans (short
tables)”에 대한 값은 전체 테이블 스캔과 관련이 있습니다. 전체 테이블 스캔 튜닝 |
파일 사용 감시
기존 데이터베이스에서 대부분의 I/O에 종속된 파일을
감시하기 위하여, 다음을 질의할 수 있습니다:
V$FILESTAT 동적인 성능 뷰의 사용
V$FILESTAT를 질의하여 디스크 파일 당 디스크 I/O 수를 찾을 수 있습니다. 디스크 병목현상을 가장 많이 유발시키는
데이터 파일을 찾기 위하여 디스크
당 데이터 파일에 대한 모든 I/O
활동을 요약하십시오.
V$FILESTAT에는 다음 열이 포함되어 있습니다:
|
열 |
설명 |
|
FILE# |
파일 번호 (이름에 대해 V$DATAFILE의 FILE#에 조인) |
|
PHYRDS |
수행된 물리적 읽기 횟수 |
|
PHYWRTS |
수행된 물리적 쓰기 횟수 |
|
PHYBLKRD |
읽혀진 물리적 블록의 수 |
|
PHYBLKWRT |
쓰여진 물리적 불록의 수 |
|
READTIM |
읽기에 소요된 시간 |
|
WRITETIM |
쓰기에 소요된 시간 |
주의: TIMED_STATISTICS 파라미터가 TRUE로 설정되지 않을 경우, 마지막 2개의 열은 0을 포함합니다.
다음 질의를 사용하여 이들 값을 감시하십시오:
SVRMGR> SELECT phyrd, phywrts,
d.name
2 FROM v$datafile d, v$filestat
f
3 WHERE d.file#=f.file# order by d.name;
PHYRDS
PHYWRTS NAME
---------- ----------
--------------------------------------
806 116
/DISK1/sys01.dbf
168 675 /DISK1/temp01.dbf
26
257 /DISK2/rbs01.dbf
8 8
/DISK3/user01.dbf
65012 564
/DISK4/scott_dat.dbf
8 8 /DISK4/scott_ind.dbf
6 rows
selected
주의
OEM 사용:
오라클
진단 팩 -> Performance Manager -> Display -> File I/O -> File I/O
Rate
또는
오라클 진단 팩 -> Performance Manager -> Display -> File I/O
-> File I/O Rate 상세 내역
report.txt의 출력결과를 검사하여 I/O 로드가 디스크 장치에 얼마나 잘 분산되었나 관찰하십시오. 출력결과는 어느 파일이 가장 활동적인가
하는 것을 나타냅니다. 위의 예에서, 테이블스페이스 SCOTT_DATA는 과중하게 액세스되고 있습니다. 읽기의 약 98%가 테이블을 포함하는
데이터 파일에서 수행되고 있습니다.
인덱스 데이터 파일은 이에 대해
수행된 디스크 읽기의 0.01%만 갖고 있습니다.
인덱스의 실패와 원가 기반 옵티마이저의 비효율적인 사용으로 인한
영향을 검사하기 위하여 수행되고 있는 전체 테이블 스캔의 수를 조사해야 합니다.
온라인 리두 로그 파일 구성
온라인 리두 로그 파일은 그룹으로 구성되어 있습니다.
한 그룹에는 하나이상의 멤버가 있어야
합니다. 그룹의 모든 멤버는 동일한 내용을 갖고 있습니다.
하드웨어 레벨에서 모든 파일을 감시하지 않을 경우, 안전을 위해 각
그룹이 2개 이상의 멤버를 갖도록 선택해야 합니다.
LGWR이 거의 계속하여 리두 로그 파일을 기록하기 때문에, 동일한 그룹의 리두
로그 파일들은 여러 빠른 장치에 이상적으로 분산되어 있어야 합니다.
리두 로그 파일의 크기를 적절하게 조정하여, 경합 및 빈번한 로그
교체 발생을 최소화하십시오. report.txt의 ‘redo size(리두 크기) ’를 사용할 수 있습니다.
주의:
Oracle8에서는, 리두 로그 처리능력을 향상시키기 위해 초기화 파라미터 LGWR_IO_SLAVES를 사용하여, LGWR 프로세스에 의해
사용되는 I/O 슬레이브 수를 지정할 수 있습니다.
리두 로그 파일 정보 감시
V$LOGFILE과 V$LOG 동적인 성능 뷰를 질의하여 온라인 리두 로그 파일의 이름, 위치,
크기, 상태에 관한 정보를 입수할 수 있습니다.
V$SYSTEM_EVENT의 "log file parallel write(로그 파일 병렬
쓰기)" 에 대한 모든 대기 상태는 로그 파일과 관련하여 발생 가능한 I/O 문제를 나타냅니다.
오라클은 리두 디스크 I/O를 감시하는
방법을 제공하지 않습니다. 따라서, 운영체제 디스크 감시 명령을 사용해야 합니다.
기록(archive) 로그 파일
구성
로그 파일을 기록하여 보관할 경우, 2개 이상의 리두 로그 그룹을 갖는 것이 훨씬 더 중요합니다.
한 그룹이
채워질 때, DBWR 프로세스는 평소처럼 체크포인트를 수행하는데, 이때 한 파일은 반드시 기록되어야 합니다. LGWR 프로세스가 파일을 다시
겹쳐쓰기를 하기 전에, 이 두 가지 작업에 시간을 허용할 필요가 있습니다.
때때로, 매우 빈번하게 사용되는 데이터베이스에서,
ARCH 프로세스는 리두 로그에 기록되는 정보의 양을 따라갈 수 없습니다.
종종 기록기(archiver)가 뒤쳐질 경우, 여분의
기록기 프로세스를 생성할 수 있습니다.
다음 명령어를 포함하는 스크립트를 규칙적으로 실행시켜 다른 프로세스를 사용하여 작업을 공유할
수 있습니다.
SQL> ALTER SYSTEM
ARCHIVE LOG ALL TO
‘directory_name’;
기록할 필요가 있는 로그가 2개 이상 있을 때마다
경고를 발하여 여분의 기록기 프로세스를 생성할 수 있도록 V$LOG를 감시하십시오.
주의: 또한, 초기화 파라미터
ARCH_IO_SLAVES를 사용하여 리두 로그파일을 기록하기 위해 ARCH 프로세스가 사용하는 여러 I/O 슬레이브를 지정하십시오(다음 섹션을
보십시오).
이것은 ARCH 프로세스에서 I/O 병목현상이 탐지되었을 때에는 일반적으로 조정이 됩니다.
기록 속도 조절
LOG_ARCHIVE_BUFFERS와 LOG_ARCHIVE_BUFFER_SIZE 파라미터를 사용하여 기록 속도를 조절할 수
있습니다. 디폴트 값과 범위는 운영체제에 따라 다릅니다. ARCH 프로세스가 너무 많은 CPU를 소비하지 않도록 버퍼의 수를 감소시키고 크기를
증가시킬 수 있습니다. 또는, 더 빠른 기록 속도를 얻기 위해 이들 단계를 반대로 할 수 있습니다.
아카이브된 로그 파일과 위치에 관한 정보 입수
V$ARCHIVED_LOG 동적인 성능 뷰를 질의하여, 아카이브 로그 이름을 포함하는 제어 파일로부터 아카이브된 로그 정보를 출력할 수
있습니다. 아카이브 로그 레코드는
온라인 리두 로그가 성공적으로 기록되거나 삭제된 후에 삽입됩니다 (로그가 삭제되었다면, 이름 컬럼은 NULL 입니다). 로그가 두 번 기록될
경우, THREAD#, SEQUENCE#, FIRST_CHANGE#는 같지만 이름은 다른 아카이브된 로그 레코드가 2개 있을
것입니다.
동적인 성능 뷰 V$ARCHIVE_DEST는 현재 인스턴스에 대해 모든 아카이브 로그 목적지, 현재 값, 모드,
상태를 설명합니다.
다음 초기화 파라미터를 사용하여 두 번째 아카이브 목적지를 활성화할 수 있습니다.
체크포인트
LGWR 백그라운드 프로세스는 연속하여 순환하는
리두 로그 그룹을 기록합니다.
한 그룹이 채워질 때, 오라클은 체크포인트를 수행하는데, 이것이 의미하는 바는 다음과
같습니다:
체크포인트가 다수의 디스크 쓰기 작업을 생성하지만, 일반적으로 체크포인트는 다른 작업이 동시에 계속될
수 있도록 허용합니다. DBWR 프로세스가 파일을 체크포인트 하는 것을 완료하지 않고 LGWR이 파일을 다시 필요로 한다면, LGWR은 기다려야
합니다.
체크포인트가 빈번하게 수행되면 인스턴스 복구 시간은 더 단축되지만 DBWR(데이터 파일에)과 CKPT(데이터 파일 헤더에)에 의한 쓰기 작업은
더 많아 집니다. 선택은 복구시간 및 실행 시간 성능과 관련된 우선순위에 따라 다릅니다.
체크포인트 빈도 감시
alert.log파일의 로그 교체 횟수를 검사할 수
있습니다.
또한, “체크포인트 미완료: 파일 할당 불능”이라는 오류 메시지에 대한 파일을 검사하십시오. 이들 메시지는 LGWR이
체크포인트가 완료되기를 기다렸다는 것을 의미합니다.
시스템 통계 “background checkpoints started(백그라운드
체크포인트 시작)”과 “background checkpoints completed(백그라운드 체크포인트 완료)”가 1이상 차이가 나는 값을 갖고
있다면, 체크포인트는 로그 교체간에 완료하지 않는 것입니다. 이때는 더 큰 로그 파일이
필요합니다.
LOG_CHECKPOINTS_TO_ALERT 파라미터를 설정할 수 있기 때문에, 체크포인트의 시작과 종료는
alert.log 파일에 기록됩니다.
report.txt의 ‘DBWR checkpoint write requests(체크포인트
쓰기 요청)’ 통계는 체크포인트가 DBWR에 보내진 회수를 나타냅니다.
트랜잭션 당 체크포인트 수가 높다는 것은 너무 많은 체크포인트가
발생하고 있다는 것을 의미합니다.
체크포인트 조절
DBWR는 항상
각 리두 로그 그룹의 마지막에 체크포인트를 수행합니다. 또한, 두개의 초기화 파라미터로 체크포인트를 설정할 수 있습니다.
효율적인
성능이 우선순위일 경우,
체크포인트가 종종(너무 자주는 아니고) 응답시간의 속도를 눈에 띄게 늦추지 않도록 적절한 리두 로그 파일 크기를 선택하십시오
많은
사이트에서, 이 빈도는 대략 30분 마다 발생하지만, 데이터베이스의 체크포인트 빈도는 비즈니스 필요에 따라 2초와 8시간 사이의 어떠한 값이라도
될 수 있습니다.
여러 다른 체크포인트 빈도를 시도할 수 있습니다. 예를 들어, OLTP 시스템은 SGA가 매우 크고 체크포인트가
드물게 발생하면 체크포인트 동안 디스크 경합을 겪게 될 것입니다. 이러한 경우에, 체크포인트가 빈번할수록 더티 블록을 더 적게
만듭니다.
LOG_CHECKPOINT_INTERVAL 파라미터
이 파라미터는 각 체크포인트 간의 운영체제 블록의 수를 설정합니다.
만일 로그 스위치시에만 체크포인트를
발생시키려면 LOG_CHECKPOINT_INTERVAL이 리두 로그 파일의 크기보다 더 큰 운영시스템 블록수로 설정되어야
합니다.
마지막 요청이 있은 이후 단일 리두 로그 버퍼가 기록되었을 경우에도 새로운 요청이 시작될 것이기 때문에, 간격으로 0 값을
지정할 경우 체크포인트가 매우 빈번하게 발생하게 될 것이라는 사실을 주의하십시오.
LOG_CHECKPOINT_TIMEOUT 파라미터
이 파라미터는
각 체크포인트 간의 초 수를 설정합니다. 디폴트 값은 0인데, 이것은 아무런 영향이 없다는 것을 의미합니다.
체크포인트의 성능
영향 감소
DBWR이 체크포인트의 성능 영향을 감소시키기에 충분한 블록을 기록하는지 확인하십시오.
DB_BLOCK_CHECKPOINT_BATCH 파라미터는 데이터베이스 작성기가 체크포인트 전용인 한 배치에 기록할 최대 블록 수를
지정합니다. 쓰기 배치 크기와 비교하여,
DB_BLOCK_CHECKPOINT_BATCH를 작은 값으로 설정하면, I/O 시스템에
체크포인트 쓰기가 밀려 들어오는 것을 막고 다른 수정된 블록이 디스크에 기록되도록 할 수 있습니다. 이 파라미터를 더 높은 값으로 설정하면,
체크포인트는 더 빨리 완료됩니다.
일반적으로 DB_BLOCK_CHECKPOINT_BATCH는 다음 체크포인트 로그 교체가 발생하기
전에 체크포인트가 완료되도록 하는 값으로 설정되어야 합니다. 체크포인트 로그 교체가 매 20분마다 발생하면, 이 파라미터는 체크포인트가 20분
이내에 완료되도록 하는 값으로 설정되어야 합니다.
DB_BLOCK_CHECKPOINT_BATCH를 0으로 설정하면, 디폴트
값이 사용됩니다.
|
I/O 슬레이브 메커니즘 |
초기화 파라미터 DBWR_IO_SLAVES, LGWR_IO_SLAVES, ARCH_IO_SLAVES, BACKUP_DISK_IO_SLAVES,
BACKUP_TAPE_IO_SLAVES는 I/O 슬레이브 전개를 제어합니다.
DISK_ASYNCH_IO와 TAPE_ASYNCH_IO
파라미터를 사용하여 비동기 I/O의
사용을 활성화 또는 비활성화할 수 있습니다. 운영체제에 의해 제공되는 비동기 I/O 기능은 비활성화시킬 필요가 있을 것입니다. 예를 들어, 플랫폼의 비동기 I/O 코드가 버그가 있고
효율적이지 못할 경우, 비동기
I/O는 “장치 유형 당” 비활성화로 할 수 있습니다.
보통, 파라미터의 디폴트 값은 TRUE이어야 합니다.
복수 DBWRR 메커니즘
테이블스페이스 사용
확장 영역 할당 시에는 영역 관리 작업을 위해 딕셔너리에 액세스해야 하기 때문에, 요청이 많은 OLTP(온라인 트랜잭션 프로세싱) 유형의 응용 프로그램에는 동시성 문 제가 존재합니다. 지역적으로 관리되는 테이블스페이스의 경우에는 딕셔너리 간섭 이 없으며 따라서 동시성 문제가 적습니다.
지역적으로 관리되는 테이블스페이스에서 생성된 테이블은 수천 개의 확장 영역을 가질 수 있지만 성능과는 관련되지 않으므로 테이블을 재구성할 필요가 없습니다.
지역적으로 관리되는 테이블스페이스에서는 비트맵이 사용 가능 영역을 추적하여 이를 효과적으로 할당하기 때문에 벌집형 단편화를 제거하기 위해 사용 가능 영역 을 병합할 필요가 없습니다.
동적 확장의 단점 회피
연속적으로 확장하는 객체에 대해 지역적으로 관리되는 테이블스페이스를 생성합 니다.
지역적으로 관리되는 테이블스페이스는 고유의 확장 영역을 관리하고 각 데이터 파 일의 비트맵을 유지 관리하여 데이터 파일에서 사용 가능한 블록 상태 또는 사용한 블록 상태를 추적합니다. 비트맵의 각 비트는 블록 또는 블록 그룹에 해당합니다. 확 장 영역이 할당되었거나 재사용을 위해 비워진 경우 Oracle 서버는 비트맵 값을 변경 하여 새로운 블록 상태를 표시합니다. 이런 변경은 데이터 딕셔너리의 테이블을 갱 신하지 않기 때문에 롤백 정보가 생성되지 않습니다
전체 테이블 스캔 작업 모니터
사용자 및 DBA는 몇 가지 방법을 사용하여 전체 테이블 스캔의 진행을 모니터하고 예상 완료 시간에 대한 정보를 얻을 수 있습니다. 이런 방법을 제공하기 위해 Oracle 서버는 작업의 진행을 추적하는 통계를 유지 관리하며 사용자가 동적 성능 뷰 V$SESSION_LONGOPS를 통하여 이 통계를 사용할 수 있도록 합니다.
참고: DBMS_APPLICATION_INFO 패키지에는 응용 프로그램의 해당 뷰를 채우는 SET_SESSION_LONGOPS 프로시저가 포함됩니다.
SQL> SELECT sid, serial#, opname,
2 TO_CHAR(start_time,'HH24:MI:SS')AS START,
3 (sofar/totalwork)*100 AS PERCENT_COMPLETE
4 FROM v$session_longops;
SID SERIAL# OPNAME START PERCENT_COMPLETE
--- -------- ------------ ---------- ----------------
8 219 TABLE SCAN 13:00:09 48.98098
아카이브 속도 규정
가끔 사용량이 많은 데이터베이스에서 단일 ARC0 프로세스로는 리두 로그에 기 록된 정보량을 따라 잡을 수 없는 경우가 발생할 수 있습니다. Oracle8i 에서는 데 이터베이스 관리자가 LOG_ARCHIVE_MAX_PROCESSES 매개변수를 사용하여 복수 아카이브 프로세스를 정의할 수 있습니다.
LGWR 프로세스는 현재 ARCn 프로세스의 수가 작업 로드를 처리하기에 충분하 지 않으면 새로운 ARCn 프로세스를 시작합니다. 아카이브에 많은 작업 로드가 소요될 것으로 예상되는 경우 다음 명령을 실행해 수동으로 서버 프로세스를 시작하여 작업을 공유할 수 있습니다.
SQL> ALTER SYSTEM ARCHIVE LOG ALL TO 'directory_name' ;
두 개 이상의 로그를 아카이브해야 할 때마다 경고하고 추가 아카이버 프로세스 를 생성하기 위해 V$ARCHIVE_PROCESSES를 모니터합니다.
SQL> select * from v$archive_processes;
PROCESS STATUS LOG_SEQUENCE STAT
--------- ---------- ------------ ----
0 ACTIVE 122 BUSY
1 ACTIVE 0 IDLE
2 STOPPED 0 IDLE
참고
초기화 매개변수 DBWR_IO_SLAVES가 0보다 큰 값으로 설정되어 있으면 리두 로그 파일 아카이브를 위해 ARC0 프로세스가 사용하는 I/O 슬래이브 수는 4로 자동 설정됩니다.
아카이브 리두 로그 파일은 원시 장치에서 생성할 수 없습니다.
LOG_ARCHIVE_MAX_PROCESSES, LOG_ARCHIVE_DEST_n, 및 LOG_ARCHIVE_DEST_STATE_n 매개변수에 대한 자세한 설명은 Oracle8i 백업 및 복구 과정의 2단원을 참조하십시오.
Oracle Enterprise Edition을 설치한 경우에만 LOG_ARCHIVE_DEST_n 매개변수 를 사용할 수 있습니다. Oracle Enterprise Edition을 설치한 경우 LOG_ARCHIVE_DEST는 계속 사용할 수 있으나 LOG_ARCHIVE_DEST_n과 LOG_ARCHIVE_DEST는 호환성이 없으므로 함께 사용할 수 없습니다.
체크포인트 지침
DBWn는 언제나 각 리두 로그 그룹의 끝에서 체크포인트를 수행해야 합니다. 또한 초기화 매개변수를 사용하여 체크포인트를 설정할 수 있습니다.
참고: 체크포인트와 Fast-start 체크포인트 그리고 이와 관련된 매개변수에 대한 자세 한 설명은 Oracle8i 백업 및 복구 과정의 2단원을 참조하십시오.
사용자의 우선 순위가 성능의 효율성에 있다면 응답 속도 저하가 눈에 띄지 않을 정도로만 체크포인트가 발생하도록 리두 로그 파일의 크기를 선택하십시오.
많은 사이트에 있어서 이런 빈도는 대개 매 30분이지만 업무상 필요에 따라 데이터 베이스에 2초에서 8시간 사이의 시간을 지정하여 체크포인트 빈도로 사용할 수 있습 니다.
다양한 체크포인트 빈도를 사용하여 실험해 볼 수 있습니다. 예를 들어, SGA가 매우 크거나 체크포인트가 드문 경우 OLTP 시스템에서 체크포인트 시 디스크 경합이 발 생할 수 있습니다. 이런 경우, 체크포인트의 빈도를 더 높이면 더티 블록의 수가 그만 큼 더 적어집니다.
DBWn I/O 튜닝 지침
이 매개변수가 지나치게 높게 설정되어 있는 경우 DBWn 프로세스는 충분한 빈도로 더티 버퍼를 쓰지 않을 수가 있으며 이로 인해 세션이 사용 가능한 버퍼를 대기해야 하는 경우가 발생할 수 있습니다.
매개변수 DB_BLOCK_MAX_DIRTY_TARGET 값이 지나치게 높으면 DBWn 프로세 스는 추가 메모리를 사용하며 이 추가 메모리는 마스터 프로세스에 할당됩니다. 또 한, 이 값이 모든 요청을 처리하는 운영 체제 용량을 초과할 때 이러한 요청이 디스크 를 사용할 수 있을 때까지 대기열에 놓여지므로 읽기 및 쓰기 작업이 지연될 수 있습 니다.
이 매개변수를 설정할 때에는 DBWn와 관련된 데이터베이스 통계(예: V$SYSTEM_EVENT의 대기 이벤트 WRITE COMPLETE WAITS)를 분석해서 DB_BLOCK_MAX_DIRTY_TARGET 값을 줄여 유익을 얻을 수 있는지 판단해야 합니다.
미리 정의한 더티 버퍼 수 상한값 및 하한값
더티 버퍼의 하한값은 min(max(DB_BLOCK_MAX_DIRTY_TARGET,100), buffers)로 설정됩니다.
더티 버퍼의 상한값은 min((low limit*12)/10, buffers)로 설정됩니다.
|
문맥 |
참조 |
|
초기화 파라미터 |
DB_WRITER_PROCESSES
|
|
동적인 초기화 파라미터 |
DB_FILE_MULTIBLOCK_READ_COUNT |
|
동적인 성능 뷰 |
V$FILESTAT |
|
데이터 딕셔너리 뷰 |
None |
|
명령어 |
ALTER TABLE ALLOCATE EXTENT |
|
패키지된 프로시저 및 함수 |
None |
|
스크립트 |
None |
|
진단 팩 애플리케이션 |
Performance Manage |