Dynix/PTX 용 DB2 EEE

STSS 팀 박 준 호

목 차

1. NUMA 의 개요

2. Dynix/PTX 의 특성

3. Dynix/PTX 용 DB2 EEE

4. Dynix/PTX 용 DB2 EEE 성능 조정

1. NUMA 의 개요

1-1. NUMA 의 필요성 :

데이터 웨어하우징(Data Warehousing)은 기업의 비즈니스 인텔리젼스를 위한 중요한 기능을

제공한다. 이러한 비즈니스 주요 정보에 대한 필요성은 보다 더 방대한 데이터베이스를 취급할 수

있는 기술을 필요로 한다.

현재 H/W 영역에서 주로 사용되는 기술은 SMP(Symmetric Multi-Processing)이지만, 보다 방대한

데이터베이스에 대한 취급을 위해 MPP(Massively Parallel Processing)를 요구한다. NUMA(Non

Uniform Memory Access) 기술을 채택하고 있는 IBM Numa-Q 플랫폼은 SMP 와 MPP 의 장점을

취하고 단점을 제거하고자 하였다. 즉, 이러한 SMP 의 소프트웨어적 장점으로는 소프트웨어를

간단히 이식할 수 있고, 대규모 응용 프로그램에 적당하다는 점을 들 수 있다. MPP 의 장점으로는

개발 비용이 저렴하다는 것이다. 또한 MPP 의 단점으로는 공유된 시스템 버스에 따라 프로세서

수가 제한되고, 노드간 통신에 따른 대기 시간을 감수해야 하며 MPP 노드간의 트래픽을 관리해야

하는 관리상의 불편을 들 수 있다. 이로써 NUMA 는 적은 비용으로 대규모 프로그램 개발이

용이하고, 이식성이 좋으며, 프로세스 수의 제한을 어느 정도 극복할 수 있고 시스템 관리가

편리한 환경을 구축하려 할 경우에 최적의 시스템을 구축할 수 있는 아키텍쳐라고 할 수 있다.

1-2. NUMA 의 개요 :

NUMA(Non Uniform Memory Access)를 글자 그대로 해석하면, 비균등 메모리 액세스

아키텍쳐를 의미한다. 최초의 NUMA 는 BBN 의 Butterfly 이며, 최초로 작동된 것은 스탠퍼드

대학의 Dash 이다. 현재 SUN 에서 개발 중인 NUMA 는 IBM 의 cc(cache – coherent) – NUMA 와

달리 COMA(Cache – Only Memery Access)로서 각 쿼드(Quad)에 메모리 대신 Attraction Cache 라는

대형 캐쉬를 사용한다. 보통 cc(cache – coherent) – NUMA 의 각 쿼드(Quad)에는 Intel Standard

High Volume (SHV) 프로세서, Quad Base Board, IQ-link, I/O Controller 와 메모리를 갖는다. 또한

각 쿼드는 PCI 버스(2bus * 64bit *7slot)를 통해 SCSI, FC, Ethernet, Token Ring, FDDI, ATM 및

ESCON 뿐만 아니라 SAN(Storage Area Network) 환경을 지원한다. 그리고 SCI(Scalable Coherent

Interconnect)를 이용하여 IEEE 표준을 지원하며 다수의 Block Building 을 허용한다.

1-3. cc(cache – coherent) – NUMA

cc(cache – coherent) – NUMA 는 다음 그림과 같은 구조로 되어 있다. 각 Building Block 은 규모에

따른 프로세서, 메모리 및 I/O 작업수를 추가할 수 있다. H/W 적으로는 TLC(Third Level Cache)를

이용하여 원격 메모리 접근을 가능케 하고, S/W 적으로는 스케쥴링을 통해 메모리 접근을 제어할

수 있도록 한 것이다.

1-4. NUMA-Q System Architecture

각 QUAD 에는 2-8GB 의 메모리와 Intel 프로세서, PCI Dual Bus 및 Quad 들간의 연결을 담당하는

IQ-Link 를 갖고 있다. 각 Quad 내부에는 720MB/s 의 내부 버스를 갖고 있으며, 한 시스템 내에 여러

개의 Quad 들이 존재하게 된다.

1-5. Intel Quad Architecture

각 쿼드에는 최대 8GB 까지의 메모리, 4 개의 프로세서, 쿼드 내부의 시스템 버스, PCI 브리지를

