오서비네 이글루

From : http://kr.forums.oracle.com/forums/thread.jspa?messageID=1462425

OPS 와 RAC의 차이

TAF를 구성하는 것이지요..;;
OPS에서도 TAF로 RAC와 같은 기능을 하게할 수 있습니다.
ops, rac도 무중단 시스템을 구축하는 것은 맞습니다.
하지만 장애가 난 시점에서 트랜잭션을 복구는 하나, 장애난 시점에서
fail난 트랜잭션을 다시 수행해주지는 못합니다. 하지만 OPS도
RAC와 마찬가지로 세션을 넘겨주고, SELECT하는 쿼리에 대해서는
장애가 나더라도 다른 노드로 서비스를 넘길 수 있지요.

technical bulletin을 보시면 자세한 정보가 많습니다.


No. 10849

OPS에서 여러 node를 사용 중 한 시스템이 fail이 생길 경우
=====================================================

다음은 사용자의 application 수정없이 failover 시스템으로 접속하는 방법이다.


제약조건 > SQL*NET V2.3.2.1.6 for windows 95
SQL*NET V2.3.2.1.8 for windows

상기의 버젼 이상이라야 하며 위의 경우 tnsnames.ora화일의 configuration은
다음과 같다 .


SQL*Net 2.3 failover가 난 경우 tnsnames.ora file

사용자가 <alias> 에 connect 하기를 요청한 경우 , sqlnet 은 description_list의
첫번째 description address 에 connect 을 시도한다.
만약 이것이 실패할 경우 description_list 의 다음 description 에 connect 을
시도한다.
필요하다면 description list 에 여러 description 을 가질수있다.
만일 모든 description 으로의 연결이 실패한다면 client 는 error 를 발생시킨다.


<alias>=
(description_list=
(description=
(address_list=
(address=
(protocol=tcp)
(host=<server 1>)
(port=1521)
)
)
(connect_data=
(sid=<sid1>)
)
)
(description=
(address_list=
(address= (protocol=tcp)
(host=<server 2>)
(port=1521)
)
)
(connect_data=
(sid=<sid2>)
)
)
)



================================================
No. 11667

ORACLE8 OPS 환경에서 FAILOVER SETUP 방법
========================================

Explanation
-----------
oracle 7 ops (sqlnet v2.3.x 이상)에서는 fail로 인한 failover 지원이 manual
하게 reconnect를 하도록 하여 지원이 되었다. <bulletin 11033 참고>
이는 sql*net기능을 사용하여 connection time failover 기능을 사용하는 경우이다.

하지만, oracle 8 이상 에서는 automatic reconnection이 가능하게 되었다.
즉, run-time failover가 가능하다.
이는 일단 connection이 이루어진 후에 발생하는 모든 failover는
Transparent Application Failover 코드에 의해 처리된다.

다음은 Oracle 8 TAF(Transparent Application Failover) setup 방법이다.

tnsnames.ora file에 다음의 parameter를 지정하여 가능하다.

1. failover_mode : run time 시에 failover가 가능하게 한다.

2. TYPE (Required) : failover 후의 operation을 지정한다.

SESSION - failover 발생 시 새로운 session이 다른 instance에
reconnection되며 이전 session에서의 모든 uncommit된
작업은 rollback 된다.
select도 이어서 진행되지 못한다.

SELECT - failover 발생 시 새로운 session이 다른 instance에
reconnection되며 이 때 long query나 복잡한 query 등의
작업 수행 시 작업이 이어서 진행된다.
단, dml 작업은 rollback된다.

NONE - This is the default. No automatic failover

3. METHOD : 어떻게 failover할지를 지정한다.

BASIC - failover 발생 시에 backup instance(server)로 다시 접속한다.

PRECONNECT - primary instance와 backup instance 두 개에 모두
connection 맺어 놓은 후 failover 시에 backup
instance를 통해 service한다.

***< 중요 > 현재 PRECONNECT는 최소한 8.0.5는 되어야 하며
BASIC은 8.0.6이나 8.1.5에서만 가능하다.

4. BACKUP : failover 시 접속할 instance의 정보를 기술한다.
tnsnames.ora의 alias name을 기술한다.


Example
--------
다음은 tnsnames.ora file의 example이다.

