Database초보우낙

inctive, current 상관안하고 전부 깨졌을 경우에는 cancel불완전복구를 하면 된다 ■ 실습1. #1. coldbackup을 수행 shutdown immediate oradata cp * /home/oracle/coldbackup6/ startup oradata rm *.log

복구의 종류 2가지 완전복구 --- 장애가 나기 직전에 최종적으로 commit한 시점으로 복구하는 것 불완전 복구 ---과거의 특정 시점으로 복구 current redo log file이 깨져서 db가 shutdown되었다면 복구하는 방법이 과거에 백업받은 모든 data file들을 다 복원하고 아카이브 로그 파일을 적용해서 복구를 하는데 current redo log file 까지 적용해야 완전 복구가 되는데 current redo log file이 없으므로 cancel base 불완전 복구를 해야한다 current redo log file만 적용안하고 cancel하겠다는 의미 ■ 실습 #1. cold backup 수행 #2. 로그 스위치를 3번 일으키고 체크포인트를 일으킨다 #3. 깨트릴 curren..

완전 복구와 불완전 복구의 차이 완전복구는 장애가 나기전에 마지막 commit시점으로 복구 불완전복구는 과거의 특정 시점으로 db를 되돌리는것 불완전 복구를 해야할때 완전 복구를 못했을 때 고객의 요청으로 특정시점으로 DB를 되돌려야할 때 실수로 유저를 drop했을 때 실수로 테이블 스페이스를 drop했을 떄 current와 active상태의 redo log group의 멤버가 모두 삭제되었을때 alter database oper resetlogs; 2시59분 컨트롤파일의 시점 -> 4시 리두로그 파일의 시점 ->4시 서로 싱크가 안맞지만 싱크를 맞춰준다 만약 금요일 3시에 scott유저를 drop했고 나는 3시 이전으로 db를 되돌리고 싶다 그러려면 과거에 백업받았던 파일들중에 모든 data file들..

■ 실습 #1. 현재 리두 로그 그룹의 상태를 확인 #2. inactive인 리두 로그 그룹을 하나 선택해서 그 그룹의 멤버를 모두 삭제 #3. 로그 스위치를 여러 번 일으킨다 #4. db가 shutdown되었다면 startup mount를 한다 #5. 문제가 되고 있는 리두 로그 그룹을 추가 #6 DB를 open ◆ 구현 #1. 현재 리두 로그 그룹의 상태를 확인 @log_status #2. inactive인 리두 로그 그룹을 하나 선택해서 그 그룹의 멤버를 모두 삭제 @logfile 3번 그룹 삭제 #3. 로그 스위치를 여러 번 일으킨다 alter system switch logfile; -->멈췄다 --sys계정만 접속가능 #4. db가 shutdown되었다면 startup mount를 한다 #5...

OCP문제 : 위의 상태에서 DB를 내렸다면 DB가 정상적으로 운영되는가? ■ 실습 구성 #1 지금 현재 있는 그룹에 멤버를 2개씩 유지하게 하세요 #2. 1번 그룹만 current이고 나머지는 inactive상태가 되게 하시오 #3. 3번 그룹의 멤버중 하나를 삭제하세요 #4. 로그스위치를 수동으로 여러 번 일으키는게 가능한지 확인하세요 ※ 리두 로그 그룹의 멤버를 삭제할 때 os의 해당 파일이 같이 삭제가 안되었다 그래서 다음과 같이 따로 삭제해야한다 그런데 이때 주의할 사항이 @/home/oracle/logfile.slq 을 해서 결과에 없는 logfile 멤버를 지워야지 기존에 잘쓰고 있던 멤버를 지우면 안된다 ◆ 실습 구현 기존에 있던 redolog0*b.log 파일들을 지우기 #1 지금 현재 ..

