Oracle 12c RMAN의 new feature 중 하나인 table recovery 

아래 table recovery 방법을 보니 AUXILIARY Database를 만들어 거기서 dump datafile을 뽑아내는 모양새. 


과거에 삭제된 table 복구를 위해 수행되었던 복구 절차를 명령어 한줄로 만들어 놓았네요. ㅎ


Recover the tables EMP and DEPT using the following clauses in the RECOVER command: DATAPUMP DESTINATION, DUMP FILE, REMAP TABLE, and NOTABLEIMPORT.


The following RECOVER command recovers the EMP and DEPT tables.


RECOVER TABLE SCOTT.EMP, SCOTT.DEPT

    UNTIL TIME 'SYSDATE-1'

    AUXILIARY DESTINATION '/tmp/oracle/recover'

    DATAPUMP DESTINATION '/tmp/recover/dumpfiles'

    DUMP FILE 'emp_dept_exp_dump.dat'

    NOTABLEIMPORT;


참고 : http://docs.oracle.com/cd/E16655_01/backup.121/e17630/rcmresind.htm#BRADV703


'Oracle Database > Oracle New Features' 카테고리의 다른 글

Queryable Patch Inventory  (0) 2014.11.11
12c Hybrid Hash Distribution with Skew Detection / Handling  (0) 2014.05.20
Oracle Database 12c의 소소한 feature.  (0) 2013.12.13
SQL prompt for Oracle Database 12c Multitenant  (0) 2013.12.09
Oracle 12c, Desupport for Raw Storage Devices  (0) 2013.12.06

HOT backup mode에서 왜 redo log에 추가 정보가 쓰일까요? 
ALTER DATABASE BEGIN BACKUP과 ALTER TABLESPACE BEGIN BACKUP의 차이는? 

아래 두개의 POST에 모든 답이 있네요.. 

Why is excessive redo generated during an Online/Hot Backup

There is not excessive redo generated, there is additional information logged into the online redo log during a hot backup the first time a block is modified in a tablespace that is in hot backup mode.  

in hot backup mode only 2 things are different:

o the first time a block is changed in a datafile that is in hot backup mode, the ENTIRE BLOCK is written to the redo log files, not just the changed bytes.  Normally only the changed bytes (a redo vector) is written. In hot backup mode, the entire block is logged the FIRST TIME.  This is because you can get into a situation where the process copying the datafile and DBWR are working on the same block simultaneously.  Lets say they are and the OS blocking read factor is 512bytes (the OS reads 512 bytes from disk at a time).

The backup program goes to read an 8k Oracle block.  The OS gives it 4k.  Meanwhile -- DBWR has asked to rewrite this block.  the OS schedules the DBWR write to occur right now.  The entire 8k block is rewritten.  The backup program starts running again (multi-tasking OS here) and reads the last 4k of the block.  The backup program has now gotten an impossible block -- the head and tail are from two points in time.  We cannot deal with that during recovery.  Hence, we log the entire block image so that during recovery, this block is totally rewritten from redo and is consistent with itself at least.  We can recover it from there.

o the datafile headers which contain the SCN of the last completed checkpoint are NOT updated while a file is in hot backup mode.  This lets the recovery process understand what archive redo log files might be needed to fully recover this file.

Why is excessive redo generated during an Online/Hot Backup

What about ALTER DATABASE BEGIN BACKUP ?
That command put all database tablespaces in backup mode at the same time. As seen previously, it is a bad idea to put all tablespaces in backup mode, as it is better to do it one by one in order to minimize the supplemental redo logging overhead. Oracle introduces this ‘shortcut’ for one reason only: when doing backup with a mirror split (BCV, Flashcopy, etc), the copy gets all the datafiles at the same time, and the copy lasts only few seconds. In that case, it is easier to use that command to put all tablespaces in backup mode during the operation.

http://narashimreddy.wordpress.com/2009/09/11/oracle-backup-and-recovery-description-of-begin-backup-end-backup/

'Oracle Database' 카테고리의 다른 글

Oracle Global Temporary Table  (0) 2010.12.08
오라클 테스트 환경 만들기  (0) 2010.11.29
Oracle LOCAL INDEX DROP 하는 방법  (0) 2010.11.23
TRUSS 명령과 SQLNET tracing 설정 방법  (0) 2010.11.04
Oracle UTL_FILE을 이용한 데이터 loading의 간단한 예제  (0) 2010.11.03

기본적으로 recovery는 backup된 datafile을 가져다 놓고 backup 시점 이후의 archive log를 적용하게 됩니다. 
complete recovery의 경우 모든 archive log가 적용된후 undo가 다시 적용되는데요..

