Hvad betyder "shrink"?

Tjaa, det processen jo gør er at gøre selve datafilen mindre. En sql datafil er fx på 10 GB, men der er måske kun 2 GB data i - og så kan man frigive op til 8 GB plads, så datafilen kun fylder de 2 GB som der rent faktisk er data i.

En fordanskning kunne måske være "gøre mindre", "formindske" eller måske det gode danske ord "skrumpe" :)

Formindske ... eller "at gøre mindre" da den jo deallokere pladsen.

// ouT

sjang >>
Jeg stemmer på "skrumpe". Det er et KONGE ord :o)

Men ellers kunne man også kalde det "Frigiv ubenyttet plads".

skrumpe er direkte oversat så det er vel korrekt nok:)
men det er vel ligemeget hvilket ord man benytter hvis blot man forstår hvad "Shrink" foretager sig.

Efter skrumpet databasen vil data filen have en størrelse som passer dens data mængde.
Det betyder at næste gang der indsættes en record vil der bliver allokeret xxx antal megabytes igen afhængig af en database indstillinger.

Jeg ville aldrig shrink en database ... det er der vel intet fornuftigt i? jo, du får pladsen ledig hvis du har smidt en masse data ud, men med en vis forøgelse i data bliver pladsen jo brugt igen ... og du undgår at databasen

// ouT

buzzzz >>

Det må være fordi du aldrig har været ude i en situation hvor det giver mening for dig.
F.eks har jeg et system der logger en masse aktiviteret i mit system til debugging og denne bliver enorm ganske hurtigt.
Det er forskelligt hvor meget der logges, men man kan forestille sig at nogle gange bliver der logget større mængder data så databasefilen udvider sig - og måske til sidst får en unødvendig stor størrelse på disken.
Der er selvfølgelig jobs til og rydde op i selve databasefilen, men det ændre ikke på den plads den optager fysisk.

Derfor går jeg i sådan en situation ind og shrinker den.. det sker endda at jeg truncater min database helt og så vil jeg gerne have den nulstillet fremfor og fylde f.eks 270GB på harddisken.

kalp#
Ja, men hvis man ved at det ville ske igen ... hvad er fordelen så ?

Hvis der er sket noget helt fucked og løbet tør for plads ... set det ved folk som får lavet et uendeligt loop ... og så fylder mange gange mere end nødvedigt ... så kan jeg se fordelen. Men ved at frigive pladsen, får du vel også fragmenteret din database udover en større en af din disk ? Deraf langsommere performance ...

I stedet for at beholde pladsen i den allokerede fil, hvis man kommer derop igen.

Husk på ... at lave en udvidelse tager jo også kræfter.

Hvis du truncater hele databasen, så snakker vi vel heller ikke et live miljø med et test setup går jeg ud fra ... og ja, så kan det være mere relevant.

Mine kommentare går på et live produktions miljø ... lader lidt til at dine går lidt i retning af et test miljø/beta stadie, korrekt ?

// ouT

så må man shrinke den i det sløve timer:)

Jeg snakker faktisk i live med mit eksempel.. det er trods alt debug data og debug data er primært relevant når man skal fejlsøge et problem:)
Derfor kan den godt tømmes hvis man virkelig ønsker det.

men for at være helt præcis i den problemstilling jeg havde på områder så var det fordi der lå andre databaser på disken og den var altså kun på sølle 136GB.
Derfor var det et problem når loggen løb løbsk på den disk:) f.eks tog den 100gb fra disken hvilket ikke giver meget til de resterende databaser.

da den havde ædt harddisken truncatede vi den og shrinkede.
der kører natlige jobs til at rydde op i databasen så den burde ikke blive så stor, men der kan ske uforudsete ting nogle gange:)

Der var også engang hvor jeg så en database var blevet sat til og vokse med 150GB istedet for 150mb.. den shrinkede jeg også:)

Ja, men så er vi jo også generelt enige om hvad og hvorfor man shrinker ... pga fejl, debug som du selv er inde på :-)

Jeg har en database jeg har sat til at vokse med 4 GB per gang, pga import af data i sølve perioder ... for ikke at skulle udvide flere gang i løbet af en import.
Data mængden går kun en vej, op :-(

Loggen kan faktisk være et problem ... den laver jo log over hvad den laver, og satte uden at tænke over det, den til at export og import en table til samme database ( mærkelig måde da jeg jo bare kunne bruge "insert into selecet from" hvilket nok ville have gjort det hurtigere :-). Men der var 140 mill rows, og det tog da lige lidt tid og nu er loggen på 30-40 GB, hvor 99% er ledig, men .... så er jeg da sikker på den er der og tror den bliver låst der.

Men nok om alt det her ... ikke det spm handlede om :-)

// ouT

Tak for jeres kommentarer. Min umiddelbare konklussion må være at der ikke findes et officelt dansk ord for den proces.

Læg et svar, hvis I vil have points :-)

Det danske ord må være krympe. Men det er ikke et af de ord som man bør fordanske.

I gamle dage (næsten tilbage til dinosauerne) brugte man altid fixed size filer.

For at kunne sikre sig at filerne er contigious i fil systemet.

Jeg kan huske da SQLServer 7.0 blev annonceret med autogrow. Ingen troede at den feature
nogen sinde ville blive brugt.

Hvis ikke min ellers glimrende(?) hukommelse svigter, så brugte MS Access i DK udgave ordene "Defragmentering" og "Komprimering".

Shrink er (æh, vist nok?) sådan lidt en blanding af begge - den både flytter lidt rundt på tingene, så de ligger tættere på hinanden (afhængig af clustered indexes) og så sørger den så for at databasefilen formindskes, så der ikke er tom/spild-plads i den.

Generelt er det en dårlig ide at shrinke sin database, for hvis man så putter nye data i, så skal filen udvides igen, hvilket typisk ender med, at selve db-filen bliver defragmenteret i filsystemet.

Til buzzzz: For at loggen kan komme ned i størrelse igen, er det dels nødvendigt at lave en fuld backup, og så kan man lave en CHECKDB med en eller anden parameter, som jeg ikke kan huske, og så vil SQL Serveren, sådan ved lejlighed og når den synes den har tid og når vinden står i vest truncate logfilen, så den kommer ned i størrelse igen.

Tænker du på DBCC SHRINKFILE ?

torbenkoch#
weee ... enig med bad idea med at skrink :-)

Men det kan vel løses på systemet senere med en defrag af selv filsystemet.

// ouT

Jo. Men først kører systemet langsomt mens filen udvider sig. Og så skal man have
databasen ned mens man defragmenterer.

Det er muligt men ikke specielt sjovt.

arne_v: Ja, det er vist den ;-)

Hvis der er nogle af d'herrer der ønsker point, så læg et svar, så jeg kan få lukket.

Tak for deltagelse.

ahh, synes snakken gik i en lidt anden retning til sidst. Så ved ik' om jeg synes jeg egentlig har bidraget til det oprindelige spørgsmål.

// ouT

et svar for "krympe"

(Google kan ikke oversætte shrink til dansk men den kan oversætte krympe til engelsk: http://translate.google.com/translate_t?hl=en#da|en|krympe%0A)