데이터 베이스 MySQL 튜토리얼 Oracle性能优化 之 保留区与ORA-04031

Oracle性能优化 之 保留区与ORA-04031

Jun 07, 2016 pm 04:46 PM

一、保留区 没有被PIN住大对象的加载、老化将会使共享池产生碎片,Oracle想了个方法解决这个问题,它专门在共享池开辟一块区域,

一、保留区

没有被PIN住大对象的加载、老化将会使共享池产生碎片,Oracle想了个方法解决这个问题,它专门在共享池开辟一块区域,所有大小超过4400字节的对象,将在此专门开辟的区域中分配空间,这块区域被称为保留区。这样,让大对象和小对象分开存储,可以减少大对象的加载、老化以大量小对象产生的影响,并且可以减少小对象区域内的内存碎片。而且Oracle针对保留区设计了专门的内存管理算法,使得大对象可以更快速的加载。

你可以使用shared_pool_reserved_size参数设置此保留区的大小,,默认情况下,保留区将被自动设置为共享池大小的5%。另外,保留区大小不能设置为超过共享池大小的一半,否则将会报出错误。通常情况下,保留区的大小保留默认值就行,我们一般不需要调节它。

关于进入保留区对象的大小,Oracle更不建议我们调节它。但有时4400这个值对我们的系统可能并不合适。假设经常4000字节左右(不到4400)的对象被加载到共享池中,三、四千字节的对象,已经是大对象了,并且这些大对象很少使用,这样将它们PIN在内存中有点浪费空间,不到4400的大小使得它们无法被加载到保留区,这些对象每次执行时的加载需要老化很多小对象,并且还很容易造成共享池的碎片。这时,我们可以调低4400这个限制值,比如我们可以将保留区的限制降到3500,这样可以让那些本来不能进入保留区的对象可以进入保留区。这不旦可以加快这些对象的加载速度,重要的是减少了它们对众多小对象的影响。我们可以通过V$DB_ OBJECT_CACHE观察对象在共享池中所占用的内存大小,如果发现上述情况,可以调低4400这个限制值。这个限制是用一个隐藏参数来设置的:_shared_pool_reserved_min_alloc。凡是参数名前带有下划线的,都被称为隐藏参数,这些隐藏参数不能通过Show parameter显示,我们可以使用我写的脚本Show_para.sql显示隐藏参数和它们的意义,此脚本的编写见本章末尾的附录部分。

有一个视图可以用来帮助调节保留区:V$SHARED_POOL_RESERVED,它有如下的列:

FREE_SPACE:保留区中自由空间的总和

AVG_FREE_SIZE:每个自由内存块的平均大小

FREE_COUNT:自由的内存块数量

MAX_FREE_SIZE:最大的自由内存块大小

USED_SPACE:保留区中已使用的空间大小

AVG_USED_SIZE:每个已经使用的内存块的平均大小

USED_COUNT:已使用的内存块数量

MAX_USED_SIZE:已使用的最大的内存块大小

REQUESTS:在保留区中搜索自由内存块的次数

REQUEST_MISSES:保留区中没有可以满足要求的内存块并开始在保留区中LRU链中刷新对象的次数

LAST_MISS_SIZE:最后一次出现REQUEST_MISSES时,所请求的空间大小

MAX_MISS_SIZE:最大一次出现REQUEST_MISSES时,所请求的空间大小

下面的列即使SHARED_POOL_RESERVED_SIZE没有被设置也是有效的:

REQUEST_FAILURES:无论保留区还是非保留区,没有可以满足要求的内存的次数(也就是ORA-4031错误发生的次数)

LAST_FAILURE_SIZE:最后一次REQUEST_FAILURES时所请求的内存大小

后三列相关DBMS_SHARED_POOL.ABORTED_REQUEST_THRESHOLD过程。

ABORTED_REQUEST_THRESHOLD:最小的超过DBMS_SHARED_POOL.ABORTED_REQUEST_THRESHOLD设置值的大小

ABORTED_REQUESTS:超过DBMS_SHARED_POOL.ABORTED_REQUEST_THRESHOLD的次数

