CHAPTER05. Managing Databases in ASM

지금까지 Oracle ASM의 다양한 구성 요소와 Oracle Database가 필요로 하는 방식으로 데이터를 저장함으로써 Oracle 메타 데이터를 활용하고 성능 이점을 제공하는 견고한 스토리지 관리 솔루션을 제공하기 위해 이들이 어떻게 협력하는지에 대해 살펴 보았습니다. 그러나 관계형 데이터베이스 관리 시스템(RDBMS)과 새로운 스토리지 관리자는 어떻게 함께 작동합니까? 이 시점에서 모든 독자는 이 중요한 질문에 대한 답을 궁금해 해야합니다.
이 장에서는 ASM과 RDBMS 간의 상호 작용에 대해 설명합니다.
또한 ASM 인스턴스에 대한 다양한 인터페이스와 ASM 스토리지로 데이터를 마이그레이션하는 방법에 대해 설명합니다.
ASM은 Oracle Database의 단일 인스턴스 버전과 클러스터된 버전을 모두 지원합니다.
전략적 관점에서 볼 때 ASM은 RAC (Real Application Clusters)와 같은 클러스터 구성에 가장 적합하지만 단일 인스턴스 데이터베이스에 ASM을 구현할 때 어떤 기능도 부족하지 않습니다.
따라서 이 장에서는 별도로 언급하지 않는 한 모든 토론이 두 유형의 구성에 모두 적용됩니다.
 
ASM과 데이터베이스 간의 상호 작용
RDBMS 인스턴스는 표준 Oracle 인스턴스이며 ASM 인스턴스의 클라이언트입니다.
RDBMS에서 ASM으로의 통신은 항상 인트라 노드입니다. 즉, RDBMS는 디스크 그룹 요청을 처리하기 위해 원격 ASM 인스턴스(RAC의 경우)에 접속하지 않습니다. 이는 12c ASM까지는 사실입니다. 자세한 내용은 14장을 참조하십시오.
RDBMS 인스턴스는 ASM 인스턴스에 I/O 요청을 하지 않습니다. 즉, RDBMS 인스턴스는 ASM을 통해 I/O 요청을 프록시하지 않습니다. RDBMS 인스턴스가 시스템 테이블 공간 데이터 파일과 같은 ASM 파일을 열면 ASM은 파일의 범위 맵을 SGA(System Global Area)에 범위의 맵을 저장하는 RDBMS 인스턴스에 전달합니다.
RDBMS 인스턴스가 SGA에 캐시된 ASM 파일의 확장 영역 맵을 가지고 있다고 가정하면, RDBMS 인스턴스는 ASM 인스턴스의 추가 개입없이 디스크에서 직접 읽기/쓰기를 처리 할 수 있습니다.
원시 디바이스의 경우와 마찬가지로, I/O 요청 크기는 ASM이 아닌 RDBMS 인스턴스에 의해 결정됩니다. 따라서 RDBMS가 8KB 데이터베이스 블록을 읽거나 플러시해야하는 경우 1MB I/O가 아닌 8KB I/O가 발행됩니다.
사용자는 종종 ASSM(Automatic Segment Space Management) 기반 데이터 파일과 ASM간에 종속성이 있는지 여부를 묻습니다. ASM과 ASSM 사이의 의존성은 없습니다(약어는 한 글자씩 다릅니다). ASM은 데이터 파일에 저장되어있는 데이터를 보지 않고 디스크간에 데이터 파일을 배치하는 방법을 관리합니다. ASSM은 단일 세그먼트 내에 존재하는 빈 블록을 처리합니다(freelists 및 freelist 그룹을 대체합니다).
비트 맵 관리 블록 (BMB)을 통해 freelist-managed 또는 autospace-segment-managed인 세그먼트가 데이터 파일에 포함되어있어 ASM은 상관하지 않으므로 내부 구조의 변환은 일어나지 않습니다.
 
ASM 저장 영역을 사용하는 활성 RDBMS 인스턴스는 일반적인 데이터베이스 인스턴스처럼 작동 할 수 있습니다.
모든 파일 액세스는 최소한의 ASM 개입으로 직접 수행됩니다. 파일이 열리거나 작성되면 ASM 인스턴스는 RDBMS 인스턴스에 파일 레이아웃을 보내고 모든 후속 입력/출력(I/O)은 RDBMS 인스턴스에 저장된 범위 맵을 사용하여 수행됩니다.
모든 ASM 파일 액세스는 RDBMS 인스턴스와 유틸리티를 통해서만 수행 할 수 있습니다. 예를 들어 ASM 파일의 데이터베이스 백업은 RMAN에서만 수행 할 수 있습니다. UNIX dd 명령과 같은 유틸리티는 ASM 디스크 그룹을 백업하거나 복원하는 데 권장되지 않습니다.
데이터베이스 인스턴스는 파일 작성, 크기 조정, 삭제 또는 열 때 일반적으로 ASM 인스턴스와 상호 작용합니다. ASM과 RDBMS 인스턴스는 디스크 추가와 같은 스토리지 구성이 변경되거나 삭제되거나 실패 할 경우에도 상호 작용합니다.
사용자 관점에서, ASM 파일의 데이터베이스 파일 레벨 액세스(읽기/쓰기)는 비 ASM과 유사합니다. 단, 더하기 기호(+)로 시작하는 데이터베이스 파일 이름은 ASM을 사용하여 자동으로 처리되고 관리됩니다. 그러나 ASM 파일의 경우 데이터베이스 파일 액세스는 기본적으로 원시 장치(즉, KAIO(kernelized asynchronous I/O)로 버퍼되지 않은 직접 I/O)의 특징을 갖습니다. RDBMS 인스턴스가 원시 디바이스에 대해 I/O를 발행하기 때문에 네트워크 파일 시스템 (NFS) 볼륨이 ASM 디스크로 사용되지 않는 한 데이터베이스 매개 변수 FILESYSTEMIO_OPTION을 설정할 필요가 없습니다. 또한 ASYNCIO가 기본적으로 사용 가능하므로 ASM을 활용하기 위해 추가 매개 변수가 필요하지 않습니다.
사실, 데이터베이스 측면에서, ASM을 지원하기 위한 데이터베이스 init.ora 매개 변수는 필수적이지 않습니다.
 
Cloning ASM and Database Homes
Oracle Database 11g Release 2부터 ASM은 이제 Grid Infrastructure (GI) 스택의 일부가 되었으며 데이터베이스 소프트웨어 스택에 더 이상 포함되지 않습니다. 이 절에서는 RAC가 아닌 환경에서 ASM 및 데이터베이스 소프트웨어 스택을 복제하는 방법을 검토합니다.
ASM 소프트웨어 복제 프로세스를 시작하려면 소프트웨어 스택을 tar 또는 zip 명령을 사용하여 루트로 압축해야 합니다. 유닉스 사용자는 tar 명령을 이용하여 파일을 ssh 명령으로 리디렉션 할 수 있으므로 대상 서버에서 단일 명령으로 파일을 추출 할 수 있습니다.
다음은 /u01/app/oracle/product/11.2.0 디렉토리에서 루트로 활용할 수 있는 단일 명령의 예입니다.
 
$ tar cvf - grid | ssh target_host "cd /u01/app/oracle/product/11.2.0; tar xvf -"
 
Grid는 Grid Infrastructure HOME 소프트웨어 디렉토리입니다.
이 단일 명령은 모든 디렉토리의 전체 하위 디렉토리를 아카이브하고 대상 호스트에 내용을 복사 한 다음 추출하여 모든 권한을 보존합니다.
기호 링크가 보존되므로 tar 명령이 선호됩니다. 비 RAC 그리드 인프라스트럭처 홈의 골든 카피는 다른 서버에 복제되도록 유지되어야 합니다. 로그 파일을 포함하는 특정 디렉토리는 ASM 소프트웨어 스택의 골든 이미지 복사본을 설정하기 전에 정리할 수 있습니다.
일단 소프트웨어가 대상 서버에 복사되면 복제 프로세스를 시작할 수 있습니다.
GI 스택을 복제하려면 디렉토리를 $ORACLE_HOME/clone/bin 디렉토리로 변경하고 다음 옵션을 사용하여 Perl 복제 스크립트를 실행하십시오.
 
쉘 스크립트를 실행하면 다음과 같은 결과가 출력됩니다.
 
$asm - oracle: ksh clone_grid.txt
/runInstaller -clone -waitForCornpletion "ORACLE_BASE=/u01/app/oracle"
"ORACLE_HOME=/u01/app/oracle/product/11.2.0/grid"
"oracle_install_OSDBA=oinstall" "oracle_install_OSOPER=oinstall"
"ORACLE_HOME_NAME=Ora11g_gridinfrahome1"
"INVENTORY_LOCATION=/u01/app/oraInventory" -silent -noConfig -nowait
root로 orainstRoot.sh 스크립트를 실행하여 새 GI 홈을 /u01/app/oraInventory 하위 디렉토리에 있는 중앙 인벤토리에 등록하십시오. oraInventory의 위치는 /etc/oraInst.loc 파일의 내용을 검토하여 식별 할 수 있습니다. 
orainstaRoot.sh 스크립트를 실행하면 다음 결과가 생성됩니다.
 
viscosity01: /home/oracle/work
$asm - oracle: sudo /u01/app/oralnventory/orainstRoot.sh
Changing permissions of /u01/app/oralnventory.
Adding read, write permissions for group.
Removing read, write, execute permissions for world.
Changing group name of /u01/app/oralnventory to oinstall.
The execution of the script is complete.
viscosity01: /home/oracle/work
 
지시에 따라 root.sh 스크립트를 실행합니다. 복제 프로세스의 마지막 단계에서 Perl 스크립트를 다시 실행하여 roothas.pl 스크립트를 호출합니다.
이제 독립형 서버용 ASM을 사용하여 GI 스택을 성공적으로 구성했습니다. 다음 단계는 ASM 디스크 그룹을 작성하는 것입니다. ASM 디스크 그룹을 생성하는 방법에는 여러 가지가 있습니다. ASMCA(ASM Configuration Assistant) 및 SQL*Plus(create diskgroup 명령 사용)는 두 가지 옵션입니다. 이 장에서는 asmcmd mkdg 명령을 소개합니다.
서버가 ASMLIB로 구성된 경우 /etc/init.d/oracleasm listdisks 명령을 사용하여 ASMLIB 디스크 이름을 검색 할 수 있습니다.
간단히 "ORCL:"디스크 이름을 listdisks 명령에서 검색 후, ASMLIB 디스크 이름으로 바꿉니다. 샘플 DATA.xml 및 FRA.xml 파일의 내용은 다음과 같습니다.
 
