[MsSql] Transaction log shrinken of deleten

Pagina: 1
Acties:
  • 202 views sinds 30-01-2008
  • Reageer

  • Blue-eagle
  • Registratie: September 2000
  • Niet online
Ik vraag dit op GoT omdat ik absoluut geen verstand heb van MsSql en degene die dat wel heeft hier op de zaak op vakantie is. Het probleem is dat een database bijna 7 gig in beslag neemt en ongelimiteerd kan groeien. De harde schijf zit nu vol waardoor meerdere processen het niet meer lekker doen op de server.

Andere topics op GoT zeggen me bijzonder weinig of komen aanzetten met oplossingen die mij als database leek te gevaarlijk lijken om zomaar uit te voeren. Daar komt bij dat ik de helft ook gewoon niet begrijp ;(

Zou iemand me in newbie-taal kunnen uitleggen hoe ik deze file verwijder of kleiner maak zonder de database in gevaar te brengen?

Note: De gewone "delete" knop in het tabblad "Transaction log" onder de database eigenschappen werkt niet: "Error 5020: The primary data or log file cannot be removed from a database."

Ik zou normaal gesproken gewoon proberen en backups maken voordat ik iets verwijder... alleen het bestand is gelocked, de database kan ik niet zomaar uitzetten en de HDD is vol.

[ Voor 5% gewijzigd door Blue-eagle op 25-08-2005 10:18 ]


  • whoami
  • Registratie: December 2000
  • Laatst online: 14:39
Als je een backup neemt van je transaction log, dan zou die log moeten shrinken dacht ik.
(Hmm, ok, de HDD is vol, je kan niet backupen naar een ander medium ?)

Je kan je Transaction log wel shrinken, maar dan ben je die wel kwijt. Dit kan een probleem zijn als je een crash krijgt tussen 2 backups door.

In de Books Online van SQL Server staat er een volledig artikel over het shrinken van het transaction log.

Met een DBCC SHRINKFILE command zou je die log moeten kunnen truncaten.

[ Voor 81% gewijzigd door whoami op 25-08-2005 10:23 ]

https://fgheysels.github.io/


  • mulder
  • Registratie: Augustus 2001
  • Laatst online: 30-04 15:47

mulder

ik spuug op het trottoir

je kan de database detachen en dan kun je volgens mij de log gewoon deleten.

oogjes open, snaveltjes dicht


  • P_de_B
  • Registratie: Juli 2003
  • Niet online
Don Facundo schreef op donderdag 25 augustus 2005 @ 10:22:
je kan de database detachen en dan kun je volgens mij de log gewoon deleten.
Ik zou gewoon

BACKUP LOG 'naam' WITH TRUNCATE_ONLY om het logische bestand te verkleinen, en daarna zoals whoami zegt DBCC shrinkfile 'c:\fysieke\bestands\locatie.ldf' gebruiken om het fysieke bestand te verkleinen, en direct daarna de database backuppen!


Wordt de database wel goed gebackupped?

[ Voor 8% gewijzigd door P_de_B op 25-08-2005 10:28 ]

Oops! Google Chrome could not find www.rijks%20museum.nl


  • miniBSD
  • Registratie: Augustus 2002
  • Laatst online: 20-12-2023
Bij de SQL Enterprise Manager kun je door middel het selecteren van de database met de optie 'shrink' in het rechtermuis menu zien hoeveel ruimte er in beslag genomen wordt. Door op 'OK' te drukken wordt de ruimte van database verkleind.

Dat je logbestand zo groot is geworden heeft een reden, bijvoorbeeld de recovery mode staat op 'Full' of er is geen maintance plan. Het is aan te raden dat de beheerder de instellingen eens doorneemt anders sta je straks weer voor hetzelfde probleem.

Quidquid latine dictum sit, altum sonatur (Whatever is said in Latin sounds profound).


  • Blue-eagle
  • Registratie: September 2000
  • Niet online
whoami schreef op donderdag 25 augustus 2005 @ 10:20:
Als je een backup neemt van je transaction log, dan zou die log moeten shrinken dacht ik.
(Hmm, ok, de HDD is vol, je kan niet backupen naar een ander medium ?)
Op geen enkele stand alone PC heb ik genoeg ruimte, en backups worden niet opgeslagen op discs o.i.d. maar op een andere manier. Helaas kan ik dus niet snel een backup maken.
Je kan je Transaction log wel shrinken, maar dan ben je die wel kwijt. Dit kan een probleem zijn als je een crash krijgt tussen 2 backups door.
Nou database damage ben ik niet zo bang voor, de gehele database is namelijk gedupliceerd voor een test omgeving. En de test omgeving is degene die zo groot wordt - als test data weg is vind ik dat niet zo erg.
In de Books Online van SQL Server staat er een volledig artikel over het shrinken van het transaction log.
Ik ga even Googlen hierop, heb namelijk geen idee wat je bedoeld :)
Met een DBCC SHRINKFILE command zou je die log moeten kunnen truncaten.
Commands?