LAST_ABORTED_SIZE:最后一次超过DBMS_SHARED_POOL.ABORTED_REQUEST_THRESHOLD时的大小。

注意,如果REQUEST_FAILURES大于0且持续增加时,说明用户要求大小为N的内存块,但共享池内已经没有大小超过N的内存块。当REQUEST_FAILURES增加的比较快时,用户的操作将会失败并收到著名的ORA-04031错误,就是“共享池内存不足”,通常还有一句“不能申请大于N字节的内存块”。

造成这种情况有三种原因,一是内存的确不足了,这个时候你要增加内存。二是共享池中还有内存,但都是小块,没有大小超过N字节的内存块以满足用户的请求,也就是说内存中有碎片了。关于共享池内存碎片的解决方法,我们马上就说。再来看第三种情况,三是共享池中还有内存,但因为保留区设置的不合理,用户要在普通区中请求内存(用户请求的内存大小未超过4400),而普通区中已经没有自由内存了,但保留区中还有很多空闲。或者情况相反,用户在保留区中请求内存,保留区内存已经不足,但普通区中仍有大量内存空余。

当4031错误出现时,你的情况是否属于第三种―――保留设置不合理,可以通过本节所介绍的视图得知。下面我们分别介绍一下普通区空间不足和保留区空间不足这两种情况的监测和解决:

(一) 、普通区内存空间不足:

REQUEST_FAILURES不为0且持续增加时,如果LAST_FAILURE_SIZE

FREE_SPACE:保留区中自由空间的总和

AVG_FREE_SIZE:每个自由内存块的平均大小

FREE_COUNT:自由的内存块数量

MAX_FREE_SIZE:最大的自由内存块大小

USED_SPACE:保留区中已使用的空间大小

AVG_USED_SIZE:每个已经使用的内存块的平均大小

USED_COUNT:已使用的内存块数量

MAX_USED_SIZE:已使用的最大的内存块大小

如果FREE_SPACE显示的自由空间还有很多,就说明保留区中仍有大量空间,完全可以将_SHARED_POOL_RESERVED_MIN_ALLOC设置的小一些,或减少保留区所占内存。

如果保留区中空间也不是太足了,就需要检查共享池中是否碎片太多,如果不是碎片的问题,就只有增大共享池大小了。关于碎片我们马上就讨论。

(二) 、保留区空间不足

当REQUEST_FAILURES不为0且持续增加时,LAST_FAILURE_SIZE > _SHARED_POOL_RESERVED_MIN_ALLOC,就说明用户所请求的内存要在保留区中分配,而保留区这时的空间已经不足已满足用户的请求了。

这时我们可以加大_SHARED_POOL_RESERVED_MIN_ALLOC的限制值,减少进入保留区的对象数。将SHARED_POOL_RESERVED_SIZE参数的值设大一些,以增加保留区大小。当然,如果你的主机上仍有空余内存,也可以增大共享池内存大小。

linux

본 웹사이트의 성명
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.

핫 AI 도구

Undresser.AI Undress

Undresser.AI Undress

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

AI Clothes Remover

AI Clothes Remover

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

Undress AI Tool

Undress AI Tool

무료로 이미지를 벗다

Clothoff.io

Clothoff.io

AI 옷 제거제

Video Face Swap

Video Face Swap

완전히 무료인 AI 얼굴 교환 도구를 사용하여 모든 비디오의 얼굴을 쉽게 바꾸세요!

뜨거운 도구

메모장++7.3.1

메모장++7.3.1

사용하기 쉬운 무료 코드 편집기

SublimeText3 중국어 버전

SublimeText3 중국어 버전

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

스튜디오 13.0.1 보내기

스튜디오 13.0.1 보내기

강력한 PHP 통합 개발 환경

드림위버 CS6

드림위버 CS6

시각적 웹 개발 도구

SublimeText3 Mac 버전

SublimeText3 Mac 버전

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

MySQL에서 인덱스를 사용하는 것보다 전체 테이블 스캔이 더 빠를 수 있습니까? MySQL에서 인덱스를 사용하는 것보다 전체 테이블 스캔이 더 빠를 수 있습니까? Apr 09, 2025 am 12:05 AM

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

InnoDB 전체 텍스트 검색 기능을 설명하십시오. InnoDB 전체 텍스트 검색 기능을 설명하십시오. Apr 02, 2025 pm 06:09 PM

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

Windows 7에 MySQL을 설치할 수 있습니까? Windows 7에 MySQL을 설치할 수 있습니까? Apr 08, 2025 pm 03:21 PM

예, MySQL은 Windows 7에 설치 될 수 있으며 Microsoft는 Windows 7 지원을 중단했지만 MySQL은 여전히 ​​호환됩니다. 그러나 설치 프로세스 중에 다음 지점이 표시되어야합니다. Windows 용 MySQL 설치 프로그램을 다운로드하십시오. MySQL의 적절한 버전 (커뮤니티 또는 기업)을 선택하십시오. 설치 프로세스 중에 적절한 설치 디렉토리 및 문자를 선택하십시오. 루트 사용자 비밀번호를 설정하고 올바르게 유지하십시오. 테스트를 위해 데이터베이스에 연결하십시오. Windows 7의 호환성 및 보안 문제에 주목하고 지원되는 운영 체제로 업그레이드하는 것이 좋습니다.

MySQL : 쉽게 학습하기위한 간단한 개념 MySQL : 쉽게 학습하기위한 간단한 개념 Apr 10, 2025 am 09:29 AM

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

InnoDB에서 클러스터 된 인덱스와 비 클러스터 된 인덱스 (2 차 지수)의 차이. InnoDB에서 클러스터 된 인덱스와 비 클러스터 된 인덱스 (2 차 지수)의 차이. Apr 02, 2025 pm 06:25 PM

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

MySQL과 Mariadb가 공존 할 수 있습니다 MySQL과 Mariadb가 공존 할 수 있습니다 Apr 08, 2025 pm 02:27 PM

MySQL 및 MariaDB는 공존 할 수 있지만주의해서 구성해야합니다. 열쇠는 각 데이터베이스에 다른 포트 번호와 데이터 디렉토리를 할당하고 메모리 할당 및 캐시 크기와 같은 매개 변수를 조정하는 것입니다. 연결 풀링, 애플리케이션 구성 및 버전 차이도 고려해야하며 함정을 피하기 위해 신중하게 테스트하고 계획해야합니다. 두 개의 데이터베이스를 동시에 실행하면 리소스가 제한되는 상황에서 성능 문제가 발생할 수 있습니다.

MySQL 사용자와 데이터베이스의 관계 MySQL 사용자와 데이터베이스의 관계 Apr 08, 2025 pm 07:15 PM

MySQL 데이터베이스에서 사용자와 데이터베이스 간의 관계는 권한과 테이블로 정의됩니다. 사용자는 데이터베이스에 액세스 할 수있는 사용자 이름과 비밀번호가 있습니다. 권한은 보조금 명령을 통해 부여되며 테이블은 Create Table 명령에 의해 생성됩니다. 사용자와 데이터베이스 간의 관계를 설정하려면 데이터베이스를 작성하고 사용자를 생성 한 다음 권한을 부여해야합니다.

다양한 유형의 MySQL 인덱스 (B-Tree, Hash, Full-Text, Spatial)를 설명하십시오. 다양한 유형의 MySQL 인덱스 (B-Tree, Hash, Full-Text, Spatial)를 설명하십시오. Apr 02, 2025 pm 07:05 PM

MySQL은 B-Tree, Hash, Full-Text 및 Spatial의 4 가지 인덱스 유형을 지원합니다. 1.B- 트리 색인은 동일한 값 검색, 범위 쿼리 및 정렬에 적합합니다. 2. 해시 인덱스는 동일한 값 검색에 적합하지만 범위 쿼리 및 정렬을 지원하지 않습니다. 3. 전체 텍스트 색인은 전체 텍스트 검색에 사용되며 다량의 텍스트 데이터를 처리하는 데 적합합니다. 4. 공간 지수는 지리 공간 데이터 쿼리에 사용되며 GIS 응용 프로그램에 적합합니다.

See all articles