명령 줄 모드에서 데이터베이스 만들기
이제 ASM 디스크 그룹이 생성되었으므로 다음 단계는 데이터베이스 소프트웨어 스택을 복제하는 것입니다.
데이터베이스 소프트웨어 복제 프로세스는 GI 스택과 유사합니다. 데이터베이스 소프트웨어 스택을 사용하여 clone.pl 스크립트를 실행하고 ORACLE_BASE, ORACLE_HOME, OSDBA_GROUP, OSOPER_GROUP, ORACLE_HOME_NAME 및 INVENTORY_LOCATION에 대해 다음 인수를 전달합니다. 효과적이고 신속한 Oracle GI 및 데이터베이스 소프트웨어 프로비저닝을 위해서는 표준화가 매우 중요합니다.
모든 DBA가 ORACLE_HOME, ORACLE_BASE 및 INVENTORY_LOCATION에 대해 동일한 디렉토리 구조로 표준화 된 경우 동일한 복제 스크립트를 사용하여 데이터베이스 홈 소프트웨어를 한 서버에서 다른 서버로 복제 할 수 있습니다. 며칠 또는 몇 주일이 아니라 몇 시간 만에 완전한 기능의 데이터베이스를 현실적으로 제공 할 수 있었습니다. GI 및 데이터베이스 소프트웨어 스택 복제의 가장 큰 장점은 데이터베이스 서버에서 X-Windows 또는 vncserver를 구성하거나 데스크톱의 X-Windows 클라이언트 또는 vncviewer를 처리 할 필요가 없다는 것입니다.
clone_db.txt 스크립트를 실행하면 다음과 같은 결과가 나타납니다. 지시에 따라 root.sh 스크립트를 실행합니다. root.sh 스크립트조차도 자동 모드로 실행됩니다. 최종 검토에서 제안된 로그 파일을 확인하여 root.sh의 내용을 보십시오.
우리는 GI 및 데이터베이스 소프트웨어 스택을 성공적으로 복제했습니다. 이제 마지막 단계는 데이터베이스를 만드는 것입니다.
물론 우리의 목표는 독립형 서버를 위한 DBCA를 사용하여 자동 모드로 데이터베이스를 작성하는 것입니다 (다음 섹션에서 데이터베이스 작성을 위한 다른 옵션을 검토합니다).
다음 예제에서는 300MB REDO 로그가 있는 DATA 디스크 그룹에 RMANPOC라는 데이터베이스를 생성합니다. 방금 지정한 옵션으로 자동 모드에서 dbca를 실행하면 다음과 같은 결과가 출력됩니다. dbca 출력에서 제안된 것처럼 추가 세부 사항은 로그 파일을 검토해야합니다.
RAC 데이터베이스의 경우 dbca 구문은 노드 목록 옵션에 RAC 클러스터의 모든 노드가 포함된다는 점을 제외하면 비슷합니다. 다음 예제는 절반의 RAC Exadata에서 DBFSPRD 데이터베이스를 생성하기 위해 작성되었습니다.
주의 사항: 템플릿 데이터베이스를 작성하지 않으면 자동 모드에서 dbca를 활용하는 아카이브로그 모드를 활성화 할 수 없습니다.
우리는 GI 및 데이터베이스 소프트웨어 스택을 위한 골든 이미지를 생성하는 것과 마찬가지로 모든 보안 정책, 올바른 리두 로그 크기 및 수, 대기 다시 실행 로그, 모니터링 스키마, 사용자 지정 이미지를 포함하는 골든 이미지 템플릿 데이터베이스를 생성해야 합니다 프로필, 사용자 지정 암호 관리 등이 있습니다.
모든 표준을 그대로 유지한 골든 이미지 데이터베이스를 구축 한 후 DBCA를 활용하여 새로운 이미지베이스 데이터베이스를 쉽게 만들 수 있는 골든 이미지 템플릿 데이터베이스를 만들 수 있습니다.
DBCA에서 골든 이미지 템플릿을 만들면 기본적으로 데이터베이스가 종료되고 데이터베이스의 콜드 백업이 수행됩니다.
골든 이미지 데이터베이스가 생성되면 새로운 데이터베이스가 모두 골든 이미지 데이터베이스에 통합된 모든 변경 사항을 자동으로 상속받습니다.
불행하게도, 골든 이미지 템플릿 데이터베이스를 만드는 것은 이 책의 범위를 벗어납니다.
자동 모드에서 DBCA 활용에 대한 고급 예제를 보려면 http://dbaexpert.com/blog 웹 사이트를 방문하십시오.
다른 방법으로 SQL*Plus를 사용하여 기존의 전통적인 모드로 데이터베이스를 생성 할 수 있습니다. 자동 옵션이 있는 DBCA가 있기 때문에 이 방법은 더 이상 권장되지 않는 옵션이지만, 자랑스러워하는 사용자 중 일부는 여전히 이 방법을 선호합니다.
SQL * Plus를 사용하여 데이터베이스를 생성하려면 다음 스크립트를 활용할 수 있습니다. 이 예에서는 DATA 디스크 그룹에 CLIDBA라는 데이터베이스를 생성합니다.
리두 로그는 구성원 당 300MB 크기의 DATA 및 FRA 디스크 그룹으로 다중화됩니다. 이 스크립트는 $ORACLE_BASE/admin/$ORACLE_SID 아래에 필요한 모든 디렉토리가 생성되고 초기화 매개 변수(또는 spfile)가 $ORACLE_HOME/dbs 아래에 이미 설정되어 있다고 가정합니다. 
데이터베이스를 생성 한 후 catalog.sql, catproc.sql, catexp.sql 및 catdbsyn.sql과 같은 표준 스크립트 집합을 실행합니다. DBCA를 사용하여 사용자 지정 데이터베이스를 만들면 이 방법과 비슷하게 데이터베이스가 만들어지며 이러한 스크립트는 백그라운드에서 실행됩니다.
 
Database Interaction with ASM
DBA는 주로 제품과 함께 제공되는 GUI 도구로 DBCA를 선택합니다.
앞의 예제에서 볼 수 있듯이 DBCA는 자동 모드 (비 그래픽 방식)로 호출 할 수도 있습니다.
GUI를 사용하여 데이터베이스를 생성하려면 디스플레이를 호출하기 위해 실행중인 일종의 X Server 또는 VNC 서버가 있어야합니다.
이것은 또한 putty 또는 SecrureCRT를 사용하여 X 패킷을 전달해야 함을 의미합니다.
이 절에서는 ASM 및 RAC와 관련된 DBCA의 주요 화면을 중점적으로 설명합니다.
RAC 구성은 하나의 데이터베이스와 두 개 이상의 인스턴스로 구성되기 때문에 RAC (Real Application Clusters) 데이터베이스의 작성은 일반적인 독립형 구성과 다릅니다.
과거에는 기억해야 할 단계가 거의 없었기 때문에 GUI를 선호했습니다.
DBCA를 사용하면 단계가 사전 정의되고 선택한 템플리트를 기반으로하며 데이터베이스 유형이 자동으로 작성, 크기 지정 및 구성됩니다. 그러나 스크립트 접근법은 사용자가 작성 프로세스 중에 발생하는 것을 볼 수 있고 프로세스를 실제로 모니터 할 수 있다는 점에서 GUI 접근법보다 이점이 있습니다.
이 옵션의 또 다른 장점은 엔터프라이즈의 필요에 따라 스크립트를 작성할 수 있다는 점입니다.
DBCA는 데이터베이스 작성을 도와줍니다. Optimal Flexible Architecture (OFA) 표준에 정의된 표준 명명 및 배치 규칙을 따릅니다.
DBCA는 Oracle 설치 프로세스의 일부로 자동으로 시작되거나 $ORACLE_HOME/bin 디렉토리에서 직접 dbca 명령을 실행하여 수동으로 시작할 수 있습니다.
이 화면에서 작성 될 데이터베이스의 유형이 선택됩니다.
이 화면에는 Oracle Real Application Clusters (RAC) 데이터베이스와 Oracle 단일 인스턴스 데이터베이스라는 두 가지 선택 항목이 있습니다.
그림 5-1은 DBCA 시작 화면을 보여줍니다. RAC One은 단일 노드의 RAC 데이터베이스입니다.
RAC One과 일반 RAC를 구성하는 데 필요한 단계는 동일합니다.
 
그림 5-1. DBCA의 시작 화면에서 데이터베이스 유형을 선택할 수 있습니다.
두 옵션 중 하나를 사용하는 데이터베이스 구성은 유사해야 합니다. 논의를 위해 RAC 옵션을 사용합니다. 따라서 Oracle Real Application Clusters (RAC) 데이터베이스 옵션을 선택하고 다음을 클릭하십시오.
 
노트
Oracle Real Application Clusters 데이터베이스 옵션은 Clusterware가 구성된 경우에만 볼 수 있습니다.
이 옵션이 이 화면에 표시되지 않으면 데이터베이스 관리자(DBA)는 구성 프로세스를 취소하고 진행하기 전에 Clusterware 및 ASM이 실행 중인지 확인해야합니다.
 
세 번째 화면은 클러스터에서 데이터베이스가 구성되는 방법을 정의합니다 (그림 5-2 참조).
이 예제에서는 클러스터 크기가 노드 3개이기 때문에 정책 관리 형을 통해 관리-관리를 선택합니다.
일반적으로 정책 관리 데이터베이스는 4개 이상의 노드로 가장 적합합니다. 이 동일한 화면에는 노드 선택 창이 있으며 RAC를 구성해야하는 적절한 노드가 선택됩니다. Oracle Universal Installer(OUI)는 필요한 파일을 클러스터에 참여하는 모든 노드에 복사하기 때문에 나열된 모든 노드를 선택하고 다음을 클릭하는 것이 좋습니다.
 
그림 5-2. DBCA의 데이터베이스 식별 화면
 
