Exercice Architecture du SGBD ORACLE
Rédigé par GC Team, Publié le 26 Avril 2010, Mise à jour le Jeudi, 12 Août 2021 19:52![](/images/thumb/122/default.png)
Exercice Architecture du SGBD ORACLE
1. Création BD GEST
Créer une base de données avec les caractéristiques suivantes :
- Nom base de données : GEST
- SID : GEST
- Trois groupes de Redologs
- Deux contrôle files
- Taille tablespace SYSTEM 100 M
2. Gestion Espace
- Créer un Tablespace permanant "Gestion"
- Taille 100 M
- Fichiers du tablespace en Autoextend ON
- Créer Tablespace permanant "INDEX"
- Taille 20 M
- Fichiers Autoextend ON
- Créer Tablespace Temporaire "TMP_TBS"
- Taille 20 M
3. Sécurité, objets et paramètres de stockage
- Créer Utilisateur PROP avec des quotas illimités sur les tablespace GESTION et INDEX
- Créer Utilisateur CONSULT
- Créer les deux tables CLIENT et COMMANDE dans le schéma de PROP dans le tablespace GESTION
- Taille initiale de chaque table est 2 Ko
- Evolution constante de chaque table de 1 ko
- Donner à CONSULT seulement le droit de lire les tables CLIENT et COMMANDE
- Créer les index suivants dans le tablespace INDEX :
- Index B*TREE sur la colonne COMMANDE.MONTANT_HT
- Index B*TREE sur la colonne COMMANDE.NO_CLIENT
- Index BITMAP sur la colonne CLIENT.SITUATION_FAMILIALE
4. Sauvegarde
Développer un script de sauvegarde avec RMAN :
- Sauvegarde à chaud
- Sauvegarde complète de la base de données
5. Optimisation
- Développer un script qui calcule
- Ratio Buffer Cache
- Ration Shared Pool
TP ORACLE: Gestion des accès concurrents
Une transaction (ensemble d'ordres SQL) est atomique c'est-à-dire qu'elle ne peut se terminer que par un succés
(elle est alors validée) ou un échec (tous ses effets sont alors détruits).
En conséquence, en contexte multi-utilisateurs, les modifications effectuées par une transaction réalisée par un
utilisateur ne sont connues des autres utilisateurs que lorsque la transaction a été confirmée par un
COMMIT.
Oracle gère automatiquement les accès concurrents. Si une transaction est en train de modifier les lignes d'une
table, les autres transactions peuvent modifier les données telles qu'elles étaient avant ces dernières
modifications (pas de temps d'attente pour la lecture).
Pour rester ``simple'' nous dirons que toute transaction pose des verrous sur les objets qu'elle manipule et que deux grands types de verrous existent :
- en lecture (verrou passant plusieurs lectures simultanées peuvent avoir lieu)
- en écriture (verrou bloquant la première écriture bloque les autres jusqu'à ce que le verrou soit relaché)
Commandes qui provoquent un blocage implicite sur les tables et les lignes impliquées : DELETE,
INSERT, UPDATE, ALTER TABLE, ...
Exemples d'application :
- Faites des sélections sur les mêmes lignes des mêmes tables avec deux noms utilisateurs différents
Par exemple, dess1 et dess2 réalisent la même requête : ``Donner les noms des employés de la société Bayer Pharma ''.
- Réessayez le même exercice mais avec des commandes provoquant des blocages
Par exemple, dess1 modifie la table SOCIETE : ``Modifiez le nom de la société Bayer Pharma en Bayer''. Puis
dess1 et dess2 réalisent la même requête : ```Donnez le nom de la société dirigée par Werner Wenning ''. Que constatez-vous ?
Tester avec COMMIT et ROLLBACK.
Etreinte mortelle (DEADLOCK) :
- dess1 fait un UPDATE sur le tuple i de la table SOCIETE
- dess2 fait un UPDATE sur le tuple j de la table MEDICAMENT
- dess2 fait un UPDATE sur le tuple j de la table SOCIETE
- dess1 fait un UPDATE sur le tuple i de la table MEDICAMENT
Que constatez-vous. Quelle est la solution ? Quelles sont les opérations qui ont été effectivement effectuées sur les tables concernées ?