통한 PCI 버스로의 연결 및 쿼드간의 연결을 담당하는 IQ-Link 로 구성되어 있다. 또한 IQ-Link 의

연결을 SCI(Scalable Coherent Interconnect)를 이용함으로써 보다 많은 Building Block 을 포함할 수

있다.

1-6. Intel Quad Architecture

모든 NUMA 의 I/O 시스템은 Fiber Channel(FC)을 기본으로 하고 있다. 다음 그림은 Multi-Path

SAN(Storage Area Network)의 예를 보여주고 있다. 이 그림에서 보듯이 SAN 의 모든 경로가

NUMA 시스템으로 접근이 가능하다. 또한 자동적인 Load Balancing 을 구현할 수 있다. 뿐만

아니라 다중 포트의 FC 를 이용한 다중 경로 I/O SAN 을 구현할 수 있다.

2. Dynix/PTX 의 특성

2-1. Dynix/PTX 의 특성 :

1) 단일 관리 시스템 (Single OS)

2) S/W 및 H/W 파티션

3) Processing Resource

4) Resource 파티션

5) Application Region

2-2. 단일 관리 시스템 (Single OS)

디스크로의 접근 경로에 있어서 Dynix/PTX 는 다중 경로(Multipath)를 지원한다. 이러한 다중

경로를 통해 데이터의 전달을 확인하기 위한 데이터의 반향을 할 수 있다. 또한 I/O 서브 시스템

H/W 오류시 Dynix/PTX 는 가능하지 않은 경로를 자동으로 감지하여 대체 경로를 찾는다. 이때

Dynix/PTX 는 가능하지 않은 경로에 대해 발생되는 오류를 Logging 한다. 즉, Dynix/PTX 는 Class 3

과 Class 2 를 지원한다. Class 3 은 수십 초내에 메시지 전달을 확인하며, SAN 환경에서 발생되는

오류를 설명할 수 없다. 이것은 멀리 있는 사람을 큰 소리로 부르는 것에 비유될 수 있다. Class 2 는

1/1000 초안에 메시지 전달을 확인하거나 오류를 발견할 수 있다. 이는 서로 전자 메일을 통해

의사 전달하는 것에 비유될 수 있다. 현재 Class 1 은 지원되지 않으며, 이 서비스는 서로 대면하고

대화하는 수준의 서비스라고 생각될 수 있다.

2-3. S/W 및 H/W 파티션

Dynix/PTX 에서 소프트웨어 및 하드웨어 파티션을 어플리케이션 리젼(Application Region)과

리소스 파티션(Resource Partition)으로 설명하고 있다. 먼저, 어플리케이션 리젼(Application

Region)에서는 CPU 와 물리적 메모리와 같은 컴퓨팅 리소스(Computing Resource)의 집합

(Collection)을 특정 워크 로드(WorkLoad)로 분산시킬 수 있다. 다수의 어플리케이션 리젼

(Application Region)은 리젼(Region)간의 융통성 있는 이동을 가능케하는 하나의 OS 인스턴스

(Instance)로 관리될 수 있다. 그 다음으로 리소스 파티션(Resource Partition)이란 독립된 주소 공간

(Address Space)와 별도의 OS (Instance)를 갖는 한 이상의 정의된 하드웨어 유닛(Unit)을 일컫는다.

리소스 파티션(Resource Partition)은 몇 개의 어플리케이션 리젼(Application Region)으로 재분할될

수 있다.

2-4. Processing Resource

파티션된 리소스(Resource)는 하나의 OS 인스턴스에서 관리될 수 있도록 하는 리소스 프로세싱

(Resource Processing)을 통해 처리된다. 이러한 리소스 프로세싱(Resource Processing)을 기반으로

어플리케이션 리젼(Application Region)을 구현할 수 있다.

2-5. Resource 파티션

리소스 파티션(Resource Partition)이란 하나 이상의 쿼드(Quads)라는 빌딩 블록(Building Blocks)

을 사용하여 작동되는 하나의 OS(Operating system) 인스턴스(Instance)이다.

2-6. Application Region

어플리케이션 리젼(Application Region)의 예를 들면 다음과 같습니다.

여기서 어플리케이션 리젼(Application Region)은 Production 과 Billing 을 갖고 있다. 각 리젼

