Bases du cache de la mémoire tampon de base de données dans Oracle 12c

Le cache du tampon de la base de données <1299> d'Oracle 12c est généralement la plus grande partie du SGA. Il a des données qui proviennent des fichiers sur le disque. Étant donné que l'accès aux données à partir du disque est plus lent que celui de la mémoire, le seul but du cache de la mémoire tampon de la base de données est de mettre les données en cache dans la mémoire pour un accès plus rapide. Le cache du tampon de la base de données peut contenir des données provenant de tous les types d'objets:

Tables

Index
Vues matérialisées
Données système
Dans la phrase

cache de la mémoire tampon de la base de données, le terme tampon fait référence aux blocs de base de données. Un bloc de base de données est la quantité minimale de stockage qu'Oracle lit ou écrit. Tous les segments de stockage contenant des données sont constitués de blocs. Lorsque vous demandez des données à partir du disque, Oracle lit au moins un bloc. Même si vous ne demandez qu'une seule ligne, de nombreuses lignes de la même table sont susceptibles d'être récupérées. Il en va de même si vous demandez une colonne dans une rangée. Oracle lit le bloc entier, qui a probablement plusieurs lignes, et toutes les colonnes de cette ligne.

Il est possible de penser que si la table de votre département n'a que dix lignes, tout peut être lu en mémoire même si vous demandez le nom d'un seul département.

Etat du cache tampon dans Oracle 12c

Le cache tampon

contrôle les blocs qui restent en fonction de l'espace disponible et de l'état du bloc (similaire à la façon dont le pool partagé décide de rester). Le cache tampon utilise sa propre version de l'algorithme LRU.

Un bloc dans le cache tampon peut être dans l'un des trois états suivants:

Gratuit:

Non utilisé pour quoi que ce soit Épinglé:
Accès en cours > Dirty: Le bloc a été modifié mais pas encore écrit sur le disque
Blocs libres Idéalement, des blocs gratuits sont disponibles quand vous en avez besoin. Cependant, ce n'est probablement pas le cas à moins que votre base de données ne soit si petite que tout puisse rentrer dans la mémoire.

L'algorithme LRU fonctionne un peu différemment dans le cache tampon que dans le pool partagé. Il note chaque bloc et ensuite combien de temps il a été depuis qu'il a été accédé. Par exemple, un bloc obtient un point chaque fois qu'il est touché.

Plus les points sont élevés, moins il est probable que le bloc sera vidé de sa mémoire. Cependant, il doit être consulté fréquemment ou le score diminue. Un bloc doit travailler dur pour rester en mémoire si la concurrence pour les ressources mémoire est élevée.

L'attribution d'un score et d'un temps à chaque bloc empêche la survenue de ce type de situation: Un bloc est largement consulté à la fin du mois pour les rapports.Son score est plus élevé que tout autre bloc du système. Ce bloc n'est jamais accessible à nouveau.

Il y a un gaspillage de mémoire jusqu'à ce que la base de données soit redémarrée ou qu'un autre bloc obtienne finalement assez de points pour le battre. Le composant temporel vieillit très rapidement une fois que vous n'y avez plus accès.

Blocs épinglés

Un bloc en cours d'accès est un bloc épinglé

.

Le bloc est verrouillé (ou épinglé) dans le cache du tampon, de sorte qu'il ne peut pas être éliminé du cache tampon pendant que le processus Oracle (représentant souvent un utilisateur) y accède. Blocs défectueux Un bloc modifié est un bloc sale

.

Pour vous assurer que vos modifications sont conservées à travers les arrêts de la base de données, ces blocs sales doivent être écrits à partir du cache du tampon sur le disque. La base de données nomme les blocs sales dans une liste ou une file d'attente en écriture. Vous pourriez penser que chaque fois qu'un bloc est modifié, il doit être écrit sur le disque pour minimiser les pertes de données. Ce n'est pas le cas - même s'il y a un commit

(quand vous enregistrez vos changements de façon permanente)! Plusieurs structures aident à éviter les données perdues. De plus, Oracle a un problème de jeu. Les performances du système seraient explorées si vous écriviez des blocs sur le disque pour chaque modification. Pour lutter contre cela, Oracle joue les chances que la base de données a peu de chances d'échouer et n'écrit des blocs sur le disque que dans des groupes plus importants. Ne vous inquiétez pas; ce n'est même pas un risque contre les données perdues. Oracle récupère les performances de la base de données

en ce moment

au prix d'une récupération plus longue . Étant donné que les défaillances sur les systèmes correctement gérés se produisent rarement, il s'agit d'un moyen peu coûteux d'améliorer les performances. Cependant, ce n'est pas comme si Oracle laissait des blocs sales partout sans se nettoyer. Bloquer les déclencheurs d'écriture dans Oracle 12c Qu'est-ce qui déclenche l'écriture d'un bloc et donc un bloc sale?

La base de données reçoit une commande shutdown.

Un point de contrôle complet ou partiel se produit - c'est à ce moment-là que le système dépose périodiquement tous les tampons sales sur le disque.

Un seuil de temps de récupération, défini par vous, est atteint; le nombre total de blocs sales entraîne un temps de récupération inacceptable.
Un bloc libre est nécessaire et aucun n'est trouvé après un certain nombre de recherches.
Certaines commandes de langage de définition de données (DDL). (Les commandes DDL sont des instructions SQL qui définissent des objets dans une base de données.)
Toutes les trois secondes.
Autres raisons. L'algorithme est complexe et vous ne pouvez pas être certain de tous les changements apportés à chaque version du logiciel.
Le fait est que la base de données reste très occupée à écrire des blocs dans un environnement où il y a beaucoup de changements.