그림 5-3에 표시된 DBCA 6 단계에서 데이터베이스 파일 저장 위치 선택 항목이 나열됩니다.
11gR2 RAC의 경우 ASM 및 Clustered Filesystem (원시는 더 이상 지원되지 않음)의 두 가지 옵션 만 제공됩니다. ASM을 선택하고 Oracle-Managed Files 사용 옵션을 선택하고 기본 디스크 그룹 위치를 표시하십시오. 오라클 관리 파일은 7장에서 자세히 설명합니다.
 
그림 5-3. 데이터베이스 파일 위치 화면에서 설정 선택
그림 5-4에서 볼 수 있듯이 ASM이 저장 유형으로 선택되면 사용자가 ASMSNMP 암호를 지정해야하는 팝업 화면이 나타납니다.
 
그림 5-4. ASM Credentials 화면
Oracle Clusterware를 처음 설치하면 ASM 인스턴스가 생성 될 때 ASMS Configuration Assistant (ASMCA)에 의해 ASMSNMP 사용자가 생성됩니다.
이 프로세스 중 사용자에게 ASMSNMP 암호를 입력하도록 프롬프트가 표시됩니다. ASMSNMP는 주로 Oracle Enterprise Manager가 ASM 인스턴스를 모니터하는 데 사용됩니다.
이 계정에는 SYSDBA 특권이 부여됩니다. 그림 5-5에 표시된 다음 화면이 복구 구성 화면입니다.
이 화면에서 DBA는 빠른 복구 영역 (FRA)을 만들고 아카이브를 활성화 할 수 있는 옵션을 제공합니다. 클러스터에 참여하는 여러 노드 간에 복구 데이터를 손쉽게 공유하려면 이러한 영역이 공유 저장 장치에 있어야합니다. OUI에는 목록을 검색하여 적절한 위치를 선택할 수 있는 옵션이 있습니다.
 
그림 5-5. DBCA의 복구 구성 화면
보관 로그 파일과 FRA는 모두 동일한 유형의 저장소에 구성됩니다.
다음 몇 개의 화면 (DBCA 프로세스의 8-11 단계, 여기에 표시되지 않음)은 데이터베이스 구성 시 샘플 스키마를 작성하는 옵션을 제공하며 DBA가 메모리 할당과 같은 다양한 인스턴스 특정 정보를 선택할 수 있도록 합니다(예를 들어, 공유 풀 및 버퍼 캐시), 크기 조정(프로세스와 같은), 문자 모드(예: UTF8) 및 연결 방법(예: 전용)이 있습니다. DBA는 화면의 각 탭을 선택하여 이러한 매개 변수를 정의합니다.
마지막 화면에는 데이터베이스 생성 옵션이 표시됩니다. 이 화면에서 DBCA는 데이터베이스 작성 스크립트를 생성하거나 데이터베이스를 작성하는 옵션을 제공합니다.
DBA는 두 가지 옵션을 모두 선택할 수 있습니다. 이 경우 OUI가 스크립트를 생성 한 후 데이터베이스를 자동으로 생성합니다.
또는 사용자는 DBCA가 스크립트를 생성하고 수동으로 실행할 수 있도록 허용 할 수 있습니다.
데이터베이스 작성 선택 란이 선택되었는지 확인한 후 완료를 누르십시오. DBA가 마침 옵션을 선택하면 DBCA가 데이터베이스 생성을 시작합니다.
프로세스가 완료되면 새 데이터베이스와 필수 데이터베이스 인스턴스가 작성됩니다. 지정된 데이터베이스 구성을 기반으로 진행 화면에 설치 프로세스의 다양한 단계가 표시됩니다.
설치의 모든 단계가 완료되면 DBCA는 해당 노드에서 인스턴스를 시작합니다. 마지막으로, OCR은 ASM 디스크 그룹, ACFS 마운트 포인트 및 리스너와 같은 새로운 데이터베이스 정보 및 종속성으로 업데이트됩니다.
 
Disk Groups and Databases 
디스크 그룹은 여러 Oracle 데이터베이스의 파일을 포함 할 수 있습니다.
이 데이터베이스는 동일한 서버에 있거나 다른 서버에 상주 할 수 있습니다. 그러나 디스크와 데이터베이스 파일은 하나의 디스크 그룹에 속할 수 있습니다. 또한 하나의 Oracle Database는 동일한 ASM 인스턴스가 관리하는 여러 디스크 그룹에 파일을 저장할 수 있습니다.
여러 데이터베이스가 디스크 그룹을 공유하도록 허용하면 디스크 사용률이 향상되고 전체 처리량이 향상됩니다. ASM 및 해당 디스크 그룹 관리의 복잡성을 줄이려면 RAC 클러스터 당 두 개의 ASM 디스크 그룹을 유지 관리하는 것이 좋습니다.
정보 수명주기 관리(ILM) 또는 계층적 저장소 관리(HSM) 배포의 계층화 된 저장소 클래스를 지원하기 위해 추가 디스크 그룹을 추가 할 수 있습니다.
고객이 배포한 이 모델의 또 다른 변형은 세 번째 디스크 그룹을 만들어 임시 테이블 공간을 저장하는 데 사용하는 것입니다.
이러한 경우 임시 테이블 공간 디스크 그룹은 일반적으로 저렴한 스토리지에 있습니다. 두 개의 기본 디스크 그룹은 데이터베이스에 대해 다음 영역에 매핑됩니다.
데이터베이스 영역이 영역에는 증분 백업에 사용되는 데이터 파일, 제어 파일, 온라인 리두 로그 및 변경 내용 추적 파일과 같은 활성 데이터베이스 파일이 저장됩니다.
빠른 복구 영역 현재 제어 파일 및 온라인 리두 로그, 아카이브 된 리두 로그, 백업 세트 및 플래시백 로그 파일의 다중 사본과 같은 복구 관련 파일이 생성됩니다.
DBCA를 통해 데이터베이스를 생성 할 때 FRA를 선택하면 제어 파일의 활성 복사본과 리두 로그 그룹의 멤버 집합이 하나씩 저장되어 데이터베이스의 가용성이 향상됩니다.
제어 파일 또는 추가 로그 파일의 추가 복사본을 만들어 두 디스크 그룹에 둘 수 있습니다.
 
NOTE
다른 디스크 그룹에서 여러 제어 파일을 사용하는 경우 데이터베이스를 시작하기 전에 모든 디스크 그룹을 사용할 수 있어야합니다.
CRS가 유지 관리하는 데이터베이스와 ASM 디스크 그룹 간의 종속성은 필요한 모든 디스크 그룹이 올바르게 마운트 되었는지 확인합니다.
서버에 여러 RPO(복구 시점 목표)와 RTO(복구 시간 목표)가 서로 다른 여러 데이터베이스가 있는 경우는 어떻게 됩니까?
한 가지 해결책은 모든 데이터베이스 영역에 대해 하나의 큰 디스크 그룹을 만들고 각 데이터베이스에 대해 별도의 FRA를 만드는 것입니다.
이는 데이터베이스 증가가 포함될 수 있고 디스크 사용률이 중요한 환경에 적합합니다.
데이터베이스를 단일 DATA 디스크 그룹과 단일 FRA 디스크 그룹으로 함께 그룹화하는 것과 같은 다른 많은 대안이 있습니다.
여기에서 요점은 너무 많은 디스크 그룹을 만들거나 파일 시스템 환경을 모방하지 않는 것입니다.
이것은 결국 "저장 영역 풀의 섬"을 생성하게 되고 매우 관리하기 어려워집니다.
추가 시나리오는 여러 단일 인스턴스 데이터베이스가 클러스터 환경에서 ASM에 의해 관리되는 디스크 그룹을 공유하는 경우입니다. 이러한 상황에서 주요 목표는 데이터베이스 통합입니다.
 
 
Transportable Tablespaces and ASM
이 절에서는 원본 및 대상 데이터베이스가 ASM 기반인 TTS(전송 가능 테이블 공간)를 만드는 방법을 설명합니다.
이 방법은 Datapump 및 데이터베이스 패키지 DBMS_FILE_TRANSFER와 같은 표준 유틸리티를 사용합니다. 이 패키지는 Datapump 메타 데이터 및 데이터 파일을 원격 데이터베이스 서버로 전송하는데 사용됩니다.
완전을 위해, CONVERT DATABASE 명령은 마지막 서브 섹션에서 다룹니다.
우리는 이동 가능한 테이블 스페이스를 만들고 연결하는 작업 예제를 살펴볼 것입니다.
이 예제에서 두 개의 서버 (host1 및 host2)는 서로 다른 위치에 있으며 각각은 독립적인 Hitachi 스토리지 배열에 있습니다.
서버 host1은 원본 데이터베이스이며 db1이라는 데이터베이스를 저장합니다.
목표 서버로 간주되어 이동 가능한 테이블에 등록 할 서버 host2는 데이터베이스 SSKYDB를 저장합니다.
 
TTS 설정을 위한 예비 단계 수행
TTS를 설정하기 전에 다음 단계를 수행해야합니다.
 
1. 소스 데이터베이스에 두 개의 기존 테이블 공간을 작성하거나 사용하십시오.
모든 경우에 두 개의 테이블 공간을 가질 필요는 없지만 이 예제에서는 객체 종속성을 보여주기 위해 두 개의 테이블 공간이 필요합니다.
 
노트
OMF가 이 예제에서 사용되고 있으므로 init.ora 매개 변수 DB_CREATE_FILE_DEST를 적절한 디스크 그룹 이름으로 설정하십시오.
 
2. TTS_1에 테이블을 작성하고 TTS_2에 인덱스를 작성하여 테이블 공간에 오브젝트 종속성이 있는지 확인하십시오.
 
3. 스스로 운반 가능한 세트가 있는지 확인하십시오. 오라클은 이 점검에 도움이되는 PL/SQL 패키지를 제공합니다.
 
4. TRANSPORT_SET_VIOLATIONS 뷰를 쿼리하여 종속성 위반이 있는지 확인합니다.
 
5. 테이블 공간이 전송 될 대상 데이터베이스를 가리키는 새 서비스 이름 항목을 작성하십시오.
예를 들어, 다음 행을 tnsnames.ora에 추가하십시오.
 
