Database
 sql >> Base de données >  >> RDS >> Database

Réorganisations de bases de données - Pourquoi elles sont importantes

Réorganisations de la base de données :  Pourquoi ils sont importants et la différence entre en ligne et hors ligne

Les réorganisations de la base de données sont effectuées pour économiser de l'espace de données et améliorer l'efficacité et les performances de la base de données. Cet article explique pourquoi. L'article suivant montre comment réorganiser plusieurs tables et bases de données dans Eclipse.

Les données des grandes tables RDBMS finissent par se fragmenter. La taille des tables et des index augmente à mesure que les enregistrements sont répartis sur davantage de pages de données. Plus de pages lues et de lignes dans un ordre sans jointure lors de l'exécution de la requête ralentissent les réponses à la requête. Pour récupérer l'espace perdu, améliorer la disponibilité de la base de données et accélérer l'accès aux données (réponses aux requêtes), envisagez une stratégie de réorganisation des objets de votre base de données.

Les réorganisations de base de données se composent de deux types pour ces objets de table, d'index et d'espace de table :en ligne (en place) et hors ligne (classique).

Base de données en ligne Les réorganisations fonctionnent de manière incrémentielle en déplaçant les lignes dans la table existante pour rétablir le clustering, récupérer de l'espace libre et éliminer les lignes de débordement. Les objets ne sont disponibles que pendant une courte période vers la fin, pas pendant les phases de rechargement et de reconstruction, qui peuvent être prolongées pour les objets volumineux. Ils permettent aux applications de se connecter à la base de données, mais ralentissent souvent leurs performances et peuvent créer des attentes de verrouillage à ce moment-là.

Base de données hors ligne Les réorganisations sont plus rapides, mais peuvent mettre la base de données hors ligne (si l'utilitaire de réorganisation de la base de données est utilisé). Avec cette méthode, les données sont exportées de la base de données vers un fichier de vidage (déchargement). Les objets de la base de données sont sauvegardés en fonction de l'extrait, généralement réorganisés (tri). Ils sont ensuite renvoyés dans le même tablespace (load), où les index sont restaurés implicitement (rebuild).

Les DBA soucieux des performances utilisent IRI FACT (Fast Extract) pour le déchargement, ce qui crée un fichier plat portable qui peut être trié (avec IRI CoSort) sur la clé d'index primaire de la table réorganisée. Avec cette approche, d'autres opérations de transformation et de reporting peuvent avoir lieu, et la base de données reste en ligne. Les chargements de chemin direct pré-triés contournent également le tri (overhead) du chargeur de base de données. Toutes ces opérations sont automatisées dans l'assistant de réorganisation hors ligne d'IRI Workbench.

La conservation d'une copie « fantôme » des données dans le système de fichiers pour chaque table ne devrait pas être excessivement onéreuse, car une fois le fichier plat trié et rechargé, il peut être supprimé. Dans le même temps, le fait que les données de réorganisation soient externalisées et disponibles pour CoSort permet également d'autres utilisations des données, notamment l'archivage, la création de rapports, la protection et la migration vers d'autres bases de données, outils de BI et cibles d'application.

La mise en garde est bien sûr que pendant le déchargement, d'autres utilisateurs du système peuvent lire et mettre à jour l'espace table, de sorte que toute mise à jour pendant ce temps pourrait manquer le rechargement et créer des incohérences dans la cible. Il est donc recommandé d'effectuer des réorganisations hors ligne lorsqu'il n'y a pas de mises à jour.

IRI propose une solution de réorganisation hors ligne, décrite et illustrée ici.