Ik baal ervan dat ik gewoon 0 idee heb van wat ik aan het doen ben... SQL query's zijn cake maar database management is toch iets heel anders ;(
Don Facundo schreef op donderdag 25 augustus 2005 @ 10:22:
je kan de database detachen en dan kun je volgens mij de log gewoon deleten.
Ja dat had ik gelezen inderdaad, alleen het detachen en dergelijke zeggen me niks.

Pagina gevonden:
http://www.databasejourna...mssql/article.php/1460151

Het komt me toch nog te gevaarlijk over allemaal. Data damage in deze specifieke database is niet zo erg, maar als het even voorkomen kan worden - graag!

  • whoami
  • Registratie: December 2000
  • Laatst online: 14:39
Detachen kan je doen in SQL Enterprise manager (rechtsklikken op de DB, en dan detach kiezen). Daarna moet je 'm wel weer attachen natuurlijk.

Die DBCC commands kan je gewoon uitvoeren in Query Analyzer, gewoon ff de juiste syntax opzoeken in de books online.

https://fgheysels.github.io/


  • P_de_B
  • Registratie: Juli 2003
  • Niet online
Je hebt voor het backuppen met WITH TRUNCATE_ONLY geen extra backup ruimte nodig, omdat er feitenlijk geen BU wordt gemaakt. Je zult wel op de 'normale' manier een backup moeten maken omdat je met het log niets meer kunt herstellen tussen 2 backups in.

Heel concreet:

1) Log backuppen met het commando dat ik zei
2) DBCC shrinkfile gebruike
3) database backuppen

Je kunt wel met Query Analyzer commando's naar de database versturen. Je weet hoe dat moet?

Oops! Google Chrome could not find www.rijks%20museum.nl


  • Blue-eagle
  • Registratie: September 2000
  • Niet online
Alright, ik ga even wat proberen :) Bedankt tot zover!

Edit:
Je kunt wel met Query Analyzer commando's naar de database versturen. Je weet hoe dat moet?
Niet echt, maar dat lijkt me niet echte rocket science :)

[ Voor 61% gewijzigd door Blue-eagle op 25-08-2005 10:39 ]


  • Blue-eagle
  • Registratie: September 2000
  • Niet online
offtopic:
Nieuwe reply ipv. edit om te kicken voor geinteresseerden


Detachen en dergelijke leek niet nodig, ik had het volgende gevonden voor de query analyzer:
code:
1
2
3
4
USE DATABASENAME
GO
DBCC SHRINKFILE (DATABASENAME_Log, 700)
GO
En dat werkte aardig zo te zien :)

Heeft dit nog nadelige gevolgen?

En kan ik nu de database zo instellen dat hij niet groter mag worden dan 2 gig zonder in de problemen te komen? (Ik neem aan dat hij dan alleen transactions logged tot de 2 gig en dan de oude transactions verwijderd om plaats te maken voor de nieuwe?)

In ieder geval kunnen andere applicaties weer verder...
Thanks :)

  • whoami
  • Registratie: December 2000
  • Laatst online: 14:39
Zoals P_de_B al zei, zou ik -indien je dat nodig acht- de DB nu backupen.

Om te voorkomen dat dit nog gebeurd, kan je in SQL Enterprise Manager een maintainance plan aanmaken voor die database. Daarbij geef je bv aan dat je DB iedere dag moet gebackup'ed worden, dat de transaction log iedere keer moet gebackuped worden (hierdoor zal de trans-log automatisch shrinken dacht ik), en dat je bv de backups van de transaction logs slechts 2 dagen ofzo wilt bewaren.

https://fgheysels.github.io/

Pagina: 1