Exercice Architecture du SGBD ORACLE

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 ?