대기 데이터베이스는 기본적으로 프로덕션 데이터베이스의 일관된 복사본으로 프로덕션 재해, 데이터 손실 또는 손상에 도움이 됩니다.
소개
다음 이유는 기본 사이트와 대기 사이트 간의 지연을 설명할 수 있습니다.
- 기본 데이터베이스와 대기 데이터베이스 간의 네트워크 대역폭 문제
- 대기 데이터베이스를 사용할 수 없습니다.
- 기본 데이터베이스의 아카이브 다시 실행 데이터를 실수로 삭제했습니다.
기본 사이트에서 아카이브 로그를 복사하여 적용하여 기본 환경과 대기 환경을 동기화할 수 있지만 이 프로세스는 시간이 많이 걸립니다.
또 다른 옵션은 기본 사이트의 증분 RMAN 백업을 사용하여 대기 사이트를 복구하는 것입니다. 시스템이 대기 데이터베이스에 적용한 적이 없는 기본에 아카이브 로그가 누락된 경우에도 이 방법을 사용할 수 있습니다.
증분 RMAN 백업을 사용하여 물리적 대기 데이터베이스를 복구하는 단계
이 시나리오를 설정하기 위해 손상된 로그 또는 누락된 로그를 시뮬레이션하기 위해 기본 사이트에서 일부 아카이브 로그를 수동으로 제거했습니다.
1단계:기본 및 대기 사이트의 동기화 상태 확인
기본(prod)과 대기(stby) 간의 동기화 상태를 간단히 살펴봐야 합니다.
기본 사이트:
대기 사이트:
2단계:기본 및 대기 간의 간격 시뮬레이션
기본 데이터베이스에 로그온하고 LOG_ARCHIVE_DEST_STATE_2를 변경해야 합니다. DEFER . 그런 다음 동일한 수동 로그 전환을 수행하여 일부 아카이브 로그를 생성하여 기본 로그와 대기 로그 사이에 간격을 만듭니다.
이제 CURRENT_SCN을 보면 기본과 대기 사이, 분명히 수동으로 동기화를 비활성화했기 때문에 대기가 따라잡지 않습니다.
기본 사이트:
대기 사이트:
이제 LOG_ARCHIVE_DEST_STATE_2를 다시 활성화하면 , 대기가 자동으로 따라잡습니다. 그러나 바로 그 옵션을 선택해서는 안 됩니다. 갭시뮬레이션을 생성하려면 기본 사이트에서 아카이브 로그를 수동으로 삭제해야 합니다.
두 사이트에서 각각 스레드 1 및 2에 대해 232 및 218 이후의 아카이브 로그가 없는지 확인하십시오.
이제 LOG_ARCHIVE_DEST_STATE_2를 다시 활성화해야 합니다. (ENABLE로 설정 ):
예상대로 기본 사이트에서 일부 로그가 누락되어 대기에서 로그를 계속 적용할 수 없습니다.
마지막으로 복구를 취소하고 대기 인스턴스를 종료합니다.
3단계:증분 백업
기본에 로그온하고 대기에 적용된 마지막 SCN에서 증분 백업을 수행합니다.
4단계:대기 제어 파일 백업
이제 대기 사이트에 제어 파일을 백업합니다.
5단계:백업을 대기 사이트로 배송
방금 가져온 증분 백업을 대기 사이트로 전송:
6단계:대기 제어 파일 복원
대기 사이트에서 제어 파일 복원:
참고 :이전 명령을 실행하기 전에 이전 제어 파일을 수동으로 제거하여 제어 파일을 사용하고 있는지 확인하십시오.
그리드 사용자로 로그온하고 이전 제어 파일을 제거합니다.
7단계:백업 조각 카탈로그화
이제 백업 프로세스를 카탈로그화하십시오.
8단계:기존 데이터 파일 카탈로그화
또한 기존 데이터 파일의 목록을 작성하십시오.
9단계:기존 데이터 파일 전환
모든 기존 데이터 파일을 이미지 사본으로 전환:
10단계:데이터베이스 복구
이제 데이터베이스를 복구하십시오.
이 단계는 대기 새로 고침을 마칩니다. 몇 단계만 더 진행하면 됩니다!
11단계:동기화 상태 확인
두 사이트의 시퀀스를 빠르게 살펴보십시오. 대기가 기본을 따라잡았습니다.
기본 사이트:
대기 사이트:
12단계:미디어 복구 시작
대기 사이트에서 미디어 복구 시작:
결론
이전 단계의 도움으로 대기 사이트를 복구할 수 있습니다. 프로덕션 환경의 증분 백업을 사용하면 상당한 시간을 절약할 수 있습니다.
데이터베이스 서비스에 대해 자세히 알아보십시오.
피드백 탭을 사용하여 의견을 작성하거나 질문하십시오. 저희와 대화를 시작할 수도 있습니다.