아래의 시나리오는 backup된 datafile은 없으나, 손상된 datafile 생성 시점이후 모든 archive log가 있을 경우 recovery하는 시나리오입니다. 
예전 data guard에서는 primary DB에서 datafile 생성한게 standby에 생성되지 않아 수작업으로 'alter database create datafile,..'을 수행했던거 같은데, 요즘 version에서는 되는지 모르겠네요..

Re-Creating Datafiles When Backups Are Unavailable: Scenario


If a datafile is damaged and no backup of the file is available, then you can still recover the datafile if:

  • All archived log files written after the creation of the original datafile are available

  • The control file contains the name of the damaged file (that is, the control file is current, or is a backup taken after the damaged datafile was added to the database)

    Note:

    You cannot re-create any of the datafiles for the SYSTEM tablespace by using the CREATE DATAFILE clause of the ALTER DATABASE statement because the necessary redo is not available.

To re-create a datafile for recovery:

Create a new, empty datafile to replace a damaged datafile that has no corresponding backup. For example, assume that the datafile ?/oradata/trgt/users01.dbf has been damaged, and no backup is available. The following statement re-creates the original datafile (same size) on disk2:


ALTER DATABASE CREATE DATAFILE '?/oradata/trgt/users01.dbf' AS
                               '/disk2/users01.dbf';

손상된 '?/oradata/trgt/users01.dbf'를 '/disk2/users01.dbf'로 이름을 바꿔 빈 datafile을 생성합니다.

This statement creates an empty file that is the same size as the lost file. The database looks at information in the control file and the data dictionary to obtain size information. The old datafile is renamed as the new datafile.

Perform media recovery on the empty datafile. For example, enter:


RECOVER DATAFILE '/disk2/users01.dbf';

새로 만들어진 빈 datafile에 대해 archive log를 complete로 적용합니다.

All archived logs written after the original datafile was created must be applied to the new, empty version of the lost datafile during recovery.




* 여기저기서 좋다는 책 몇권 추천합니다. 고수가 되는 그날까지.. 파이팅!!


'Oracle Database' 카테고리의 다른 글

ORACLE Nested Group Operations  (0) 2010.08.06
Oracle Table의 통계정보를 옮기는 방법.  (1) 2010.08.03
간단히 테스트해본 oracle 11g new feature invisible index  (0) 2010.07.19
Database에 savepoint를 찍어보자 !!  (0) 2010.07.13
Oracle Join 종류: CROSS, INNER, OUTER, NATURAL,EQUI, SELF join  (0) 2010.07.13

요즘 IT의 화두 중 주목 받는 화두가 클라우드 기술입니다.
구글, 아마존 등 여러 서비스 업체들이 이를 위해 많은 준비를 해왔고 또 주도하고 있습니다.
기존의 IT를 주도하던 대형 업체들이 이들을 따라가는 모양새인 듯 한데요..

Oracle Home page에 보면 오라클도 cloud 기술에 대해 많은 준비를 하고 있는 듯 한데,
oracle 11g release 2에서 클라우드 기술을 이용해 지원하는 amazon AWS service로 backup을 소개하는 좋은 자료가 있어 post 해봅니다.

Backup to Amazon Simple Storage Service (S3) Using OSB Cloud Computing  (oracle 11g R2)

Oracle now offers backup to Amazon S3, an internet-based storage service, with the Oracle Secure Backup (OSB) Cloud Module. This is part of the Oracle Cloud Computing offering. This feature provides easy-to-manage, low cost database backup to Web services storage, reducing or eliminating the cost and time to manage an in-house backup infrastructure.

amazon AWS service로 backup에 대한 자세한 설명은 아래의 presentation을 보시면 확인하실 수 있습니다.

presentation을 보시면 아시겠지만 
DB size 500G정도면 backup time이 4시간, incremental backup time 30분, $200/month 이면 가격도 훌륭해 보이는 군요.  
더구나 디스크 구입이나 유지보수 없이, 또 용량 증설도 간단하니 향후 고려해 볼만한 구조가 아닐까 싶습니다. 

오라클의 클라우드 관련 문서 몇개 링크 겁니다.


* 여기저기서 좋다는 책 몇권 추천합니다. 고수가 되는 그날까지.. 파이팅!!

'Oracle Database' 카테고리의 다른 글

