로그가 사용되는 로거 버퍼 크기

문제 분석을 용이하게 하기 위해 엔지니어에게 피드백 사용 정보 및 기록을 제공하는 기능입니다(개발 중에 사용). 사용자 자신은 업로드 로그를 자주 생성하지 않으므로 사용자에게는 쓸모가 없습니다. 로깅 버퍼는 디스크에 기록될 리두 로그에 대한 변경 벡터의 단기 저장에 사용되는 작은 임시 영역입니다. 디스크에 대한 로그 버퍼 쓰기는 여러 트랜잭션의 변경 벡터 배치입니다. 그럼에도 불구하고 로그 버퍼의 변경 벡터는 거의 실시간으로 디스크에 기록되며, 세션에서 COMMIT 문을 발행하면 로그 버퍼 쓰기 작업이 실시간으로 수행됩니다.

이 튜토리얼의 운영 환경: Windows 7 시스템, Dell G3 컴퓨터.

로그 레코더 버퍼 크기 로그의 목적은 주로 문제 분석을 용이하게 하기 위해 엔지니어에게 사용 정보 및 기록을 피드백하는 데 사용됩니다(개발 중에 사용). 사용자 자신은 업로드 로그를 자주 생성하지 않으므로 사용자에게 쓸모가 없습니다.

로깅 버퍼는 디스크에 기록될 리두 로그에 대한 변경 벡터를 단기적으로 저장하는 데 사용되는 작은 임시 영역입니다. "변경 벡터"는 특정 개체에 적용되는 수정 사항입니다. DML 문을 실행하면 데이터에 적용되는 변경 벡터가 생성됩니다.

리두 로그를 사용하면 데이터베이스는 데이터가 손실되지 않도록 보장할 수 있습니다. 데이터 블록이 변경될 때마다 블록에 적용된 변경 벡터가 리두 로그에 기록되고, 데이터 파일을 복원해야 하는 경우 이를 통해 전달됩니다. 리두 로그에서 변경 벡터를 추출하여 데이터 파일 백업에 적용할 수 있습니다.

세션 서버 프로세스는 리두 로그 파일에 직접 리두 레코드를 기록하지 않습니다. 그렇지 않으면 세션은 DML 문이 실행될 때마다 디스크 I/O 작업이 완료될 때까지 기다려야 합니다. 대신 세션은 리두 레코드를 메모리 내 로그 버퍼에 기록합니다. 이는 디스크에 쓰는 것보다 훨씬 빠릅니다. 그런 다음 로그 버퍼(여러 세션에 대한 교대 변경 벡터를 포함할 수 있음)가 리두 로그 파일에 기록됩니다. 따라서 디스크에 대한 로그 버퍼 쓰기는 여러 트랜잭션의 변경 벡터 배치입니다. 그럼에도 불구하고 로그 버퍼의 변경 벡터는 거의 실시간으로 디스크에 기록되며, 세션에서 COMMIT 문을 발행하면 로그 버퍼 쓰기 작업이 실시간으로 수행됩니다. 쓰기 작업은 LGWR(로그 기록기 백그라운드 프로세스)에 의해 수행됩니다.

특징

다른 메모리 구조에 비해 로그 버퍼는 매우 짧은 저장 영역이기 때문에 크기가 더 작습니다. 변경 벡터를 여기에 삽입하고 거의 실시간으로 디스크에 흐르게 합니다. 로그 버퍼는 최대 몇 MB보다 클 필요는 없으며 실제로 기본값보다 크게 설정하면 성능에 매우 나쁜 영향을 미칠 수 있습니다. 기본값은 Oracle 서버에 의해 결정되며 서버 노드의 CPU 수에 따라 달라집니다.

개발자 옵션에는 "로거 버퍼 크기"라는 옵션이 있습니다. 기본값은 256K입니다. 로그는 순환 방식으로 버퍼에 기록되며 가득 찬 로그는 삭제됩니다. 새 로그를 위한 공간.

로거 버퍼의 크기는 일반적으로 개인에 따라 조정됩니다. 더 빠르게 정리하려면 작게 설정해도 됩니다. 크게 신경쓰지 않는다면 100 정도 정도로 조금 더 크게 설정해도 됩니다.

이론적으로 특정 값 내에서는 클수록 좋습니다(열 수 있는 애플리케이션 레이어 수를 결정하기 때문입니다).

사용자 스스로는 업로드 로그를 자주 생성하지 않기 때문에 최소한으로 조정할 필요는 없습니다. 사용자는 기본 설정을 사용할 수 있습니다. 예를 들어, 높은 장치 구성의 경우 사용자의 개인 요구 사항을 충족하기 위해 기본값 또는 최대값을 늘릴 수 있습니다.

