Oracle 데이터베이스에서 로그가 삭제된 여러 가지 복구 방법
때때로, 여러 가지 원인으로 인해 우리의 온라인 로그가 잘못 삭제되거나 의외로 파손되었을 때, 우리는 어떻게 회복해야 하는가, 사실은 매우 간단하다. 아래의 내용을 보면 다음과 같다.
온라인 로그를 삭제함으로써 로그가 잘못 삭제된 경우를 시뮬레이션합니다.
[oracle@test orcl]$ rm redo*
[oracle@test orcl]$ ls -l redo*
ls: redo*:
[oracle@test orcl]$ sqlplus / as sysdba
SQL> startup mount
ORACLE 。
。。。
。
우리는 온라인 리셋 로그만 부족하기 때문에 데이터베이스는 mount 상태로 시작할 수 있습니다. mount 상태의 데이터베이스는 제어 파일만 열 수 있고 모든 데이터 파일의 상태를 검사하지 않습니다. 검사 동작은 오픈 단계에서 진행됩니다.
SQL> alter database open;
alter database open
*
1 :
ORA-03113:
ID: 4607
ID: 125 : 5
데이터베이스를 열면 오류가 발생하고 데이터베이스가 강제로 닫힙니다
다음은 resetlogs 방법을 사용하여 데이터베이스를 열려고 시도한 것입니다.
SQL> recover database until cancel;
。
SQL> alter database open;
alter database open
*
1 :
ORA-01589: RESETLOGS NORESETLOGS
SQL> alter database open resetlogs;
。
resetlogs 데이터베이스를 열려면 데이터베이스가 완전히 복구되지 않은 후에만 사용할 수 있으며, 완전히 복구되지 않은 후에는RESETLOGS 또는NORESETLOGS 옵션을 사용해야 합니다
이 방법 외에도 다음과 같이 logfile을 지우는 방법으로 데이터베이스를 열 수 있습니다.
먼저 데이터베이스를 mount 상태로 시작합니다
조회 v$log 보기:
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES BLOCKSIZE MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME NEXT_CHANGE# NEXT_TIME
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ------------------- ------------ -------------------
1 1 1 134217728 5121 NO CURRENT 984719 2015-09-16 16:04:30 2.8147E+14
3 1 0 134217728 5121 YES UNUSED 0 0
2 1 0 134217728 5121 YES UNUSED 0 0
만약 ARCHIVED 칸이 YES라면 우리는 통과할 수 있다
alter database clear logfile , No ,
alter database clear unarchived logfile
SQL> alter database clear logfile group 2;
。
SQL> alter database clear logfile group 3;
。
SQL> alter database clear unarchived logfile group 1;
alter database clear unarchived logfile group 1
*
1 :
ORA-01624: 1 orcl ( 1)
ORA-00312: 1 1: '/app/oradata/orcl/redo01.log'
그러나 그룹 1은 현재 온라인 로그이기 때문에 이전에 내가 사용했던 shutdown abort로 닫힌 데이터베이스도
데이터 파일 상태가 일치하지 않기 때문에 현재 로그를 사용하여 실례 복구를 해야 하기 때문에 로그 지우기 명령을 통해 지울 수 없습니다
만약 데이터베이스 파일의 상태가 일치한다면 여기까지alter 데이터베이스 오픈 명령을 통해 데이터베이스를 열 수 있습니다. 그러나 이러한 일치하지 않는 상황에 부딪히면resetlogs를 통해 데이터베이스를 열어야 합니다. 다음과 같습니다.
SQL> recover database until cancel;
ORA-00279: 984722 ( 09/16/2015 16:04:43 ) 1
ORA-00289: : /app/archivelog/orcl_1_1_890582670.dbf
ORA-00280: 984722 ( 1) #1
: {<RET>=suggested | filename | AUTO | CANCEL}
AUTO
ORA-00308: cannot open archived log '/app/archivelog/orcl_1_1_890582670.dbf'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
ORA-00308: cannot open archived log '/app/archivelog/orcl_1_1_890582670.dbf'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/app/oradata/orcl/system01.dbf'
SQL> recover database until cancel
ORA-00279: 984722 ( 09/16/2015 16:04:43 ) 1
ORA-00289: : /app/archivelog/orcl_1_1_890582670.dbf
ORA-00280: 984722 ( 1) #1
: {<RET>=suggested | filename | AUTO | CANCEL}
CANCEL
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/app/oradata/orcl/system01.dbf'
ORA-01112:
SQL> alter database open resetlogs;
alter database open resetlogs
*
1 :
ORA-01194: 1
ORA-01110: 1: '/app/oradata/orcl/system01.dbf'
그러나 우리는 불완전한 복구는 실패한 것이고 이때resetlogs를 통해 데이터베이스를 열 수도 없다는 것을 발견했다. 그러면 우리는 은밀한 파라미터를 응용하고 은밀한 파라미터를 통해 상태가 일치하지 않는 데이터베이스를 열 수 밖에 없다. 다음과 같다.
SQL> create pfile='/home/oracle/p2.ora' from spfile;
pfile *._allow_resetlogs_corruption=TRUE
echo "*._allow_resetlogs_corruption=TRUE">>p2.ora
pfile mount :
SQL> startup mount pfile='/home/oracle/p2.ora'
ORACLE 。
Total System Global Area 334036992 bytes
Fixed Size 2253024 bytes
Variable Size 171970336 bytes
Database Buffers 155189248 bytes
Redo Buffers 4624384 bytes
。
resetlogs
SQL> alter database open resetlogs;
。
저희가 임시로 생성한pfile로 시작했기 때문에 마지막 단계를 마치고 데이터베이스를 다시 시작하면 됩니다
자, 데이터베이스가 열렸지만 저희 데이터베이스가 이상한 상황에서 회복되어 문제가 있을 수 있으므로 데이터 분실을 방지하기 위해 백업을 잘 하는 것이 좋습니다.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
Control Version de una base de datos OraclePodemos는 Flyway y Liquibase의 새로운 기반 버전을 제어할 수 있는 프로젝트를 제안합니다. Dada la integración de SQLcl y Liquibase, este ejemplo nos...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.