首先我们来看下什么是archive log file,oracle 11g 的concept中是这样定义的:When you enable archiving of the online redo l
首先我们来看下什么是archive log file,Oracle 11g 的concept中是这样定义的:When you enable archiving of the online redo logs, Oracle Database copies the online redo log files to another location before they are overwritten. These copied files are referred to as archived redo log files. 那么根据这个定义,archive log file就是redo log file的拷贝,既然是拷贝,在排除压缩的情况下,两种文件的大小应该是一致的。但是我们在真实环境中看到的archive log file就是redo log file却不是一样大,真实情况是archive log file比redo log file小,极端情况下,甚至会小非常多。
引起archive log file就是redo log file大小不一致的原因大致有如下几种:
一、人为操作类型
1、SQL>alter system switch logfile;
2、SQL>alter system archive log current;
3、RMAN>backup archive log all;
4、RMAN>backup database plus archivelog;
二、参数设置类型
archive_lag_target:日志切换的强制时间间隔,即只要到达该参数设置的时间间隔,无论redo 文件是否写满,都会进行日志切换。
三、oracle bug类型
BUG 9272059、BUG 10354739、BUG 12317474、BUG 5450861、BUG 7016254
下面对archive log file就是redo log file大小不一致的原因进行分析,首先,如果redo log file中是以空白结尾,那么,archive log file中会将末尾的空白去除,这就样就会出现archive log比redo log file小,具体小多少,就根据归档时redo log file末尾的空白大小决定。这种情形常见于前面提到的认为操作类型和参数设置类型。因为在进行强制切换日志的时候,redo log file是没有被写满的,文件的末尾必然存在空白。
另外,日志切换并不是发生redo log file 100%满的时候,这是由于oracle的内部算法决定的,这样做的主要目的是处于性能的考虑。所以redo log file始终不会被100%的写满,在进行归档的时候,末尾的空白会被丢弃,所以就导致了archive log file小于redo log file。影响redo log切换时间的因素有:LOG_BUFFER_SIZE参数设置、系统负载、log file size、logfile 空间分配算法。
CUP_COUNT值会影响logfile空间分配算法,所以,如果出现日志频繁切换且归档日志远小于redo log file的情况,请检查CUP_COUNT是否符合系统的实际情况。
再次,如果是RAC环境,如果各节点的负载不一致,为了保证数据库的可恢复性,空闲节点会进行一些的日志切换,主要是为了增进redo 日志的FIRST_CHANGE#,空闲节点产生的归档日志大小会与redo file大小有较大差距。下面进行验证:
--查看redo file大小
SQL> select thread#,group#,bytes/1024/1024 "size" from v$log order by 1,2;
THREAD# GROUP# size
---------- ---------- ----------
1 1 50
1 2 50
2 3 50
2 4 50
--在节点1上建立测试表
SQL> create table darren(id number,item varchar2(2));
--查看当前的归档情况和redo log的FRIST_CHANGE#
SQL> select thread#,name,blocks*block_size/1024/1024 "size" from v$archived_log order by 1,2;
THREAD# NAME size
---------- ---------------------------------------------------------------------- ----------
1 +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_10.268.861729569 1.4453125
1 +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_11.270.861730475 49.9980469
1 +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_12.271.861730509 49.9980469
1 +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_13.272.861730545 49.9980469
1 +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_14.274.861730573 49.9980469
1 +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_15.275.861730601 49.9980469
1 +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_16.276.861788401 35.8242188
2 +DATADG01/gyl/archivelog/2014_10_23/thread_2_seq_2.269.861729571 2.37207031
2 +DATADG01/gyl/archivelog/2014_10_23/thread_2_seq_3.273.861730551 .008300781
2 +DATADG01/gyl/archivelog/2014_10_24/thread_2_seq_4.277.861788403 .567871094
SQL> select GROUP#,THREAD#,SEQUENCE#,STATUS,FIRST_CHANGE# from v$log order by 2;
GROUP# THREAD# SEQUENCE# STATUS FIRST_CHANGE#
---------- ---------- ---------- ---------------- -------------
1 1 17 CURRENT 794878
2 1 16 INACTIVE 700672
3 2 5 CURRENT 794876
4 2 4 INACTIVE 517670
--在节点1上进行事务,由于是测试环境,节点2上完全没事务,是空闲实例
begin
for i in 1..500000 loop
insert into darren values(1,'aa');
commit;
end loop;
end;
--查看归档情况和redo log 的FRIST_CHANGE#
SQL> select thread#,name,blocks*block_size/1024/1024 "size" from v$archived_log order by 1,2;

MySQL 느린 쿼리를 최적화하려면 SlowQueryLog 및 Performance_Schema를 사용해야합니다. 1. SlowQueryLog 및 Set Stresholds를 사용하여 느린 쿼리를 기록합니다. 2. Performance_schema를 사용하여 쿼리 실행 세부 정보를 분석하고 성능 병목 현상을 찾고 최적화하십시오.