현장에서 redo log group을 삭제하는 경우는? redo log group안의 멤버가 손상되었을 때 group을 삭제한다 ※ group 삭제시 주의사항 current상태와 active 상태의 group은 삭제할 수 없다 ■ 실습 단계 #1. 4번그룹의 상태를 확인하고 current나 active이면 inactive로 바꾼다 #2. 4번 그룹을 삭제 ◆ 실습 구현 #1. 4번그룹의 상태를 확인하고 current나 active이면 inactive로 바꾼다 alter system checkpoint; @log_status.sql #2. 4번 그룹을 삭제 alter database drop logfile group 4; 문제1. 그룹 5번을 삭제 alter system checkpoint; @log_st..

오라클에서 권장하는 그룹의 개수는 최소 5개 이상 유지하는것을 권장한다 --> 성능문제 때문에. 리두로그 그룹의 개수가 적으면 DML작업이 많을때 오라클이 느려진다. INACTIVE와 ACTIVE의 차이 메모리의 변경사항이 DATA FILE에 내려써졌으면 inactive 안내려써졌으면 active ■ 실습 단계 #1. 리두로그 그룹의 개수를 확인 #2. 리두로그 그룹을 추가 (5개) #3. 그룹이 잘만들어졌는지 확인 ◆ 구현 #1. 리두로그 그룹의 개수를 확인 @log_status.sql #2. 리두로그 그룹을 추가 (5개) alter database add logfile group 4 '/u01/app/oracle/oradata/Ouh/redo04.log' size 10m; #3. 그룹이 잘만들어졌는지..

리두 로그 그룹의 멤버를 삭제하려면 삭제하려는 리두 로그 그룹의 상태가 current나 active면 안된다 ■ 실습 #1. redo log group의 상태를 확인 #2. inactive인 리두 로그 그룹의 멤버를 하나 drop한다 #3. 나머지 리두 로그 그룹의 멤버도 다 drop하고 그룹당 멤버를 1개씩만 유지 (※ 로그 스위치와 체크포인트를 일으켠서 상태를 inactive로 만들어놓고 작업) ◆ 실습 구현 #1. redo log group의 상태를 확인 @log_status.sql select group#, member from v$logfile order by 1 , 2 ; --로그파일확인 save logfile.sql #2. inactive인 리두 로그 그룹의 멤버를 하나 drop한다 alte..

리두로그 파일 (redo log file) 의 역할 복구를 하기 위해 필요한 파일 redo log file 에 redo log buffer의 내용을 적는 백그라운드 프로세서 -> LGWR redo log file은 순환적으로 사용이 된다 --> 재사용 변경사항이 갑자기 많은 때에 LGWR가 Redo log file에 내용을 적다가 redo log file이 깨지는 경우가 종종 생긴다 ex) 대학교 학교 시스템에 갑자기 insert & update & delete작업이 몰린다 --> 수강신청 장애에 대처를 빠르게 하려면 평소에 백업을 잘해야한다. redo log file같은 경우는 다중화를 해놔야한다 DB장애는 어쩔 수 없이 발생한다. 평상시에 백업을 해둬서 대비를 잘해둬야한다 그룹 : 논리적인 단위 멤버..

* 리두로그 파일? (redo logfile) ↓ 다시 작업하다. 다시 작업하기위한 로그 파일입니다. 즉, 복구를 하기 위해서 필요한 데이터가 있는 파일입니다. select 만 빼고 insert,update, delete, merge, create, alter ,drop, truncate 등의 명령어들이 이 안에 들어있습니다. 리두로그 파일의 상태 4가지 current : LGWR가 현재 쓰고 있는 상태 active : LGWR가 다 썻고 쓴 내용에 대한 메모리의 변경사항들이 datafile로 반영이 안된 상태 inactive : LGWR가 다 내려썻고 메모리의 변경사항이 DATA FILE에 다 반영된 상태 unised : LGWR 가 한번도 사용하지 않은 상태 active를 사용하면 불완전복구를 해야하..