Oracle 11g Trace file 정리하는 방법, ADRCI purge 기능  (0) 2010.04.21
Oracle Online re-org 기능을 이용해 일반 table을 interval partition으로 변경하는 방법  (0) 2010.04.21
Oracle 내 table에 걸쳐있는 constraint 찾고, disable 하기  (0) 2010.04.06
Oracle DECODE() Function  (0) 2010.04.06
Oracle Active DataGuard Monitoring script  (0) 2010.03.31

운영 중 spfile이 유실 되는 경우, 간편하게 recovery 할 수 있는 명령어가 oracle 11g에서 추가되었네요.

뭐 alert log file에 나온 parameter 정보나 show parameter 등으로도 만들 수 있지만 많이 귀찮죠.
(사실 spfile이나 init file 유실되는 건 본적은 없으나...)

create spfile from memory;
create spfile='/u01/oracle/app/oracle/product/11g/dbs/spfile_back.ora' from memory;






'Oracle Database' 카테고리의 다른 글

Oracle INVISIBLE index  (0) 2010.02.08
Oracle의 감춰진 parameter 찾아보기  (0) 2010.01.29
Oracle 11g New feature : Database resident connection pooling  (0) 2010.01.26
오렌지 무료교육  (2) 2010.01.13
Oracle UNDO tablespace의 datafile 옮기는 방법 2개.  (0) 2010.01.07

10G 이전에는 v$fast_start_servers, v$fast_start_transactions 두개의 view를 통해 parallel transaction recovery를 모니터링 할 수 있었습니다. 그러나 일반적인 transaction rollback이나 SMON에 의한 transaction recovery는 모니터링 할 수 없었죠.

그러나 10G에서는 transaction rollback monitoring 기능의 향상으로 일반적인 transaction rollback 작업과 SMON에 의한 transaction recovery에 대한 모니터링이 가능해 졌습니다. v$fast_start_servers, v$fast_start_transactions 두개의 view는 transaction recovery와 transaction rollback작업에 관한 historical 정보까지 갖고 있어 transaction recovery 관련되어 평균 rollback duration을 확인할 수 있습니다.

추가적으로 일반적인 transaction recovery 시간의 산정이 가능해졌으며, system performance에 맞춘 FAST_START_PARALLEL_ROLLBACK init parameter 설정도 가능합니다.

v$fast_start_transaction 의 STATE column은 RECOVERED, RECOVERING 등의 상태를 instance가 shutdown 될때까지 갖고 있어 현재 transaction 상태를 갖고 있으며, 작은 transaction은 보이지 않을 수 있습니다.

Example:
SELECT state,undoblocksdone,undoblockstotal,cputime FROM v$fast_start_transactions;

STATE         UNDOBLOCKSDONE        UNDOBLOCKSTOTAL CPUTIME
---------- -------------- --------------- ---------
RECOVERING     574                    1945             16
…
SQL> /
STATE         UNDOBLOCKSDONE         UNDOBLOCKSTOTAL CPUTIME
---------- -------------- --------------- ---------
RECOVERING     1300                     1945             34
…
SQL> /
STATE        UNDOBLOCKSDONE         UNDOBLOCKSTOTAL CPUTIME
---------- -------------- --------------- ---------
RECOVERED     1945                     1945              65

oracle metalink Note 265198.1를 참조했습니다.

Note 265198.1 - Oracle 10G Transaction Rollback Monitoring





'Oracle Database' 카테고리의 다른 글

INTRODUCTION TO PARALLEL DML  (0) 2009.07.17
Oracle Parallel Query Execution  (1) 2009.07.16
Oracle index block split 현상  (7) 2009.07.10
SQL*NET Trace 설정하기  (0) 2009.07.10
Bulletin no : 12060 SQL*NET V2 최적화하기 [펌]  (2) 2009.07.08

얼마전에  "smon recovery 중인 작업이 언제쯤 끝날까요? <undo_rollback_info.sql>"라는 포스팅을 했었죠. 오늘은 "transaction recovery를 조금 더 빨리 진행하게 하는 방법"에 대해 이야기 해보겠습니다. 

smon(pmon)이 recovery를 하고 있다는 것은 이미 user process가 해당 recovery를 cancel (kill -9 <process id>) 시키거나, database를 강제로 shutdown 시킨 이후의 상황이죠. 이 상황에서 recovery를 빠르게 하려면 두가지 방법이 있습니다.

1. 여러개의 프로세서가 동시에 recovery를 하는 방법
2. 한번 recovery를 할때 많은 양의 recovery를 하게 하는 방법

여러개의 프로세서로 동시에 transaction recovery 하는 방법은 oracle 8i에서 소개된 fast start parallel recovery 기능이 있습니다. 이 기능은 fast_start_parallel_recovery parameter의 설정으로 가능합니다.