MySQL 및 SQL은 개발자에게 필수적인 기술입니다. 1.MySQL은 오픈 소스 관계형 데이터베이스 관리 시스템이며 SQL은 데이터베이스를 관리하고 작동하는 데 사용되는 표준 언어입니다. 2.MYSQL은 효율적인 데이터 저장 및 검색 기능을 통해 여러 스토리지 엔진을 지원하며 SQL은 간단한 문을 통해 복잡한 데이터 작업을 완료합니다. 3. 사용의 예에는 기본 쿼리 및 조건 별 필터링 및 정렬과 같은 고급 쿼리가 포함됩니다. 4. 일반적인 오류에는 구문 오류 및 성능 문제가 포함되며 SQL 문을 확인하고 설명 명령을 사용하여 최적화 할 수 있습니다. 5. 성능 최적화 기술에는 인덱스 사용, 전체 테이블 스캔 피하기, 조인 작업 최적화 및 코드 가독성 향상이 포함됩니다.

MySQL 비동기 마스터 슬레이브 복제는 Binlog를 통한 데이터 동기화를 가능하게하여 읽기 성능 및 고 가용성을 향상시킵니다. 1) 마스터 서버 레코드는 Binlog로 변경됩니다. 2) 슬레이브 서버는 I/O 스레드를 통해 Binlog를 읽습니다. 3) 서버 SQL 스레드는 데이터를 동기화하기 위해 Binlog를 적용합니다.

MySQL은 오픈 소스 관계형 데이터베이스 관리 시스템입니다. 1) 데이터베이스 및 테이블 작성 : CreateAbase 및 CreateTable 명령을 사용하십시오. 2) 기본 작업 : 삽입, 업데이트, 삭제 및 선택. 3) 고급 운영 : 가입, 하위 쿼리 및 거래 처리. 4) 디버깅 기술 : 확인, 데이터 유형 및 권한을 확인하십시오. 5) 최적화 제안 : 인덱스 사용, 선택을 피하고 거래를 사용하십시오.

MySQL의 설치 및 기본 작업에는 다음이 포함됩니다. 1. MySQL 다운로드 및 설치, 루트 사용자 비밀번호를 설정하십시오. 2. SQL 명령을 사용하여 CreateAbase 및 CreateTable과 같은 데이터베이스 및 테이블을 만듭니다. 3. CRUD 작업을 실행하고 삽입, 선택, 업데이트, 명령을 삭제합니다. 4. 성능을 최적화하고 복잡한 논리를 구현하기 위해 인덱스 및 저장 절차를 생성합니다. 이 단계를 사용하면 MySQL 데이터베이스를 처음부터 구축하고 관리 할 수 있습니다.

innodbbufferpool은 데이터와 색인 페이지를 메모리에로드하여 MySQL 데이터베이스의 성능을 향상시킵니다. 1) 데이터 페이지가 버퍼 풀에로드되어 디스크 I/O를 줄입니다. 2) 더러운 페이지는 정기적으로 디스크로 표시되고 새로 고침됩니다. 3) LRU 알고리즘 관리 데이터 페이지 제거. 4) 읽기 메커니즘은 가능한 데이터 페이지를 미리로드합니다.

MySQL은 설치가 간단하고 강력하며 데이터를 쉽게 관리하기 쉽기 때문에 초보자에게 적합합니다. 1. 다양한 운영 체제에 적합한 간단한 설치 및 구성. 2. 데이터베이스 및 테이블 작성, 삽입, 쿼리, 업데이트 및 삭제와 같은 기본 작업을 지원합니다. 3. 조인 작업 및 하위 쿼리와 같은 고급 기능을 제공합니다. 4. 인덱싱, 쿼리 최적화 및 테이블 파티셔닝을 통해 성능을 향상시킬 수 있습니다. 5. 데이터 보안 및 일관성을 보장하기위한 지원 백업, 복구 및 보안 조치.

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


핫 AI 도구

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

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

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

Clothoff.io
AI 옷 제거제

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

인기 기사

뜨거운 도구

Atom Editor Mac 버전 다운로드
가장 인기 있는 오픈 소스 편집기

Eclipse용 SAP NetWeaver 서버 어댑터
Eclipse를 SAP NetWeaver 애플리케이션 서버와 통합합니다.

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

SecList
SecLists는 최고의 보안 테스터의 동반자입니다. 보안 평가 시 자주 사용되는 다양한 유형의 목록을 한 곳에 모아 놓은 것입니다. SecLists는 보안 테스터에게 필요할 수 있는 모든 목록을 편리하게 제공하여 보안 테스트를 더욱 효율적이고 생산적으로 만드는 데 도움이 됩니다. 목록 유형에는 사용자 이름, 비밀번호, URL, 퍼징 페이로드, 민감한 데이터 패턴, 웹 셸 등이 포함됩니다. 테스터는 이 저장소를 새로운 테스트 시스템으로 간단히 가져올 수 있으며 필요한 모든 유형의 목록에 액세스할 수 있습니다.

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

뜨거운 주제



