Lamiae
Cours architecture et administration d’une base de données, tutoriel et exercices d’application système de gestion de bases de données document PDF.
1. Architecture d’une base de données
1.1. La structure logique
1.1.1. Les tablespaces
1.1.2. Les segments, extensions et blocs
1.2. La structure physique
1.2.1. Les fichiers de paramètres
1.2.2. Le fichier de contrôle
1.2.3. Arborescence des répertoires
2. Instance de base de données
2.1. Introduction
2.2. Notion d’instance
2.3. Les états d’une base
2.4. Arrêt et démarrage d’une instance
2.5. Le mode sysdba
2.6. La SGA
2.6.1. Le database buffer cache
2.6.2. Le buffer de reprise (redo log buffer)
2.6.3. Le pool partagé
3. Les processus Oracle
3.1. Introduction
3.2. Les processus background
3.2.1. Le processus SMON
3.2.2. Le processus PMON
3.2.3. Le processus RECO
3.2.4. Le processus ARCH
3.2.5. Le processus ORALSN
3.3. Visualisation des processus connectés
3.4. La circulation des données
3.5. Variantes architecturales
4. Utilisateurs et privilèges
4.1. Niveaux de sécurité
4.1.1. Sécurité de compte
4.1.2. Privilèges objet
4.1.3. Privilèges système
4.2. Création d’un utilisateur
5. Sauvegarde, restauration et récupération
5.1. Vue d’ensemble
5.2. Archivage des fichiers de journalisation
5.3. Le mode Archivelog
5.4. Solutions de sauvegarde et restauration
5.5. Stratégie de sauvegarde
5.6. Outils logiques
5.6.1. Exportation de données : Export
5.6.2. Importation de données : Import
5.6.3. Un tablespace transportable
5.6.4. Oracle Data Pump
5.6.4.1. Exportation avec Data Pump
5.6.4.2. Importation avec Data Pump
5.7. Rappels
5.7.1. Définitions
5.7.2. Les fichiers redo
5.7.3. Que faut-il sauvegarder?
5.8. Archivage des redo log files
5.8.1. Mode opératoire
5.8.2. Problèmes courants
5.9. Présentation de RMAN
5.9.1. RMAN
5.9.2. Lancer RMAN
5.9.3. Configurer RMAN
5.10. Sauvegarde
5.10.1. Généralités
5.10.2. Manipulations
5.10.2.1. Sauvegarde de la totalité de la base de données
5.10.2.2. Sauvegarde de tablespaces ou fichiers de données
5.10.2.3. Sauvegarde du fichier de contrôle et du spfile
5.10.2.4. Sauvegarde de fichier archivés
5.10.2.5. Sauvegarde incrémentale
5.10.2.6. Sauvegarde incrémentale
5.10.3. Scénario
5.10.4. Sauvegarde complète (cohérente)
5.10.5. Sauvegarde complète (incohérente)
5.10.6. Sauvegarde partielle base ouverte
5.10.7. Sauvegarde incrémentale
5.11. Le repository RMAN
5.11.1. Trouver les informations
5.11.1.1. La Commande LIST
5.11.1.2. La commande REPORT
5.11.2. Gérer le repository
5.11.2.1. La commande CROSSCHECK
5.11.2.2. La commande DELETE
5.11.2.3. La commande CATALOG
5.12. Restauration
5.12.1. Vue d’ensemble
5.12.2. Principes généraux
5.12.2.1. En mode NOARCHIVELOG
5.12.2.2. En mode ARCHIVELOG
5.12.3. Incidents sur les fichiers de contrôle
5.12.4. Identification de la nature des problèmes
5.12.5. Les commandes RMAN
5.12.5.1. La commande RESTORE
5.12.5.2. La commande RECOVER
5.12.6. Scénarios de restauration
5.12.6.1. Scénario 1 : Restauration du SPFILE
5.12.6.2. Scénario 2 : Restauration d’un fichier de contrôle
5.12.6.3. Scénario 3 : Restauration d’un fichier de journalisation
5.12.6.4. Scénario 4 : Restauration complète de la totalité d’une base de données en mode ARCHIVELOG
5.12.6.5. Scénario 5 : Restauration complète d’une partie d’une base de données en mode ARCHIVELOG
5.12.6.6. Scénario 6 : Restauration des fichiers de contrôle en mode ARCHIVELOG
5.12.6.7. Scénario 7 : Restauration incomplète en mode ARCHIVELOG
5.12.6.8. Scénario 8 : Restauration en mode NOARCHIVELOG
5.12.6.9. Scénario 9 : Restauration à un emplacement différent
5.12.6.10. Scénario 10 : Tablespace temporaire géré localement
5.12.7. Techniques de flashback
Résumé sur administration d’une base de données
1. Architecture d’une base de données
Une base de données est composée de deux niveaux :
• niveau logique
• niveau physique
Les informations de description et de comportement constituant ces deux niveaux sont enregistrées dans le dictionnaire.
1.1. La structure logique
La structure logique est le niveau le plus abstrait : c’est une collection de schémas.
Un schéma contient les objets élémentaires comme les tables, les vues, les déclencheurs, … . Ces objets sont aussi appelés objets relationnels.
Un schéma est répartis en zone logiques, tablespaces; ces tablespaces sont constitués de segments; ces segments sont composées d’extensions; ces dernières sont organisées en blocs.
Ces quatre niveaux (tablespace, segments, extensions et blocs) permettent de définir l’organisation de la base et le lien entre les niveaux physiques et logiques.
1.1.1. Les tablespaces
Les tablespaces sont des unités logiques, identifiées par un nom. Un objet relationnel ne peut être associé qu’à un seul tablespace ; un objet y est « logiquement » stocké.
L’utilisation de tablespaces améliore la maintenance, la sécurité et les performances d’une base de données Oracle. En effet, l’utilisation de tablespaces permet d’éviter les risques de contentions et de saturations.
Un tablespace permet à l’administrateur de :
• contrôler l »allocation de disque de chacun
• regrouper les objets (utilisateur, application, groupe d’utilisateurs)
• définir un quota à chaque utilisateur
• contrôler la disponibilité des données (online/offline)
• réaliser des sauvegardes/recouvrements partiels
• répartir le stockage des données sur plusieurs disques
A un tablespace sont associés un ou plusieurs fichiers de données où seront stockés les objets lui appartenant. C’est la taille de ces fichiers qui détermine la capacité de stockage des tablespaces.
La taille d’un tablespace est la somme des tailles des fichiers qui le constitue.
La taille d’une base Oracle est le total des tailles de ses tablespaces.
Il est possible d’obtenir les tailles de tous les tablespaces d’une base en effectuant le script suivant :
select t.TABLESPACE_NAM, round(sum(f.bytes)/1024/1024)
from dba_data_files f, dba_tablespaces t
where f.TABLESPACE_NAME = t.TABLESPACE_NAME
group by t.TABLESPACE_NAME
order by t.TABLESPACE_NAME;
Le tablespace SYSTEM contient les tables du dictionnaire et peut suffire pour une petite base de données.
Il est conseillé d’utiliser un autre tablespace pour les utilisateurs (séparation du dictionnaire) car cela assure une meilleur flexibilité pour l’administration et une réduction des contentions.
Le tablespace SYSAUX est propre à Oracle 10g. C’est un tablespace auxiliaire à SYSTEM. L’objectif de ce tablespace est de réduire la charge du tablespace SYSTEM. Si SYSAUX devient indisponible, les fonctionnalités de base d’Oracle restent accessible. Ce tablespace contient un ensemble d’occupants comme les informations systèmes associées à une option comme XDB, OracleSpacial, …
Le tablespace UNDO : le journal des images avant peut être stocké dans un RS ou dans un tablespace de type UNDO (automatic undo management mode).
Le journal des images avant permet :
• d’annuler les transactions
• de réaliser le recovery
• d’assurer la lecture cohérente des données
• des possibilités de « flashback »
1.1.2. Les segments, extensions et blocs.
Il y a trois niveaux de granularité utilisés par Oracle pour stocker les données :
• bloc de données (bloc logique) : est le niveau le plus fin. C’est l’unité de transfert entre les disques et la mémoire.
• extension : est le deuxième niveau. Une extension est une suite de blocs contigus alloués simultanément. Les extensions sont utilisées pour le stockage d’un type spécifique de données.
• segment : est le troisième niveau. Un segment est un ensemble d’extensions (pas forcément contigüe) allouées à une certaine structure logique (comme par exemple les lignes d’une table).
Lorsqu’un segment est plein, Oracle alloue une nouvelle extension pour ce segment (allocation à la demande ou incremental extent). Le bloc « en-tête » de chaque segment contient un répertoire de ses extensions.
Il existe différents types de segments :
• segments de données
• segments d’index
• segment d’annulation
• segments temporaire
• segments d’amorçage
1.2. La structure physique
Il existe trois types de fichiers :
• les data files qui contiennent les données de la base c’est à dire les objets définis par les utilisateurs et les objets nécessaires au bon fonctionnement de celle-ci. La taille des data files est définie à la création de la base de données avec possibilité d’extension ultérieure. Leur localisation est variable excepté pour le premier fichier créé.
• les redo log files
• les control files
1.2.1. Les fichiers de paramètres
Les fichiers de paramètres contiennent les paramètres nécessaires à la configuration d’un serveur définis dans un fichier de paramètres appelé PFILE (parameter file). Dans les versions antérieures à Oracle 9i, un fichier de type « texte » est lu lors du démarrage de l’instance. Depuis Oracle 9i, un fichier binaire réside sur le serveur de base de données appelé SPFILE (server parameter file).
Modification de la valeur d’un paramètre : ALTER SYSTEM
• SCOPE = SPFILE (effectif au prochain redémarrage)
• SCOPE = MEMORY (immédiat mais non persistant)
• SCOPE = BOTH (immédiat et persistant)
1.2.2. Le fichier de contrôle
Le fichier de contrôle sert à localiser les fichiers de données et autres. Il est le garant de la cohérence ; ilest donc nécessaire d’en faire des copies miroir (trois par défaut).
Le fichier de contrôle comprend aussi :
• le nom de la base de données
• les noms et emplacements des fichiers de données
• les noms et emplacements des fichiers Redolog (journaux des images « après »)
• une estampille précisant la date de création de la base de données
………..
Si le lien ne fonctionne pas correctement, veuillez nous contacter (mentionner le lien dans votre message)Cours architecture et administration d’une base de données (913.6 KB) (Cours PDF)
Excellent cours…