Admin CliCours
Création d’une base de données météorologique à l’aide d’oracle
CHARGEMENT DES DONNEES DANS UNE BASE
METHODES DE CHARGEMENT DES DONNEES
Il existe plusieurs méthodes de chargement des données dans des tables d’une base de données Oracle. Le chargement des données par chemin direct et l’utilitaire SQL*Loader sont présentés dans cette partie. a- SQL*Loader: L’utilitaire SQL*Loader charge les données de fichiers externes dans les tables d’une base de données Oracle. Son puissant moteur d’analyse des données applique peu de contraintes sur le format des données du fichier de données. b- Chargement de données par chemin direct : Utiliser la méthode de chargement des données par chemin direct pour copier les données d’une table vers une autre au sein d’une même base de données. Cette méthode accélère les opérations d’insertion en passant outre le cache de tampons (buffer cache) de la base de données en écrivant directement les données dans les fichiers de données. Deuxième partie : Mode de création d’une base de données Le chargement des données par chemin direct (en série ou en parallèle) ne peut prendre en charge que la syntaxe INSERT … SELECT d’une instruction INSERT, et non la syntaxe INSERT … Valeurs. Le parallélisme de INSERT …SELECT est déterminé en fonction de conseils (Hints) en parallèle ou de la définition de table en parallèle. Oracle8i fournit des extensions syntaxiques qui augmentent la portée de l’instruction INSERT … SELECT de sorte que l’on peut insérer des lignes dans plusieurs tables dans le cadre d’une instruction LMD. Le chargement des données par chemin direct peut être appelé à l’aide du conseil APPEND, comme indiqué dans la commande suivante : INSERT / *+APPEND */ INTO [schema.] table [ [NO]LOGGING ] sub-query; Où : Schema correspond au propriétaire de la table, Table correspond au nom de la table, Sub-query correspond à la sous-interrogation qui permet de sélectionner les colonnes et les lignes à insérer. c- Mode LOGGING : Lorsqu’on effectue une insertion à l’aide de l’option par défaut LOGGING, l’opération génère des entrées de journalisation (redo log entries), ce qui permet une récupération complète en cas d’incident. Si on utilise l’option NOLOGGING, les modifications apportées aux données ne seront pas enregistrées dans le tampon de journalisation (redolog buffer). Toutefois, un nombre minimal d’informations de journalisation est généré lors de la mise à jour du dictionnaire de données. Le mode NOLOGGING est utilisé si l’attribut correspondant a été défini pour la table. Si plusieurs modifications en lignes (online) des données de la table sont susceptibles de se produire simultanément, il est conseillé de définir l’attribut NOLOGGING avant de charger les données et de réinitialiser (LOGGING) une fois le chargement des données terminé. Deuxième partie : Mode de création d’une base de données d- Autres considérations : Toutes les données chargées à l’aide de cette méthode sont chargées au-dessus du repère high-water mark. Si la table contient un grand nombre de blocs dont des lignes ont été supprimées, on peut considérer une perte d’espace et un ralentissement des balayages complets de table (full table scans).
CHARGEMENT DES DONNEES PAR CHEMIN DIRECT EN SERIE
partitionnée
Chargement des données par chemin direct dans une table non, une table partitionnée ou une table sous-partitionnée : Les données sont insérées au-delà du repère high-water mark actuel du segment de table ou de chaque segment de partition. Le repère high-water mark correspond au niveau auquel les blocs n’ont jamais été formatés pour recevoir des données. Lors de l’exécution d’une instruction, une nouvelle valeur est affectée à ce repère, rendant ainsi les données visibles aux autres utilisateurs. Lors du chargement d’une table partitionnée ou sous-partitionnée, SQL*Loader partitionne les lignes et gère les index (qui peuvent également être partitionnés). Un chargement de données par chemin direct d’une table partitionnée ou sous-partitionnée peut consommer une grande quantité de ressources.
CHARGEMENT DES DONNEES PAR CHEMIN DIRECT EN PARALLELE
Le chargement des données par chemin direct en parallèle peut se faire : • en utilisant le conseil PARALLEL dans l’instruction INSERT, comme indiqué dans l’exemple, • en créant la table ou en la modifiant pour définir la clause PARALLEL. Lorsqu’on effectue des chargements de données par chemin direct en parallèle, le serveur Oracle utilise plusieurs processus, appelés processus esclaves « Parallel Query », pour insérer les données dans la table. Des segments temporaires sont alloués pour le stockage des données insérées par chaque processus esclave. Lorsque la transaction est validée, les extents (ensembles de blocs contigus) de chaque segment sont intégrés à la table dans laquelle les enregistrements sont insérés. Remarque : • Il faut exécuter la commande ALTER SESSION ENABLE PARALLEL DML au début de la transaction. • Un objet modifié par chargement de données par chemin direct en parallèle ne peut pas être interrogé ni modifié de nouveau dans la même transaction. a- Chargement des données par chemin direct en parallèle dans une table non partitionnée : Chaque serveur d’exécution en parallèle alloue un nouveau segment temporaire et insère des données dans ce segment. Lors de l’exécution d’une instruction, le coordinateur de l’exécution en parallèle fusionne les nouveaux segments temporaires dans le segment de table principal. b- Chargement des données par chemin direct en parallèle dans une table partitionnée : Chaque serveur d’exécution en parallèle peut avoir une ou plusieurs partitions, mais pas plus d’un processus par partition. Ce serveur insère des données au-delà du repère high-water mark actuel des segments de partition qui lui sont affectés. Lors de l’exécution d’une instruction, le repère high-water mark de chaque segment de partition est mis à jour par le coordinateur d’exécution en parallèle et prend la nouvelle valeur, rendant ainsi les données visibles aux autres utilisateurs.
LISTE DES FIGURES |