(Region)별로 워크로드를 시작한다. Billing 리젼에서 과부하이면, 이 리젼에서 얼마간의 부하를

제거하여 Production 리젼으로 옮긴다. 만약 Billing 리젼에 문제가 있다면, Billing 리젼의 모든

부하를 Production 리젼으로 옮긴다. 그 다음 Billing 리젼을 종료한다.

2-7. PTX Tools :

1) ARM 관련 명령

1-1) Region 생성

rgnctl -c -a -R cpu=0,1,2,3 -R mem_min=0:50m RGN1

1-2) Region 변경

rgnctl -m -R mem_min=200m RGN1

1-3) Region 삭제

rgnctl -d -r RGN1

1-4) Region 상태 보기

rgnstat -l

ps -R

1-5) Quad status

/etc/showquads

2) SVM(System Virtual Management)을 이용한 파일 시스템 생성 및 마운트

- vxassist -g -ibm -U fsgen make vol1 4000m sd7 (File System)

- umount /dev/vx/dsk/ibm/~

- mount -F efs /dev/vx/dsk/ibm/~ /dir_name

3) SVM(System Virtual Management)을 이용한 Raw Device 생성

- vxassist -g -ibm -U gen make vol1 4000m sd7 (Raw : /dev/vx/rdsk/ibm/vol1)

4) 시스템 모니터링 툴

- Top2

- sar -r 2 10 (system activity report)

5) 파일 시스템 및 Raw Device 의 size 산정

- Raw Device

vxprint -v -g ibm

8,192,000 * 512=4,194,304,000byte,

sd7 - sd10 는 각각 4GB

- File System (df -k : 4,094,144,000byte , sd6 - 9GB)

vxdisk -g ibm list

vxedit

3. Dynix/PTX 용 DB2 EEE

3-1. 테스트 환경 :

H/W 환경

IQ link

PCI- Fibre

Ethernet Network 환경에서 테스트를 수행하였다.

S/W 환경

Dynix/PTX v4.5

DB2 UDB EEE v6.1

데이터베이스 구성

db2nodes.cfg 는 다음과 같다.

Nodenum Hostname Logical-Port Quad

0 numaq 0 0

1 numaq 1 1

각 Quad 당 데이터베이스 구성 매개변수를 다음과 같이 수정하였다.

DB heap size : 6000 * 4KB

Buffpage size : 6250 * 32KB = 204 MB

Quad0 (180MHz * 4) (760 MB)

Quad1 (180MHz * 4) (1 GB)

Sd6 ( 9GB)Sd7, Sd8, Sd9, Sd10 (4GB * 4)

32KB 페이지 단위의 테이블 스페이스를 다음과 같이 생성하였다.

Quad Name Type Size Disks

0,1 Data_ts Raw 4GB *2 2 disks

0,1 Temp_ts Directoy 4GB *2 2 disks

데이타

A table containg 1.374GB (4,435,996 reconds)

file_01.del : 1,530,573 records (474 MB)

file_02.del : 2,905,423 records (900 MB)

물리적 구조 :

EEE (2Node)

코드

DataFileSource

Node1 Node2

log

Data lv

temp

log

Data lv

temp

DB

분석 : Node 당 2 개의 Physical Device 를 할당하였고, 데이터와 인덱스는 별도로 다른 Lv 에

저장하지 않고 하나의 lv 에 함께 저장하였다.

Load 시 데이타 파일 소스에서 파일을 읽는 것과 실제 테이블로 저장하는 I/O 을 고려하여 별도의

Physical Device 로 분리하였다.

Log 는 Load 와 Select Query 시에는 거의 사용되지 않았다고 볼 수 있다.

3-2. SVM(System Virtual Management)의 사용 :

SVM(System Virtual Management)을 이용하여 파일 시스템 생성 및 마운트하는 작업은 다음과

같다.

vxassist -g -ibm -U fsgen make fsvol1 4000m sd 7

umount /dev/vx/dsk/ibm/fsvol1

mount -F efs /dev/vx/dsk/ibm/fsvol1 /temp0

SVM(System Virtual Management)을 이용하여 Raw Device 를 생성하는 작업은 다음과 같다.

vxassist -g -ibm -U gen make vol1 4000m sd9

이 때 생성되는 Raw Device 는 /dev/vx/dsk/ibm/vol1 이다.

파일 시스템의 크기는 다음 명령을 통해 알 수 있다.

df -k

