ORACLE PARALLEL SERVER (OPS)

Question

제품 : ORACLE SERVER
작성날짜 : 2004-08-13
ORACLE PARALLEL SERVER (OPS)
==============================
PURPOSE
다음은 OPS(ORACLE PARALLEL SERVER) 의 구조에 대해서 알아본다.
SCOPE
Standard Edition 에서는 Real Application Clusters 기능이 10g(10.1.0) 이상 부터 지원이 됩니다.
Explanation
1. Parallel Server Architecture
OPS는 다수의 Loosely Coupled System들 간의 원활한 Resource
Sharing을 위해 제공하는 DLM(PCM)을 이용하여 동시에 다수의
사용자가 각 Node를 통해 한 Database를 Access함으로써 System의
가용성과 전체적인 성능을 극대화시키기 위한 다중처리 System
구성이다.
(1) Loosely Coupled System
SMP Machine과 같이 Tightly Coupled System들 간에 Data Files,
Print Queue 같은 Resource를 공유하기 위한 Shared Disk
Architecture로 Node간의 정보전송은 Common High-Speed Bus를
이용한다.
(2) Distributed Lock Manager(DLM)
Loosely Coupled System에서 Resource Sharing을 조정,관리하는
Software로 Application들이 같은 Resource에 대해 동시에 Access를
요구할 때 서로간의 Synchronization을 유지하며 Conflict가
발생하지 않도록 하는 기능을 담당한다.
다음은 DLM의 주요 Service이다
- Resource에 대한 Current "ownership" 유지 관리
- Application Process들의 Resource Request Accept
- 요구한 Resource가 가용할 경우 해당 Process에 공지
- Resource에 대한 Exclusive Access 허용
(3) Parallel Cache Management(PCM)
Data File내의 하나 이상의 Data Block을 관리하기 위해
할당되는 Distributed Lock을 PCM Lock이라 하며 어떤 Instance가
특정 Resource를 Access하기 위해서는 반드시 그 Resource의 Master
Copy의 "owner"가 되어야 한다.
이는 곧 그 Resource를 Cover하는 Distributed Lock의 "owner"가
됨을 의미한다. 이러한 "owner ship"은 다른 Instance가 동일
Data Block 또는 그 PCM Lock에 의해 Cover되고 있는 다른 Data
Block에 대한 Update 요구가 있을때까지 계속 유지된다.
"owner ship"이 한 Instance에 다른 Instance로 전이 되기 전에
변경된 Data Block은 반드시 Disk로 "write"하므로 각 Node의
Instance간 Cache Coherency는 철저하게 보장된다.
2. Parallel Server의 특성
- Network상의 각 Node에서 Oracle Instance 기동 가능
- 각 Instance는 SGA + Background Processes로 구성
- 모든 Instance는 Control File과 Datafile들을 공유
- 각 Instance는 자신의 Redo Log를 보유
- Control File, Datafiles, Redo Log Files는 하나 이상의
Disk에 위치
- 다수의 사용자가 각 Instance를 통해 Transaction 실행 가능
- Row Locking Mode 유지
3. Tuning Focus
서로 다른 Node를 통해서 하나의 Database 구성하의 Resource를
동시에 사용하는 OPS 환경에서 Data의 일관성과 연속성을 위한
Instance간의 Lock Managing은 불가피한 현실이다. 즉, 위에서
언급한 Instance간의 Resource "owner ship"의 전이(pinging 현상)
와 같은 Overhead를 최소화하기 위해선 효율적인 Application
Partition(Job의 분산)이 가장 중요한 현실 Factor이다.
다시 말해 서로 다른 Node를 통한 동일 Resource에의 Cross-Access
상황을 최소화해야 함을 의미한다.
다음은 OPS 환경에서 Database Structure 차원의 Tuning Point로서
PCM Lock 관련 GC(Global Constant) Parameters와 Storage에 적용할
Options 및 기타 필요한 사항이다.
(1) Initial Parameters
OPS 환경에서 PCM Locks를 의해 주는 GC(Global Constant)
Parameters는 Lock Managing에 절대적인 영향을 미치며 각 Node마다
반드시 동일한 Value로 설정(gc_lck_procs 제외)되어야 한다.
일반적인 UNIX System에서 GC Parameters로 정의하는 PCM Locks의
총합은 System에서 제공하는 DLM Configuration 중 "Number of
Resources"의 범위 내에서 설정 가능하다.
- gc_db_locks
PCM Locks(DistributedLocks)의 총합을 정의하는 Parameter로
gc_file_to_locks Parameter에 정의한 Locks의 합보다 반드시
커야 한다.
너무 작게 설정될 경우 하나의 PCM Lock이 관리하는 Data Blocks가
상대적으로 많아지므로 Pinging(False Pinging) 현상의 발생
가능성도 그만큼 커지게 되며 그에 따른 Overhead로 인해 System
Performance도 현격히 저하될 가능성이 크다. 따라서 가능한
최대의 값으로 설정해야 한다.
- False Pinging
하나의 PCM Lock이 다수의 Data Blocks를 관리하므로 자신의
Block이 아닌 같은 PCM 관할하의 다른 Block의 영향으로 인해
Pining현상이 발생할 수 있는 데 이를 "False Pinging"이라 한다.
Database Object별 발생한 Pinging Count는 다음과 같이 확인할 수
있으며 sum(xnc) > 5(V$PING) 인 경우에 더욱 유의해야 한다.
- gc_file_to_locks
결국 gc_db_locks에 정의된 전체 PCM Locks는 각 Datafile 당
적절히 안배가 되는데 전체 Locks를 운용자의 분석 결과에 의거
각 Datafile에 적절히 할당하기 위한 Parameter이다.
운용자의 분석 내용은 각 Datafile 내에 존재하는 Objects의 성격,
Transaction Type, Access 빈도 등의 세부 사항을 포함하되 전체
PCM Locks 대비 Data Blocks의 적절하고도 효율적인 안배가
절대적이다.
이 Parameter로 각 Datafile당 PCM Locks를 안배한 후 Status를
다음의 Fixed Table로 확인할 수 있다.
Sample : gc_db_locks = 1000
gc_file_to_locks = "1=500:5=200"
X$KCLFI ----> 정의된 Bucket 확인
Fileno      Bucket     
1     1     
2      0      
3     0     
4      0     
5     2     
X$KCLFH ----> Bucket별 할당된 Locks 확인
Bucket     Locks     Grouping     Start     
0     300     1     0     
1     500     1     300     
2     200     1     800     
gc_files_to_locks에 정의한 각 Datafile당 PCM Locks의 총합은 물론
gc_db_locks의 범위를 초과할 수 없다.
다음은 각 Datafile에 할당된 Data Blocks의 수를 알아보는 문장이다.
select e.file_id id,f.file_name name,sum(e.blocks) allocated,
f.blocks "file size"
from dba_extents e,dba_data_files f
where e.file_id = f.file_id
group by e.file_id,f.file_name,f.blocks
order by e.file_id;
- gc_rollback_segments
OPS로 구성된 각 Node의 Instance에 만들어진 Rollback Segment
(Init.ora의 rollback_segments에 정의한)의 총합을 정의한다.
다수의 Instance가 Rollback Segment를 공용으로 사용할 수는 있으나
OPS 환경에서는 그로 인한 Contention Overhead가 엄청나므로 반드시
Instance당 독자적인 Rollback Segment를 만들어야 하며 Instance간
동일한 이름의 부여는 불가하다.
select count(*) from dba_rollback_segs
where status='ONLINE';
위의 결과치 이상의 값으로 정해야 한다.
- gc_rollback_locks
하나의 Rollback Segment에서 동시에 변경되는 Rollback Segment
Blocks에 부여하는 Distributed Lock의 수를 정의한다.
Total# of RBS Locks = gc_rollback_locks * (gc_rollback_segments+1)
위에서 "1"을 더한 것은 System Rollback Segment를 고려한 것이다.
전체 Rollback Segment Blocks 대비 적절한 Locks를 정의해야 한다.
다음은 Rollback Segment에 할당된 Blocks의 수를 알아보는 문장이다.
select s.segment_name name,sum(r.blocks) blocks
from dba_segments s,dba_extents r
where s.segment_name = r.segment_name
and s.segment_type = 'ROLLBACK'
group by s.segment_name;
- gc_save_rollback_locks
특정 시점에서 어떤 Tablespace 내의 Object를 Access하고 있는
Transaction이 있어도 그 Tablespace를 Offline하는 것은 가능하다.
Offline 이후에 발생된 Undo는 System Tablespace내의 "Differred
Rollback Segment"에 기록, 보관 됨으로써 Read Consistency를
유지한다. 이 때 생성되는 Differred Rollback Segment에 할당하는
Locks를 정의하는 Parameter이다.
일반적으로 gc_rollback_locks의 값과 같은 정도로 정의하면 된다.
- gc_segments
모든 Segment Header Blocks를 Cover하는 Locks를 정의한다. 이 값이
작을 경우에도 Pinging 발생 가능성은 그 만큼 커지므로 해당
Database에 정의된 Segments 이상으로 설정해야 한다.
select count(*) from dba_segments
where segment_type in ('INDEX','TABLE','CLUSTER');
- gc_tablespaces
OPS 환경에서 동시에 Offline에서 Online으로 또는 Online에서
Offline으로 전환 가능한 Tablespace의 최대값을 정의하는 것으로
안전하게 설정하기 위해서 Database에 정의된 Tablespace의 수만큼
설정한다.
select count(*) from dba_tablespaces;
- gc_lck_procs
Background Lock Process의 수를 정하는 것으로 최대 10개까지
설정(LCK0-LCK9)할 수 있다. 기본적으로 하나가 설정되지만 필요에
따라 수를 늘려야 한다.
(2) Storage Options
- Free Lists
Free List는 사용 가능한 Free Blocks에 대한 List를 의미한다.
Database에서 새롭게 가용한 Space를 필요로 하는 Insert나
Update시엔 반드시 Free Space List와 관련 정보를 가지고 있는
Blocks Common Pool을 검색한 후 필요한 만큼의 충분한 Blocks가
확보되지 않으면 Oracle은 새로운 Extent를 할당하게 된다.
특정 Object에 동시에 다수의 Transaction이 발생한 경우 다수의
Free Lists는 그만큼 Free Space에 대한 Contention을 감소시킨다.
결국 Free List의 개수는 Object의 성격과 Access Type에 따라
적절히 늘림으로써 커다란 효과를 거둘 수 있다.
예를 들면 Insert나 크기가 늘어나는 Update가 빈번한 Object인
경우엔 Access 빈도에 따라 3 - 5 정도로 늘려줘야 한다.
- freelist groups
Freelist group의 수를 정의하며 전형적으로 OPS 환경에서
Instance의 수만큼 설정한다. 특정 Object의 Extent를 특정
Instance에 할당하여 그 Instance에 대한 Freelist Groups를
유지하므로 Instance별 Free List 관리도 가능하다.
(3) 기타
- Initrans
동시에 Data Block을 Access할 때 필요한 Transaction Entries에
대한 초기치를 의미하며 Entry당 23Byte의 Space를 미리 할당한다.
기본값은 Table이 "1" 이고 Index와 Cluster는 "2" 이다. Access가
아주 빈번한 Object인 경우 Concurrent Transactions를 고려하여
적절히 설정한다.
4. Application Partition
OPS Application Design의 가장 중요한 부분으로 Partitioning의
기본 원리는 다음과 같다.
. Read Intensive Data는 Write Intensive Data로부터 다른
Tablespaces로 분리한다.
. 가능한 한 하나의 Application은 한 Node에서만 실행되도록
한다. 이는 곧 다른 Application들에 의해 Access되는 Data에
대한 Partition을 의미한다.
. 각 Node마다 Temporary Tablespaces를 할당한다.
. 각 Node마다 Rollback Segments를 독립적으로 유지한다.
5. Backup & Recovery
일반적으로 OPS 환경의 Sites는 대부분 24 * 365 Online 상황이므로
전체적인 Database 운영은 Archive Log Mode & Hot Backup으로 갈
수에 없으며 Failure 발생시 얼마나 빠른 시간 안에 Database를
완벽하게 복구 할 수 있는 지가 최대 관건이라 하겠다.
모든 Backup & Recovery에 관한 일반적인 내용은 Exclusive Mode
Database 운영 환경에서와 동일하다.
(1) Backup
- Hot Backup Internal
Archive Mode로 DB를 정상적으로 운영하며 Online Data Files를
Backup하는 방법으로 Tablespace 단위로 행해진다.
alter tablespace - begin backup이 실행되면 해당 Tablespace를
구성하는 Datafiles에 Checkpoint가 발생되어 Memory상의 Dirty
Buffers를 해당 Datafiles(Disk)에 "Write"함과 동시에 Hot Backup
Mode에 있는 모든 Datafiles의 Header에 Checkpoint SCN을 Update
하는데 이는 Recovery시에 중요한 Point가 된다.
또한 alter tablespace - end backup이 실행되기 전까지 즉,
Hot Backup이 행해지는 동안 해당 Datafiles는 "fuzzy" Backup
Data가 생성되며 특정 Record의 변형 시에도 해당 Block이 Redo
Log에 기록 되므로 다수의 Archive File이 더 생성되는 것을 볼 수
있다. 따라서 Admin이 해당 Datafiles를 모두 Backup하고도 end
backup을 실행하지 않으면 전체 인 System 성능에 심각한 영향을
미치게 되므로 특히 주의해야 한다.
Hot Backup 중인지의 여부는 다음 문장을 통해 확인할 수 있다.
select * from v$backup; -> status 확인
- Hot Backup Step (Recommended)
① alter system archive log current
② alter tablespace tablespacename begin backup
③ backup the datafiles,control files,redo log files
④ alter tablespace tablespacename end backup
⑤ alter database backup controlfile to 'filespec'
⑥ alter database backup controlfile to trace noresetlogs(safety)
⑦ alter system archive log current
(2) Recovery
- Instance Failure시
OPS 환경에서 한 Instance의 Failure시 다른 Instance의 SMON이
즉시 감지하여 Failed Instance에 대한 Recovery를 자동으로
수행한다. 이 때 운영중인 Instance는 Failed Instance가 생성한
Redo Log Entries와 Rollback Images를 이용하여 Recovery한다.
Multi-Node Failure시엔 바로 다음에 Open 된 Instance가 그 역할을
담당하게 된다. 아울러 Failed Instance가 Access하던 모든 Online
Datafiles에 대한 Recovery도 병행되는 데 이런 과정의 일부로
Datafiles에 관한 Verification이 실패하여 Instance Recovery가 되지
않을 경우엔 다음 SQL Statement를 실행시키면 된다.
alter system check datafiles global;
- Media Failure시
다양한 형태로 발생하는 Media Failure시엔 Backup Copy를
Restore한 후 Complete 또는 Incomplete Media Recovery를 행해야
하며 이는 Exclusive Mode로 Database를 운영할 때와 전혀 다르지
않다.
Node별 생성된 즉, Thread마다 생성된 모든 Archived Log Files는
당연히 필요하며 많은 OPS Node 중 어디에서든지 Recovery 작업을
수행할 수 있다.
- Parallel Recovery
Instance 또는 Media Failure시 ORACLE 7.1 이상에서는 Instance
Level(init.ora) 또는 Command Level(Recover--)에서 Parallel
Recovery가 가능하다. 여러 개의 Recovery Processes를 이용하여
Redo Log Files를 동시에 읽어 해당 After Image를 Datafiles에
반영시킬 수 있다. Recovery_Parallelism Parameter는 Concurrent
Recovery Processes의 수를 정하며 Parallel_Max_Servers Parameter의
값을 초과할 수는 없다.
(3) 운영 시 발생 가능한 Error
- ORA-1187 발생
ORA-1187 : can not read from file name because it
failed verification tests.
(상황) 하나의 Node에서 create tablespace ... 한 상태에
정상적으로 운영하던 중 다른 Node를 통해 특정 Object를
Access하는데 ORA-1187 발생.
(원인) 다른 Node에서 raw disk의 owner, group, mode 등을
Tablespace가 생성된 후 뒤늦게 전환.
(Admin의 Fault)
(조치) SQL> alter system check datafiles global;
Reference Documents
--------------------

