9i의 경우 Controlfile은 다음과 같이 다중화 할 수 있습니다.

1) spfile이나 init를 사용할 경우 먼저 spfile 혹은 init 파일에 다중화 하고자 하는 control file의 위치를 지정합니다.

ALTER SYSTEM SET CONTROL_FILES = 
   '$ORACLE_HOME/DATA/DISK1/cntrl01.ctl',
   '$ORACLE_HOME/DATA/DISK2/cntrl02.ctl',
   '$ORACLE_HOME/DATA/DISK3/cntrl03.ctl' SCOPE=SPFILE;

2) 위치 지정 이후 database를 종료하고

3) controlfile을 위에서 지정한 위치로 각각 복사

4)database를 시작합니다.

controlfile은 database의 구성에 관한 정보를 담고 있으므로 다중화하셔야 하고(하나로 운영하다가 controlfile을 담고 있는 디스크가 깨지면 database가 다 날아갈 수도 있음) disk 구성이 RAID가 아닐 경우에는 특히나 서로 다른 디스크에 둘 것을 권장합니다.)

다음으로 redo log는 database 복구할 때 사용되는 것으로 이 역시 다중화 해 두는 것이 좋습니다.(이유는 컨트롤 파일과 동일하다고 보면 됩니다.) redo log 파일의 그룹 수와 멤버 수는 그냥 남이 이렇게 하니 좋더라 해서 설정할 수 있는 것은 아니고 <SID>alert.log 파일에서 checkpointing 되는 간격을 지켜 본 후 10~20분에 한번씩 일어나도록 size를 계산해서 설정해야 합니다.

하나의 리두 로그 그룹 또한 2개 이상의 멤버로 구성하시는 것이 낳습니다. 리두 로그의 경우 이동하는 경우가 아니라면 database를 내릴 필요는 없구요 online 상에서 가능합니다.

리두 로그 그룹을 추가하는 예제

ALETR DATABASE [데이터베이스명]
ADD LOGFILE [GROUP n] 파일스팩
[, [GROUP n] 파일스팩 ...];

alter database add logfile group 5 ('$ORACLE_HOME/DATA/DISK1/log3a.rdo','$ORACLE_HOME/DATA/DISK2/log3b.rdo') size 5m;

리두 로그 맴버 추가 예제

