BULLETIN CATEGORY
BULLETIN TOPIC : RDBMS
: ORACLE PARALLEL SERVER
--------------------------------------------------------------------------------
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;
BULLETIN TOPIC : RDBMS
: ORACLE PARALLEL SERVER
--------------------------------------------------------------------------------
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;
 |  [100%환급,개발자전문]빅데이터/SQL/자바/스프링/안드로이드/닷… | 12-27 | 2641 | |
| [채용확정무료교육]오라클자바개발잘하는신입뽑기2개월과정,교육… | 12-11 | 1909 | |
| 53 | [평일100%환급7건]Spring,자바&JSP,안드로이드,웹퍼블리싱,C#닷… | 03-15 | 1723 | |
| 52 | [주말]C#,ASP.NET마스터 | 01-31 | 1847 | |
| 51 | [기업100%환급,평일주간]SQL기초에서스키마오브젝트,PLSQL,힌트… | 01-31 | 2684 | |
| 50 | [평일주간야간,주말]C기본&자료구조,알고리즘 | 01-31 | 1437 | |
| 49 | [평일주간,평일야간,주말]Spring,MyBatis,Hibernate개발자과정-… | 01-19 | 1759 | |
| 48 | [평일야간,주말]안드로이드개발자과정(Android기초실무) | 01-11 | 1645 | |
| 47 | [평일야간,주말주간야간]JAVA,Network&JSP&Spring,MyBatis,Hiber… | 01-03 | 2163 | |
| 46 | [100%환급,개발자전문]빅데이터/SQL/자바/스프링/안드로이드/닷… | 12-27 | 2641 | |
| 45 | [평일주간]NoSQL,MongoDB,빅데이터기초과정 | 12-19 | 1868 | |
| 44 | [평일주간야간, 주말]웹퍼블리싱 마스터(HTML5,CSS3,jQUERY,AJAX… | 12-14 | 1838 | |
| 43 | [채용확정무료교육]오라클자바개발잘하는신입뽑기2개월과정,교육… | 12-11 | 1909 | |
| 42 | [평일주간]빅데이터하둡기초과정(BigData Hadoop) | 12-09 | 1499 | |
| 41 | [평일야간]닷넷(C#,Network,ADO.NET,ASP.NET)마스터 | 12-01 | 1730 | |
| 40 | [기업100%환급]오라클&자바웹스프링신입과정3주(SQL,JAVA,JSP,Se… | 12-01 | 1907 | |
| 39 | [평일야간,주말]SQL기초에서실무까지(SQL기초,PLSQL,힌트,튜닝) | 12-01 | 1373 | |
댓글 없음:
댓글 쓰기