6. SYSTEM으로 두 데이터베이스 사이에 데이터베이스 링크를 만듭니다.
이는 DBMS_FILE_TRANSFER 패키지를 사용하여 두 데이터베이스간에 메타 데이터를 이동하기 때문에 필요합니다.
 
7. 원본 데이터베이스 db1에 덤프 파일을 보관할 디렉토리 객체를 만듭니다.
우리가 ASM을 사용하기 때문에 이것은 ASM 객체여야합니다. 디렉토리 경로가 슬래시(/)로 끝나야 합니다.
 
8. 원본 데이터베이스에서 로그 파일의 운영 체제 경로를 가리키는 다른 디렉터리 개체를 만듭니다.
 
9. 원본 데이터베이스에서 데이터 파일을 가리키는 디렉터리 개체를 만듭니다.
 
10. 내보내기를 수행 할 사용자에게 읽기/쓰기 권한을 부여하십시오(비 권한 사용자를 사용하는 경우에만 이 단계를 수행하면 됩니다).
 
11. 대상 데이터베이스 SSKYDB에 대해서도 [7 - 10 단계를] 복하십시오.
 
12. 전송 가능 세트의 모든 테이블 공간을 읽기 전용으로 설정하십시오.
 
13. 소스 데이터베이스에서 테이블 공간의 상태를 점검하십시오.
 
14. 두 개의 테이블 공간에 대한 메타 데이터를 내보냅니다.
 
15. DBMS_FILE_TRANSFER를 사용하여 덤프 파일을 대상으로 보내십시오.
또는 asmcmd copy를 사용할 수도 있습니다.
 
16. 전송 중인 두 개의 테이블 공간에 대한 소스 데이터베이스의 파일 이름을 점검하십시오.
 
17. DBMS_FILE_TRANSFER를 사용하여 두 개의 데이터 파일을 대상 데이터베이스로 전송합니다.
 
18. host2 (대상 서버)에서 Datapump를 사용하여 데이터 파일 메타 데이터를 가져옵니다.
 
노트
TRANSPORT_DATAFILES 매개 변수의 경우 별칭 이름 (DBMS_FILE_TRANSFER의 파일 이름)을 사용하거나 
DBMS_FILE_TRANSFER (File_Transfer.xxxx.xxxxxx로 시작하는 이름)로 생성된 이름을 사용할 수 있습니다.
후자의 시스템 생성 이름을 판별하려면 cd +DATA/sskydb/datafile 다음에 ls -l 명령을 입력하여 asmcmd 행 도구를 사용하십시오.
19. 테이블 스페이스를 다시 읽기 / 쓰기 모드로 전환하십시오.
 
20. 데이터 파일이 성공적으로 연결되었는지 확인하십시오.
 
21. 데이터를 가져 왔는지 확인하려면 필요한 테이블을 선택하십시오.
Alert Log Monitoring
ASM 인스턴스 모니터링은 다른 데이터베이스와 다르지 않으며 경고 로그 파일을 면밀히 조사합니다. ASM 인스턴스 경고 로그 파일은
$DIAG_DEST/asm/+asm/+ASM1 인스턴스에 대한 ASM1/trace 디렉토리, +ASM2 인스턴스에 대한 $DIAG_DEST/asm/+asm/+ASM2/trace 디렉토리 등이 있습니다.
DIAG_DEST는 초기화 매개 변수로 정의되며 기본값은 $ORACLE_BASE입니다.
bash 또는 ksh 쉘의 다음 기능을 사용하면 디렉토리를 ASM 추적 디렉토리로 쉽게 변경할 수 있습니다.
이 함수는 현재 ORACLE_SID를 해석하고 현재 ORACLE_SID에 대한 추적 하위 디렉토리로 디렉토리를 변경합니다.
ASM이 아닌 ORACLE_SID의 경우 trace라는 단어를 입력하고 ENTER를 누릅니다.
$ DIAG_DEST 디렉토리의 trace 하위 디렉토리로 즉시 변경됩니다. ASM ORACLE_SID의 경우 다음과 같이 asm 매개 변수를 전달해야 합니다.
 
다음 Perl 스크립트를 사용하여 ASM 경고 로그를 모니터링 할 수 있습니다.
경고 로그 모니터링 스크립트의 전제는 alert_+ASM[i].log에 있는 모든 ORA 메시지를 캡처하는 것입니다. 여기서 i는 ASM 인스턴스 ORACLE_SID 번호를 나타냅니다.
효율성은 경보 로그 모니터링 스크립트의 핵심이므로 경보 로그 파일 끝에 마지막 행 번호를 캡처하여 저장합니다.
후속 검사는 마지막 저장된 회선 번호에서 시작하여 ORA- 메시지의 파일 끝까지 검사합니다.
파일의 끝에서 라인 번호가 다시 저장되어 다음 스캔의 시작점으로 사용됩니다.
전제 조건으로 $ORACLE_BASE/admin/$ORACLE_SID 디렉토리에 /u01/app/oracle/admin/+ASM/bdump라는 bdump를 작성해야 합니다.
또한 추적 디렉토리의 alert_+ASM[i].log를 가리키는 기호 링크를 bdump 디렉토리에 작성해야 합니다.
다음은 경고 로그 심볼 링크의 예입니다.
이 특정 예에서, 기호 링크는 alert_+ASM.log 파일을 가리키는 alert_+ASM.log(ASM 인스턴스 이름없이)로 작성됩니다.
우리는 cron 작업이 서버가 독립형 서버인지 또는 RAC 노드인지 여부에 관계없이 모든 데이터베이스 서버에서 동일 할 수 있도록 의도적으로이 작업을 수행합니다.
cron 작업의 모양은 다음과 같습니다.
alertlog.pl 파일에 나열된 SH_TOP은 Perl 스크립트가 실행되는 위치를 정의합니다.
SH_TOP 디렉터리 아래에 경고 로그의 마지막 줄 번호가 log 하위 디렉터리에 저장됩니다.
로그 서브 디렉토리는 경고 로그 파일 모니터링 구성의 일부로 작성되어야합니다.
어떤 이유로 인해 경고 로그 마이닝을 처음부터 시작하려는 경우 alert_+ASM.id 파일의 내용을 0으로 간단히 변경할 수 있습니다.
Perl 스크립트의 alert_notification_db.ksh 행은 mail 또는 mailx로 바꿀 수 있습니다.
이 예에서 경고 로그 파일에서 탐지 된 각 ORA 메시지는 향후 분석을 위해 Oracle 테이블에 업로드됩니다.
데이터베이스 경고 로그와 마찬가지로 ASM 경고 로그도 삭제 및 보관해야합니다. -s 옵션은 logrotate 유틸리티의 대체 상태 파일을 지정합니다.
oracle 또는 grid unix 계정이 logrotate를 실행하려면 기본 상태 파일이 /var/lib/logrotate.status이므로 -s 옵션을 지정해야 합니다.
일반적으로 root 계정만이 이 파일에 쓸 수 있습니다.
-f 옵션은 logrotate 유틸리티가 회전이 필요하다고 생각하지 않더라도 복수 옵션으로 파일을 회전시키는 강제 옵션을 지정합니다.
로그 회전 스크립트의 마지막 옵션은 다음을 지정할 수 있는 구성 파일을 나타내는 것입니다.
 
회전 할 로그 파일의 위치 및 로그 회전 옵션.
회전의 빈도
보관할 파일 수
압축 여부
로그 회전 스크립트를 처음 실행하면 이전 경고 로그가 압축되고 새 파일의 파일 크기가 0 바이트임을 알 수 있습니다.
===========================================================
Monitoring the ASM Disk Group
ASM 디스크 그룹은 네트워크의 모든 서버에서 원격으로 쉽게 모니터링 할 수 있습니다.
필요한 것은 SQL*Plus, 데이터베이스 액세스 및 V$ASM_DISKGROUP_STAT 사전보기에 대한 SELECT 권한뿐입니다.
이 절에 표시된 셸 스크립트와 모든 보조 스크립트는 http://viscosityna.com/asmbook/에서 다운로드 할 수 있습니다.
ASM 인스턴스에서 V$ASM_DISKGROUP_STAT를 쿼리하는 대신 기본 데이터베이스를 쿼리 할 수 있습니다.
대부분의 환경에서 단일 데이터베이스를 쿼리하여 서버에 대한 ASM 디스크 그룹 여유 공간 정보를 얻을 수 있어야합니다.
이 셸 스크립트는 두 개의 매개 변수를 허용합니다.
페이징 임계 값
TNSNAMES.ORA 파일에 나열된 TNS 별칭
여유 공간 임계 값이 TNSNAMES.ORA 파일의 TNS ALIAS로 지정된 데이터베이스 $ DB의 $ PAGER_THRESHOLD 매개 변수 아래로 떨어지면 스크립트가 경고를 보냅니다.
쉘 스크립트는 또한 RODBA 스키마(읽기 전용 DBA를 의미 함)로 데이터베이스에 로그인하고 데이터베이스에 대한 사전 권한을 선택합니다.
 
이 셸 스크립트는 alert_notification.ksh 셸 스크립트를 호출하여 모든 경고를 보내는 방식이 고유합니다.
alert_notification.ksh 쉘 스크립트는 mailx, wpostemsg와 통합 된 Tivoli 경고 및 opcmsg가있는 HP Openview 경고를 처리하도록 설정됩니다.
alert_notification.ksh 쉘 스크립트는 http://viscosityna.com/asmbook/에서도 다운로드 할 수 있습니다.
 
Issues DBAs Encounter with ASM
많은 DBA는 ASM 내부의 동일한 문제 세트로 고생하고 있습니다. 보통 파일 시스템 세계에서 이러한 문제가 발생하지 않기 때문입니다.
특히, DBA가 ASM 내부를 탐색하는 올바른 절차를 모르는 경우 몇 가지 별개 영역으로 인해 추가로 생산 중단이 발생할 수 있습니다.
우리는 이러한 공통적 인 문제를 표면에 적용하여 모든 사람이 쉽게 문제를 해결하고 불필요한 정전을 완화 할 수 있기를 바랍니다.
 