이 parameter는 (LOW/HIGH/FALSE)의 값을 지정할 수 있으며 LOW 지정시에는 CPU * 2개의 parallel slave process까지 기동할 수 있으며, HIGH의 경우 CPU * 4개의 parallel slave process가 기동 됩니다. parallel recovery는 v$fast_start_servers와 v$fast_start_transactions view로 확인이 가능합니다. 가끔 parallel recovery가 smon과의 통신으로 인해 성능 저하가 발생할 경우가 있다는데, 이럴 경우 FALSE로 설정하여 serial하게 recovery를 진행할 수 있습니다.



두번째 한번 수행시 많은 양의 recovery를 하게끔 유도하는 방법은 cleanup_rollback_entries parameter로 조정가능합니다. 기본적으로 smon은 한번에 20개의 undo entriy를 정리하고 잠깐 sleep 하게 됩니다. 따라서 많은 양의 transaction recovery가 필요한 경우 이 값을 많이 늘려 한번에 수행되는 양을 많게 설정합니다. 유의할 점은 smon에게 한번에 많은 양의 recovery를 지정하였으므로 CPU를 과도하게 소모할 수 있으므로 recovery시 수행되는 다른 작업에 영향을 끼칠 수 도 있습니다.

참고:
fast-start parallel rollback 기능에 대한 추가 설명




'Oracle Database' 카테고리의 다른 글

job이 자동으로 수행이 안될때 checklist  (0) 2009.01.23
Linux, iSCSI 환경에서 Oracle RAC 10g Release 2 클러스터 설치하기 [펌]  (0) 2009.01.20
oracle fuzzy bit  (0) 2009.01.18
oracle 11g documents library  (0) 2009.01.18
대용량의 transaction rollback, 얼마나 걸릴까요?  (0) 2009.01.18

가끔 이전 데이터 backup을 이용해서 과거의 데이터를 추출해 내야 될 경우들이 있다.
또 어느 누군가 데이터를 삭제하거나 큰 사고로 특정 시점으로 돌아가야 하는 불행한 사태가 아주 가끔 벌어지곤 한다.

다행이 backup 받은게 남아 있다면 time-recovery를 수행하면 해당 시점까지의 복구가 가능하다. 그런데, 가끔 time-base recovery를 진행하다 보면 가끔 요런 메세지가 뜨기도 한다.

ORA-1547 warning: RECOVER succeeded but OPEN RESETLOGS would get error be


간단히 말하자면  "지금 reset log로 올리면 안올라 갈수 도 있으니 좀 더 recovery 하셔야 되요" 라는 내용이다. 이러한 메세지는 datafile header에 fuzzy bit가 설정되어 발생하는 메세지 이다.

fuzzy bit는 해당 datafile에 적용되어야 할 변경사항이 아직 남아 있다는 의미이다. 더 엄밀히 말하자면 fuzzy bit를 해제할 fuzzy marker가 필요하다는 의미이다.

 fuzzy bit는 hot-backup fuzzy, online fuzzy, media recovery fuzzy,absolute fuzzy의 4 가지가 있으며, 일반적으로 hot-backup fuzzy bit가 recovery시 종종 문제가 되곤 한다.

hot-backup buzzy bit는 tablespace에 begin backup이 수행되면 해당 datafile의 header에 fuzzy bit가 설정된다. 이후 end backup이 수행되면 해당 시점의 redo log내에 fuzzy marker가 등록되어 이 redo log를 적용하면 fuzzy bit가 해제 되게 된다.

따라서 hot backup으로 backup을 받은 datafile은 반드시 end backup 시점의, fuzzy marker를 갖고 있는 redo log file이 필요하게 된다.

v$datafile_header의 fuzzy column으로 fuzzy bit 상태를 알 수 있다.

OTN Discussion Forums : FUZZY BIT에 대해서 (DATAFILE의 FUZZY 상태) ...





'Oracle Database' 카테고리의 다른 글

Linux, iSCSI 환경에서 Oracle RAC 10g Release 2 클러스터 설치하기 [펌]  (0) 2009.01.20
지금 수행 중인 smon recovery를 더 빠르게 할 수는 없을까?  (0) 2009.01.19
oracle 11g documents library  (0) 2009.01.18
대용량의 transaction rollback, 얼마나 걸릴까요?  (0) 2009.01.18
Oracle 지금 smon recovery 중인 작업이 언제쯤 끝날까요?  (0) 2009.01.18

