Database reorgs: Waarom ze ertoe doen en het verschil tussen online en offline
Reorganisatie van databases wordt uitgevoerd om gegevensruimte te besparen en de efficiëntie en prestaties van de database te verbeteren. In dit artikel wordt uitgelegd waarom. Het volgende artikel laat zien hoe u meerdere tabellen en databases in Eclipse kunt reorganiseren.
Gegevens in grote RDBMS-tabellen raken uiteindelijk gefragmenteerd. De grootte van tabellen en indexen neemt toe naarmate records over meer gegevenspagina's worden verspreid. Meer paginalezingen en rijen in niet-deelnamevolgorde tijdens het uitvoeren van trage queryreacties. Om de verspilde ruimte terug te winnen, de uptime van de database te verbeteren en de toegang tot gegevens (query-antwoorden) te versnellen, moet u een strategie overwegen om uw database-objecten te reorganiseren.
Database reorgs bestaan uit twee typen voor deze tabel-, index- en tablespace-objecten:online (in plaats) en offline (klassiek).
Online database reorgs werken stapsgewijs door rijen binnen de bestaande tabel te verplaatsen om clustering te herstellen, vrije ruimte terug te winnen en overlooprijen te elimineren. Objecten zijn tegen het einde slechts korte tijd niet beschikbaar, niet tijdens de herlaad- en herbouwfasen, die bij grote objecten lang kunnen duren. Ze zorgen ervoor dat applicaties verbinding kunnen maken met de database, maar vertragen vaak hun prestaties en kunnen op dat moment vergrendelingswachten creëren.
Offline database reorgs zijn sneller, maar kunnen de database offline halen (als de database reorg utility wordt gebruikt). Bij deze methode worden gegevens uit de database geëxporteerd naar een dumpbestand (unload). De databaseobjecten die een back-up maken op basis van het uittreksel, worden meestal opnieuw gerangschikt (sorteren). Ze worden dan teruggestuurd naar dezelfde tablespace (load), waar indexen impliciet worden hersteld (rebuild).
Prestatiebewuste DBA's gebruiken IRI FACT (Fast Extract) voor het verwijderen, waarmee een draagbaar plat bestand wordt gemaakt dat kan worden gesorteerd (met IRI CoSort) op de primaire indexsleutel van de gereorganiseerde tabel. Met deze aanpak kunnen andere transformatie- en rapportagebewerkingen plaatsvinden en blijft de database online. Voorgesorteerde, directe padladingen omzeilen ook de sortering (overhead) van de databaselader. Al deze bewerkingen zijn geautomatiseerd in de IRI Workbench offline reorganisatiewizard.
Het bewaren van een "schaduw"-kopie van de gegevens in het bestandssysteem voor elke tabel zou niet onnodig belastend moeten zijn, want zodra het platte bestand is gesorteerd en opnieuw is geladen, kan het worden verwijderd. Tegelijkertijd biedt het extern en beschikbaar hebben van de reorganisatiegegevens aan CoSort ook de mogelijkheid voor ander gebruik van de gegevens, waaronder archivering, rapportage, bescherming en migratie naar andere databases, BI-tools en toepassingsdoelen.
Het voorbehoud is natuurlijk dat tijdens het verwijderen andere systeemgebruikers de tabelruimte kunnen lezen en kunnen bijwerken, dus eventuele updates gedurende deze tijd kunnen het opnieuw laden missen en inconsistenties in het doel veroorzaken. Het wordt daarom aanbevolen om offline reorganisaties uit te voeren wanneer er geen updates plaatsvinden.
IRI biedt een offline reorganisatie-oplossing, die hier wordt beschreven en getoond.