Komprimering av Enterprise Geodatabase

Alle Geodatabaser som bruker versjonert redigering, vil over tid oppleve dårligere ytelse dersom det ikke gjøres noe med den. En av oppgavene som må kjøres jevnlig for å opprettholde ytelsen er å kjøre komprimering av geodatabasen.

Hvilke databasetyper kan komprimeres?

De geodatabasetypene som kan komprimeres er de som bruker versjonert redigering. Alle benytter ArcSDE teknologi:

  • Enterprise Geodatabase – databaser som benytter SQL Server, Oracle, PostgreSQL osv. til å lagre data.
  • ArcSDE Workgroup – benytter SQL Server Express til å lagre data. Har begrensninger på databasestørrelser og samtidige brukere. Ti redigeringsbrukere samtidig.
  • ArcSDE Personal – benytter SQL Server Express til å lagre data. Har begrensninger på databasestørrelser og samtidige brukere. En redigeringsbruker og to innsynsbrukere samtidig.

Hvorfor må vi komprimere Geodatabasen?

Årsaken ligger i hvordan den versjonerte geodatabasen håndterer redigeringer. Når en geodatabase verjoneres, vil det for hvert geodatabaseobjekt lages to nye tabeller som vi kaller deltatabeller. Det er disse deltatabellene som inneholder alle de endringene som blir gjort i databasen. Over tid vil disse tabellene etter hvert inneholde mange rader og det vil bli tungt for ArcGIS å hente opp den siste statusen for hvert enkelt objekt fra deltatabellene.

Sammen med deltatabellene finnes det en tabell som er den tabellen som lages når vi oppretter et geodatabaseobjekt første gangen. Dette er den såkalte businesstabellen. Alle versjoner vil i utgangspunktet hente alle data som ligger i businesstabellen før endringene som ligger for hver enkelt versjon, inklusive eventuelle endringer i DEFAULT versjonen, fra deltatabellene.

For å få ryddet opp i dette, må vi flytte alle rader i deltatabellene som er felles for alle versjoner tilbake til businesstabellen. Det er dette vi kaller komprimering av geodatabasen. Dette vil redusere antall rader i deltatabellene og øke antall rader i businesstabellen. Det betyr lite for ytelsen hvor mange rader som befinner seg i businesstabellen i motsetning til hvor mange rader som finnes i deltatabellene.

Hvilke brukere kan kjøre komprimering av en Geodatabase?

Komprimering av geodatabasen må kjøres av Geodatabase administratoren. Normalt er dette bruker SDE, men i SQL Server kan dette være en OS-bruker som har DBO-rettigheter i databasen. Komprimeringen kan startes på flere måter, uavhengig av hva slags type Geodatabase det er.

Alternativ 1, oppstart fra databasekoblingen.

Dersom vi høyreklikker en databasekobling med geodatabaseadministratorbrukeren, vil vi få opp en kontekst meny som gir oss muligheter til å komprimere databasen:

Figur 1. Komprimering av geodatabase fra databasekobling

Dette starter komprimering av den valgte databasen. Denne metoden er den enkleste å bruke dersom man ønsker å kjøre komprimering av databasen etter behov.

Alternativ 2, komprimering via toolboxer

Alternativ to er ikke like enkelt tilgjengelig, men likefullt en normal måte å gjøre det på. I verktøyene under Geodatabase Administration, ligger verktøyet Compress, som i praksis er samme verktøy som brukes i alternativ 1. Forskjellen er at her må vi fortelle verktøyet hvilken databasekobling vi skal bruke for å få kjørt komprimeringen.

Figur 2. Verktøy for å komprimere geodatabase.

Når vi starter verktøyet, får vi spørsmål om hvilken databasekobling vi skal benytte for å komprimere databasen:

Figur 3. Dialogbilde fra verktøy for å komprimere geodatabase.

Vi velger her de samme databasekoblingene som de vi kan benytte i alternativ 1.

Kan noe påvirke resultatet av komprimeringen?

Dersom det er brukere inne i databasen og de har satt låser på tabeller/featureklasser, vil dette påvirke komprimeringen. Resultatet av slike låser, selv om det er «delte låser» (Shared Locks), vil medføre at komprimeringsfunksjonen hopper over de tabellene/featureklassene hvor det finnes låser.

I praksis vil det si at skal man få til en god komprimering må det ikke være noen brukere inne i databasen når den kjøres.

Hva skjer i databasen ved komprimering?

For å få en forståelse av hva som skjer i databasen, må vi først se på versjonstreet. Det er versjonstreet som «bestemmer» hvilke, eller hvor mange, rader som kan dyttes ned i businesstabellen. For å visualisere versjonstreet, kan vi tenke det oss som et tre:

Figur 4. Et tenkt versjonstre.

Som figuren viser, befinner alle endringene seg i den delen av treet som er over jorden. Alle rader som befinner seg i rota, under bakken, er felles for alle versjoner. I figuren vil også en del av radene som befinner seg i stammen være felles for alle versjoner, men det trenger ikke å være tilfelle.

Komprimering vil flytte alle rader i stammen som er felles for alle versjoner ned i rota. De radene som er felles for alle versjoner, er rader som ligger nederst i stammen, helt til innfestingspunktet for nederste gren.

Figur 5. Viser hvor mye av deltatabellene som kan overføres til businesstabellen.

I figuren ser vi at vi kan flytte ned den mengden rader som ligger mellom bakkenivået og den røde streken. Dette vil under en kompress dyttes ned i rota. Et viktig poeng her er at det ikke er viktig hvor stor versjonen er. Alle versjoner, uavhengig om det er gjort endringer i dem eller ikke, vil være med å markere plasseringen av den røde streken. Det er alltid den versjonen som sitter lavest nede på stammen som sier hvor høyt oppe den røde streken kan settes.

For å få en mest mulig effektiv komprimering er vi avhengige av å ha mest mulig ledig stamme mellom bakken og nederste gren. Det er samkjøring og posting av versjoner som hjelper til med å frigjøre mer av stammen.