sql >> Database teknologi >  >> RDS >> Database

Database-omlægninger – hvorfor de betyder noget

Databaseomlægninger:  Hvorfor de betyder noget, og forskellen mellem on-line og offline

Databaseomorganiseringer udføres for at spare dataplads og forbedre databaseeffektiviteten og ydeevnen. Denne artikel forklarer hvorfor. Den næste artikel viser, hvordan man omorganiserer flere tabeller og databaser i Eclipse.

Data i store RDBMS-tabeller bliver til sidst fragmenteret. Størrelsen af ​​tabeller og indekser øges, efterhånden som poster bliver fordelt over flere datasider. Flere sidelæsninger og rækker i ikke-sammenføjningsrækkefølge under udførelse af forespørgsler langsomme forespørgselssvar. For at genvinde den spildte plads, forbedre databasens oppetid og fremskynde dataadgangen (forespørgselssvar), overvej en strategi til omorganisering af dine databaseobjekter.

Database-omorganiseringer består af to typer for disse tabel-, indeks- og tablespace-objekter:online (på plads) og offline (klassisk).

Online database reorgs arbejder trinvist ved at flytte rækker i den eksisterende tabel for at genetablere klyngedannelse, genvinde ledig plads og eliminere overløbsrækker. Objekter er kun utilgængelige i kort tid nær slutningen, ikke under genindlæsnings- og genopbygningsfaserne, som kan blive langvarige for store objekter. De tillader programmer at oprette forbindelse til databasen, men sænker ofte deres ydeevne og kan skabe låseventer på det tidspunkt.

Offline database reorgs er hurtigere, men kan tage databasen off-line (hvis database reorg utility bruges). Med denne metode eksporteres data fra databasen til en dumpfil (unload). Databaseobjekterne, der er sikkerhedskopieret baseret på uddraget, typisk omarrangeret (sorteret). De returneres derefter til det samme tablespace (indlæs), hvor indekser gendannes implicit (genopbygget).

Ydeevnebevidste DBA'er bruger IRI FACT (Fast Extract) til udlæsningen, hvilket skaber en bærbar flad fil, der kan sorteres (med IRI CoSort) på den primære indeksnøgle i den omorganiserede tabel. Med denne tilgang kan andre transformations- og rapporteringsoperationer forekomme, og databasen forbliver online. Forudsorterede, direkte stibelastninger omgår også sorteringen (overhead) af databaseindlæseren. Alle disse operationer er automatiseret i IRI Workbenchs offline reorg-guide.

At holde en "skygge"-kopi af dataene i filsystemet for hver tabel bør ikke være unødigt besværlig, fordi når den flade fil er sorteret og genindlæst, kan den slettes. Samtidig giver det at have reorg-dataene eksternaliseret og tilgængelige for CoSort også muligheden for andre anvendelser af dataene, herunder arkivering, rapportering, beskyttelse og migrering til andre databaser, BI-værktøjer og applikationsmål.

Forbeholdet er selvfølgelig, at andre systembrugere kan læse og muligvis opdatere tablespacet under aflæsningen, så enhver opdatering i løbet af denne tid kan gå glip af genindlæsningen og skabe uoverensstemmelser i målet. Det anbefales derfor, at der udføres offline omorganiseringer, når opdateringer ikke forekommer.

IRI tilbyder en off-line reorg-løsning, beskrevet og vist her.


  1. Android:Sqlite-fejl - (1) nær null:syntaksfejl

  2. Få ekstra rækker - Efter sammenføjning af de 3 borde ved hjælp af Left Join

  3. Ved hjælp af PL/SQL, hvordan får jeg en fils indhold ind i en klat?

  4. 10 Microsoft Access Navigationsrude Tastaturgenveje