Raw Device 의 크기는 다음 명령으로 구할 수 있다.

vxprint -v -g ibm

여기서 위의 명령으로 나온 값의 단위는 512 byte 이다.

3-3. 데이터베이스 디자인 :

테이블 스페이스 :

EEE (Node 2)

Create TableSpace DATA_TS pagesize 32k Managed by DataBase

using (device '/dev/vx/dsk/ibm/vol1' 3200) on node(0)

using (device '/dev/vx/dsk/ibm/vol2' 3200) on node(1) ;

Create Temporary Tablespace TEMP_TS pagesize 32k Managed by System

using ('/temp0') on node(0)

using ('/temp1') on node(1) ;

테이블 :

Create Table CustomerFund

(Year DECIMAL(6,0) NOT NULL,

Code DECIMAL(3,0) NOT NULL,

SerialNumber DECIMAL(7,0) NOT NULL,

BizNumber DECIMAL(13,0) NOT NULL WITH DEFAULT 0.0,

RegNumber DECIMAL(13,0) NOT NULL WITH DEFAULT 0.0,

Part CHAR(2) NOT NULL WITH DEFAULT ' ',

ObjectCode DECIMAL(9,0) NOT NULL WITH DEFAULT 0.0,

A DECIMAL(15,0) NOT NULL WITH DEFAULT 0.0,

J DECIMAL(7,4) NOT NULL WITH DEFAULT 0.0,

B DECIMAL(15,0) NOT NULL WITH DEFAULT 0.0,

F DECIMAL(15,0) NOT NULL WITH DEFAULT 0.0,

G DECIMAL(15,0) NOT NULL WITH DEFAULT 0.0,

K DECIMAL(15,0) NOT NULL WITH DEFAULT 0.0,

L DECIMAL(7,4) NOT NULL WITH DEFAULT 0.0,

C DECIMAL(15,0) NOT NULL WITH DEFAULT 0.0,

I DECIMAL(15,0) NOT NULL WITH DEFAULT 0.0,

M DECIMAL(15,0) NOT NULL WITH DEFAULT 0.0,

H DECIMAL(15,0) NOT NULL WITH DEFAULT 0.0,

D DECIMAL(15,0) NOT NULL WITH DEFAULT 0.0,

N DECIMAL(15,0) NOT NULL WITH DEFAULT 0.0,

E DECIMAL(15,0) NOT NULL WITH DEFAULT 0.0,

OutputCode CHAR(2) NOT NULL WITH DEFAULT ' ',

O CHAR(2) NOT NULL WITH DEFAULT ' ',

P CHAR(2) NOT NULL WITH DEFAULT ' ')

In Data_ts ;

EEE 의 경우에는 데이터를 각 노드별로 분배를 해야 하기 때문에 Partitiong Key 를 지정해

주어야 한다. 그러면, 데이터가 Hashing 알고리즘과 Partitiong Key 에 따라 적합한 Node 에

저장되게 된다.

Partitioning Key – Year, Code

인덱스 :

Create Index Idx1 ON CustomerFund (Year ASC, Code ASC, BizNumber ASC, Part ASC)

Create Index Idx2 ON CustomerFund(Year ASC, Code ASC, RegNumber ASC, Part ASC)

Create Unique Index Idx3 ON CustomerFund

(Year ASC, Code ASC, SerialNumber ASC, Part ASC, ObjectCode ASC, BizNumber ASC,

RegNumber ASC, OutputCode ASC)

설정된 DBM 파라미터 :

SHEAPTHRES 40123

설정된 DB 파라미터 :

NUM_FREQVALUES 10

NUM_QUANTILES 20

DBHEAP 8400

CATALOGCACHE_SZ 128

LOGBUFSZ 32

UTIL_HEAP_SZ 14000

BUFFPAGE 262144

LOCKLIST 881

APP_CTL_HEAP_SZ 192

SORTHEAP 2006

STMTHEAP 3072

APPLHEAPSZ 3072

PCKCACHESZ 800

STAT_HEAP_SZ 4384

MAXLOCKS 18

STAT_HEAP_SZ 4384

MAXAPPLS 100

LOGFILSIZ 2500

LOGPRIMARY 10

LOGSECOND 30

3-4. AutoLoader

AutoLoader 파라미터 :

EE 의 경우는 일반 Load 를 명령어를 사용하여 데이타를 적재하지만, EEE 의 경우는 각

