SQL Server 2008 R2 Transactional Logs.

[To_Tall]

Ik heb voor CRM 2011 MS SQL Server 2008 R2 draaien. Met de laatste updates e.d.
Machine is een beetje traag. Mn werkgever moest en zou de SQL DB's virtueel hebben. Makkelijk met back-uppen e.d.

Anyway.

Nu omdat de VM werdt geback-uped is het Transactional Log gegroeid naar 450 GB Dat is veel te groot voor de DB die zelf maar 36 GB groot is..

Nu heb ik de back-up van de VM zelf stopgezet.. Onzin om een VM volledig te back-uppen.. Ik gebruik DPM 2010 voor back-ups. Werkt prima, kan makkelijk de SQL DBa's zien en maak daar netjes een backup van.

Echter ik verwacht na een back-up dat de Transactional LOG een Truncate krijg.. Niet meer gebruikte data wordt uit het log bestand verwijderd..
Ik draai hierna een SHRINK DB command via de SQL managment studio. Maar het eigenlijke log bestand blijft 450 GB houden.. Optie release unused space staat aan.

Log bestand gaat nu problemen geven ivm performance.. Ik ben bezig om een 2 tal fysieken SQL server te plaatsen met 15k schijven.

Iemand enig idee waarom Transactional Log File niet wil truncaten?

[redfoxert]

Ik meen ergens gelezen te hebben dat SQL Server 2008 de transaction logs niet meer bij backups commit maar alleen als je een maintenance plan hebt ingesteld...

Correct me if i'm wrong, ben geen MSSQL specialist

[McWolf82]

Ligt aan het recovery model wat voor de database wordt gebruikt. Simple truncate de logs wel, Full niet.

Je zou de database kunnen detachen, logfile hernoemen, database attachen.
SQL Management Studio zal aangeven dat logfile niet meer bestaat, dan kun je de logfile verwijderen, SQL zal dan een nieuw logfile aanmaken.

Het gaat hier om 450 GB, maak dus wel een backup van de logfile voordat je bovenstaande doet.

[ Voor 78% gewijzigd door McWolf82 op 16-02-2012 17:13 ]

[Arjen42]

Als je geen transaction log backups gaat maken en ook niet om een andere reden het full recovery model nodig hebt. Kun je deze het recovery model het beste op simple zetten. Daarna kun je met DBBC shrinkfile(2); de transaction log file kleiner maken. (Wel eerst USE [database]; gebruiken.)

Het effectief verwijderen van de transaction log file zou ik niet doen. SQL Server doet dan wel een herstel poging door een nieuwe transaction log file aan te maken, maar dit is dan wel een noodoplossing. Liever niet dus.

Zie verder voor details:

• MSDN: Recovery Model Overview.
• MSDN: DBCC SHRINKFILE (Transact-SQL)

[Brainstorm]

Inderdaad, eigenlijk is het vrij simpel:
* Als je een full recovery model hebt, dan is de enige manier om de logs te kunnen shrinken door een transaction log backup te maken. Dat zorgt ervoor dat de logs daarna geshrinkt kunnen worden. Verwar dit niet met een full backup, dat is niet voldoende.
* En als je geen full recovery model nodig hebt, gebruik je het simpel model.

Zie voor een uitgebreider hoe&waarom hiervan:
* http://www.sqlskills.com/...to-convince-yourself.aspx
* http://www.sqlskills.com/...-log-size-management.aspx

Mijn gok is dat je alleen een full back-up hebt en een full recovery model, waardoor je tegen het eerste punt aanloopt.

[ Voor 8% gewijzigd door Brainstorm op 18-02-2012 09:10 ]

[_Arthur]

To_Tall schreef op woensdag 15 februari 2012 @ 00:00:
Echter ik verwacht na een back-up dat de Transactional LOG een Truncate krijg.. Niet meer gebruikte data wordt uit het log bestand verwijderd..
Ik draai hierna een SHRINK DB command via de SQL managment studio. Maar het eigenlijke log bestand blijft 450 GB houden.. Optie release unused space staat aan.

Een truncate is geen shrink. Je logs worden wel getruncate (create empty space inside the transaction log) echter kennelijk niet geshrinked door je handmatige actie. Ik zou daar verder naar kijken. Eventueel een SQL Maintenance Plan job maken om te zien of, wanneer je die laat draaien, dan wel je logs worden geshrinked.

Een SQL Maintenance Plan kan je naast je reguliere backup configureren.

En nog de laatste opmerking: SHRINK DB shrinkt je Database, niet je Transaction Log files.

Iemand enig idee waarom Transactional Log File niet wil truncaten?

Dat is dus je probleem niet, zo te lezen

[ Voor 9% gewijzigd door _Arthur op 18-02-2012 10:57 ]

[_Arthur]

En, nog gelukt?