설정방법

로그 버퍼는 기본값보다 작게 설정할 수 없습니다. 이렇게 하면 로그 버퍼가 기본 크기로 설정됩니다. 기본값보다 큰 버퍼를 생성하는 것이 가능하지만 일반적으로 권장되지 않습니다. 문제는 COMMIT 문이 실행될 때 커밋 처리의 일부에 로그 버퍼 내용을 디스크의 리두 로그 파일에 쓰는 작업이 포함된다는 것입니다. 쓰기 작업은 실시간으로 수행되며, 진행되는 동안 COMMIT를 실행한 세션이 중단됩니다. 커밋 처리는 Oracle 아키텍처의 핵심 부분입니다. 커밋된 트랜잭션이 손실되지 않도록 하기 위해 데이터 블록이 변경되고(트랜잭션이 완료되었음을 의미) 변경 벡터가 디스크의 리두 로그에 기록될 때까지 캐시의 데이터 블록을 변경할 수 없습니다. 필요한 경우 트랜잭션을 복원할 수 있습니다.) 커밋 완료 메시지를 세션에 반환합니다. 로그 버퍼가 크다는 것은 COMMIT 문이 실행될 때 더 많은 콘텐츠를 작성해야 하며 커밋 메시지가 완료되고 세션이 작업을 재개하는 데 시간이 더 오래 걸린다는 것을 의미합니다.

설명:

• 일부 애플리케이션의 경우 로그 버퍼 크기를 기본값보다 크게 설정해야 하지만 일반적으로 튜닝을 시작하려면 기본 로그 버퍼를 사용합니다.

• 로그 버퍼는 인스턴스가 시작될 때 할당되며 이후에 인스턴스를 다시 시작하지 않으면 크기를 조정할 수 없습니다. 순환 버퍼입니다. 현재 쓰기 주소는 서버 프로세스가 변경 벡터를 쓸 때 앞뒤로 이동합니다. 로그 기록기 프로세스는 벡터를 일괄적으로 작성하며, 이 시점에서 벡터가 차지하는 공간을 사용할 수 있게 되고 더 많은 변경 벡터로 처리할 수 있습니다. 활동이 가장 많은 시간에는 변경 벡터가 로그 기록기 프로세스에서 기록할 수 있는 것보다 빠르게 생성될 수 있습니다. 이런 일이 발생하면 로그 기록기가 버퍼를 지우는 동안 모든 DML 활동이 몇 밀리초 동안 중지됩니다.

• Oracle 아키텍처에서 로그 버퍼를 디스크에 덤프하는 것은 기본적인 병목 현상 중 하나입니다. DML은 LGWR이 변경 벡터를 온라인 리두 로그 파일에 덤프할 수 있는 것보다 빠를 수 없습니다.

• 리두 생성이 데이터베이스 성능을 제한하는 요소라면 유일한 옵션은 RAC를 사용하는 것입니다. RAC 데이터베이스에서 각 인스턴스에는 자체 로그 버퍼와 LGWR이 있습니다. 이는 리두 데이터를 디스크에 병렬로 쓰는 유일한 방법입니다.

로거 버퍼에 대한 참고 사항:

1. 크기 설정: 일부 응용 프로그램의 경우 로그 버퍼 크기를 기본값보다 높게 설정해야 하지만 일반적으로 기본 로그 버퍼가 사용됩니다. 조정을 시작합니다.

2. 인스턴스 할당: 인스턴스가 시작될 때 로그 버퍼가 할당됩니다. 인스턴스를 다시 시작하지 않으면 이후에 크기를 조정할 수 없습니다. 순환 버퍼입니다. 현재 쓰기 주소는 서버 프로세스가 변경 벡터를 쓸 때 앞뒤로 이동합니다.

3. 일괄 처리: 로그 작성 프로세스는 일괄 모드로 벡터를 작성합니다. 이때 차지하는 공간은 더 많은 변경 벡터로 처리될 수 있습니다. 활동이 가장 많은 시간에는 변경 벡터가 로그 기록기 프로세스에서 기록할 수 있는 것보다 빠르게 생성될 수 있습니다. 이런 일이 발생하면 로그 기록기가 버퍼를 지우는 동안 모든 DML 활동이 몇 밀리초 동안 중지됩니다.

관련 지식이 더 궁금하시다면 FAQ 칼럼을 방문해 주세요!

위 내용은 로그가 사용되는 로거 버퍼 크기의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!