노드별로 데이타를 split 하여 적재를 해야 하기 때문에 이와 같은 과정을 자동으로 해주는 db2atld

라고 하는 툴을 사용하여 작업을 하게 된다. 이때 사용되는 구성 파일의 내용이다.

RELEASE=V5.01

db2 load from /source1/Fund-01.del of del insert into CustomerFund

DATABASE=testdb

SPLIT_FILE_LOCATION=/load

OUTPUT_NODES=(0,1)

SPLIT_NODES=(0)

MODE=SPLIT_AND_LOAD

LOGFILE=./load

NOTNFS_DIR=/notnfs

CHECK_LEVEL=NOCHECK

명령을 실행하기 위해서는 db2atld 라는 명령어를 수행하면 현재 디렉토리에서 자동적으로

autoloader.cfg 파일을 찾는다. 만일 다른 디렉토리에 해당 autoloader..cfg 를 작성하였다면 db2atld –

c /해당 디렉토리/ autoloader..cfg 로 실행해야 한다.

4. Dynix/PTX 용 DB2 EEE 성능 조정

4-1.성능 테스트 :

한글 테이블 생성 및 한글 데이터 입력 테스트

create table 한글테이블 (컬럼명 1 char(10) not null,

컬럼명 2 varchar(100),

컬럼명 3 decimal(9,2) ) ;

insert into 한글 테이블 values ( ‘한글’, ‘한글 테이터’, 3000.20 ) ;

Load Test :

Autoloader –c autoloader.cfg ;

분석 : 데이터 Load 는 크게 Load, Build, Delete 단계로 이루어진다. 이 과정에서 Index 을 만들기

위해 Sort 를 하게 되는데, Sort 를 Parallel 하게 진행할 수 있으므로 속도가 빠름을 알 수 있다.

Import Test :

분석 : 데이터 Load 에 비해 크게 Performance 가 느리다.

Insert Test :

Insert into CustomerFund values( '80', 2, 7, 6, 4, 8, 3, 4, 5, '23', '22', '33', 9,

0, 1, 4, 5, 3, 7, 500077, 6666666666, 777,

999, 7102081466328)

분석 : 처음 SQL 을 발행하였을 경우, 시간이 조금 걸리지만 다음부터는 일정한 시간을 보여주고,

1 라인 insert 의 경우에는 EE 와 EEE 의 속도차를 크게 느낄 수 있다..

Delete Test :

EEE (2 Node)에서 Test

분석 : 처음 SQL 을 발행하였을 경우, 시간이 조금 걸리지만 다음부터는 일정한 시간을 보여주고,

1 라인 insert 의 경우에는 EE 와 EEE 의 속도차를 크게 느낄 수 있습니다.

Backup & Restore Test :

EEE (2 Node)에서 Test

분석 : 각 노드별로 병렬로 Backup 및 Restore 를 수행할 수 잇습니다.

4-2. 성능과 관련된 매개변수 :

1) DB2_CORRELATED_PREDICATES : 조인의 상관(correlationship) 컬럼에 고유한 인덱스가 있고

이 레지스트리 변수가 ON 인 경우, 최적화 프로그램은 조인 술어의 상관을 감지하고 보상하려고

시도합니다. 이 레지스트리 변수가 ON 인 경우, 최적화 프로그램은 고유 인덱스 통계의

KEYCARD 정보를 사용하여 상관 경우를 감지하고 상관 술어의 결합된 선택성을 동적으로

조정하여 더 정확한 조인 크기 및 비용 예측 값을 얻습니다. 기본값=OFF

2) DB2BPVARS : 버퍼 풀을 조정할 때 사용되는 매개변수를 포함하는 파일의 경로를 지정합니다.

현재 지원되는 매개변수는 NT_SCATTER_DMSFILE, NT_SCATTER_DMSDEVICE 및

NT_SCATTER_SMS입니다.

이러한 각 매개변수의 기본값은 0(또는 OFF)이며, 가능한 값에는 0(또는 OFF)과 1(또는 ON)이

있습니다. 각 매개변수는 각 컨테이너 유형에 대해 스캐터 읽기를 ON 으로 설정하는 데

사용됩니다. 레지스트리에서 DB2NTNOCACHE 가 ON 으로 설정된 경우, 각각은 작동 가능으로만

