(실행 취소)를 (다시 실행) 실행 취소 다시 실행하면 트랜잭션의 복구 및 해지를 보장하기 위해 오라클의 중요한 특성이다.
6.1의 역할을 다시 실행
데이터베이스에서 주로 세 가지 구성 요소를 통해 기능을 다시 실행 (아카이브 모드에서, 리두 로그가 아카이브 로그 파일로 결국 파일) 파일 로그 버퍼, LGWR 백그라운드 프로세스 및 리두 로그를 다시 실행.
6.2 다시 실행 내용
변경 벡터 : 변경 한 번 데이터베이스 내의 데이터 블록의 표현입니다.
기록 재실행 : 일반적으로 벡터의 구성에 대한 변경의 세트로 구성되어, 데이터베이스의 변경을 나타내는 변경 벡터의 집합이고, 최소 회수 부 데이터베이스 변경을 구성한다.
문제를 업데이트 문을 가정 : 업데이트 EMP 세트 샐-4000 곳 EMPNO = 7788;
(1)이 있는지 확인 EMPNO = 7788 버퍼 캐시에 기록하고 버퍼 캐시에 판독되지 않은 경우;
(2) 분배 거래의 각각의 홈이 동작은 기록 정보를 다시 요구 트랜잭션 롤백 테이블 스페이스 롤백;
(3)로부터 판독 또는 롤백 미러가 생성 리두 로그 버퍼에 기록해야 할 정보를 다시 상기 버퍼 캐시에까지 = 3000 SAL을 생성한다;
업데이트 데이터 업데이트 (4) 변형 SAL = 4000, 입금 리두 로그 버퍼를 요구한다;
사용자가 제출하는 경우 (5), 기록 정보가 로그 버퍼 다시 제출하고 롤백 비활성 (비활성)에서 트랜잭션을 표시합니다.
6.3 많은 리두를 생성
(1) 기능의 자동 추적의 SQL * Plus 사용
776 리두 크기
(2) V $의 MYSTAT 문의하여
현재 세션에 대한 정보를 기록
A30에 대한 COL 이름
a.statistic # = b.statistic # 및이 a.name = '크기를 다시'a.name, 브이 $ statname A로부터 ab.value, 브이 $ MYSTAT 선택 b;
(3) V $의 SYSSTAT 문의하여
데이터베이스 전역 리두의 발생량의 경우, 브이 $ SYSSTAT 뷰를 통해 조회 할 수 있습니다
9999999에 대한 COL 값
브이 $ SYSSTAT 이름 = '리두 크기'에서 이름 값을 선택;
이러한 관점에서 데이터베이스 인스턴스의 시작 이후 축적 된 로그 발생량 얻어진 로그 발생량 매일 시작 시간을 실시 예에 따라 추정 될 수있다.
startup_time 형태의 브이 $ 인스턴스를 선택;
아카이브 로그 데이터 볼륨, 브이 $ ARCHIVED_LOG, 당신은 매일 추정 및주기적인 활성 데이터베이스를 설정하고 공간 할당 및 기타 문제를 결정할 수 있습니다.
6.4 재실행 기록 트리거 조건
6.4.1 3 초마다 제한 시간 (타임 아웃)
LGWR는 쓰기 작업을 수행 할 파일 병렬 쓰기 대기 이벤트가 발생합니다 로그인합니다.
10046 개 이벤트를 활성화하는 것은 명확하게 LGWR 추적에서 볼 수있는 것은 이러한 이벤트를 기록합니다.
6.4.2 임계 값에 도달 할 때
buffer1 / 3 리두 로그 满
1메가바이트 갖는 더티 데이터를 버퍼 재실행 로그
즉, 분 (1M, 1/3 로그 버퍼 크기),이 때 로그 버퍼 크기를 측정하는 로그 블록 인 경우 LGWR가 트리거된다.
버퍼 3메가바이트로 설정 로그?
6.4.3 사용자 제출
트랜잭션이 성공 플래그를 반환하기 전에, 당신은 파일 동기화 이벤트 로그 및 최대 절전 모드 시간 제한을 시작하기 위해 작성하는 LGWR 프로세스를 쓰기를 완료 통지 LGWR 대기해야하는 것은 1 초입니다.
저자는 사용자에게 반환하는 대응을 필요로하는 재귀 호출 (재귀 호출)를 알고 동기화를 다시 실행이 필요하지 않기 때문에 사용자 만 RBA를 호출하기 전에 작업을 마지막 커밋으로 돌아갑니다 재귀 호출을 동기화해야합니다.
스레드 동기화해야 리두 SGA 기록 로그 블록 번호에 대한 변수가있다. 후류 LGWR 전에 여러 장의 사진이 발생한 경우,이 변수는이 디스크에 기록되기 전에 모두 다시, 가장 높은 로그 블록 수를 기록했다. 이것은 때때로 (그룹 커밋) 제출 그룹이라고합니다.
6.4.4 DBWn 이전에 작성된
6.5 리두 로그 버퍼 크기 설정
일반적으로 3메가바이트는보다 합리적인 조정 시작은 로그 버퍼 공간의 대기 시간이 더 중요한 나타날 때, 경쟁을 줄이기 위해 로그 버퍼를 늘리는 것이 좋습니다입니다.
6.6 무엇을 커밋
완료하기 위해 제출, 이것은 오라클이 로그 파일을 다시 실행 다시 실행 시점 이전에 기록 된 것을 의미한다.
6.7 로그의 주
브이 $ 로그에서 *를 선택;
가장 일반적인 상태는 다음과 같습니다되지 않은 현재, 활성, 비활성,
(1) 현재의
현재 활동이 사용되고, 응급 복구가 필요하다
(2) 활성
충돌을 복원 할 때 비유동, 전체 아카이브 또는 아카이브를 완료하지 않을 수 있습니다, 그것은 사용됩니다 수 있습니다.
활성 상태는 검사 점 로그 파일을 다시 파일의 재활용에 도달하면, 데이터베이스가 경고 파일이 시간, 당신은 다음과 같은 기록을 볼 수, 정지 대기에있을 것입니다, 완료되지 않았 음을 의미합니다 :
스레드 1은, 순서 7239 새 로그를 할당 할 수 없습니다
완료되지 체크 포인트
현재 로그 # 5 서열 번호 7238 MEM # 0 : /opt/oracle/oradata/hsmk/redo05.log
이 문제가 발생하면 데이터베이스가 브이 $ SESSION_WAIT를 통해 내부에서 볼 수있는 뷰는 대기의 종류에 데이터베이스 현재 세션을 표시합니다.
체크 포인트 완료되지는 데이터베이스의 대기 시간 로그 파일 스위치 (체크 포인트 불완전)를 구현;
원인 검사 점 imcomplete 몇 가지 이유가있을 수 있습니다 :
① 로그 파일이 너무 작고, 너무 빈번한 전환이고;
② 로그 그룹은 정상 거래량의 요구를 충족 할 수없는, 너무 작습니다;
느린 쓰기로 이어지는, O 파일을 디스크 I / 병목 현상을 기록 ③;
④의 I / O 병목 현상, DBWR이 작성하는 데이터 파일 디스크 때문에 너무 느립니다;
⑤ 인해 큰 트랜잭션 볼륨, DBWR 부하 압도, 너무 높습니다.
여러 가지 이유를 들어, 우리는 다른 각도에서 문제를 해결하기 위해 시작할 수 있습니다 :
① 로그 파일 크기를 적절한 증가;
적절하게 로그 그룹의 수를 증가 ②;
③ 빠른 디스크 로그 파일을 사용하여 저장되고 (예를 들어,보다 고속의 디스크를 사용하는 대신 RAID10 RAID5 등을 사용);
디스크를 향상 ④ I / O 성능;
⑤ 다수의 DBWR 프로세스를 사용 정도에 비동기 I / O를 사용합니다.
이것은 데이터베이스가 완전히 정지됩니다 모든 데이터베이스 수정 작업의 로그를 생성 할 수 없음을 의미, 대기의 심각한 종류이다.
(3) 비활성
더 이상 인스턴스 복구에 필요한 비활성 비활성 로그를 로그하지만, 매체 복구를 사용할 수있다. 비활성 상태는 보관을 기록하지 않을 수 있습니다. 아카이브가 완료되지 때까지 데이터베이스 아카이빙 시작 모드, 로그 파일도 적용 할 수없는 경우,이 시간에 대기 (필요한 아카이브) 로그 파일 스위치에 적극적으로 과정이 될 것입니다.
로그 아카이브는 아카이브 필드의 브이 $ 로그에 따라 판단 할 수있다, 완료됩니다.
이 조건은 일반적으로 가능 I 때문에 / O는 예외적 인 경우에, 그것은 로그 때문에 손상 될 수 가능성이 있기 때문에 과도한 거래, 천천히, 데이터베이스에 의해 이상에 의해 발생합니다. 문제는 경고 로그 파일을 확인하여 찾을 수 있습니다.
(4) 미
사용되지 않는 로그는 이러한 로그가 바로 데이터베이스에 추가 할 수있다, 기록 된 적이없는, 또는 RESETLOGS 후 다시 것을 의미한다. 사용 된 후에, 상태가 변경된다.
6.8 로그의 블록 크기
512bytes에
6.9 로그 파일 크기
일반적으로, 실제 환경에서, 30 분의 로그 전환 시간 제어를 생성;
일반적인 운영 체제의 경우, 로그 파일의 최대 크기 때문에 로그의 제한된 크기로, 로그 꽤 잘되었습니다 10 분에 제어 할 수있는, 매우 바쁜 비즈니스 시스템에 2GB의입니다.
평소보다 더 뜨거운 대기 중에 생성 된 리두 왜 6.10
핫 백업하는 동안, 오라클은 분할 블록의 문제를 해결하기 때문에 블록 데이터 로그 파일의 변화는 단지 정보를 수정하지 미러 라인 이전에 기록 할 필요가있다.
핫 스탠바이 상태에서, 상기 데이터의 변화가 오라클 데이터 로그의 전체 변화의 블록 이전에 기록되어야 미러.
redo_size에서 *를 선택;
6.11 리두를 생성 할 수 없습니다
데이터베이스에 6.11.1 NOLOGGING에 미치는 영향
생성 된 로그 있지만 (예컨대 사전 테이블에 대한 변경 등)에 필요한 로그가 기록되도록 NOLOGGING이 크게 감소 될 수있다.
당신은 NOLOGGING 환경이 매우 제한되어 사용할 수 있으며, 일부 조작에서는, 당신은 NOLOGGING 단어를 증가시킬 수있다 :
① 인덱스 또는 인덱스 재 구축을 작성할 때,
② 저자 / * + * / 프롬프트 직접 삽입 작업 또는 배치 경로 * SQL 로더 직접 경로 로딩 트랜잭션을 추가;
때 당신은 데이터 테이블 ③CTAS 방법을 만들;
④ 큰 개체 LOB 동작;
등 이동, 분할, 같은 ⑤ 일부 테이블 변경 작업,
쿼리 리두 로그를 용이하게 할 수있는 뷰를 생성합니다
만들거나보기 redo_size 교체
같이
mystat.statistic $ # = # statname.statistic에서 $ 및 $에 statname.name = '크기를 다시'$ statName에서 브이 $ MYSTAT로부터 값을 선택;
영향 6.11.2 disable_logging의 데이터베이스의 경우
위의 정상 작동뿐만 아니라, 오라클 내부 매개 변수, 데이터베이스가 로그 오프 할 수 있습니다, 또는 어떤 특별한 도움이 필요한 테스트 목적을 달성하기 위해이 매개 변수는 시스템 설정 "_disable_logging"= 사실을 변경 동적으로 설정 될 수있다;
6.11.3 힘 기록 모드
백업으로 사용하거나, 재해 복구 가드 (DataGuard) 고 가용성 데이터베이스를 의미하는 경우, 로그는 일반적으로 로그 모드를 강제 할 수있는 데이터베이스로, 필수 불가결하게된다. 이 모드에서는 모든 작업이 기록됩니다.
6.12 재실행 오류 복구
6.12.1는 비활성 로그 오류 복구 그룹을 잃었다
다시 설정 로그의 명확한 재건으로
! RM은 /op/oracle/oradata/redo02.log
시스템 스위치 로그 파일을 변경하는 행위
시작
atartup 마운트;
브이 $ 로그에서 *를 선택;
브이 $ 로그 파일에서 *를 선택;
그것은, (부패는 일반적으로 실패한 작업 후 발생하는 로그 그룹이 손실 되었기 때문에, 로그의 핸드 오버 프로세스가 데이터베이스 충돌이 상태에서 Invalidated 그룹 3 로그가되도록, 로그 파일 상태 redo03.log가 부실되고, 주목 성공적인 수술 후 다음 상태가 정상으로 돌아갑니다)
당신은 로그 그룹을 삭제 한 후 데이터베이스를 시작할 수 있습니다 :
데이터베이스 명확 로그 파일 그룹 2를 변경하는 행위
데이터베이스가 아카이브 모드에있는 경우 및 아카이브 로그를 완료하지 않은 그룹은 제거를 강제로 필요합니다 :
데이터베이스 명확한 언 아카이브 로그 파일 그룹 2를 변경하는 행위
6.12.2 분실 또는 현재 활동 로그 파일을 복구
오라클 데이터는 반드시 손실되지 로그 파일의 성공에 제출하지만, 실패, 사용자는 현재 로그 파일이 손실 될 수 있습니다. 이것은 차례로 데이터베이스 정상 또는 비정상 차단 해제 두 가지 경우로 나누어.
(1) 때 현재 로그 손실, 정상 종료 데이터베이스
데이터베이스를 닫기 전에, 오라클 전체 체크 포인트를 수행합니다, 현재 로그는 더 이상 인스턴스 복구에 필요한 수 없습니다.
(2) 때 현재 손실 로그 데이터베이스 닫힌다
이 경우, 일반적으로 로그 파일을 손상 손실 된 데이터를, 마지막으로 좋은 로그 파일까지 앞으로 공제를 적용하여 백업 파일, 아카이브 로그 파일에서 데이터를 복원 한 다음 데이터베이스 복구가 RESETLOGS를 통해 수행 할 수 있습니다 시작해야 데이터입니다.
데이터베이스를 백업하지 않은 경우, 오라클은 일관성 등의 문제를 무시하고, 필수 내부 데이터베이스하기위한 수단이 열려 있습니다. 데이터베이스를 연 후, 데이터 꼬마 도깨비, 완벽한 재해 복구를 재 구축하는 데이터베이스를 다음 가져 오기 다음 데이터 내보내기 특급을 권장하고 oralce.
암시 적 매개 변수를 사용하여 데이터베이스를 시작하는 강제 :
"_allow_resetlogs_corruption"= 사실 SPFILE 설정 시스템을 변경;
즉시 종료;
시작 마운트;
취소 할 때까지 백업 제어 파일을 사용하여 데이터베이스를 복구;
데이터베이스 열린 RESETLOGS를 변경하는 행위
즉시 종료;
시작
6.13 진단 사례 나 : 로그 지우기하여 데이터베이스를 복원하려면
로그에서 참조 데이터베이스는 경로 오류를 보관, 보관 될 수 없다
브이 $ ARCHIVE_DEST에서 *를 선택;
파라미터 LOG_ARCHIVE_DEST을 보여;
여러 보관 실패 때문에 같은 정상적인 로그 아카이브를 수행 할 수 있도록 데이터베이스 아카이브 로그 플래그의 결과 것은 오류가 아닙니다.
브이 $ 로그에서 *를 선택;
로그가 현재 로그 그룹이 아니기 때문에 핸드 오버 프로세스를 다시 시작하기 위해 다른 사람의 숫자에서 볼 수있는 로그 그룹 2와 그룹 순서 # 3 로그가 추진되었습니다 만, 그래서 1, 여전히 그룹 1 (202)입니다 순서 번호의 그룹 로그 로그 정상 상태 있도록 로그의 내용은 명확한 방법에 의해 제거 될 수있다.
데이터베이스 명확한 언 아카이브 로그 파일 그룹 1을 변경하는 행위
로그가 보관되지 않기 때문에, 복구를위한 백업 전에 너무 뜨거워 이러한 격차를 교차하지 않습니다, 오라클 데이터베이스 백업은 다시 전체에, 경고에서 당신은 또한 프롬프트를 볼 수있는 로그 좋습니다.
후속 작업은 데이터베이스를 백업하기 위해 필요합니다.
6.14 진단 사례 II : 진단 로그 그룹의 과도한 활성화
문제 설명 : 해당 느린 응용 프로그램 요청은 반환 할 수 없었다
이 때 데이터베이스 검사를 착륙 현재 리두 로그 그룹에 추가 활성 상태에있는 것을 발견
로그가 활성 상태에있는 경우, 분명히 DBWR 쓰기는 검사 점 로그 스위치 트리거 유지할 수 없었다. 그런 바쁜 서쪽 DBWR를 확인합니다.
추신 -ef | 그렙 ORA_
DBWR 프로세스 수는 2266, 보는 top 명령입니다 :
상단
과정을 볼 수있는 번호 2266 분명 바쁜별로 CPU를 소모, 그때는 IO에 병목이 도구 'iostat의 사용 플러스 IO 상황을 확인합니다. "
iostat의 -xn 3
디스크의 쓰기 속도 크기가 10MB / s의, 아마도 손상된 디스크에 일반적으로있는 동안 만 5백킬로바이트에 대한 쓰기 속도 (kw / S)를 볼 수 있습니다. 디스크를 교체 한 후, 시스템은 점차 정상으로 돌아왔다.
제 6 장 끝