ALETR DATABASE [데이터베이스명]
ADD LOGFILE MEMBER
['파일명' [REUSE] [, '파일명' [REUSE] ...]
TO {GROUP n| ('파일명' [,'파일명' ...])
... ;

alter database add logfile memeber '$ORACLE_HOME/DATA/DISK3/log1c.rdo' to group 1,

'$ORACLE_HOME/DATA/DISK3/log2c.rdo' to group 2';

답변 감사드립니다.

저희 회사의 DB버젼은 windows환경하의 오라클8.04이며 raid5로 디스크가 구성되어있으며 archieve모드로 구성되어있습니다.

DBA쪽에 거의 모르다 보니 답변을 읽고 추가적으로 문의드립니다.

initoral.ora파일의 control files정보는

control_files = D:\orant\DATABASE\ctl1ORCL.ora 로 되어있습니다. size는 2442k이고요.

이걸 system user로 로그인해

ALTER SYSTEM SET CONTROL_FILES = 
   'D:\orant\DATABASE\ctl1ORCL.ora' ,

   'D:\orant\DATABASE\ctl2ORCL.ora', 

   'D:\orant\DATABASE\ctl3ORCL.ora' scope=spfile; 
이렇게하면 콘트롤파일이 3개가 만들어지나요? (size정보가 없네요?)

글에 보니까 control file을 해당위치로 복사하라고 되어있는데 무슨말인지 이해가 가지않습니다. T.T

copy 하지 않아도 된다면 위처럼하고 svrmgr30에서 db 셧다운후 스타트 하면 이상없이 콘트롤 파일이 2개가 더 추가되고 DB가 돌아가는데 문제가 없는지요?

redo log관련해서는 *alert.log파일이 없네요. 또 너무 복잡해 보여서 그냥 싸이즈만 추가해서 성능향상이 있지 않을까요?

현재 그룹없이 멤버만

D:\orant\DATABASE\log1orcl.ora,

D:\orant\DATABASE\log2orcl.ora,

D:\orant\DATABASE\log3orcl.ora,

D:\orant\DATABASE\log4orcl.ora  이렇게 4개가 이미 있고 싸이즈는 1025k로 되어있습니다.

그룹 한 2~3개정도로 만들고 싶은데

DBA쪽에 거의 지식이 없고 몇년전에 잠깐 교육받고 만들었던것이라 생각도 나지 않는군요.

혹시나 잘못 손댓다가 DB안살아 날까봐 무서워서 엄청 조심스럽습니다.

조금만 더 도움을 주시면 감사하겠습니다.

control 파일은 우리가 싸이즈를 정해주고 하는 성질의 것이  아닙니다. 그리고 제가 복사하라고 하는 것은 컨트롤 파일을 다중화 할꺼라고 하시니까 말씀드린 것이구요 그렇게 안할 경우의 위험부담도 위에 적었죠...

컨트롤 파일을 alter system으로 설정한 위치에 복사하라는 것이죠.. 위에 처럼만 설정하고 나서 그냥 DB내리고 파일 복사하지 않고 DB올리려고 하면 아마 DB가 올라오지 않을 것입니다.

따라서 먼저 명령문 실행하고 나서 DB내린 뒤 반드시 해당 위치의 control 파일을 설정한 위치로 복사하고 DB를 올려야 합니다. 그리고 해당 작업은 sys로 하셔야 합니다. system으로 되는지는 잘 모르겠네요. 안전하게 sys로 하세요.

그리고 <SID>alert.log는 database parameter의 중 bdump 위치에 있습니다. sqlplus로 들어가서 sho parameter background_dump_dest 라고 치면  value 값이 나오는데 거기에 alert.log 파일이 존재합니다.

물론 싸이즈만 추가해도 가능하지만 아마 디스크 깨지거나 하면 DB를 통채로 날려먹을 수도 있으니 조심하셔야 할 것입니다.

그리고 덧붙여 말씀드리면 아카이브 모드로 DB를 운영하면서 online redo log를 RAID 5에 사용하는 것은 별로 권장하지 않는 것입니다. LGWR이 RAID5에서는 쥐약이라고들 하죠~~^^

먼저 관련 작업에 대해 여러 군데서 자료를 모아서 검토 하신 후에 작업하세요. 신중하게 하셔야 할것입니다.

control 파일의 copy에 대해서 물어본 이유는 현재 어디에 있는 control file을 copy하라는건지를 몰라서입니다. 현재 control file이 한개인데 이걸 이름을 바꿔서 copy하라는건가 해서요.

그리고 raid5가 디스크 깨지면 디스크 하나 추가해서 원상태로 복구가 가능한 장점이 있는데, 이걸로 문제가 해결되는게 아닌가 보네요.

1.기존에 존재하고 있는 control file을 copy해야 합니다. Oracle에서는 동일한 control file을 여러 군데 위치해 놓고 장애 시 DB를 보호 할 수 있도록 하고 있습니다.

다음은 oracle9i database concept에 나오는 항목입니다.

Oracle 8이라고 해도 개념은 같으므로 동일하다고 보면 될겁니다. 먼저 database concept에서 찾아보세요.

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

Multiplexed Control Files
As with online redo log files, Oracle enables multiple, identical control files to be
open concurrently and written for the same database.
By storing multiple control files for a single database on different disks, you can
safeguard against a single point of failure with respect to control files. If a single
disk that contained a control file crashes, then the current instance fails when Oracle
attempts to access the damaged control file. However, when other copies of the
current control file are available on different disks, an instance can be restarted
easily without the need for database recovery.
If all control files of a database are permanently lost during operation, then the
instance is aborted and media recovery is required. Media recovery is not
straightforward if an older backup of a control file must be used because a current
copy is not available. Therefore, it is strongly recommended that you adhere to the
following practices:

Use multiplexed control files with each database

Store each copy on a different physical disk

Use operating system mirroring

Monitor backups

2.두번째 것은 아래 문서를 참고하세요

A BRIEF OVERVIEW OF RAID AND ORACLE

                              Oracle Corporate Support
                                 Problem Repository

1. Prob# 1011675.6  A BRIEF OVERVIEW OF RAID AND ORACLE
2. Soln# 2059721.6  A BRIEF OVERVIEW OF RAID AND ORACLE


1. Prob# 1011675.6  A BRIEF OVERVIEW OF RAID AND ORACLE

Problem ID          : 1011675.6
Affected Platforms  : Generic: not platform specific
Affected Products   : Oracle Server - Enterprise Edition V7
Affected Components : RDBMS Generic
Affected Oracle Vsn : Generic

Summary:
A BRIEF OVERVIEW OF RAID AND ORACLE

+=+

Problem Description: 
==================== 
 
This document gives a general overview of RAID (Redundant Arrays of 
Inexpensive Disks), the different levels of RAID and their uses, and the use 
of RAID with Oracle databases. 
 
 
Search Words: RAID, disk-striping, disk arrays, 
mirroring,raid5					

+==+

Diagnostics and References:



2. Soln# 2059721.6  A BRIEF OVERVIEW OF RAID AND ORACLE

Solution ID         : 2059721.6
For Problem         : 1011675.6
Affected Platforms  : Generic: not platform specific
Affected Products   : Oracle Server - Enterprise Edition V7
Affected Components : RDBMS Generic
Affected Oracle Vsn : Generic

Summary:
A BRIEF OVERVIEW OF RAID AND ORACLE

+=+

1. RAID - General Description 
 
RAID (Redundant Arrays of Inexpensive Disks) is frequently used to provide 
data redundancy in case of disk failure and involves, in part, striping of 
data across several physical drives.  RAID can be implemented in any one of 
several levels, ranging from 0 to 6.  Those levels are characterized by the 
following: 
 
RAID 0: This is a 'normal' file system, in which there will be data loss 
        with any disk failure.  This level provides good performance 
        and speed of access but no data redundancy.  If something on the 
        disk becomes corrupted, there is no way to restore or recalculate 
        that data. 
 
RAID 1: Full data redundancy is provided by complete mirroring of all files. 
        This method requires twice as much disk space as there is data.  No 
        error correction codes (ECC's) are used, and there is hence no parity 
        information involved. 
 
RAID 2: Redundancy is provided through ECC's (also sometimes called parity), 
        which are calculated for each 'chunk' of data. These ECC's can be used 
        to recreate the data in question and so this method requires less disk 
        space that RAID level 1.  However, the need to calculate ECC's will 
        generally make writes slower. 
 
RAID 3: ECC's are again calculated to provide data redundancy, but all the 
        parity bytes are stored on one physical disk with bit level parity. 
 
RAID 4: The same as RAID level 3 but with block level parity. 
 
RAID 5: Redundancy is provided by ECC's as in RAID 3 and 4, but in this case, 
        parity information is stored along with the data and is hence stripped 
        across several physical disks.  RAID 5 should not be used for 
        write-intensive files, since the continuous calculation of ECC's makes 
        writing data to disk slower.  RAID 3 should be used instead.  RAID 5 
        works best for read-only data files. 
 
RAID 6: ECC's are calculated in a more complex way, and redundancy is provided 
        with an advanced 2-dimensional parity. 
 
Raid levels 1 and 5 are most commonly used.  However, the choice of which 
specific RAID level to choose and how to implement that choice can be 
a complex question which must balance performance, cost, and data availability 
issues. 
 
 
2. Pro's and Cons of Implementing RAID technology 
 
There are benefits and disadvantages to using RAID, and those depend on the 
RAID level under consideration and the specific system in question. 
 
In general, RAID level 1 is most useful for systems where complete redundancy 
of data is a must and disk space is not an issue.  For large datafiles or 
systems with less disk space, this RAID level may not be feasible.  Writes 
under this level of RAID are no faster and no slower than 'usual'. 
 
For all other levels of RAID, writes will tend to be slower and reads will be 
faster than under 'normal' file systems.  Writes will be slower the more 
frequently ECC's are calculated and the more complex those ECC's are. 
Depending on the ratio of reads to writes in your system, I/O speed may have a 
net increase or a net decrease.  RAID can improve performance by distributing 
I/O, however, since the RAID controller spreads data over several physical 
drives and therefore no single drive is overburdened. 
 
The striping of data across physical drives has several consequences besides 
balancing I/O.  One additional advantage is that logical files may be created 
which are larger that the maximum size usually supported by an operating 
system.  There are disadvantages, as well, however.  Striping means that it is 
no longer possible to locate a single datafile on a specific physical drive. 
This may cause the loss of some application tuning capabilities.  Also, in 
Oracle's case, it can cause database recovery to be more time-consuming.  If a 
single physical disk in a RAID array needs recovery, all the disks which are 
part of that logical RAID device must be involved in the recovery. 
 
One additional note is that the storage of ECC's may require up to 20% 
more disk space than would storage of data alone, so there is some disk 
overhead involved with usage of RAID. 
 
 
3. RAID and Oracle 
 
The usage of RAID is transparent to Oracle.  All the features specific to 
RAID configuration are handled by the operating system and go on behind- 
the-scenes as far as Oracle is concerned.  Different Oracle file-types 
are suited differently for RAID devices.  Datafiles and archive logs can be 
placed on RAID devices, since they are accessed randomly.  Redo logs should be 
not be put on RAID devices, since they are accessed sequentially and 
performance is enhanced in their case by having the disk drive head near the 
last write location.  However, mirroring of redo log files is strongly 
recommended by Oracle. 
 
                                                
Recommendations:                                                               
  
Online or archived redo log files can be put on RAID 1 devices.   
You should not use RAID 5. 'TEMP'  tablespace data files should also go on  
RAID1 instead of RAID5 as well. The reason for this is that streamed  
write performance of distributed parity (RAID5) isn't as good as that of 
simple mirroring (RAID1).                          
 
Swap space can be used on RAID devices without affecting Oracle.   
         
 
References: 
1. Oracle for Unix Performance Tuning Tips pp. 26-27 (A22535-1) 
2. RAID: High-Performance, Reliable Secondary Storage (Chen, Peter etal, 1994) 


+==+

References: