Maison >base de données >Oracle >Résumer et organiser l'allocation de mémoire et le réglage de l'apprentissage Oracle

Résumer et organiser l'allocation de mémoire et le réglage de l'apprentissage Oracle

WBOY
WBOYavant
2022-03-11 18:17:383022parcourir

Cet article vous apporte des connaissances pertinentes sur Oracle, qui présente principalement les problèmes liés à l'allocation et au réglage de la mémoire. La mémoire d'Oracle peut être divisée en zone globale du système et en zone globale de processus du point de vue partagé et privé. Examinons-les ensemble. J'espère que cela sera utile à tout le monde.

Résumer et organiser l'allocation de mémoire et le réglage de l'apprentissage Oracle

Tutoriel recommandé : "Oracle Learning Tutorial"

1. Présentation

La mémoire d'Oracle peut être divisée en zone globale du système et en zone globale de processus du point de vue partagé et privé, c'est-à-dire SGA. et PGA (zone globale de processus ou zone globale privée). Pour la mémoire de la zone SGA, elle est partagée globalement. Sous UNIX, un segment de mémoire partagée (peut être un ou plusieurs) doit être défini pour Oracle, car Oracle est un multi-processus sous UNIX alors que sous WINDOWS, Oracle est unique. processus (plusieurs threads), il n’est donc pas nécessaire de configurer des segments de mémoire partagée. PGA est une zone privée de processus (thread). Lorsque Oracle utilise le mode serveur partagé (MTS), une partie du PGA, c'est-à-dire l'UGA, sera placée dans la mémoire partagée large_pool_size.

Postez une photo de la composition de l'architecture mémoire Oracle Vous pouvez voir les paramètres clés et les noms des paramètres en un coup d'œil selon l'affichage sur la photo :

Pour la partie SGA, nous pouvons. voyez-le via la requête sqlplus :

SQL> select * from v$sga; 
  
NAME                VALUE 
  
----------             --------------------
  
Fixed Size                   454032 
  
Variable Size             109051904 
  
Database Buffers             385875968 
  
Redo Buffers                667648

Taille fixe :

Oracle peut être différent selon les plates-formes et les versions, mais il s'agit d'une valeur fixe pour un certain environnement. Il stocke des informations sur chaque composant de SGA et peut être considéré comme un domaine pour guider la création de SGA.

Taille variable :

Contient shared_pool_size, java_pool_size, large_pool_size et d'autres paramètres de mémoire

Tampons de base de données :

fait référence au tampon de données :

Dans 8i, il comprend trois parties de mémoire : db_block_buffer*db_block_size, buffer_pool_keep et buffer_pool_recycle.​ ​

Dans 9i, il comprend db_cache_size, db_keep_cache_size, db_recycle_cache_size, db_nk_cache_size.

Refaire les tampons :

fait référence au tampon de journal, log_buffer. Un point supplémentaire à noter ici est que les valeurs de requête pour v$parameter, v$sgastat et v$sga peuvent être différentes. La valeur du paramètre v$ fait référence à l'initiale de l'utilisateur

La valeur définie dans le fichier de paramètres d'initialisation, v$sgastat est la taille du tampon de journal réellement allouée par Oracle (car la valeur d'allocation du tampon est en fait discrète et elle n'est pas allouée en bloc comme la plus petite unité),

La valeur interrogée dans v$sga est après qu'Oracle ait alloué le tampon de journal, afin de protéger le tampon de journal, certaines pages de protection sont configurées. Habituellement, nous constatons que la taille de la page de protection est d'environ 11 Ko (cela peut. être différent dans différents environnements).​ ​

2. Paramètres et réglages internes du SGA : ​ ​ ​ ​

2.1 Log_buffer

Je ne pense généralement pas qu'il y ait trop de suggestions pour définir la taille du tampon de journal, car après avoir fait référence aux conditions de déclenchement écrites par LGWR, nous constaterons que dépasser généralement 3M n'est pas très significatif. En tant que système formel,

Vous pouvez d'abord envisager de définir cette partie sur log_buffer=3-5M, puis de l'ajuster en fonction de la situation spécifique.

log_buffer est le tampon du Redo log.

Donc ici, vous devez comprendre l'événement déclencheur (LGWR) du Redo Log

1 Lorsque la capacité du tampon de journalisation atteint 1/3

2. atteint, généralement c'est 3 secondes.

3. La capacité de journalisation dans le tampon de journalisation atteint 1M

4 Avant que DBWn n'écrive les données dans le tampon dans le fichier de données

5.

La conclusion ci-dessus peut être dite en d'autres termes

1 Lorsque le contenu de log_buffer est plein à 1/3, le cache est actualisé une fois.

2. L'intervalle maximum est de 3 secondes, le cache est rafraîchi une fois

3 Les données dans log_buffer atteignent 1M, le cache est rafraîchi une fois.

4. Chaque fois qu'une "transaction" est soumise, le cache est actualisé

2.2 Large_pool_size

Pour la configuration d'un grand pool tampon, si MTS n'est pas utilisé, il est recommandé que 20-30M suffisent. Cette partie est principalement utilisée pour sauvegarder certaines informations lors de requêtes parallèles, et peut être utilisée par RMAN lors de la sauvegarde.

Si MTS est configuré, puisque la partie UGA sera déplacée ici, la taille de cette partie doit être prise en compte de manière globale en fonction du nombre de processus serveur et des paramètres de mémoire de session associés.

2.3 Java_pool_size

Si la base de données n'utilise pas JAVA, nous pensons généralement qu'en conserver 10 à 20 Mo est suffisant. En fait, cela peut être inférieur, voire au moins 32 Ko, mais cela dépend des composants lors de l'installation de la base de données (comme le serveur http).

2.4 Shared_pool_size

La surcharge Shared_pool_size doit généralement être maintenue dans les 300 M. À moins que le système n'utilise un grand nombre de procédures stockées, de fonctions et de packages,

Les applications telles qu'Oracle erp peuvent atteindre 500 M ou même plus. Nous supposons donc un système avec 1 Go de mémoire, nous pouvons envisager

Réglez ce paramètre sur 100M. Pour les systèmes 2G, pensez à le régler sur 150M. Pour les systèmes 8G, pensez à le régler sur 200-300M

2.5SGA_MAX_SIZE

La zone SGA comprend divers tampons et mémoire. pools , et la plupart d’entre eux peuvent spécifier leur taille via des paramètres spécifiques. Cependant, en tant que ressource coûteuse, la taille de la mémoire physique d'un système est limitée.

Bien que la taille réelle de la mémoire physique n'ait pas besoin d'être liée à l'adressage de la mémoire du processeur (cela sera présenté en détail plus tard), une utilisation excessive de la mémoire virtuelle entraîne des entrées/sorties de page,

affectera grandement les performances du système et peut même provoquer un crash du système. Par conséquent, un paramètre est nécessaire pour contrôler la taille maximale de la mémoire virtuelle utilisée par SGA. Ce paramètre est SGA_MAX_SIZE. Lorsque l'instance est démarrée,

Chaque zone de mémoire alloue uniquement la taille minimale requise par l'instance. Lors des opérations ultérieures, leurs tailles sont étendues selon les besoins et leur taille totale est limitée par SGA_MAX_SIZE.

Pour le système OLTP, reportez-vous à :

Mémoire système

SGA_MAX_SIZ Valeur E

1G

400-500M

2G

1G

4G

2500M

8G

5G

2.6 PRE_PAGE_SGA

Lorsque l'instance Oracle démarre, seule la plus petite taille de chaque zone mémoire sera chargée. Et les autres mémoires SGA ne sont allouées qu'en tant que mémoire virtuelle,

Seulement lorsque le processus touche la page correspondante, elle sera remplacée dans la mémoire physique. Mais on peut espérer qu'une fois l'instance démarrée, tous les SGA

sont tous alloués à la mémoire physique. À ce stade, l'objectif peut être atteint en définissant le paramètre PRE_PAGE_SGA. La valeur par défaut de ce paramètre

est FAUX, ce qui signifie que tous les SGA ne seront pas placés en mémoire physique. Lorsqu'il est défini sur TRUE, le lancement de l'instance placera tous les SGA dans le physique

En mémoire. Cela permet à l'instance de démarrer jusqu'à son état de performances maximum, cependant, le temps de démarrage sera également plus long (car pour que tous les SGA

sont placés dans la mémoire physique et le processus Oracle doit toucher toutes les pages SGA).

2.7 LOCK_SGA

Afin de garantir que SGA est verrouillé dans la mémoire physique sans avoir à effectuer de page/sortie, il peut être contrôlé via le paramètre LOCK_SGA.

La valeur par défaut de ce paramètre est FALSE Lorsqu'il est spécifié comme TRUE, tous les SGA peuvent être verrouillés dans la mémoire physique. Bien sûr,

Certains systèmes ne prennent pas en charge le verrouillage de la mémoire, ce paramètre n'est donc pas valide.

2.8 SGA_TARGET

Ce que je veux présenter ici est un paramètre très important introduit dans Oracle10g. Avant 10g, diverses zones mémoire de SGA Les tailles de

doivent être spécifiées via leurs paramètres respectifs, et elles ne peuvent pas dépasser la valeur de la taille spécifiée par les paramètres, bien que leur somme ne puisse pas être

La limite maximale de SGA n'a pas été atteinte. De plus, une fois allouée, la mémoire de chaque zone ne peut être utilisée que par cette zone et ne peut être partagée entre elles.

Prenez les deux zones de mémoire les plus importantes dans SGA, Buffer Cache et Shared Pool. Elles ont le plus grand impact sur les performances de l'instance, .

Mais il existe une telle contradiction : lorsque les ressources mémoire sont limitées, la demande de données à mettre en cache est parfois très importante,

Afin d'améliorer l'impact du tampon, il est nécessaire d'augmenter le cache tampon. Cependant, en raison du SGA limité, il ne peut être "volé" que dans d'autres domaines - comme la réduction du pool partagé, .

Augmentez le cache tampon ; parfois de gros morceaux de code PLSQL sont analysés et stockés en mémoire, ce qui entraîne un pool partagé insuffisant,

Même une erreur 4031 se produit et le pool partagé doit être étendu. À ce stade, une intervention humaine peut être nécessaire pour récupérer la mémoire du cache tampon.

Avec cette nouvelle fonctionnalité, cette contradiction mémoire dans SGA est facilement résolue. Cette fonctionnalité est appelée gestion automatique de la mémoire partagée

(Gestion automatique de la mémoire partagée ASMM). Le seul paramètre qui contrôle cette fonctionnalité est SGA_TARGE.

Après avoir défini ce paramètre, vous n'avez pas besoin de spécifier la taille de chaque zone de mémoire. SGA_TARGET spécifie la taille de mémoire maximale que SGA peut utiliser,

La taille de chaque mémoire dans SGA est contrôlée par Oracle lui-même et n'a pas besoin d'être spécifiée manuellement. Oracle peut ajuster la taille de chaque zone à tout moment pour réaliser le système

La taille la plus raisonnable pour des performances optimales du système et contrôlez leur somme pour qu'elle soit comprise dans la valeur spécifiée par SGA_TARGET. Une fois que vous avez spécifié une valeur pour SGA_TARGET

(La valeur par défaut est 0, c'est-à-dire que ASMM n'est pas activé), la fonctionnalité ASMM est automatiquement activée.

三、oracle 内存调优办法   

