oracle Log Buffer内部机制以及常见等待事件
重做产生于PGA,再由各个session的服务器进程将重做记录拷贝到SGA 的log buffer中,再由LGWR进程刷新到redo log文件中
重做产生于PGA,再由各个session的服务器进程将重做记录拷贝到SGA 的log buffer中,再由LGWR进程刷新到redo log文件中
涉及到的三个latch:
Redo copy latch
Redo allocation latch
Redo writing latch
Redo copy latch
redo copy latch的数量可以有多个,可以通过_log_simultaneous_copies参数来设定,,缺省值是两倍CPU的个数,
此latch保护日志缓存中的信息,主要用于从PGA拷贝重做到log buffer中,但是不允许对重做记录一边进行修改,
一边将重做记录写入磁盘。所以LGWR工作的时候,必须等待持有redo copy latch 的前台进程将要刷新的重做记录拷贝完毕
这里也就是说,LGWR从redo log buffer写到文件的时候,是无法写正在copy的redo log buffer,但是可以写不持有
Redo copy latch的log buffer。
Redo allocation latch
前台进程和LGWR都将持有该latch
Oracle把向log buffer中写缓存这样一个操作分做两个步骤:
1. 是先在log buffer中分配一块空间
2. 是向这块空间中实际的写入重做信息
当前台进行分配空间的时候,必须先持有该latch,但是该阶段该latch只有一个,所以前台进程这个时候会相互阻塞。
当LGWR进行刷新缓存时,持有该latch,当确定刷新的范围后,那么就会写到磁盘,写磁盘前会释放该latch
Redo writing latch
当日志缓存没空间分配时,前台进程必须通知LGWR刷新日志缓存,只有第一个得到此latch的进程通知LGWR,
用来阻止其他进程通知LGWR,通知后,马上释放该latch,不会一直占用。LGWR得到通知,持有该latch,
写入磁盘文件前释放该latch。
重做产生的流程:
1.先在PGA中生成重做记录,并计算出重做记录大小
2.由服务器进程申请redo copy latch如果成功的话继续
3.再去申请redo allocation,成功分配空间后
4.释放redo allocation
5.开始把PGA中的重做记录写往log buffer
6.记录写完后,释放redo copy latch
_log_io_size:如果使用的log buffer大小等于或者大于该值,那么就触发LGWR写磁盘,缺省大小为log buffer的1/3,上限值为1M
redo buffer等待事件:
LOG BUFFER SPACE:
redo copy的速度快于LGWR,造成free log buffer总是不够用
原因:
LOG BUFFER太小,总没有空间copy
LOG BUFFER太大,但是录入的太频繁
提高LGWR写的效率,以及磁盘的IO性能
log file parallel write
此等待事件是LGWR将log buffer写到在线日志文件,重用log buffer。
解决方法:
减少日志的生成(NOLOGGING)
减少日志组成员数
避免在备份模式下做大量的事务
尽量用最小的辅助日志模式(Supplemental Logging),如在LOGMINER下分析日志.
日志组成员分布在不同的物理磁盘上
不要将在线日志存放在RAID5上
尽量使用裸设备
Log file sync
事物提交时,一个进程创建一个重做记录,LGWR从log buffer写到磁盘,当再次发出commit,前面的LGWR还没有完成,会造成log file sync等待
原因:
过度频繁的提交
CPU使用过度
bug
如果log file sync接近log file parallel write,那么冲突可能是日志IO问题,如果远大于,则IO不是主要问题
Log file switch(checkpoint incomplete)
当日志切换的时候,要覆盖一个检查点未完成的的日志造成的等待
解决办法:
IO有严重问题,增加DBWR的效率,提高磁盘IO性能
增大日志文件
增加日志组
Log file switch (archiving needed)
如果是归档模式存在此等待,那就是归档的速度慢,可以调整归档日志所在磁盘的性能,调整log_archive_max_processes。
log file sequential read
当redo进行归档时,会顺序读取redo日志,会造成此等待

핫 AI 도구

Undresser.AI Undress
사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover
사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool
무료로 이미지를 벗다

Clothoff.io
AI 옷 제거제

AI Hentai Generator
AI Hentai를 무료로 생성하십시오.

인기 기사

뜨거운 도구

메모장++7.3.1
사용하기 쉬운 무료 코드 편집기

SublimeText3 중국어 버전
중국어 버전, 사용하기 매우 쉽습니다.

스튜디오 13.0.1 보내기
강력한 PHP 통합 개발 환경

드림위버 CS6
시각적 웹 개발 도구

SublimeText3 Mac 버전
신 수준의 코드 편집 소프트웨어(SublimeText3)

뜨거운 주제











이 기사는 MySQL의 Alter Table 문을 사용하여 열 추가/드롭 테이블/열 변경 및 열 데이터 유형 변경을 포함하여 테이블을 수정하는 것에 대해 설명합니다.

InnoDB의 전체 텍스트 검색 기능은 매우 강력하여 데이터베이스 쿼리 효율성과 대량의 텍스트 데이터를 처리 할 수있는 능력을 크게 향상시킬 수 있습니다. 1) InnoDB는 기본 및 고급 검색 쿼리를 지원하는 역 색인화를 통해 전체 텍스트 검색을 구현합니다. 2) 매치 및 키워드를 사용하여 검색, 부울 모드 및 문구 검색을 지원합니다. 3) 최적화 방법에는 워드 세분화 기술 사용, 인덱스의 주기적 재건 및 캐시 크기 조정, 성능과 정확도를 향상시키는 것이 포함됩니다.

기사는 인증서 생성 및 확인을 포함하여 MySQL에 대한 SSL/TLS 암호화 구성에 대해 설명합니다. 주요 문제는 자체 서명 인증서의 보안 영향을 사용하는 것입니다. [문자 수 : 159]

기사는 MySQL Workbench 및 Phpmyadmin과 같은 인기있는 MySQL GUI 도구에 대해 논의하여 초보자 및 고급 사용자를위한 기능과 적합성을 비교합니다. [159 자].

기사는 MySQL에서 파티셔닝, 샤딩, 인덱싱 및 쿼리 최적화를 포함하여 대규모 데이터 세트를 처리하기위한 전략에 대해 설명합니다.

클러스터 인덱스와 비 클러스터 인덱스의 차이점은 1. 클러스터 된 인덱스는 인덱스 구조에 데이터 행을 저장하며, 이는 기본 키 및 범위별로 쿼리에 적합합니다. 2. 클러스터되지 않은 인덱스는 인덱스 키 값과 포인터를 데이터 행으로 저장하며 비 예산 키 열 쿼리에 적합합니다.

이 기사에서는 Drop Table 문을 사용하여 MySQL에서 테이블을 떨어 뜨리는 것에 대해 설명하여 예방 조치와 위험을 강조합니다. 백업 없이는 행동이 돌이킬 수 없으며 복구 방법 및 잠재적 생산 환경 위험을 상세하게합니다.

전체 테이블 스캔은 MySQL에서 인덱스를 사용하는 것보다 빠를 수 있습니다. 특정 사례는 다음과 같습니다. 1) 데이터 볼륨은 작습니다. 2) 쿼리가 많은 양의 데이터를 반환 할 때; 3) 인덱스 열이 매우 선택적이지 않은 경우; 4) 복잡한 쿼리시. 쿼리 계획을 분석하고 인덱스 최적화, 과도한 인덱스를 피하고 정기적으로 테이블을 유지 관리하면 실제 응용 프로그램에서 최상의 선택을 할 수 있습니다.
