RMAN 복구 데이터베이스 ORA - 01861 오류
새로운 환경 에서 데이터베이스 백업 을 복원 합 니 다.데이터 파일 복원 단계 에서 오류 가 발생 했 습 니 다.
환경 설명: Oracle 10.2.0.3 for solaris 10, 백업 데이터 베 이 스 는 RAC 이 고 복 구 는 단일 인 스 턴 스 에서 이 루어 집 니 다.
조작 출현 과정 은 다음 과 같다.
첫 번 째 단 계 는 데이터 베 이 스 를 어느 시점 으로 복원 하 는 데 오류 가 발생 했 습 니 다.
RMAN> run 2> { 3> allocate channel ch01 type disk; 4> allocate channel ch02 type disk; 5> set until time "to_date('2012-06-25 23:00:00','yyyy-mm-dd hh24:mi:ss')"; 6> set newname for datafile 1 to '/stor2T/app/oracle/oradata/urpdb/system01.dbf'; 7> set newname for datafile 2 to '/stor2T/app/oracle/oradata/urpdb/undotbs1.dbf'; 8> restore datafile 1; 9> restore datafile 2; 10> switch datafile all; 11> release channel ch01; 12> release channel ch02; 13> } using target database control file instead of recovery catalog allocated channel: ch01 channel ch01: sid=155 devtype=DISK allocated channel: ch02 channel ch02: sid=156 devtype=DISK executing command: SET until clause executing command: SET NEWNAME executing command: SET NEWNAME Starting restore at 27-JUN-12 released channel: ch01 released channel: ch02 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of restore command at 06/27/2012 16:09:51 ORA-01861: literal does not match format string
나 는 이것 이 아마도 시간 격식 문제 일 것 이 라 고 생각한다. 우선 그것 을 피하 자.
두 번 째 단 계 는 UNTIL SCN 으로 바 꾸 어 데이터 파일 을 복원 합 니 다.
RMAN> run 2> { 3> allocate channel ch01 type disk; 4> allocate channel ch02 type disk; 5> set until scn 3054150330; 6> set newname for datafile 1 to '/stor2T/app/oracle/oradata/urpdb/system01.dbf'; 7> restore datafile 1; 8> switch datafile all; 9> release channel ch01; 10> release channel ch02; 11> } allocated channel: ch01 channel ch01: sid=155 devtype=DISK allocated channel: ch02 channel ch02: sid=156 devtype=DISK executing command: SET until clause executing command: SET NEWNAME Starting restore at 27-JUN-12 released channel: ch01 released channel: ch02 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of restore command at 06/27/2012 16:12:38 ORA-01861: literal does not match format string RMAN>
SCN 을 사용 하 더 라 도 잘못 보고 했다.
세 번 째 단 계 는 백업 결과 집 을 검사 하고 잘못 보고 합 니 다.
RMAN> list backupset summary; using target database control file instead of recovery catalog RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of list command at 06/27/2012 16:29:18 ORA-01861: literal does not match format string
큰일 났 네.문 제 는 환경 변수 에서 나 온 것 일 까?
환경 변수 설정 을 검사 하고 데이터베이스 에서 매개 변수 설정 을 초기 화 합 니 다.
env|grep NLS_DATE_FORAMT
결 과 는 이미 'yyy - mm - dd hh 24: mi: ss' 형식 으로 나 타 났 습 니 다.
metalink 를 다시 찾 아 보 니 bug 가 있 습 니 다.
Cause
Bug 8513905 : ORA-1861 DURING RMAN RECOVERY Backuppieces in the controlfile have an invalid date. To check if you are hitting this bug query the controlfile:
SQL> alter session set nls_date_format='dd-mon-rr hh24:mi:ss';
SQL> select recid, status, device_type, handle, completion_time from
v$backup_piece where completion_time > '';
Use '' to limit the output to those backuppieces being used during recovery and check for invalid dates. In this case, completion_time for the backuppiece was 04/31/2009 00:57:33 (April only has 30 days).
If the SQL above raises ORA-1861, dump the controlfile and find the trace file in target udump directory :
SQL> alter session set events 'immediate trace name controlf level 20';
Look for a the BACKUP PIECE RECORDS section eg
***************************************************************************
BACKUP PIECE RECORDS
***************************************************************************
...
RECID #68030 Recno 5688 Record timestamp 06/30/09 16:32:01 piece #1 copy
#1 pool 0
Backup set key: stamp=690857355, count=69079
V$RMAN_STATUS: recid=1152921504606803592, stamp=1152921504606803584
Flags:
Device: DISK
Handle: /orashare/backup/S_DBARCLG_BCK_enkir9cb_1_1
Media-Handle:
Comment:
Tag: S_DBARCLG_Q1QSST1_300609_0015
Completion time 06/31/09 11:43:20 <<<
doc 에서 영향 을 미 친 데이터베이스 버 전 은 10.2.0.3 에서 10.2.0.5 로 나 타 났 다.
이번 에는 골 치 아 프 게 되 었 다.
(miki 서유 @ mikixiyouhttp://mikixiyou.iteye.com/blog/1569221 )
doc 를 참조 하여 한 걸음 한 걸음 해결 하 세 요.
첫 번 째 해결 방법 은 제어 파일 을 재 구축 하 는 것 이다.
두 번 째, 세 번 째, 공식 doc, ID 852723.1 을 참고 하 세 요.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
activemq 5.5 의 입문 은 설치, 시작, 데이터베이스 지속 화 를 포함한다Apache ActiveMQ 5.5.0 은 주로 유지보수 버 전 으로 130 개가 넘 는 문 제 를 복 구 했 으 며 대부분 bug 와 개선 이 었 다. Improved performance for offline d...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.