될 수 있습니다(ON 으로 설정). DB2NTNOCACHE 가 OFF 로 설정된 경우(또는 설정되지 않은

경우), 스캐터 읽기는 작동 불가능으로 남아 있습니다. 시스템에는 각각의 컨테이너 유형에 대해

대량의 순차 프리페치를 가진 매개변수가 권장되며, 이미 OFF 로 설정된 DB2NTNOCACHE 를

사용하기로 결정되었습니다.

다음 예시에는 파일에 대해 경로를 설정하는 방법입니다.

db2set DB2BPVARS = f:\BPVARSFILE

파일의 내용은 다음 형식을 가진 매개변수로 구성됩니다.

parameter=value

3) DB2_HASH_JOIN : 액세스 플랜 컴파일시 가능한 조인 방법으로서 해쉬 조인을 지정합니다.

기본값=NO

4) DB2_PRED_FACTORIZE : 최적화 프로그램이 분리된 것들에서 추가 술어를 발췌할 수 있는

기회에 대해 탐색할 것인지를 지정합니다. 어떠한 상황에서는 추가 술어가 중간 및 최종 결과

세트에 대한 예측된 기본 행 수(cardinality)를 변경할 수 있습니다. 예를 들면 다음과 같습니다.

다음 조회에서,

SELECT n1.empno, n1.lastname FROM employee n1, employee n2 WHERE

((n1.lastname='SMITH' AND n2.lastname='JONES')

OR (n1.lastname='JONES' AND n2.lastname='SMITH'))

최적화 프로그램은 다음과 같은 추가 술어를 생성할 수 있습니다.

SELECT n1.empno, n1.lastname FROM employee n1, employee n2

WHERE n1.lastname IN ('SMITH', 'JONES') AND n2.lastname IN

('SMITH', 'JONES') AND ((n1.lastname='SMITH' AND n2.lastname='JONES')

OR (n1.lastname='JONES' AND n2.lastname='SMITH'))

기본값=NO

5) DB2MEMDISCLAIM : 실행중인 작업 로드 및 풀 에이전트 구성에 따라, 에이전트가 유휴

상태일 때에는 각 DB2 에이전트에 대한 커밋(Commit)된 메모리가 32 MB 가 넘게 상주하게 되는

상황에서 실행할 수도 있습니다. 이 동작이 예상되며 메모리가 신속하게 재사용됨에 따라 성능이

향상되는 결과를 낳게 됩니다. 그러나, 메모리 제한 시스템에서 이는 바람직한 부가작용이 아닐

수도 있습니다. 이러한 문제점을 방지하려면, 다음 명령을 발행하십시오.

db2set DB2MEMDISCLAIM = yes

메모리를 포기하면 AIX 운영 체제에게 영역의 페이지화를 중단하도록 지시하므로, 더 이상

실제 메모리를 점유하지 않게 됩니다. DB2MEMDISCLAIM 를 "YES"로 지정하면

DB2MEMMAXFREE 에 따라 DB2 UDB 에게 일부 또는 전체 메모리를 일단 해제하도록

지시합니다. 이는 메모리가 해제되자마자 바로 다른 프로세스에 사용할 수 있도록 합니다. 또한,

DB2MEMMAXFREE 를 참조하십시오.

기본값=널(NULL) AIX

6) DB2MEMMAXFREE : 각 DB2 에이전트가 보유하는 사용 가능한 메모리의 양을 지정합니다.

이 변수를 4-256 MB 로 설정할 수 있습니다. 이 기능을 사용할 경우, 이 값을 8 MB 로 설정하도록

권장합니다.

db2set DB2MEMMAXFREE = 8000000

또한 DB2MEMDISCLAIM 을 참조하십시오.

기본값=널(NULL) 이고 값의 범위는 (값: 4000000 - 256000000 ) 입니다.

7) DB2_RR_TO_RS : YES 로 설정되면, user table 에 대한 RR 아이솔레이션(isolation) 레벨은

효과적으로 RS 로 하향 조정됩니다. RR 경계는 데이터베이스 관리 프로그램 인스턴스에서는 이제

제공되지 않습니다. 응용프로그램에 RR 경계가 필요하지 않으면, 이 레지스트리 변수는 종종 RR

다음에서 발생할 수 있는 다음 키 잠금 경합 문제점을 제거하는 데 사용될 수 있습니다.

기본값=NO