Spfile with an Incorrect Initialization Parameter
잘못된 초기화 매개 변수로 인해 인스턴스를 시작할 수없고 spfile이 ASM 안에 있으면 어떻게합니까?
nomount 데이타베이스를 시작할 수 조차 없을 것이다.
일반적으로 시스템 변경 명령을 실행하고 spfile에 변경 사항을 커밋하기 전에 항상 spfile의 백업을 pfile에 작성하십시오.
그러나 초기화 매개 변수에서 잘못된 구문으로 인해 데이터베이스 인스턴스를 가져올 수없는 상황에 처한 경우 환경을 ASM 인스턴스로 변경하고 pfile을 작성할 수 있습니다.
먼저 srvctl 명령을 사용하여 spfile의 위치를 확인하십시오. 그런 다음 ASM 인스턴스에서 asmcmd에서 spfile의 복사본을 만듭니다.
기본 Unix strings 명령을 호출하여 spfile의 내용을 텍스트 파일로 가져올 수 있습니다.
일부 줄이 겹치고 일부 줄이 잘릴 것이므로 파일을 수동으로 마사지해야합니다. 이 기회를 통해이 문제의 원인이 된 잘못된 초기화 매개 변수 항목을 수정할 수 있습니다.
황금 초기화 매개 변수를 얻으면 이전 spfile을 바꿀 수 있습니다. 먼저 기존 DATA_EXAD/prod/spfileprod.ora 파일을 사전에 제거 할 수 있습니다.
nomount 모드에서 데이터베이스 인스턴스를 시작하면 다음 구문을 사용하여 pfile에서 spfile을 생성 한 다음 데이터베이스를 다시 시작할 수 있습니다.
 
Archiver Is Stuck
아카이브 대상 (이 경우 FRA 디스크 그룹)이 100 % 사용률에 도달하면 어떻게합니까?
이제는 다음과 같은 두려운 Oracle 오류 메시지가 나타납니다.
DBA는이 메시지를보고 싶지 않습니다.
흔히 ASM FRA 디스크 그룹에서 공간을 사용했기 때문에가 아니라, 초기화 매개 변수 db_recovery_file_dest_size의 크기가 적절하지 않기 때문입니다.
db_recovery_file_dest_size 매개 변수를 상당히 높은 값으로 수정하여이 문제를 쉽게 해결할 수 있습니다.
예를 들어 다음과 같이 db_recovery_file_dest_size를 5TB로 설정할 수 있습니다.
그러나 FRA 디스크 그룹의 공간이 부족하여 100% 사용되면 상황을 벗어나기 위해 영웅을 수행해야하는 상황이 발생할 수 있습니다.
FRA 디스크 그룹이 100 % 가득 차면 다음 작업 중 하나를 수행해야합니다.
가능한 경우 오래된 보관 로그를 제거하십시오. 아카이브 로그를 백업하고 삭제하십시오.
새 디스크를 추가하여 FRA에 스토리지를 추가하십시오. 주어진 디스크 그룹에 스토리지를 추가하는 방법에 대한 자세한 내용은 4 장을 참조하십시오.
이전 아카이브 로그를 제거하려면 그리드 사용자로 asmcmd에 로그인하십시오. 종종 그리드 사용자는 오라클입니다. Exadata 세계에서 그리드 사용자는 오라클입니다.
그리드 사용자로 로그인 한 후 asmcmd 명령을 성공적으로 호출 할 수 있도록 환경을 제공하십시오.
환경을 소싱 한 후 asmcmd를 실행하십시오. asmcmd 내에서 디렉토리를 FRA 디렉토리로 변경하고 데이터베이스 이름 다음에 아카이브 로그 디렉토리를 변경하십시오.
 
The easiest way would be to remove the oldest directory. 
이 시나리오에서는 다음 명령을 사용하여 2012_09_19/, 2012_11_07/ 및 2012_11_08/ 하위 디렉토리를 안전하게 제거 할 수 있습니다.
공간이 부족하고 아카이브 로그를 제거하는 일이 없으면 먼저 아카이브 로그를 파일 시스템에 백업 한 다음 이전 백업을 제거 할 수 있습니다.
아카이브 로그를 백업하고 제거하는 가장 좋은 방법은 RMAN을 사용하여 다음 명령을 사용하는 것입니다.
이렇게하면 모든 보관 로그가 백업되고 삭제됩니다. 이 명령은 한 번에 다섯 개의 아카이브 로그를 백업하고 삭제하기 때문에 FRA에서 사용 가능한 공간을 즉시 알 수 있습니다.
또 다른 옵션은 단순히 RMAN에서 이전 아카이브 로그를 삭제하는 것입니다.
 
Moving the Control Files to ASM
DBA는 종종 제어 파일을 파일 시스템에서 ASM 디스크 그룹으로 이동하려고 애 쓰고 있습니다.
알고 있어야 할 첫 번째 점은 활동이 발생할 때 데이터베이스가 nomount 모드에 있어야한다는 것입니다.
둘째, ASM 디스크 그룹당 하나 이상의 제어 파일 사본이 있어야합니다.
일부 DBA는 종종 DATA 디스크 그룹에 세 개의 제어 파일을 만들고 FRA 디스크 그룹에 대한 제어 파일 복사본을 만드는 것을 잊어 버리는 실수를 범합니다.
DATA 디스크 그룹에 대해 세 개의 제어 파일을 만드는 대신 DATA 디스크 그룹에 하나의 제어 파일을 배치하고 FRA 디스크 그룹에 제어 파일의 두 번째 복사본을 배치하는 것이 좋습니다.
제어 파일을 ASM으로 이동하려면 다음 두 가지 중 하나를 수행하십시오. asmcmd cp 명령을 사용하여 파일 시스템에서 ASM 디스크 그룹으로 제어 파일을 복사하십시오.
RMAN을 사용하여 제어 파일을 ASM 디스크 그룹에 복원하십시오. 예비 단계로서 제어 파일을 파일 시스템에서 ASM 디스크 그룹으로 복원하십시오.
각 디스크 그룹에 restore 명령을 실행해야합니다. FRA 디스크 그룹 (이 예에서는 + dba_pf101)에 대해 복원 단계를 반복하십시오.
 
Oracle Database 11g Release 2부터는 RMAN restore 명령 대신 asmcmd 명령을 활용하고 파일 시스템에서 ASM 디스크 그룹으로 파일을 복사 (cp) 할 수 있습니다.
마지막 단계로 alter system 명령을 사용하여 ASM에서 control_files 초기화 매개 변수를 새 위치로 변경하십시오.
앞의 예제에서 우리는 RMAN 명령에서 제어 파일을 복원하고 대상 위치를 지정했습니다.
대신 CONTROL_FILES 초기화 매개 변수에서 제어 파일의 위치 대상을 수정할 수 있으며 다음 명령을 실행하기 만하면됩니다.
이 명령은 초기화 매개 변수에 지정된 모든 위치에 제어 파일을 복원합니다.
마지막 단계로, ASM에서 새 제어 파일을 사용하여 데이터베이스를 종료하고 다시 시작해야합니다.
Oracle Database 11g Release 2부터 제어 파일 백업 및 스냅 샷 제어 파일을 공유 스토리지에 위치시켜야합니다.
공유 스토리지는 ASM 디스크 그룹, NFS 또는 ACFS에있을 수 있습니다. RAC 구성에서 클러스터의 모든 인스턴스는 스냅 샷 제어 파일에 쓸 수 있습니다.
이러한 이유로 모든 인스턴스에서 스냅 샷 제어 파일을 볼 수 있어야합니다.
SQL * Plus / RMAN을 사용하여 제어 파일을 백업하는 동안 제어 파일의 자동 백업이 비공개로 구성된 경우 "ORA-00245 : 제어 파일 백업에 실패했습니다. 
대상이 로컬 파일 시스템에있을 가능성이 있습니다"오류가 발생합니다. 스냅 샷 제어 파일을 ASM 디스크 그룹으로 이동해야합니다.
 
또한 제어 파일을 공유 저장 영역에 백업해야합니다.
제어 파일을 FRA 디스크 그룹 (Exadata의 +RECO_EXAD)에 백업하려면 다음 명령을 실행하십시오.
백업 제어 파일의 이름에는 제어 파일 backup에 지정된 태그가 포함됩니다.
 
Use Cases for DBAs
이 절에서는 ASM 구성을 관리하는 DBA에게 다양한 유스 케이스 시나리오가 미치는 영향에 대해 설명하고 ASM이 등장 할 때의 특정 작업을 설명합니다.
ASM 디렉토리 구조에 대한 DB_UNIQUE_NAME의 영향 DB_UNIQUE_NAME은 ASM 디렉토리 구조에서 중요한 역할을합니다.
기본적으로 DB_NAME 및 DB_UNIQUE_NAME 초기화 매개 변수는 동일합니다.
DB_UNIQUE_NAME은 +DATA 및 +FRA 디스크 그룹 이름 뒤에 사용되는 디렉토리 이름을 나타냅니다.
다음 디렉토리 구조는 DB_UNIQUE_NAME 디렉토리 아래에 작성됩니다.
+DATA/DB_UNIQUE_NAME/datafile
+DATA/DB_UNIQUE_NAME/controlfile
+DATA/DB_UNIQUE_NAME/parameterfile
+DATA/DB_UNIQUE_NAME/onlinelog
+DATA/DB_UNIQUE_NAME/changetracking
+DATA/DB_UNIQUE_NAME/tempfile
+FRA/DB_UNIQUE_NAME/archivelog
+FRA/DB_UNIQUE_NAME/backupset
+FRA/DB_UNIQUE_NAME/controlfile
+FRA/DB_UNIQUE_NAME/onlinelog
 