Answer 1

hal lavender wrote:
Hi,
I am trying to achieve Load Balancing & Failover of Database requests to two of the nodes in 8i OPS.
Both the nodes are located in the same data center.
Here comes the config of one of the connection pools.
<JDBCConnectionPool CapacityIncrement="5" ConnLeakProfilingEnabled="true"
DriverName="oracle.jdbc.driver.OracleDriver" InactiveConnectionTimeoutSeconds="0"
InitialCapacity="10" MaxCapacity="25" Name="db1Connection598011" PasswordEncrypted="{3DES}ARaEjYZ58HfKOKk41unCdQ=="
Properties="user=ts2user" Targets="ngusCluster12,ngusCluster34" TestConnectionsOnCreate="false"
TestConnectionsOnRelease="false" TestConnectionsOnReserve="true" TestFrequencySeconds="0"
TestTableName="SQL SELECT 1 FROM DUAL" URL="jdbc:oracle:thin:@192.22.11.160:1421:dbinst01" />
<JDBCConnectionPool CapacityIncrement="5" ConnLeakProfilingEnabled="true"
DriverName="oracle.jdbc.driver.OracleDriver" InactiveConnectionTimeoutSeconds="0"
InitialCapacity="10" MaxCapacity="25" Name="db2Connection598011" PasswordEncrypted="{3DES}ARaEjYZ58HfKOKk41unCdQ=="
Properties="user=ts2user" Targets="ngusCluster12,ngusCluster34" TestConnectionsOnCreate="false"
TestConnectionsOnRelease="false" TestConnectionsOnReserve="true" TestFrequencySeconds="0"
TestTableName="SQL SELECT 1 FROM DUAL" URL="jdbc:oracle:thin:@192.22.11.161:1421:dbinst01" />
<JDBCMultiPool AlgorithmType="Load-Balancing" Name="pooledConnection598011"
PoolList="db1Connection598011,db2Connection598011" Targets="ngusCluster12,ngusCluster34" />
Please let me know , if you need further information
HalHi Hal. All that seems fine, as it should be. Tell me how you
enact a failure so that you'd expect one pool to still be good
when the other is bad.
thanks,
Joe