DBMS 1
DA, SQL, DB보안 등 실무자를 위한 위한 DB기술 바이블!
최근 들어, 데이터베이스 백업 툴로써의 RMAN의 잠재력이 새롭게 인정받고 있습니다. RMAN이 데이터를 디스크 또는 테이프에 직접 백업하는 기능을 지원한다는 사실을 이미 알고 계실 것니다. 테이프 솔루션이 사용되는 경우, RMAN은 Media Management Library (MML)라는 이름의 API를 통해 테이프 서브시스템을 제어합니다. MML은 테이프 관리 시스템 및 하드웨어 별로 구현됩니다. (예를 들어, Tivoli Storage Manager가 사용되는 환경에서 RMAN이 Tivoli를 통해 테이프를 관리하도록 하려면 해당되는 MMLTivoli Data Protector을 사용해야만 합니다.) RMAN은 데이터베이스 엔진 내부에 구현되는 반면, MML은 써드 파티를 통해 지원되며 그 가격 또한 만만치 않습니다. 단지 오라클 데이터베이스를 백업하는 것이 목적이라면, 굳이 MML에 추가적인 비용을 들여야 하는지 고민해 볼 필요가 있습니다. Oracle Database 10g Release 2에 추가된 Oracle Secure Backup (OSB)은 기존에 써드 파티를 통해 제공되던 MML을 대체하는 효과를 제공합니다. OSB를 이용하면 테이프 라이브러리에 직접 백업을 수행할 수 있으며, 따라서 별도의 미디어 관리 계층(media management layer)을 사용할 필요가 없습니다. 그 뿐 아니라, OSB는 데이터베이스 엔진과 긴밀하게 통합되어 있으며 Oracle Enterprise Manager를 통해 관리할 수 있다는 장점이 있습니다. 하지만 데이터베이스 외부의 파일들, 예를 들어 Oracle Home 디렉토리, 초기화 파일, (RAC의 경우) Cluster Registry 파일 등은 어떻게 백업할 수 있을까요 이 파일들을 위해서라도 별도의 백업 툴이 필요하지는 않을까요 그렇지 않습니다. OSB는 다른 스탠드얼론 툴과 동일한 파일시스템 백업 기능을 제공합니다. RMAN 백업에서 MML을 사용할 필요가 없다는 것, 파일시스템의 백업이 가능하다는 것은 매우 중요한 장점이며, 보다 저렴하고 단순한 백업/복구 환경의 구현을 가능하게 합니다. Oracle Enterprise Manager에서 MML 컴포넌트를 이용하는 방법이 다음과 같습니다. 먼저, Oracle Enterprise Manager GUI에서 Maintenance 탭을 선택합니다: Oracle Backup Administrative 소프트웨어는 별도의 호스트에서 실행 가능합니다. 이 경우, 데이터베이스 서버에는 에이전트가 설치됩니다. 여기에서는, Administrative 소프트웨어가 proliback.proligence.com 서버에 설치되었고, Oracle Backup 소프트웨어가 /bin/obt 디렉토리에 설치된 것으로 가정합니다. 대부분의 DBA들은 커맨드라인 환경에서 스크립트를 통해 작업하는 것을 선호합니다. OSB는 obtool이라는 커맨드라인 툴을 제공합니다. 위와 같이 명령을 실행하면 OSB 프롬프트(ob>)가 표시됩니다. “help”를 입력하면 사용 가능한 명령의 도움말을 볼 수 있습니다. 또 커맨드 뒤에 “glossary” 키워드를 삽입하면 명령에 대한 보다 자세한 설명이 표시됩니다: Oracle Home을 백업하려면 다음과 같이 실행합니다: 첫 번째 매개변수(level)는 백업 레벨을 지정하는 용도로 사용됩니다. 여기에서는 증분 백업(incremental backup)을 사용하고, 마지막으로 증분 백업이 수행된 시점 이후의 변경 데이터만을 백업하도록 지정하였습니다. 두 번째 매개변수(at)는 백업이 실행되는 시간을 지정하기 위해 사용합니다 (여기에서는 2005년 3월 29일 오전 9시에 실행하도록 하였습니다.) 여러 개의 백업 작업이 존재하는 경우에는 그 실행 순서를 어떻게 지정해야 할까요 실행 순서는 priority 옵션에 의해 정의되며, 여기서는 가장 높은 우선순위(“1”)로 설정되었습니다. 우선순위는 최저 100까지 설정 가능합니다. 또 백업 유형에 따라 여러 가지 미디어 풀(media pool)을 정의할 수 있습니다. 예를 들어, 데이터 파일 백업을 위한 미디어 풀, 아카이브 로그를 위한 미디어 풀, 그리고 일반 파일 백업을 위한 미디어 풀 등을 정의하는 것이 가능합니다. 여기에서는, 이 백업을 위해 Pool1이라는 이름의 미디어 풀을 사용하도록 지정하였습니다. dataset 매개변수는 백업 대상이 되는 파일을 지정하기 위해 사용합니다. 마지막으로 expirerequest 매개변수는 백업의 보존기한이 만료되는 시점을 정의합니다. 여기에서는 7일 이후 보존기한이 만료되는 것으로 지정하였습니다. 필자는 여기에서 새로운 Oracle Secure Backup 툴을 매우 간략하게 소개하였습니다. 이 툴을 제대로 설명하려면 책 한 권의 분량이 필요할 것입니다. OSB에 대한 자세한 정보는 제품문서를 참고하시기 바랍니다. 여러분과 마찬가지로, 필자 역시 Oracle8에서 처음 소개된 RMAN의 매력에 깊이 빠져 있습니다. 하지만, RMAN의 실행 내역을 제대로 이해하고 있다고 생각했던 적은 단 한 번도 없었습니다. Oracle Database 10g Release 2에 추가된 새로운 다이내믹 뷰를 이용하면, 과거 또는 현재의있습니다. V$RMAN_BACKUP_JOB_DETAILS 뷰는 백업 히스토리 정보를랜는 아래와 같습니다: SESSION KEY 컬럼은 다른 뷰의 관련 정보를 참조하기 위한 키로써 활용됩니다. START_TIME 컬럼과 END_TIME 컬럼은 별다른 설명이 필요 없어 보입니다. ELAPSED_SECONDS 컬럼은 작업에 소요된 시간을 초 단위로 표시합니다 (여기에서는 이해가 쉽도록 시간 단위 포맷으로 변환하였습니다). STATUS 컬럼은 RMAN 작업의 상태를 의미합니다. 작업이 현재 진행 중인 경우, STATUS 컬럼은 “RUNNING”으로 표시됩니다. 백업이 얼마나 빠른 속도로 진행되었는지, 읽기/쓰기 속도는 얼마나 되었는지 확인하는 것도 중요할 것입니다. 위에서 시간이 “hours:minutes:seconds” 포맷으로 표시되고 있음에 주목하시기 바랍니다. INS 컬럼과 OUTS 컬럼은 초당 데이터 입력/출력을 의미합니다. 여기에서도 읽기 쉬운 포맷이 사용되었습니다 (M은 메가바이트를 의미합니다). 위 예제에서, SESSION_KEY가 4인 작업의 읽기 속도가 6.92MB/s, 5.2MB/s였음을 확인할 수 있습니다. 여러 개의 RMAN 실행 결과를 종합해서 분석하면 일정한 패턴을 도출하는 것이 가능합니다. 이러한 패턴 분석을 이용하면 잠재적인 성능 병목을 쉽게 진단해 낼 수 있습니다. 백업 정보를 백업 유형을 기준으로 필터링할 수도 있습니다. V$RMAN_BACKUP_TYPE 뷰는 RMAN이 수행하는 백업 작업의 유형에 대한 정보를 포함하고 있습니다. weight 오브젝트 타입은 뷰의 정렬 방식을 결정하는데 사용됩니다. 그 밖에 유용한 뷰로 V$RMAN_OUTPUT이 있습니다. 셸 스크립트를 통해 RMAN 작업을 실행했는데 실패한 경우를 생각해 봅시다. RMAN이 출력한 결과를 저장한 파일을 그만 잃어버리고 말았습니다. 어떻게 해야 할까요 V$RMAN_OUTPUT 뷰는 RMAN 작업의 실행 결과를 저장하는 용도로 활용됩니다. 이 뷰는 스크립트 기반의 RMAN 작업 뿐 아니라, 사용자가 임의로 수행한 작업의 결과를 조회하는 용도로도 활용 가능합니다. V$RMAN_OUTPUT 뷰에 RMAN 작업이 반환한 결과가 모두 캡처되어 있음을 확인할 수 있습니다. V$RMAN_OUTPUT은 인-메모리 뷰(in-memory view)이기 때문에 인스턴스가 셧다운될 때 삭제됩니다. RMAN 실행 결과를 영구적으로 저장하고 싶다면, V$RMAN_OUTPUT 뷰의 레코드를 다른 테이블에 복사하면 됩니다. SESSION_KEY 컬럼은 V$RMAN_BACKUP_JOB_DETAILS 뷰의 SESSION_KEY 컬럼과 연계되어 있습니다. 따라서 RMAN 작업의 실행 결과가 또다시 삭제되어 버리지 않을까 걱정할 필요가 없습니다. Oracle Enterprise Manager에서 이 새로운 뷰를 이용하여 백업 리포트를 생성하고, 기업 전체의 백업 작업에 대한 개요 보고서를 작성할 수 있습니다. 리포트의 데이터는 백업 유형 또는 상태를 기준으로 필터링이 가능합니다. Oracle RAC 환경에서는 하나 이상의 데이터베이스 인스턴스가 하나 이상의 호스트에서 실행됩니다. 하지만 Oracle RAC 환경에서 RMAN 작업을 실행할 때에는, 단 하나의 인스턴스에만 연결할 수 있습니다 (“TARGET=/”). 따라서 특정 노드에서 작업이 수행되는 동안, 다른 노드는 유휴 상태로 머물게 됩니다. Oracle Database 10g Release 2 이전 버전에서 양쪽 노드에 동시 작업을 수행하기 위해서는, 여러 개의 인스턴스를 연결하는 멀티 채널을 구성해야 했습니다. 이를 위한 RMAN 커맨드가 아래와 같습니다: 이 커맨드는 두 개의 인스턴스(inst1과 inst2)만이 존재하는 경우를 가정하고 있습니다. 하지만, 이와 같은 환경에서는 노드 중 하나에 장애가 발생한 경우 대처할 방법이 없다는 문제가 있습니다. 따라서 특정 노드에 장애가 발생하면 전체 RMAN 작업이 실패하게 되며, 진정한 의미의 로드 밸런싱 구성으로 보기 어렵습니다. Oracle Database 10g Release 2에서는 백업을 수행하기 위해 각 RAC 노드에 별도의 채널을 명시적으로 할당할 필요가 없어졌습니다. 단지 백업 작업을 위한 “degree of parallelism”을 정의하기만 하면, RMAN이 자동적으로 병렬 스트림을 생성하고, 가장 부하가 적은 인스턴스에 연결합니다. 또 로드 밸런싱과 함께 채널 페일오버 기능이 제공되므로, 특정 인스턴스에 장애가 발생하는 경우 다른 노드로 페일오버가 가능합니다. 이와 같은 새로운 기능 덕분에 RMAN 프로세스의 안정성은 더욱 개선되었습니다. RMAN 백업으로부터 데이터베이스를 복구할 때, 가장 먼저 임시 테이블스페이스 파일을 재생성하는 작업을 수행하게 됩니다. 임시 테이블스페이스에는 영구적으로 저장되어야 할 오브젝트가 존재하지 않기 때문에, RMAN은 임시 테이블스페이스를 복제하지 않습니다. 하지만 오라클 데이터베이스가 효과적으로 동작하려면 임시 테이블스페이스가 반드시 필요한 것은 사실입니다. 그렇다면 RMAN이 임시 테이블스페이스까지 함께 복구하도록 하는 것이 더 바람직하지 않을까요 Oracle Database 10g Release 2에서는 바로 이러한 기능이 추가되었습니다. 데이터베이스를 복구하는 과정에서 임시 테이블스페이스 파일이 자동으로 재생성되는 것입니다. 로그 파일을 통해 확인한 복구 과정이 아래와 같습니다: Oracle Database 10g에서 처음 소개된 Flashback Database는 플래시백 로그에 저장된 변경 내역에 대한 “undo” 처리를 통해 전체 데이터베이스를 롤백(roll-back)할 수 있는 기능을 제공합니다. 하지만 다음과 같은 시나리오를 생각해 봅시다: RESETLOGS 옵션으로 데이터베이스를 오픈한 경우, SCN 넘버를 1로 설정한 상태에서 데이터베이스가 시작됩니다. 따라서 새로운 컨트롤파일은 과거에 업데이트된 SCN 넘버에 대해 아무런 정보를 가지고 있지 않습니다. Flashback Database는 SCN 넘버를 필작할 수 있을까요 Oracle Database 10g Release 2에서는 정상 동작합니다. 데이터베이스는 이전 데이터베이스의 “incarnation”을 컨트롤파일에 저장하고 적극적으로 활용, 이전의 incarnation을 쿼리하고 그 결과를 이용해서 이전의 데이터베이스 상태로 플래시백 처리하는 것이겠습니다. 먼저, account number가 3인 계정 보유자의 이름을 조회해 봅시다. 이제 이름을 업데이트합니다: 그런 다음 데이터베이스를 삭제하고, 백업으로부터 다시 복구한 뒤, RESETLOGS 옵션으로 복구된 데이터베이스를 오픈합니다. 그로부터 얼마 되지 않아, 누군가가 RESETLOGS 작업이 수행되기 이전의 시점으로 데이터베이스를 복구해 달라는 요청을 한다고 가정해 봅시다. 이러한 경우 아래와 같이 간단한 명령만 실행하면 됩니다. 데이터베이스는 RESETLOGS 작업이 수행되기 바로 전의 SCN 상태로 돌아갔습니다. 명령을 실행한 후 다시 테이블을 확인해 봅니다. RESETLOGS 작업이 플래시백 작업에 아무런 영향을 미치지 않았음을 확인할 수 있습니다. 새로운 기능은 Flashback Database를 훨씬 강력하고 유용하게 만들어 줍니다. 또 Flashback Query에서도 같은 기능을 활용하는 것이 가능합니다. SQL의 savepoint라는 개념을 기억하십니까 트랜잭션에서 savepoint를 생성한 후, 데이터를 일부 수정한 다음, 다시 savepoint를 생성하는 식으로 작업합니다. 그리고 변경된 내용을 다시 되돌리고 싶다면, 해당되는 savepoint로 롤백하면 됩니다. Oracle Database 10g의 Flashback Database는 데이터베이스를 과거의 특정 시점으로 되돌리는 기능을 제공합니다. 그렇다면 여기에도 savepoint와 유사한 개념을 도입하면 유용하지 않을까요 시간을 기준으로 하지 않고, 명명된 시점(named point)으로 되돌릴 수 있게 하면 좋지 않을까요 Oracle Database 10g Release 2에 추가된 “restore point”라는 기능이 바로 이러한 역할을 담당합니다. 그 작동 원리가 다음과 같습니다. 월말 결산 과정에서 여러 개의 배치 프로그램을 순차적으로 실행해야 한다고 가정해 봅시다. 작업의 실행 순서가 다음과 같습니다: 만일 batch job 2가 실행 도중 실패한다면, 그리고 데이터베이스의 일관성을 보장해야 한다면, 전체 작업 내용을 모두 롤백할 필요는 없습니다. 배치 작업을 실행하기 전에 restore point rp2를 미리 생성해 두었으므로, 해당 restore point로 데이터베이스를 플래시백 처리하기만 하면 됩니다. restore point를 생성하는 방법은 다음과 같습니다: 위와 같이 하면, 현재 데이터베이스 시간과 SCN을 기준으로 새로운 restore point (BEFORE_MONTHEND_200503)가 생성됩니다. 데이터베이스를 해당 restore point로 플래시백 처리할 수 있음을 보장하고 싶다면, 아래와 같이 “guarantee” 키워드를 추가합니다: V$RESTORE_pOINT 뷰를 조회하면 생성한 restore point가 존재함을 확인할 수 있습니다: 나중에 데이터베이스를 플래시백 처리하려면 아래와 같이 명령을 실행합니다: 로그에는 다음과 같은 기록이 남게 됩니다: Restore point, 특히 “guaranteed” restore point는 데이터베터베이스가 좋은 예입니다. 관리자는 restore point를 생성한 후 몇 가지 테스트를 실행하고, 다시 restore point로 플래시백 함으로써 데이터베이스를 이전의 상태로 깨끗하게 돌려 놓을 수 있습니다. Flash Recovery Area에 여러 가지 유형의 유형이 현재 사용되고 있는지 확인하려면 어떻게 해야 할까요 새롭게 추가된 V$FLASH_RECOVERY_AREA_USAGE 뷰를 조회하면 Flash Recovery Area의 정보를 확인할 수 있습니다. 이 뷰를 통해서, Flash Recovery Area에서 어떤 종류의 파일이 사용 가능한지 확인할 수 있습니다. 하지만 여기서는 값이 퍼센트로만 표시되고 있습니다. 실제 값을 확인하려면 $RECOVERY_FILE_DEST 뷰를 조회해야 합니다. 위에서 Flash Recovery Area로 사용될 수 있는 디스크 영역은 최대 2147483648 바이트임을 확인할 수 있습니다. 앞의 쿼리에서 알 수 있듯이, 플래시백 로그는 SPACE_LIMIT의 0.95%를 차지하고 있습니다. 이 값을 이용하여 플래시백 로그의 실제 크기를 계산할 수 있습니다. 또 Flash Recovery Area에서 재확보할 수 있는 공간의 크기를 파일 유형 별로 확인할 수도 있습니다. 예를 들어, “backup piece”가 점유하는 공간 중, 전체의 1.02%에 해당하는 공간을 재확보할 수 있습니다. 또 이 뷰를 이용하면 Flash Recovery Area의 활용도와 크기에 대한 예측이 가능합니다. Oracle Enterprise Manager의 Recovery Settings 페이지에서, V$RECOVERY_FILE_DEST 뷰를 조회한 결과를 파이 차트 포맷으로 확인하실 수도 있습니다: 백업과 복구는 DBA (특히 운영 시스템을 지원하는 DBA)가 담당하는 가장 중요한 임무의 하나입니다. Oracle Database 10g Release 2에 추가된 새로운 기능들을 활용함으로써 DBA의 작업을 보다 쉽고 안정적으로 수행할 수 있을 것입니다.백업 및 가용성 관련 기능
백업 및 가용성 관련 기능
Oracle's Own Backup
메뉴에서 "Configure Backup Settings” 링크를 클릭하면, 아래와 같은 스크린이 표시됩니다:
이 스크린의 "Tape Settings" 섹션에서 Oracle Backup 툴을 설정할 수 있습니다.
obtool
ob > help
ob> help restore glossary
ob> backup --level incr --at 2005/03/29.09:00
--priority 1 --family Pool1 --privileged --dataset OracleHome --expirerequest 7days
과거/현재의 작업에 대한 다이내믹 RMAN 뷰
SESSION_KEY INpUT_TYpE STATUS START_TIME END_TIME HRS
----------- ------------- -------- -------------- ------------- -------
1 DATAFILE FULL COMpLETED 03/25/05 00:48 03/25/05 00:48 .00
4 DB FULL COMpLETED 03/27/05 02:09 03/27/05 02:11 .04
7 DB FULL FAILED 03/27/05 02:18 03/27/05 02:24 .10
SQL> col ins format a10
SQL> col outs format a10
SQL> select SESSION_KEY,
2 OPTIMIZED,
3 COMPRESSION_RATIO,
4 INPUT_BYTES_PER_SEC_DISPLAY ins,
5 OUTPUT_BYTES_PER_SEC_DISPLAY outs,
6 TIME_TAKEN_DISPLAY
7 from V$RMAN_BACKUP_JOB_DETAILS
8 order by session_key;SESSION_KEY OPT COMPRESSION_RATIO INS OUTS TIME_TAKEN
----------- --- ----------------- ---------- ---------- ----------
1 NO 2.23776224 3.33M 1.49M 00:00:06
4 NO 1.31065794 6.92M 5.28M 00:02:16
7 NO 1.32363058 3.68M 2.78M 00:06:00
SQL> select * from V$RMAN_BACKUp_TYpE; WEIGHT INpUT_TYpE
---------- -------------
1 BACKUpSET
2 SpFILE
3 CONTRolFILE
4 ARCHIVELOG
5 DATAFILE INCR
6 DATAFILE FULL
7 DB INCR
8 RECVR AREA
9 DB FULL
SQL> select output
2 from v$rman_output
3 where session_key = 4
4 order by recid;OUTpUT
----------------------------------------------------------------------connected to target database: TEST (DBID=1849323268)
Starting backup at 27-MAR-05
using target database controlfile instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=201 devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00001 name=/u01/app/oracle/oradata/TEST/system01.dbf
input datafile fno=00003 name=/u01/app/oracle/oradata/TEST/sysaux01.dbf
input datafile fno=00002 name=/u01/app/oracle/oradata/TEST/undotbs01.dbf
input datafile fno=00004 name=/u01/app/oracle/oradata/TEST/users01.dbf
input datafile fno=00005 name=/u01/app/oracle/oradata/TEST/accdata01.dbf
channel ORA_DISK_1: starting piece 1 at 27-MAR-05
channel ORA_DISK_1: finished piece 1 at 27-MAR-05
piece handle=/u01/app/oracle/product/10.2.0/db_1/dbs/07ggc7qr_1_1 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:01:46
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
including current controlfile in backupset
channel ORA_DISK_1: starting piece 1 at 27-MAR-05
channel ORA_DISK_1: finished piece 1 at 27-MAR-05
piece handle=/u01/app/oracle/product/10.2.0/db_1/dbs/08ggc7u6_1_1 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
Finished backup at 27-MAR-05
Oracle RAC 클러스터의 다이내믹 채널 할당
allocate channel = c1 type sbt_tape connect = 'rman/rmanpass@inst1';
allocate channel = c2 type sbt_tape connect = 'rman/rmanpass@inst2';
RMAN을 통한 Tempfile 복구
ORA-01157: cannot identify/lock data file 201 - see DBWR trace file
ORA-01110: data file 201: '/u01/app/oracle/oradata/TEST/temp01.dbf'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
Sun Mar 27 20:29:00 2005
Errors in file /u01/app/oracle/admin/TEST/bdump/test_dbw0_15457.trc:
ORA-01186: file 201 failed verification tests
ORA-01157: cannot identify/lock data file 201 - see DBWR trace file
ORA-01110: data file 201: '/u01/app/oracle/oradata/TEST/temp01.dbf'
Sun Mar 27 20:29:00 2005
File 201 not verified due to error ORA-01157
Sun Mar 27 20:29:00 2005
Dictionary check complete
Sun Mar 27 20:29:00 2005
SMON: enabling tx recovery
Sun Mar 27 20:29:00 2005
Re-creating tempfile /u01/app/oracle/oradata/TEST/temp01.dbf
Flashback Database/Query Through RESETLOGS
엉뚱한 레코드가 업데이트 되었으니 플래시백 처리해달라고 요청을 전달함.SQL> select first_name, last_name
2 from accounts
3 where acc_no = 3;FIRST_NAME LAST_NAME
------------------------------ -----------
Alan Smith
SQL> update accounts
2 set first_name = 'John'
3 where acc_no = 3;
SQL> flashback database to before resetlogs;
SQL> select first_name, last_name
2 from accounts
3 where acc_no = 3;FIRST_NAME LAST_NAME
------------------------------ -----------
Alan Smith
Restore point in Flashback Database
create restore point before_monthend_200503;
create restore point before_monthend_200503
guarantee flashback database;
SQL> select * from v$restore_point; SCN DATABASE_INCARNATION# GUA STORAGE_SIZE
---------- --------------------- --- ------------
TIME
---------------------------------------------------
NAME
--------------------------------------------------- 1429811 1 YES 8192000
27-MAR-05 05.18.39.000000000 pM
BEFORE_MONTHEND_200503
flashback database to restore point before_monthend_200503;
Media Recovery Applied UNTIL CHANGE 1429814
Flash Recovery Area 들여다 보기
SQL> select * from V$FLASH_RECOVERY_AREA_USAGE; FILE_TYpE pERCENT_SpACE_USED pERCENT_SpACE_RECLAIMABLE NUMBER_OF_FILES
------------ ------------------ ------------------------- ---------------
CONTRolFILE 0 0 0
ONliNELOG 0 0 0
ARCHIVELOG .02 .02 1
BACKUppIECE 68.98 1.02 10
IMAGECOpY 0 0 0
FLASHBACKLOG .95 0 3
SQL> select * from V$RECOVERY_FILE_DEST;NAME
----------------------------------------------------------
SpACE_liMIT SpACE_USED SpACE_RECLAIMABLE NUMBER_OF_FILES
----------- ---------- ----------------- ---------------
/home/oracle
2147483648 1502122496 22201856 14