그래서 당신이 묻습니다, 왜 이것이 중요한가요?
이렇게하면 기본 데이터베이스와 다른 디렉토리 구조로 실제 대기 데이터베이스를 작성할 수 있습니다.
DB_UNIQUE_NAME은 데이터베이스를 수동으로 복제 할 때도 중요한 역할을합니다.
PROD 데이터베이스를 QA에 복제하려는 경우 DB_NAME을 PROD로 유지하지만 RMAN 복원 프로세스 중에 DB_UNIQUE_NAME을 QA로 변경합니다.
데이터베이스 복원 및 복구가 완료되면 PROD 데이터베이스의 이름을 QA로 변경합니다.
이 시점에서 DB_NAME의 초기화 매개 변수를 DB_UNIQUE_NAME과 일치하도록 변경하고 제어 파일을 다시 작성합니다.
데이터베이스를 FRA 디스크 그룹에 백업 OK, 데이터베이스를 +FRA 디스크 그룹에 백업했습니다.
미디어 관리 계층 (MML)의 라이센스를 소유하고 있지 않으며 라이센스를 구입할 계획도 없습니다.
그럼 이제 어쩌지? 전체 데이터베이스 백업을 수행하기 위해 백업 스크립트를 검토해 보겠습니다.
RMAN 저장소에 질의하여 수행 된 백업에 대한 상위 레벨의 정보를 수집 할 수 있습니다.
전체 데이터베이스 백업의 태그를 이용하면 FULL_DB_BACKUP 백업 세트에 기본 키 946, 947, 948, 949 및 950이 포함되어 있음을 알 수 있습니다.
백업 세트의 기본 키를 사용하여 백업 세트를 파일 시스템에 백업 할 수 있습니다.
다음 명령을 사용하여 백업 세트 또는 이미지 사본의 사본을 백업 파일 시스템으로 수행 할 수 있습니다.
 
보다 바람직한 접근법은 태그를 다시 활용하여 백업 세트를 파일 시스템에 백업하는 것입니다.
이 장 전체에서 알 수 있듯이 RMAN 태그는 백업 및 복원 인프라를 지원하고 단순화하기 위해 많이 사용됩니다.
동일한 논리가 FRA 디스크 그룹에 적용되는 이미지 사본에도 적용됩니다.
FRA 디스크 그룹의 데이터베이스 이미지를 파일 시스템에 복사하려면 다음 RMAN 명령을 실행하십시오.
 
데이터 파일 및 리두 로그의 기본 위치 지정
db_create_file_dest 매개 변수는 데이터베이스 데이터/임시 파일이 상주하는 DATA 디스크 그룹으로 항상 설정되어야합니다.
테이블 스페이스를 생성하는 동안 데이터베이스 파일의 위치를 지정하거나 테이블 스페이스에 데이터 파일을 추가하는 대신 새로 생성 된 모든 데이터 파일의 기본 위치를 활용할 수 있습니다.
db_create_online_log_dest_1 및 db_create_online_log_dest_2 매개 변수는 리두 로그를 나타내며 중요한 역할을합니다.
다음은 조사중인 세 가지 초기화 매개 변수입니다.
db_create_file_dest 매개 변수가 설정되었으므로 간단한 명령을 실행하여 테이블 공간을 만들 수 있습니다.
위치 옵션이 지정되지 않았습니다. 자동으로 asm_default_test 테이블 공간은 DATA 디스크 그룹 (+DATA_EXAD)에 100MB 데이터 파일로 생성됩니다.
자동 확장 기능이 자동으로 활성화되므로이 새로 생성 된 데이터 파일은 약 32GB까지 자동 확장 될 수 있습니다.
 
테이블 스페이스에 데이터 파일을 추가하는 것은 결코 쉬운 일이 아닙니다. 다음 명령을 실행하면됩니다.
다시 100MB 데이터 파일이 db_create_file_dest 매개 변수에 지정된 위치에 만들어집니다.
대형 데이터베이스를 관리하는 다른 모든 사람들처럼 32GB 데이터 파일을 지정할 수 있기를 원합니다.
구문도 매우 간단합니다.
db_create_file_dest 매개 변수는 테이블 공간 생성/변경시 시간을 절약 할뿐만 아니라 테이블 공간 증가 프로세스 중에 잠재적인 fat-fingering을 완화 할 수 있습니다.
테이블 스페이스 증가 프로세스 중에 실수로 + 기호가 누락되면 새 데이터 파일은 다음과 같이 $ ORACLE_HOME/dbs 디렉토리에 위치합니다.
다른 RAC 인스턴스는 데이터 파일을 읽고 쓸 수 없기 때문에 새로 생성 된 데이터 파일에서 파울 플레이를보고합니다.
이 상황에서 벗어나려면 데이터 파일을 오프라인 상태로 만든 후에 RMAN 또는 asmcmd를 사용하여 파일 시스템의 데이터 파일을 다시 ASM으로 복사하십시오.
데이터 파일이 ASM으로 복사되면 데이터 파일을 복사하여 데이터 파일 복구를 시작하고 복사 할 수 있습니다.
데이터 파일 복구가 완료되면 프로덕션 사용을 위해 온라인으로 데이터 파일을 사용할 수 있습니다.
지금까지는 데이터 파일의 기본 위치를 다루었습니다.
db_create_online_log_dest_1과 db_create_online_dest_2의 두 매개 변수는 온라인 리두 로그의 기본 위치를 지정합니다.
RAC 인스턴스의 경우 250MB 크기의 다른 리두 로그 그룹을 만들 수 있습니다.
 
리두 로그가 +DATA_EXAD 및 +RECO_EXAD 디스크 그룹에 생성되면 v$logfile 및 v$log 뷰에 대한 쿼리를 실행하여 리두 로그 그룹의 위치를 검색 할 수 있습니다.
보시다시피, +DATA_EXAD 및 +RECO_EXAD 디스크 그룹에 리두 로그 그룹 30이 성공적으로 생성되었습니다.
리두 로그의 기본 위치는 RMAN으로 데이터베이스를 복제 할 때 매우 편리합니다.
"alter database open resetlogs"명령을 실행하면 모든 리두 로그가 db_create_online_log_dest_1 및 db_create_online_dest_2 디스크 그룹에 생성됩니다.
하나의 ASM 인스턴스에서 다른 ASM 인스턴스로 파일 복사 기본 데이터베이스에서 대기 데이터베이스로 아카이브 로그를 전송해야하는 경우 어떻게합니까?
주 데이터 센터의 기본 RAC 클러스터에서 재해 복구 데이터 센터의 물리적 대기 RAC 클러스터로 백업을 보내야하고 백업을 준비 할 파일 시스템이없는 경우 어떻게해야합니까?
Oracle Database 11g Release 1은 asmcmd cp 명령을 사용하여 ASM 디스크 그룹에서 다른 ASM 디스크 그룹으로 파일을 복사하는 기능을 제공합니다.
이 기술을 활용할 수는 있지만 대다수의 DBA에게는 표준 OS scp 명령을 사용하여 아카이브 백업을 소스에서 대상으로 복사하는 것이 더 쉬운 방법입니다.
오늘날 많은 기업들이 직면하는 고전적인 문제는 대기업이 수백 테라 바이트의 데이터베이스 또는 심지어 테라 바이트 급의 데이터베이스를 보유하고 있다는 것입니다.
분명히 멀티 테라 바이트 데이터베이스가 있다면 네트워크를 통해, 특히 WAN을 통해 복사 할 수 없습니다.
이 경우 테이프로 백업하고 백업을 복원합니다. MML (Media Management Layer) 라이센스를 소유 한 경우 직접 ASM으로 복원 할 수 있습니다.
그렇지 않은 경우 ASM Clustered File System (ACFS)은이 시나리오에서 중요한 역할을합니다.
로컬 파일 시스템이나 네트워크 파일 시스템과 마찬가지로 ACFS를 디스크 대 디스크 백업의 대상으로 사용할 수 있습니다.
시스템 관리자에게 ACFS 파일 시스템을 테이프로 스윕하도록 요청할 수 있습니다.
대상 Data Guard 서버에서 시스템 관리자는 주 데이터 센터에서 가져온 백업을 ACFS 또는 로컬 파일 시스템으로 복원 할 수 있습니다.
많은 회사들이 ASM 디스크 그룹에 여유 공간을 가지고 있습니다.
ASM 디스크 그룹에서 볼륨을 쉽게 조각 할 수 있으며 필요할 때 즉시 ACFS 파일 시스템을 생성 할 수 있습니다.
ACFS를 사용하면 필요한 공간에 맞게 ACFS 파일 시스템의 크기를 동적으로 조정할 수 있습니다.
대기업의 경우 테이프 백업을 수행하고 테이프를 수집하여 재해 복구 사이트에 보내고 테이프를 테이프 어레이에 추가하고 테이프 내용을 ACFS 파일 시스템에 복원하는 데 며칠이 소요될 수 있습니다.
이 기간 동안 기본 데이터 센터에서 재해 복구 데이터 센터로 보관 로그를 수동으로 보내야합니다.
프로세스를 단순화하기 위해 기본 데이터 센터 FRA ASM 디스크 그룹 (+ASM1 인스턴스)에서 재해 복구 사이트 FRA ASM 디스크 그룹 (+ASM1)으로 아카이브 로그를 보내려고합니다.
ACFS로 아카이브 로그의 RMAN 백업을 수행하고, 재해 복구 사이트의 ACFS 파일 시스템으로 아카이브 로그를 복사하고, 아카이브 로그를 복원하는 지루한 작업은 대부분의 DBA에게 부담이됩니다.
주 데이터 센터에서 재해 복구 데이터 센터로 아카이브 로그를 전송하는 데 훨씬 간단한 방법이 필요합니다.
asmcmd cp 명령을 사용하여 하나의 ASM 인스턴스에서 다른 ASM 인스턴스로 Oracle 관련 파일을 복사 할 수 있습니다.
복사 명령을 수행하는 구문은 다음과 같습니다.
아카이브 로그를 푸시하는 경우 아카이브 로그 파일을 마지막으로 푸시 한 후 생성 된 델타 아카이브 로그를 일별 또는 점차적으로 증분을 밀어 넣기를 원할 것입니다.
다음 스크립트는 정확히 수행합니다. 이 스크립트 예제에서 YYYY_MM_DD 형식을 사용하여 ARCH_DATE를 우리가 전송하려는 아카이브 로그의 실제 날짜로 대체하십시오.
push_passwd 변수는 dgmenu라는 사용자 계정의 암호를 나타냅니다.
SYS 계정을 사용하는 대신 ASM 인스턴스에 대해 적절한 sysasm 권한을 가진 dgmenu라는 사용자 계정을 생성했습니다.
이 결정의 논리는 아카이브 로그 전파 작업이 완료된 후 dgmenu 계정을 삭제하거나 비활성화하는 것입니다.
쉘 스크립트는 해당 날짜와 일치하는 아카이브 로그 이름의 목록을 포함하는 push_arch_asm.list.[i]라는 파일을 생성합니다.
다음 출력은 문제의 처음 세 가지 아카이브 로그만 나열합니다.
스크립트가 디렉터리 내용을 나열하여 푸시 할 보관 로그를 식별하면 나머지 구문을 작성합니다.
이 스크립트는 마지막 푸시 이후 아카이브 로그의 델타를 복사해야하는 요구 사항이 있으므로 현재 push_arch_asm.list 파일과 발견 된 최신 파일 사이에 diff를 수행합니다.
또한 sysasm 권한이있는 권한있는 사용자 계정의 암호는 스크립트에 하드 코딩되어 있음을 알 수 있습니다.
암호는 asmcmd cp 명령 실행 중에 다시 표시되지 않습니다.
아카이브 로그를 재난 복구 사이트로 보내기 시작하기 전에 ASM + FRA 디스크 그룹에 수동으로 디렉토리 구조를 작성해야합니다.
asmcmd 명령 프롬프트에서 cd를 + FRA로 누른 다음 mkdir ARCH; ARCH 디렉토리에서 mkdir PROD.
그러면 대상 ASM 인스턴스에 필요한 설정이 완료됩니다. 분명히 디렉토리 구조는 다를 수 있으며 환경에 따라 다를 수 있습니다.
앞의 쉘 스크립트의 출력을 캡쳐하고 출력을 다른 쉘 스크립트로 재지 정한 다음 백그라운드에서 끊지 않은 모드 (nohup)로 쉘 스크립트를 실행하십시오.
새 캡처 된 셸 스크립트를 실행하면 다음과 같은 결과가 출력됩니다.
아카이브 로그가 제공 될 때, +FRA/ARCH/PROD 디렉토리를 점검하고 du 명령을 실행하여 디렉토리의 공간 소비 증가를 볼 수 있습니다.
주의해야 할 중요한 점 중 하나는 의도적으로 대상 파일 이름을 완전히 한정하지 않는다는 것입니다. 고유성을 보장하기 위해 사용되는 file.incarnation 파일/화신 쌍을 제공 할 수 없습니다.
목표 파일 이름이 완전한 경우, ASMCMD-8016 오류가 발생합니다.
ASM 파일 이름이 단일 파일을 작성하는 데 사용할 수있는 단일 파일 작성 양식이 아니기 때문에 대상 파일 이름을 완전히 규정하면 cp 명령이 실패합니다.
파일 이름에는 파일 번호/화신이 포함되어서는 안됩니다. 언급 할 또 다른 중요한 정보는 대상 파일 이름이 시스템 생성 파일 이름을 사용하는 대신 별칭을 생성한다는 것입니다.
thread_2_seq_2455의 파일 이름 별명을 확인하십시오.
 