가끔 오라클이 대량 작업 중에 죽거나 abort로 내렸을 경우
alert log에 보면 다음과 같이 SMON이 transaction rollback을 하는 메세지를 볼 수 있다.

SMON: about to recover undo segment 4
SMON: mark undo segment 4 as available
                    :


"음 .. 뭔가 큰 transaction이 있었군.."
"어? 왜 아직도 안끝나지? 언제 끝나는 거야? "


다음의 SQL은 rollback 대상 extent size를 확인할 수 있는 sql 문입니다.
이외에 undo segment header dump로 확인하는 방법도 있긴하지만,
요게 시간 산정하기는 더 편하겠지요..


select KTUXEUSN,KTUXESLT,KTUXESQN,KTUXERDBF,KTUXERDBB,KTUXESTA,KTUXESIZ
from x$ktuxe
where KTUXEUSN in (select segment_id from dba_rollback_segs where segment_name = '_SYSSMU156$')
and KTUXESTA = 'ACTIVE';



저작자표시

'Oracle Database' 카테고리의 다른 글

oracle 11g documents library  (0) 2009.01.18
대용량의 transaction rollback, 얼마나 걸릴까요?  (0) 2009.01.18
Oracle 9i online documents  (0) 2009.01.18
oracle 10g documents library  (0) 2009.01.18
Oracle AWR 이란?  (0) 2009.01.07

DB 관리하면서 가장 긴장되는 순간이 ..
당연히 recovery를 수행해야 하는 순간이죠...

잘못하면 데이터 다 날라가거나,
아니면 restore하는데, 10여시간씩 걸리는데,
한번 잘못 명령어 날리면 ..

상상만 해도 끔찍하죠..ㄷㄷ

다음의 dictionary view는 recovery시 꼭 챙겨봐야 할 dictionary view 입니다.
돌다리도 두들겨 보고 건넙니다.. ^^


DBA_DATA_FILES, V$DATAFILE

: 해당 datafile의 현황 및 현재 상태를 check할 수 있다.

V$DATAFILE_HEADER

: 해당 datafile의 fuzzy 상태를 확인할 수 있다. 만약 fuzzy 상태라고 하면 v$backup에서 정상적으로 end backup이 수행되었는지,
추가로 archive log를 적용해야 하는지의 판단이 필요하다.

V$BACKUP

: 최종에 Online Backup받은 file들에 대한 정보를 가지고 있다.
즉, Hot Backup이 수행되고 있는 Tablepsace가 아직 Backup Mode로 있는지 아니면 Backup이 완료 된 상태인지 확인 할 수 있다.
만약 Online Backup을 수행 하면서 ALTER TABLESPACE ~ END BACKUP; 을 수행하지 않았다면 STATUS가 ACTIVE로 남아있게 되며, 
해당 file을 Backup받은 후에 ALTER TABLESPACE ~ END BACKUP command를 실행하지 않은 것이므로 즉시 ALTER TABLESPACE ~ END BACKUP command 를 실행해야 한다.

(fuzzy bit에 대한 자세한 내용..)

v$logfile, v$log

: archive log의 현황및 상태를 확인할 수 있다.

v$archived_log, V$LOG_HISTORY

: archive된 archive log의 정보를 controlfile로 부터 보여준다.

v$controlfile

: controlfile의 현황 정보를 확인할 수 있다.

v$tablespaces

: tablespace의 현황 정보를 확인할 수 있다.

V$RECOVERY_LOG

: media recovery를 위해 적용해야할 archive log의 정보를 확인할 수 있다.

V$RECOVER_FILE

: recovery가 필요한 datafile 정보를 확인할 수 있다.
 
V$RECOVERY_FILE_STATUS

: recovery를 수행하고 있는 oracle process에게 각각의 datafile의 recovery 정보를 보여준다. 다른 세션에서는 정보가 보이지 않는다.

V$RECOVERY_PROGRESS

: v$session_longops의 subview로 해당 recovery 작업 시간 산정등 recovery operation을 tracking 할때 사용한다.

V$RECOVERY_STATUS

: recovery를 수행하고 있는 oracle process에게 현재의 recovery process의 statistic 수치를 보여준다. 다른 세션에서는 정보가 보이지 않는다.



'Oracle Database' 카테고리의 다른 글

oracle 10g documents library  (0) 2009.01.18
Oracle AWR 이란?  (0) 2009.01.07
dba_ view와 v$ view (oracle dictionary view & dynamic performance view)  (0) 2009.01.03
oracle 10g RAC & CRS  (1) 2008.12.31
Oracle SQL plan 확인하는 방법  (0) 2008.12.16

+ Recent posts

티스토리툴바