< example 1 >
=========================================================================
node1.WORLD =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(Host = node1)(Port = 1521))
(CONNECT_DATA = (SID = SID1)
(FAILOVER_MODE = (BACKUP = node2)
(TYPE = SELECT )
(METHOD = PRECONNECT))
)
)
)

node2.WORLD =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(Host = node2)(Port = 1521))
(CONNECT_DATA = (SID = SID2)
(FAILOVER_MODE = (BACKUP = node1)
(TYPE = SELECT )
(METHOD = PRECONNECT))
)
)
)
========================================================================

< test 1 >
1) 각 node의 instance를 start한다.
2) 각 node의 listener를 구동한다.

node1% lsnrctl start lsnr_node1
node2% lsnrctl start lsnr_node2

3) node1에서 다음의 작업을 한다.

sqlplus scott/tiger@node1
SQL> select count(*) from emp;
COUNT(*)
----------
14

4) Node1에서 instance를 shutdown abort한다.
5) 3번의 session에서 select를 다시 한다.

SQL> select count(*) from emp;
*
ERROR at line 1:
ORA-25404: lost instance

다시 select한다.
SQL> select count(*) from emp;

COUNT(*)
----------
14

Data가 node2 instance를 통해 제대로 select되며 이는 failover가 정상적으로
작동됨을 알 수 있다.

< example 2 >

다음은 TAF(Transparent Application Failover) 기능에 SQL*NET의
connection time failover 기능을 추가한 경우이다.
========================================================================
node1.WORLD =
(DESCRIPTION_LIST =
(DESCRIPTION = (ADDRESS = (PROTOCOL= TCP)(Host= node1)(Port= 1521))
(CONNECT_DATA =(SID = SID1)(SERVER=SHARED)
(FAILOVER_MODE = (BACKUP = node2)(TYPE=SESSION)(METHOD=PRECONNECT))))
(DESCRIPTION =(ADDRESS = (PROTOCOL= TCP)(Host= node2)(Port= 1521))
(CONNECT_DATA =(SID = SID2)(SERVER=SHARED)
(FAILOVER_MODE = (BACKUP = node1)(TYPE=SELECT)(METHOD=PRECONNECT))))
)

node2.WORLD =
(DESCRIPTION_LIST =
(DESCRIPTION =(ADDRESS = (PROTOCOL= TCP)(Host= node2)(Port= 1521))
(CONNECT_DATA =(SID = SID2)(SERVER=SHARED)
(FAILOVER_MODE = (BACKUP = node1)(TYPE=SESSION)(METHOD=PRECONNECT))))
(DESCRIPTION = (ADDRESS = (PROTOCOL= TCP)(Host= node1)(Port= 1521))
(CONNECT_DATA = (SID = SID1)(SERVER=SHARED)
(FAILOVER_MODE = (BACKUP = node2)(TYPE=SELECT)(METHOD=PRECONNECT))))
)

=======================================================================
< test 2 >

1) 각 node의 instance를 start한다.

2) 각 node의 listener를 구동한다.

node1% lsnrctl start lsnr_node1
node2% lsnrctl start lsnr_node2

3) node1에서 다음의 작업을 한다.

sqlplus scott/tiger@node1

SQL> select count(*) from emp;

COUNT(*)
----------
14

4) Node1에서 instance를 shutdown abort한다.

5) 3번의 session에서 select를 다시 한다.
ORA-25404 error조차 없이 select된다.

SQL> select count(*) from emp;

COUNT(*)
----------
14

Data가 node2 instance를 통해 제대로 select되며 이는 failover가 정상적
으로 작동됨을 알 수 있다.

(참고 1) dedicated 방식의 경우는 shared 대신에 dedicated를 기술한다.
물론 initSID.ora의 mts를 기술하지 않고 tnsnames.ora의 server option을 쓰지
않으면 default로 dedicated 방식을 쓴다.

(참고 2) example 1을 사용할 경우 session 종료 후 재접속 시 자동 failover가
되지는 않는다.


Reference Documents
-------------------
oracle8 parallel server concepts & administration manual



==================================================


No. 10297

ORACLE PARALLEL SERVER (OPS)
==============================

PURPOSE
---------
다음은 OPS(ORACLE PARALLEL SERVER) 의 구조에 대해서 알아본다.


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

====================================================