최소의 중단 시간으로 파일 시스템에서 ASM으로 마이그레이션하는 방법
몇 가지 똑똑한 기술을 사용하여 최소한의 중단 시간으로 파일 시스템에서 ASM으로 데이터베이스를 이동할 수 있습니다.
즉시 사용 가능한 솔루션 중 하나는 방정식에서 Data Guard를 활용하고 ASM에서 데이터베이스로 간단히 전환하는 것입니다.
또 다른 옵션은 영원히 증분 업데이트 된 RMAN 이미지 사본을 활용하는 것입니다.
이 절에서는 이미지 사본 백업에 대한 증분 업데이트를 수행하는 옵션에 대해 설명합니다.
우리가 실사를 수행하고 ASM 환경을 사전에 준비 할 수 있기 때문에 정전 시간을 크게 줄일 수 있습니다.
데이터베이스의 크기가 500GB, 5TB 또는 심지어 50TB 인 경우에도 중단 시간을 30 분 이내로 줄여서 가장 큰 데이터베이스를 이동시킬 수 있습니다.
Data Guard 방식을 사용하면 강제 로깅 모드에있는 데이터베이스에 대해 걱정해야합니다.
데이터베이스가 강제 로깅 모드에 있지 않으면 일괄 작업, 예약된 유지 관리 및 복구 할 수없는 모드 또는 nologging 모드로 실행되는 특정 작업을 조사하기 위해 개발 및 비즈니스로 돌아 가야합니다.
nologging 모드로 실행중인 작업을 확인하면 작업을 수정하거나 로깅 모드를 강제로 강제 실행할 수 없음을 알게됩니다.
반면에 Data Guard 옵션은 ASM의 저장소가 데이터베이스 작업 부하의 IOP 및 처리량 요구 사항을 충족시키지 못하면 파일 시스템으로 다시 전환 할 수 있기 때문에 추가적인 이점을 제공합니다.
ASM으로의 마이그레이션을 시작하려면 먼저 데이터 디스크 그룹에 대한 데이터베이스의 RMAN 이미지 사본을 수행해야합니다.
이 단계는 프로세스를 실행하는 데 가장 오래 걸리는 단계입니다. RMAN 이미지를 ASM에 복사하는 데 약 1TB의 시간이 소요될 것으로 예상됩니다.
성능을 고려하여 RMAN 채널 수를 6에서 8로 늘릴 수 있습니다. 데이터베이스의 RMAN 이미지 사본을 ASM으로 수행하려면 다음 명령을 실행하십시오.
 
백업을 식별하기 위해 구문에 "tag ="가 삽입되어 있습니다.
태그는 영원히 증분 업데이트 전략에 중요합니다.
사용자에게 친숙한 태그를 지정하지 않으면 RMAN은 자동으로 태그를 생성하고이를 백업에 할당합니다.
추가 할 또 다른 정보는 RMAN 이미지 복사본이 데이터베이스 파일의 정확한 복사본이라는 것입니다.
RMAN 이미지 사본의 크기는 데이터베이스의 크기와 동일합니다.
압축 된 RMAN 이미지 사본을 수행 할 수 없습니다.
RMAN 이미지 카피는 컷 오버 이전, 컷 오버 일 전 또는 컷 오버 이전의 밤까지 촬영할 수 있습니다.
소요 시간과 과정에 얼마나 편한지를 기준으로 결정해야합니다.
RMAN 이미지 카피를 컷 오버 날짜에 가깝게할수록 수행해야하는 증분 백업 및 업데이트가 줄어 듭니다.
레벨 0 이미지 사본을 성공적으로 수행하면 레벨 1 증가 백업을 수행 할 수 있습니다.
레벨 1 증가 백업에서 레벨 0 이미지 사본 백업을 복구하는 데 사용되도록 지정합니다.
또한 사용중인 태그에 특히주의하십시오.
태그는 레벨 0 이미지 사본 백업에서 지정한 태그와 같습니다. 백업 단순화를 위해 파일 시스템에 레벨 1 증가 백업을 배치합니다.
그런 다음 증분 업데이트를 수행합니다. 증분 업데이트는 실제로 데이터베이스 이미지 복사본을 복구하여 데이터베이스를 프로덕션 데이터베이스의 현재 상태로 만듭니다.
업데이트 프로세스가 완료되면 증분 백업을 다시 수행 할 수 있습니다.
이것이 우리가 반복 할 과정이며, 따라서 마케팅 용어는 "영원한 증분"입니다. 업데이트 이미지 복사 프로세스의 구문을 보자.
태그는 복구 프로세스에서도 다시 참조됩니다.
절단 시간까지 2 단계와 3 단계를 반복해야합니다. 또한 최소 2 ~ 3 단계를 가능한 한 많이 반복해야합니다.
컷 오버의 날에는 2 단계와 3 단계를 자주 반복해야합니다.
컷 오버 창 근처에서 데이터베이스 이미지 복사본에 대한 또 다른 증분 업데이트를 수행하려고합니다.
컷 오버시 데이터베이스를 종료하고 마운트 모드로 다시 가져 오려고합니다.
마지막 단계로 최종 증분 업데이트를 수행합니다.
이제 데이터베이스를 이미지 복사본으로 전환 할 준비가되었습니다.
구식 타이머는 각 데이터 파일의 원본에서 대상으로 데이터베이스 이름 바꾸기 파일을 변경하는 스크립트를 생성하는 데 시간을 소비합니다.
단일 switch database 명령을 사용하여 전체 데이터베이스의 데이터 파일 이름을 바꿀 수 있습니다.
우리는 거의 다 왔어.
ASM에서 데이터베이스가 완전히 일관성을 유지하고 데이터베이스를 열려면 recover database 명령을 실행해야합니다.
우리는 아직도해야 할 일이 있습니다.
우리는 여전히 리두 로그 (실제로는 새 그룹 작성 및 이전 그룹 삭제)를 ASM으로 이동하고, 제어 파일을 ASM으로 이동하고, spfile을 다음 위치로 이동해야합니다.
ASM으로 이동하고 임시 테이블 공간을 ASM으로 이동하십시오.
앞에서 설명한 단계 중 제어 파일 및 spfile 재배치 작업에 정전 창이 필요합니다.
데이터베이스가 온라인 인 동안 다른 모든 활동을 수행 할 수 있습니다.
컷 오버 주말 전에 리두 로그 활동을 수행하는 것이 좋습니다.
같은 논리가 임시 테이블 공간에 적용되어 ASM으로 이동합니다.
ASM과 파일 시스템간에 ping을 앞뒤로 핑핑 할 수 있기 때문에 컷 오버 주말 동안의 스트레스를 줄이고 미리이 두 가지 작업을 수행해야합니다.
Oracle은 하이브리드 ASM 및 파일 시스템 데이터베이스 배치 구성을 완벽하게 지원합니다.
재실행 로그와 임시 테이블 공간을 ASM으로 이동하는 요리 책 접근법은 이 장의 후속 절에서 사용 가능합니다.
 
임시 테이블 공간을 ASM으로 이동하는 방법
임시 테이블 공간도 파일 시스템에서 ASM으로 이동해야합니다. RMAN은 임시 테이블 스페이스를 백업하지 않습니다.
임시 테이블 공간을 ASM으로 이동하는 가장 쉬운 방법은 새 테이블 공간을 생성하고 모든 임시 데이터베이스 테이블 공간을 사용하도록 모든 데이터베이스 계정을 이동하는 것입니다.
임시 테이블 공간을 명시 적으로 지정하여 데이터베이스 계정을 만든 경우 새로 생성 된 임시 테이블 공간으로이 계정을 수정해야합니다.
다음 예에서는 시스템 계정의 기본 테이블 공간을 새 임시 테이블 공간으로 재배치합니다.
마지막 단계로 이전 임시 테이블 스페이스를 삭제해야합니다.
임시 테이블 공간의 삭제가 너무 오래 걸리면 V$SORT_USAGE 뷰에서 임시 테이블 공간의 사용자를 쿼리 할 수 있습니다.
또는 새로운 임시 파일을 ASM에 추가하고 이전 임시 파일을 삭제할 수 있습니다.
먼저 V$TEMPFILE 사전보기를 쿼리하여 파일 시스템에서 삭제할 임시 파일을 식별합니다.
이 예에서는 다른 임시 파일을 +DATA_EXAD 디스크 그룹에 추가하고 파일 시스템에 있던 이전 임시 파일을 삭제합니다.
 