当项目的生产环境出现性能问题,我们如何通过判断那些参数需要调整呢?   

3.1 检查ORACLE实例的Library Cache命中率:   

 标准:一般是大于99%                   检查方式:

select 1-(sum(reloads)/sum(pins)) "Library cache Hit Ratio" from v$librarycache;

 处理措施:    如果Library cache Hit Ratio的值低于99%,应调高shared_pool_size的大小。通过sqlplus连接数据库执行如下命令,调整shared_pool_size的大小:    

SQL>alter system flush shared_pool;
    
SQL>alter system set shared_pool_size=设定值 scope=spfile;

3.2 检查ORACLE实例的Data Buffer(数据缓冲区)命中率:   

 标准:一般是大于90%     检查方式:    

select 1 - (phy.value / (cur.value + con.value)) "HIT RATIO"
    from v$sysstat cur, v$sysstat con, v$sysstat phy
   
 where cur.name = 'db block gets'
    and con.name = 'consistent gets'
     and phy.name = 'physical reads';

处理措施:    

如果HIT RATIO的值低于90%,应调高db_cache_size的大小。通过sqlplus连接数据库执行如下命令,    

调整db_cache_size的大小    

SQL>alter system set db_cache_size=设定值 scope=spfile

3.3 检查ORACLE实例的Dictionary Cache命中率:     

标准:一般是大于95%       

检查方式:       

select 1 - (sum(getmisses) / sum(gets)) "Data Dictionary Hit Ratio"       
  from v$rowcache;

处理措施:       

如果Data Dictionary Hit Ratio的值低于95%,应调高shared_pool_size的大小。通过sqlplus连接数据库执行如下命令,调整shared_pool_size的大小:       

SQL>alter system flush shared_pool;       
SQL>alter system set shared_pool_size=设定值 scope=spfile;

3.4  检查ORACLE实例的Log Buffer命中率:     

标准:一般是小于1%       

检查方式:      

select (req.value * 5000) / entries.value "Ratio"       
  from v$sysstat req, v$sysstat entries       
 where req.name = 'redo log space requests'       
   and entries.name = 'redo entries';

处理措施:       

如果Ratio高于1%,应调高log_buffer的大小。通过sqlplus连接数据库执行如下命令,调整log_buffer的大小:       

SQL>alter system set log_buffer=设定值 scope=spfile;

3.5 检查undo_retention:     

标准:undo_retention 的值必须大于max(maxquerylen)的值       

检查方式:       

col undo_retention format a30
      
select value "undo_retention" from v$parameter where name='undo_retention';
      
select max(maxquerylen) From v$undostat Where begin_time>sysdate-(1/4);

处理措施:       

如果不满足要求,需要调高undo_retention 的值。通过sqlplus 连接数据库执行如下命令,调整undo_retention 的大小:       

SQL>alter system set undo_retention= 设定值 scope=spfile;

注:    

32bit  和 64bit  的问题    

对于 oracle 来说,存在着 32bit 与 64bit 的问题。这个问题影响到的主要是 SGA 的大小。在 32bit 的数据库下,通常 oracle 只能使用不超过 1.7G 的内存,即使我们拥有 12G 的内存,但是我们却只能使用 1.7G,这是一个莫大的遗憾。假如我们安装 64bit 的数据库,我们就可以使用很大的内存,我们几乎不可能达到上限。但是 64bit 的数据库必须安装在 64bit 的操作系统上,可惜目前 windows 上只能安装 32bit 的数据库,我们通过下面的方式可以查看数据库是 32bit 还是 64bit     

Mais sous un système d'exploitation spécifique, certains moyens peuvent être prévus, nous permettant d'utiliser plus de 1,7G de mémoire, atteignant plus de 2G voire plus.

Tutoriel recommandé : "Tutoriel Oracle"

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Déclaration:
Cet article est reproduit dans:. en cas de violation, veuillez contacter admin@php.cn Supprimer