Quelques questions de base sur les SGBDR

Question

J'ai parcouru Date et Silberschatz, mais je n'arrive pas à trouver de réponses à ces questions spécifiques.

1. Si 2 utilisateurs de base de données émettent une requête - par exemple, 'select * from AVERYBIGTABLE;' - Où les résultats de la requête seraient-ils stockés en général ... c'est-à-dire indépendamment de la taille du jeu de résultats?

   a. Dans la mémoire physique / virtuelle gérée par le système d’exploitation du serveur SGBD?

   b. Dans un fichier temporaire géré par un SGBD?

2. L'ensemble de résultats de la requête est-il conservé par connexion?

3. Si le jeu de résultats de la requête est effectivement conservé par connexion, que se passe-t-il si le regroupement de connexions est effectif (par une couche de code située au-dessus du SGBD)? Le jeu de résultats ne sera-t-il pas conservé par requête (au lieu de par connexion)?

4. Si la base de données change en temps réel alors que ses utilisateurs émettent simultanément des requêtes sélectionnées, qu'advient-il des requêtes qui ont déjà été exécutées mais pas encore (entièrement) «consommées» par les émetteurs de la requête? Par exemple, supposons que le jeu de résultats comporte 50 000 lignes; l'utilisateur itère actuellement à la centième position, lorsqu'un autre utilisateur exécute parallèlement une insertion / suppression telle que cela conduirait à plus / moins de 50 000 lignes si la requête précédente devait être réémise par un utilisateur du SGBD?

5. D'un autre côté, dans le cas d'une base de données qui ne change pas en temps réel, si 2 utilisateurs émettent des requêtes identiques, chacune avec des ensembles de résultats identiques mais TRÈS GRANDS, le SGBD conserverait-il deux copies identiques de l'ensemble de résultats, ou aurait-il une seule copie partagée?

Merci d'avance.

Answer 1

Certaines de ces informations peuvent être spécifiques à Oracle.

1. Il n'est pas nécessaire de copier les résultats complets de la requête. Chaque utilisateur obtient un curseur (semblable à un pointeur) qui gère les lignes extraites et celles qu'il reste à extraire. La base de données mettra en cache autant de données qu’elle le pourra car elle lira les données hors des tables. Le même principe que deux utilisateurs ont un handle de fichier en lecture seule.

2. Les curseurs sont conservés par connexion, les données de la ligne suivante peuvent ou non être déjà en mémoire.

3. Les connexions sont pour la plupart à un seul thread, un seul client peut utiliser une connexion à la fois. Si la même requête est exécutée deux fois sur la même connexion, la position du curseur est réinitialisée.

4. Si un curseur est ouvert sur une table en cours de mise à jour, les anciennes lignes sont copiées dans un espace séparé (annulé dans Oracle) et sont conservées pendant toute la vie du curseur, ou du moins jusqu'à épuisement espace pour le maintenir. (Oracle donnera une erreur d’instantané trop ancienne)

5. La base de données ne dupliquera jamais les données stockées dans le cache. Dans le cas d'Oracle avec partage du curseur, il n'y aurait qu'un seul curseur en cache et chaque curseur client n'aurait plus qu'à conserver sa position dans le curseur en cache.

Concepts de base de données Oracle

Voir 8 Mémoire pour les questions 1, 2, 5

Voir 13 Concurrence et cohérence des données (questions 3 et 4)

Answer 2

Si vous ne trouvez pas cela dans Date, etc., c'est parce qu'ils peuvent changer de produit de SGBD. La théorie des modèles relationnels ne contient aucune information sur la mise en pool des connexions à la base de données ni sur la gestion des jeux de résultats à partir d'une requête (comme la mise en cache). etc). Le seul point qui est partiellement couvert est le point 4 - où le niveau de lecture entrerait en jeu (par exemple, lecture non validée), mais cela ne s'applique que jusqu'à ce que le jeu de résultats ait été généré.