How to Move the Spfile to ASM
spfile을 ASM으로 이동하는 것은 간단한 프로세스입니다. 최종 목표를 달성하기 위해 여러 기술을 활용할 수 있습니다.
pfile에서 spfile을 작성하고 ASM 내부에서 위치를 지정하거나, 마지막 백업에서 ASM으로 spfile을 복원하거나, asmcmd를 사용하여 spfile을 DATA 디스크 그룹에 복사 할 수 있습니다.
가장 쉬운 방법은 asmcmd를 활용하는 것입니다.
spfile을 파일 시스템에서 ASM으로 복사 한 후 새 위치를 반영하도록 OCR의 내용을 업데이트해야합니다.
사전 예방 조치로 데이터베이스를 종료했다가 다시 시작하여 ASM 내부의 spfile로 데이터베이스를 다시 시작할 수 있습니다.
일반적으로 spfile을 만지기 전에 파일 시스템에 백업 pfile을 작성하는 것이 좋습니다.
하나의 디스크 그룹에서 다른 디스크 그룹으로 테이블 스페이스를 이동하는 방법 한 테이블 그룹이나 다른 그룹으로 테이블 스페이스 또는 데이터 파일을 이동해야하는 경우가 종종 있습니다.
기존 디스크 그룹의 공간이 부족하거나 기존 디스크 그룹이 데이터베이스 작업 부하에 필요한 IOP 및 처리량 수준을 제공하지 않습니다.
한 디스크 그룹에서 다른 디스크 그룹으로 테이블 스페이스를 이동하려면 테이블 스페이스를 오프라인으로 설정하고 한 디스크 그룹의 데이터 파일을 
다른 디스크 그룹으로 복사하고 테이블 스페이스의 데이터 파일 이름을 바꾸고 테이블 스페이스를 다시 온라인으로 가져와야합니다.
대형 테이블 공간의 경우 한 디스크 그룹에서 다른 디스크 그룹으로 데이터 파일을 복사하는 데 필요한 가동 중지 시간은 몇 시간에서 며칠이 걸릴 수 있습니다.
방정식에 테이블 공간 복구를 도입하여 가동 중지 시간을 줄일 수 있습니다.
한 디스크 그룹에서 다른 디스크 그룹으로 테이블 스페이스를 복사하고, 테이블 스페이스에 대한 데이터 파일의 이름을 바꿀 수 있으며, 
최종 단계에서 시스템 변경 번호 (SCN)를 전달하여 데이터베이스와 일치하도록 테이블 스페이스를 복구합니다.
작은 테이블 스페이스의 경우에도이 방법은 가동 중지 시간이 최소화되기 때문에 완벽하게 수용 할 수 있습니다.
최종 복구 단계를 수행하기위한 중단 시간은 반나절 또는 하루 종일 데이터베이스 작업을 롤 포워드하는 것과 관련하여 과도 할 수 있습니다.
특히 RAC 분야에서 일하는 ASM과 함께 일하는 DBA는 우리가하는 모든 일에 고 가용성 및 최소 다운 타임을 염두에 두어야합니다.
다운 타임을 최소화하면서 테이블 스페이스를 이동하려면 다운 타임을 줄이기 위해 증분 백업을 도입해야합니다.
테스트 케이스에서는 r1.sql, r2.rman, r3.rman 및 rf.rman의 4 가지 스크립트 세트를 노출합니다. 단계는 다음과 같습니다.
1. r1.rman은 테이블 공간의 이미지 사본을 수행합니다.
2. r2.rman은 테이블 공간에 대한 증가 백업을 수행합니다.
3. r3.rman은 새 디스크 그룹의 새 테이블 공간에서 증분 업데이트 (복구)를 수행합니다.
우리는 rf.rman에 필요한 다운 타임을 줄이기 위해 필요한만큼 r2.rman 및 r3.rman 단계를 수행 할 수 있습니다.
4. RMAN final을 나타내는 rf.rman은 테이블 스페이스를 오프라인으로 전환하고 복사 할 테이블 스페이스를 전환하고 새 디스크 그룹에서 
새 테이블 스페이스를 복구하고 테이블 스페이스를 다시 온라인으로 가져 오는 마지막 단계를 실행합니다.
r1.rman 스크립트에서 ck라는 테이블 스페이스를 DATA 디스크 그룹의 이미지 사본으로 RECO 디스크 그룹에 복사하기 만하면됩니다.
두 번째 단계로 테이블 공간에 대한 증분 백업을 수행합니다.
테스트 케이스에서는 /u01에있는 파일 시스템에 대한 증분 백업을 수행합니다.
bkups 서브 디렉토리는 NFS 마운트 포인트를 가리키는 기호 링크입니다.
또는 ASM 디스크 그룹에 백업을 수행 할 수 있습니다.
 
세 번째 단계로 새 디스크 그룹의 새로운 ck 테이블 스페이스에 대한 증분 업데이트를 수행합니다.
태그는 증분 업데이트를 수행하는 데 유용합니다.
새로 복사 된 테이블 공간을 최대한 최신 상태로 유지하는 데 필요한만큼 r2.rman 및 r3.rman 단계를 반복 할 수 있습니다.
간단한 정전 시간을 얻을 수 있거나 테이블 스페이스를 멈출 수있을 때 rf.rman 최종 단계를 수행 할 수 있습니다.
다음 단계에서 마지막 단계는 테이블 스페이스를 오프라인으로 전환하고, 복구중인 사본 이미지로 테이블 스페이스를 전환하고, 새 테이블 스페이스를 복구하고, 새로운 디스크 그룹의 온라인으로 새 테이블 스페이스를 가져옵니다.
rf.rman 최종 단계를 실행하면 다음과 같은 결과가 출력됩니다.
 
rf.rman을 마지막 단계로 실행하면 테이블 공간이 이제 새 디스크 그룹에서 실행 중입니다.
동일한 기술을 활용하여 다음 작업을 수행 할 수 있습니다.
하나의 ASM 디스크 그룹에서 다른 디스크 그룹으로 데이터 파일 이동
파일 시스템에서 ASM 디스크 그룹으로 테이블 스페이스 이동
파일 시스템에서 ASM 디스크 그룹으로 데이터 파일 이동
 
Create Multiplexed Redo Logs
때때로 DBA는 최적의 성능을 위해 리두 로그의 크기를 조정해야합니다.
온라인 리두 로그 파일의 크기는 데이터베이스에서 생성하는 재실행의 양에 따라 달라집니다.
일반적으로 20 분마다 한 번 이상 로그 스위치가 표시되지 않아야합니다.
과도한 리두 로그 스위치 (한 시간에 3 ~ 4 개 이상)가있는 경우 새 리두 그룹을 작성하고 이전 리두 그룹을 삭제해야합니다.
안타깝게도 온라인 리두 로그의 크기는 조정할 수 없습니다. 수백 메가 바이트에서 수 기가 바이트 범위의 재실행 로그를 보는 것이 합리적입니다.
새로운 재실행 로그를 작성하려면 alter database add logfile 명령을 사용하십시오.
가장 좋은 방법은 재실행 로그 그룹을 DATA 및 FRA 디스크 그룹의 한 구성원과 다중화해야합니다. 우리는 최소한 각 스레드에 대해 적어도 네 개의 그룹을 가져야합니다.
대기 재실행 로그 (SRL)의 경우,이를 다중화 할 필요가 없습니다.
전체 데이터베이스에 대한 총 재실행 그룹 수보다 하나의 SRL 만 있으면됩니다.
가능한 한 가장 빠른 디스크 그룹에 SRL을 만들어야합니다. 특정 스레드에 속할 필요는 없습니다.
SRL은 기본 및 대기 데이터베이스 모두에서 작성되어야합니다.
가장 좋은 방법으로, SRL은 Data Guard 인스턴스화 프로세스보다 먼저 기본 데이터베이스에 작성되어야합니다.
SRL은 자동으로 물리적 스탠바이로 복사됩니다.
SRL을 만드는 구문은 다음과 같습니다.
기존 리두 로그 그룹을 삭제하는 것은 약간 더 까다 롭습니다.
삭제하려는 리두 그룹이 현재 또는 활성 상태가 아닌지 확인해야합니다.
활성 상태가 아닌 경우 다음 명령을 사용하여 리두 로그 그룹을 삭제할 수 있습니다.
리두 로그간에 전환하려면 다음 세 명령 중 하나를 활용하는 것이 좋습니다.
 
Summary
ASM은 오라클 (Oracle Corporation)의 스토리지 관리 솔루션으로 스토리지 관리 레이어를보다 적합하고 유연하게 만들어줍니다.
이 장에서는이 기술에 대해 논의했고 ASM 스토리지 관리 솔루션이 시장에서 사용 가능한 다른 솔루션과 어떻게 다른지 ASM이 RAC를 보완하는 방법을 배웠습니다.
이 장에서는 유지 보수 관리 및 성능 모니터링을 통한 기본 설치 및 구성부터 RDBMS 인스턴스와 함께 ASM을 사용하는 방법에 대해 설명했습니다.
DBCA를 사용하여 RDBMS 인스턴스를 구성하는 동안 데이터 용과 FRA 용의 두 가지 디스크 그룹을 사용하는 것이 가장 좋습니다.
데이터베이스가 클러스터 솔루션인지 또는 단일 인스턴스인지에 관계없이 ASM의 구성 및 배포는 다르지 않습니다.
데이터를 ASM이 아닌 Oracle 데이터베이스에서 ASM으로 마이그레이션 할 수 있는 다양한 방법에 대해 설명했습니다.
마지막으로 모니터링 옵션을 살펴 보았습니다.