---

Hej gruppe

Har en SQL server der rammer loftet pga. af den allokeret plads - det viser
sig at det er Transactions loggen der vokser og vokser ...

1) hvordan slettes/undgås den ?
Ved forsøg på sletning via Enterprise manager får jeg fejlen 5042 the file "
.....log " can't be removed because its not empty...

2) hvordan undgås at den vokser og rammer loftet ?

på forhånd tak

---

> Har en SQL server der rammer loftet pga. af den allokeret plads - det
> viser sig at det er Transactions loggen der vokser og vokser ...

Jeg kan heller ikke forstået det med loftet - hvis man sætter det, og filen
bliver så stor, så dør databasen pga. pladsmangel... (?)

> 1) hvordan slettes/undgås den ?
> Ved forsøg på sletning via Enterprise manager får jeg fejlen 5042 the
> file " ....log " can't be removed because its not empty...

Jeg mener du skal unmounte din database før du kan gøre noget med dens
filer. Men mener heller ikke at den anbefales at gøre det sådan.

> 2) hvordan undgås at den vokser og rammer loftet ?

Vokse-problemet burde svjv. kunne undgåes ved at tage backup at
trans-filen - dermed skulle den blive nulstillet.

--
Mvh
///JJ

---

"Erik" wrote

> Har en SQL server der rammer loftet pga. af den allokeret plads - det
> viser sig at det er Transactions loggen der vokser og vokser ...
>
Jeps, det gør den

> 1) hvordan slettes/undgås den ?

Backup?

> Ved forsøg på sletning via Enterprise manager får jeg fejlen 5042 the file
> " ....log " can't be removed because its not empty...

Don't du kan miste alle dine data
>
> 2) hvordan undgås at den vokser og rammer loftet ?
>
Det kan du ikke

Det vil sige med dine nuværende indstillinger for recovery model så _skal_
du tage backup af din transactionlog

Hvis du ikke ønsker at gøre dette, så skal du ændre din recovery model

Start Enterprise Manager
Find din server og derefter din database
Højreklik og vælg properties -> fanebladet options
Recovery model ændres fra "full" til "simple"
Genstart serveren

Du lan læse mere om recovery model i BOL
Led efter "using recovery model"

Hvis du ikke har adgang vha Enterprise Manageren så sig lige til

- Peter

---

Hej Erik.

Lyt til Peter, ellers rammer alverdens katastrofer og data-tab dig snart

En transaktions log er en fil der indeholder alle de rettelser der er
foretaget i din database, siden et bestemt tidspunkt. Det er altså
bevidst designet sådan, at "nye ting" hober sig op i transaktions
loggen, indtil man syntes man vil "comitte" dem til sin database.
Årsagerne kommer vi ikke ind på hér

Din transaktionslog "nulstilles" eller "comittes" til databasen på flere
måder. Det kan enten ske før/efter hver backup du tager, på et fast
tidspunkt hver dag/uge, eller løbende under driften. Det kan også gøres
manuelt ved udførelsen af en SQL kommando.

Hvis du ikke bruger "transaktioner" til noget, så kan det tænkes du slet
ikke har brug for at tænke så meget på det, og du kan så følge Peters
glimrende procedure til at vælge "Simple recovery" i egenskaberne for
din database.

Venligst


- Jesper




Peter Lykkegaard wrote:
> "Erik" wrote
>
>
>>Har en SQL server der rammer loftet pga. af den allokeret plads - det
>>viser sig at det er Transactions loggen der vokser og vokser ...
>>
>
> Jeps, det gør den
>
>
>>1) hvordan slettes/undgås den ?
>
>
> Backup?
>
>
>>Ved forsøg på sletning via Enterprise manager får jeg fejlen 5042 the file
>>" ....log " can't be removed because its not empty...
>
>
> Don't du kan miste alle dine data
>
>>2) hvordan undgås at den vokser og rammer loftet ?
>>
>
> Det kan du ikke
>
> Det vil sige med dine nuværende indstillinger for recovery model så _skal_
> du tage backup af din transactionlog
>
> Hvis du ikke ønsker at gøre dette, så skal du ændre din recovery model
>
> Start Enterprise Manager
> Find din server og derefter din database
> Højreklik og vælg properties -> fanebladet options
> Recovery model ændres fra "full" til "simple"
> Genstart serveren
>
> Du lan læse mere om recovery model i BOL
> Led efter "using recovery model"
>
> Hvis du ikke har adgang vha Enterprise Manageren så sig lige til
>
> - Peter
>
>

---

"Jesper Sommer" wrote

> En transaktions log er en fil der indeholder alle de rettelser der er
> foretaget i din database, siden et bestemt tidspunkt.

Så langt så godt

> Det er altså bevidst designet sådan, at "nye ting" hober sig op i
> transaktions loggen, indtil man syntes man vil "comitte" dem til sin
> database.

Nej det har du misforstået (ellers har jeg

Hvis man kører med full recovery model så indeholder transaction loggen alle
ændringer i datagrundlaget siden sidste fulde backup
Full recovery model indebærer at man ligeledes tager en løbende backup af
transaction loggen

Har man brug for at genindlæse en backup, fx pga diskcrash etc
Så tager man først en backup af den aktive transactionlog
Så indlæser man først den fulde backup fx fra om natten + evt differential
backups
Derefter indlæser man backups af transactionsloggen indtil seneste backup
hvorved man faktisk udfører opdateringer løbende mod databasen
Til sidst den sidste backup af transaction loggen

Fra BOL (Books OnLine):
<quote>
Recovering in the Event of Media Failure
You can restore a database to the state it was in at the point of failure if
the current transaction log file for the database is available and
undamaged. To restore the database to the point of failure:

Back up the currently active transaction log. For more information, see
Transaction Log Backups.
Restore the most recent database backup without recovering the database.
If differential backups exist, restore the most recent one.
Restore each transaction log backup created since the database or
differential backup in the same sequence in which they were created without
recovering the database.
Apply the most recent log backup (created in Step 1), and recover the
database.

Important To protect against loss of transactions under the Full Recovery
model, the transaction log must be protected against damage. It is strongly
recommended that fault-tolerant disk storage be used for the transaction
log.
</quote>


Mht manuel trunkering af loggen:
<quote>
Although the transaction log may be truncated manually, it is strongly
recommended that you do not do this, as it breaks the log backup chain.
Until a full database backup is created, the database is not protected from
media failure. Use manual log truncation only in very special circumstances,
and create a full database backup as soon as practical.
</quote>

Dvs man er imho bedre tjent med at køre med "Simple Recovery Model"

NB arbejder man med Simple Recovery Model så mister man alle data siden
sidste backup fx i tilfælde af et diskcrash og databasen er væk

- Peter

---

>>Det er altså bevidst designet sådan, at "nye ting" hober sig op i
>>transaktions loggen, indtil man syntes man vil "comitte" dem til sin
>>database.
>
> Nej det har du misforstået (ellers har jeg

Mjoeh ... den er go' nok. Ved at opsamle transaktioner i en separat
fil, sikres konsistens i forbindelse med nedbrud. Derfor anbefales det
også at transaktionsloggen ligger filmæssigt på et andet fysisk drev
end datafilerne, og at der tages hyppig backup.

Finten er, at alle statements der ændrer i data (DML som f.eks. INSERT
eller UPDATE) opsamles i transaktionsloggen og bliver liggende dér
indtil loggen trunkeres. Ved hjælp af et truncate statement kan man få
serveren til at skrive indholdet af transaktionsloggen ned i databasen,
og slette de posteringer i loggen som databasen nu indeholder. Dette
sker automatisk på f.eks. MS SQL Server når man foretager backup, men
det kan også gøres som en del af en maintenance plan. Hvis systemet
bryder sammen inden loggen er trunkeret, kan man indlæse backup af den
fysiske database, og derefter foretage roll-back i transaktionsloggen
indtil et tidspunkt hvor man mener databasen er konsistent. Resten af
loggen kan så enten kasseres eller behandles manuelt. Formålet med at
adskille transaktionsloggen fra den fysiske databasefil er bl.a. at
sikre konsistens ved nedbrud, men også nogle andre nørdede ting som
f.eks. performance tuning ved mange og tunge INSERT/UPDATE statements,
samt replikering af data mellem flere adskilte fysiske databaser.

Selv hvis man vælger at køre "uden transaktionslog" så laver de fleste
severe faktisk een alligevel. Den bliver bare automatisk trunkeret
(skrevet og valideret) i basen ved hver eneste checkpoint som serveren
udfører. Derfor ser loggen altid ud til at være tom. Checkpoints er
regelmæssige interne "helbredscheks" som serveren udfører, og som rydder
op i tabte forbindelser eller udfører andre interne handlinger på
serveren. Ved at vælge "simple recovery model" i MS SQL Server sker der
i praksis det, at serveren trunkerer transaktionsloggen ved hvert eneste
checkpoint.

Jeg faldt over denne engelske gennemgang som måske kan forklare det
bedre end jeg kan ...

http://techrepublic.com.com/5100-6313-5173108.html

Venligst


- Jesper

---

"Jesper Sommer" wrote

> Finten er, at alle statements der ændrer i data (DML som f.eks. INSERT
> eller UPDATE) opsamles i transaktionsloggen og bliver liggende dér indtil
> loggen trunkeres.

Jow, det er den del jeg ikke er helt enig i

Jeg mener at det er en kopi af transaktionerne (siden sidste
backup/trunkering)
Hvis de ikke skrives den aktuelle database så mister jeg data når jeg
trunkere den eller jeg mister/sletter transaktionsloggen udenom mssql
Trunkeren = sletning af loggen, der sker ikke nogen skrivning til databasen
ved en trunkering

PS: Jeg har ikke lige læst linket, kommer senere

- Peter

---

NOT Trunkering = sletning af loggen.



- Jesper



Peter Lykkegaard wrote:
> "Jesper Sommer" wrote
>
>
>>Finten er, at alle statements der ændrer i data (DML som f.eks. INSERT
>>eller UPDATE) opsamles i transaktionsloggen og bliver liggende dér indtil
>>loggen trunkeres.
>
>
> Jow, det er den del jeg ikke er helt enig i
>
> Jeg mener at det er en kopi af transaktionerne (siden sidste
> backup/trunkering)
> Hvis de ikke skrives den aktuelle database så mister jeg data når jeg
> trunkere den eller jeg mister/sletter transaktionsloggen udenom mssql
> Trunkeren = sletning af loggen, der sker ikke nogen skrivning til databasen
> ved en trunkering
>
> PS: Jeg har ikke lige læst linket, kommer senere
>
> - Peter
>
>