14장. 백업 및 Recovery

 

14-6

DML 권한이 있는 사용자.

1. 부적잘한 데이터를 테이블에 입력하려고 시도한 경우

1) 제약조건

오라클이 강제함.

테이블 제약조건 5가지, 뷰는 2가지.

 

2. 권한이 부족한 상태에서 작업을 수행하려고 시도.

권한 관리를 ROLL을 통해서 줬을 텐데, (획일화 된 내용)

그래서 특정 사용자가 특별한 부분에 대해선 오류날 가능성.

 

3. 공간 할당 시도에 실패한 경우

대량의 데이터 조작하면서 작업 하기 이전에 Resumable Space Allocation 활성화 하면

잠깐 그 작업 멈춰서 Parallel 처리, 이어갈 수 있게... -> 9i에서만 쓴 듯..

10g 이상에서는 Server generate Alert 이라는 기능으로 공간 부족 현상 해소.

 

 

4. 응용 프로그램에 논리 오류가 발생한 경우

 

 

 

 

14-8

transaction backup (백업 아닐 텐데..) ; 연관된 트랜잭션들 모두 처리 11g

오라클에서 TABLE DROP 해서 휴지통에 들어간 거 확인.

휴지통 안 비웠어도 오라클에 의해서 사라질 수 있다.

해당 세그먼트가 얹어진 테이블스페이스에 공간이 부족하면 오라클이 직접 삭제하고 공간 회수.

DBA 입장에선 귀찮아서 해당 기능 막을 수도..

 

 

Oracle Logminer : dbms logmnr ㅇㅣ라는 패키지.

세밀한 복구를 위해 사용했던 기능.

오라클의 리두로그파일을 가지고 그 내용을 가지고 짜맞춰서 복구 가능했었음.

 

 

자동관리에 의해서 오라클이 돌아가는 기능 확인

 

 

DBWR는 더티한 블록을 쓰는데, 유저가 작업한 내역내역 정보를 하나씩 내려쓰는 거가 더 빨름

블록 하나를 다 내려 쓰는 것보다.

 

 

 

리두로그파일 최소 2개 필요. (리두로그그룹 과 같은 말)

LGWR가 계속 내역 정보를 내려 쓸텐데, 해당 파일을 다 쓰면 덮어쓰게 됨.

그 내용이 더티한 블록으로 계속 남아 있고 스토리지에 저장 안 되어 있었으면..

그러므로 두개 필요.

circular 하게 써지므로 하나의 리두 로그 파일이 써지면 다음 파일에 내역 정보가 쓰여짐.

 

 

*** 로그 스위치

쓰는 파일에 대한 변경이 일어났다.

즉 하나의 로그 파일이 다 써지고 두번 째 로그파일 쓸 때 발생.

 

로그 스위치가 발생하면 오라클은 체크포인트 라는 이벤트를 발생한다.

그래서 데이터파일에 쓰도록.

 

 

 

최소

2그룹 1멤버

 

그룹 : 서로 다른 작업 내역을 갖고 있는 영역.

물리적인 파일로 이루어진 그룹.

 

그러다 GROUP 1이 지워지면 문제가 발생.

그래서 멤버를 구성.

내역 정보를 또 다른 곳에도 기록.

멤버 : 똑같은 내용을 가지고 있는 복사본.

 

 

DBWR : 8CPU당 하나의 DBWR 권장

최대 36개 DBWR 가능.

 

CKPT 오라클 권장 : 20분 내외

 

성능에 민감하면 CKPT 안 일어나는 게 좋음.

백업/복구에 민감하면 CKPT 많이 일어나는 게 좋음.

 

 

 

14-17

가능한 해결 방법 1. 복원 한다는게 recovery 가 아니라 restore.

2. 데이터베이스에 알린다 -> 콘트롤파일에 알려서 물리적 위치를 알아낸다.

 

 

 

 

FRA

 10G 까지는 FLASH , 11g 부터 Fast Recovery Area.

DB_RECOVERY_FILE_DEST , DB_RECOVERY_FILE_DEST_SIZE

 

가용성을 높이기 위해 다중화 함.

RMAN 과 같이 연계되는 기능.

 

 

14-20

FS 쓸 때 콘트롤 파일 추가 할 때..

->

초기화 파라미터는 바이너리 파일이라 내가 건드릴 수 없으므로

ALTER SYSTEM SET control_files 명령으로..

 

 

ASM -> 적어도 내가 해당 내용으로써의 복사본 유지할 필요 없음.

왜냐하면 ASM 자체에서 STRIPE , MIRROR 제공하기 때문에.

 

 

 

SQL> select GROUP#,MEMBERS,BYTES,STATUS,ARCHIVED
  2  from v$log;

    GROUP#    MEMBERS      BYTES STATUS           ARC
---------- ---------- ---------- ---------------- ---
         1          2   52428800 CURRENT          NO
         2          2   52428800 INACTIVE         NO
         3          2   52428800 INACTIVE         NO

 

리두 로그 파일 상태

- current

LGWR가 현 시점에 사용하면서 내역정보 쓰고 있는 파일.

그러므로 current 못 지움.

- active

current  리두로그 그룹 다 쓰고 나면 로그 스위칭 됐을 때 바뀌고 남은 그룹.

즉, 내역 정보 다 쓴 리두로그그룹은 active 상태가 됨.

CKPT로써 해당 내용을 사용하고 있는 중이면 active.

그러므로 active도 못 지움.

- inactive

CKPT 다 끝나고 난 뒤의 리두로그그룹.

inactive는 지울 수 있음.

 

 

ARCHIVED..

오라클은 작업 내역 정보를 갖고 있다. 리두로그파일에..

정상적으로 쓰게 되면 리두로그파일은  circular하게 사라질 것이다.

리두로그가 겹쳐써지기 전에 백업을 받으면 , 원하는 시점의 데이터를 살려줄 수 있다.

이걸 하는 게 아카이브로그 모드 이다.

겹쳐써지기 전에 복사본을 받아..

 

ARC라는 선택적인 백그라운드프로세스가 해 준다.

아카이브로그 모드로 운영해야 한다 설치시에..(샘플스키마 선택하는 단계임)

 

근데 만약 중간 데이터가 날라가면 리두로그파일은 순차적이기 때문에 다 날라가게 된다.

중간 데이터 빠지기 전까지밖에 못 살려낸다.

이걸 보완하는 게 또 로그 마이너 임.

 

 

 

리두 정보를 보존하려면 다음 단계를 수행하여 리두 로그 파일의
아카이브된 복사본을 생성합니다.
    1. 아카이브 로그 파일의 이름 지정 규칙을 지정합니다.
    2. 하나 이상의 아카이브 로그 파일 위치를 지정합니다.
    3. 데이터베이스를 ARCHIVELOG 모드로 전환합니다.

어디에 리두로그 파일이 있는지 그룹과 멤버는 어디에 있는지 다 컨트롤 파일에 있다.

아카이브 모드로 전환하면 컨트롤 파일에 기록.

아카이브로그모드에 대한 운영 정보는 컨트롤 파일에 있음.

 

 

EM에 대한 정보를 번호로 순번.

 

 

sqlplus / as sysdba
// 정상적으로 DB 내리고

shutdown immediate

// MOUNT 단계까지 구동하고 (컨트롤파일 구동)
startup mount

//아카이브로그 모드 설정

// 위치 지정 안 해주면 디폴트 위치는 FRA
alter database archivelog;
alter database open;
archive log list