일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- kotlin
- 고전역학
- 역학
- Database
- 웹 크롤링
- oracle
- 리눅스
- python
- Spring boot
- NIO
- GIT
- 코틀린
- 시스템
- 인프라
- JVM
- 유닉스
- write by GPT-4
- 뉴턴역학
- 파이썬
- 자바
- chatGPT's answer
- 소프트웨어공학
- Java
- android
- flet
- 자바네트워크
- lombok
- 자바암호
- GPT-4's answer
- write by chatGPT
- Today
- Total
Akashic Records
PLT 1.2 리두 로그 파일(Redo Log Files) 본문
PLT 1.2 리두 로그 파일(Redo Log Files)
오라클 서버는 데이터베이스 내의 데이터 손실을 최소화하기 위해 온라인 리두 로그 파일을 유지합니다. 리두로그 파일은 데이터베이스 버퍼 캐쉬 내의 데이터에 가해진 모든 변경사항을 기록합니다. 리두 로그 파일은 인스턴스 실패 같은 상황에서 데이터 파일에는 쓰여지지 않은 Commit된 데이터를 복구하기 위해 사용됩니다.
온라인 리두 로그 파일의 동일한 사본들을 온라인 리두 로그 그룹이라고 합니다.
백그라운드 프로세스인 LGWR 은 그룹 내의 모든 온라인 리두 로그 파일에 동시에 동일한 정보를 기록합니다.
오라클 서버는 데이터베이스의 정상적인 작동을 위하여 최소한 두 개의 온라인 리두 로그 그룹을 필요로 합니다.
위의 그림은 리두 로그 그룹이 3개이며, 한 개의 그룹에는 서로 다른 디스크에 존재하는 두 개의 멤버가 있음을 알 수 있습니다. 예를 들어 D 드라이브에 그룹1의 첫번째 멤버가 있고, E 드라이브에 그룹1의 두 번째 멤버가 있다면 이 두 멤버는 완전히 동일한 파일임을 뜻합니다. 그룹내의 멤버 중 하나가 손상되면 이 멤버를 무시하고 남은 멤버만 사용됩니다. (멤버가 손상되었음을 alert 파일에 기록할 것입니다.)
오라클은 최소한 두 개의 리두로그 그룹이 필요합니다. 그룹의 멤버가 반드시 2개 이상일 필요는 없습니다.(하지만 각기 다른 디스크에 2개 이상의 멤버로 구성하는 것을 권장합니다.)
로그 파일의 생성
데이터베이스가 생성될 때 만들어 집니다. CREATE DATABASE 명령의 MAXLOGFILES 파라미터는 온라인 리두 로그 그룹의 최대수를 지정합니다. 최대 255 CREATE DATABASE 명령의 MAXLOGMEMBERS 파라미터는 그룹 당 멤버의 최대수를 결정합니다. 초기화 파라미터 파일의 LOG_FILES 파라미터는 데이터베이스가 실행될 때 오픈 할 수 있는 로그 그룹의 최대수를 설정하며,MAXLOGFILES * MAXLOGMEMBERS 를 초과할 수 없습니다.
온라인 리두 로그 그룹 추가
ALTER DATABASE ADD LOGFILE('C:\ORACLE...\log3a.rdo', 'D:\ORACLE...\log3b.rdo') SIZE 1M; |
위의 예제는 두 개의 멤버(크기가 1M인)를 갖는 새로운 그룹을 추가합니다. 그룹 값을 지정할 수도 있습니다.
ALTER DATABASE ADD LOGFILE GROUP 4 ('C:\ORACLE\log3a.rdo','c:\ORACLE\log3b.rdo') SIZE 1M |
온라인 리두 로그 멤버 추가
ALTER DATABASE ADD LOGFILE MEMBER 'D:\ORACLE\log1b.rdo' TO GROUP 1, 'D:\ORACLE\log2b.rdo' TO GROUP 2; |
멤버를 추가할 때는 이전 멤버와 사이즈가 동일해야 하므로 SIZE 값을 줄 수는 없습니다. 파일이 이미 존재하는 경우 REUSE 옵션을 사용해야 합니다.( 'D:\...........' REUSE TO GROUP 1 )
온라인 리두 로그 파일의 재배치
리두 로그 파일의 이름을 변경하거나 위치를 변경할 때
1. 데이터베이스를 종료합니다.
2. 온라인 리두 로그 파일을 운영체제명령으로 새로운 위치에 복사합니다. 또는 이름을 바꿉니다.
3. 데이터베이스를 마운트 단계까지 오픈 합니다.
4. ALTER DATABASE RENAME FILE 'old_filename1', 'old _filename2', .... TO 'new_filename1', new_filename2', .... ;
5. 데이터베이스를 오픈 합니다.
ALTER DATABASE RENAME FILE .... 명령은 컨트롤 파일내의 정보를 수정하는 것입니다.
온라인 리두 로그 그룹 삭제
’ ALTER DATABASE DROP LOGFILE GROUP 번호;’
"," 로 구분하여 여러 개의 그룹을 한번에 삭제할 있습니다. 활성중인 그룹은 삭제할 수 없습니다. 최소한 2개의 그룹이 있어야 함을 명심하십시오. 아카이브 모드일 때 로그 파일 그룹이 아카이브되지 않았으면 그 그룹은 삭제할 수 없습니다. 삭제 후 운영 체제 파일은 수동으로 삭제해야 합니다.
온라인 리두 로그 멤버 삭제
‘ALTER DATABASE DROP LOGFILE MEMBER 'filename1', 'filename2', ....;’
그룹의 멤버가 하나뿐이라면 이 멤버는 삭제할 수 없습니다. (그룹을 삭제해야 합니다.) 활성중인 그룹의 멤버라면 삭제 전에 로그 스위치를 발생시켜서 비활성 상태로 만들어야 합니다. 아카이브 모드에서 아카이브되지 않은 멤버는 삭제할 수 없습니다. 삭제 후 운영 체제 파일은 수동으로 삭제해야 합니다.
온라인 리두 로그 파일 정리
’ALTER DATABASE CLEAR LOGFILE 'filename1', 'filename2', ... ;’
이 명령은 해당 로그 파일을 내부적으로 삭제 후 생성시킵니다. 즉, 초기화 시킵니다. 그룹이 2개뿐이고 멤버가 하나씩일 때 삭제가 불가능하므로 이 방법을 사용할 수 있습니다. 또한 아카이브되지 않아도 사용 가능합니다. 아카이브되어 있지 않을 때에는 UNARCHIVED 키워드를 넣어야만 합니다. (... CLEAR UNARCHIVED LOGFILE ....) 이렇게 하면 복구에 온라인 리두 로그 파일이 필요할때 백업을 사용할 수 없게 만들 것입니다.
온라인 리두 로그 파일 개수
LGWR 추적 파일이나 ALTER 파일에 들어 있는 메시지에 체크포인트가 완료되지 않거나 그룹이 아카이브되지 않아 LGWR 이 자주 그룹을 기다리고 있다는 것을 나타낸다면 그룹을 추가해야 합니다. 그룹이 서로 다른 개수의 멤버를 갖는 것을 허용하지만 대칭적인 구성을 하도록 하십시오.
각 그룹의 멤버는 동일한 로그 시퀀스 번호(log sequence number)와 같은 크기를 갖습니다. 로그 시퀀스 번호는 오라클 서버가 각 리두 로그 파일을 유일하게 식별하기 위해 로그 그룹에 쓰기를 시작할 때마다 할당합니다. 현재의 로그 시퀀스 번호는 컨트롤 파일과 모든 데이터 파일의 헤더에 저장되어 있습니다. 온라인 리두 로그 파일을 다중화할 때 한 그룹의 멤버들을 서로 다른 디스크에 놓으면, 멤버 중 하나를 사용할 수 없더라도 다른 멤버를 사용할 수 있어 인스턴스가 종료되지 않습니다.
|
리두 로그 버퍼와 백그라운드 프로세스 LGWR
오라클 서버는 데이터베이스에 가해진 모든 변경 사항을 리두 로그 버퍼에 순차적으로 기록합니다. 리두 로그 버퍼는 원형 방법으로 사용됩니다. (즉 1번 그룹의 멤버에 쓰기 시작해서 내용을 다 채우고 더 이상 빈 공간이 없으면 2번 그룹의 멤버에 쓰기 시작합니다. 이런 식으로 해서 마지막 그룹의 멤버에 쓰기를 마쳤다면 다시 1번 그룹의 멤버로 돌아오는 것입니다. 때문에 원형 방법이라고 합니다.) 다음 상황일 때 LGWR 프로세스가 리두 로그 파일에 기록을 합니다.
커밋 시
리두 로그 버퍼 풀의 3분의 1가량 찼을 때
LGWR 타임 아웃 발생 시
DBWR 이 데이터베이스 버퍼 캐쉬의 수정된 블럭을 데이터 파일에 적기 전에
로그 스위치
LGWR은 온라인 리두 로그 파일에 순차적으로 씁니다. 즉, 현재의 온라인 리두 로그 그룹이 차게 되면 LGWR은 다음 그룹에 쓰기 시작합니다. 로그 스위치는 이때처럼 다음 온라인 리두 로그 그룹에 쓰기 시작하는 이벤트입니다. (로그 스위치가 발생할 때 체크 포인트라는 이벤트도 시작됩니다.)
데이터베이스 관리자가 다음 명령으로 로그 스위치를 발생시킬 수 있습니다.
ALTER SYSTEM SWICH logfile; |
체크 포인트
체크포인트가 발생한 로그와 관련된 사용된 모든 데이터베이스 버퍼(더티버퍼)는 DBWR에 의해 데이터파일로 옮겨 쓰여집니다.(리두 로그 버퍼 캐쉬의 내용도 리두 로그 파일에 저장됩니다.) 체크포인트 백그라운드 프로세스인 CKPT 는 완료된 것을 반영하여 모든 데이터 파일의 헤더와 컨트롤파일을 갱신합니다. 체크포인트가 발생하는 상황은 다음과 같습니다.
모든 로그 스위치 때(로그 스위치가 발생하면 체크포인트가 발생합니다. 하지만 체크포인트가 발생했다고 해서 반드시 로그 스위치가 발생하는 것은 아닙니다.)
인스턴스가 정상 종료되거나 트랜잭션 종료, 또는 즉시 종료되었을 때(SHUTDOWN ABORT 를 제외한..)
LOG_CHECKPOINT_INTERVAL 과 LOG_CHECKPOINT_TIMEOUT 초기화 파라미터의 설정에 따라
데이터베이스 관리자가 수동으로 요구했을 때
=> ALTER SYSTEM CHECKPOINT;
LOG_CHECKPOINT_INTERVAL : 파라미터에 지정된 수만큼의 블럭(운영체제 블럭단위)에 쓰게 되면 바로 체크포인트가 시작됩니다. 실제 로두 로그 파일의 크기보다 크게 지정하면 아무의미가 없습니다. 0으로 지정하면 한 개의 리두 로그 버퍼만 쓰여져도 체크 포인트가 발생합니다.(너무 자주 발생하게 됩니다.)
LOG_CHECKPOINT_TIMEOUT : 다음 체크포인트가 발생할 때까지의 시간을 지정.(초단위) 0으로 지정하면 시간에 따른 체크포인트가 발생하지 않습니다. => 권장사항
초기화 파라미터 LOG_CHECKPOINTS_TO_ALERT 가 TRUE 이면 모든 체크포인트에 대한 정보가 ALERT 파일에 기록됩니다. 기본값은 FLASE 입니다.
'오래된글 > DataBase' 카테고리의 다른 글
PLT 2.2 Index (0) | 2018.04.17 |
---|---|
PLT 1.3 롤백 세그먼트 (ROLLBACK SEGMENTS) (0) | 2018.04.17 |
Oracle User Defined Object을 이용한 Table Return Function (0) | 2018.04.17 |
Oracle 중요 Hint (0) | 2018.04.17 |
MongoDB, mogo Shell (0) | 2018.04.17 |