MSSQL 2008 Transaction log

[Fanman]

Als eerste, ik kom nog maar net kijken op het gebied van Microsoft SQL 2008, dus veroordeel me niet gelijk als n00b svp.

Ik heb een database waarvan de transaction log eigenlijk te groot wordt.
Deze wil ik graag elke week opschonen (truncate) maar kennelijk werkt het commando wat ik gebruikte in SQL 2005 niet meer in 2008.

Ik gebruikte eerder:

code:

USE <DBNAME>
GO
Backup Log YourDatabaseName With Truncate_Only
GO
eclare @LogFileLogicalName sysname
select @LogFileLogicalName=Name from sys.database_files where Type=1
print @LogFileLogicalName

DBCC Shrinkfile(@LogFileLogicalName,1024)
GO

2008 pikt het commando "Truncate_Only" kennelijk niet meer.

Wat ik nu heb gedaan is het volgende:

code:

USE <DBNAME>
select name,recovery_model_desc from sys.databases
GO
Alter database <DBNAME> Recovery simple
GO
Declare @LogFileLogicalName sysname
select @LogFileLogicalName=Name from sys.database_files where Type=1
print @LogFileLogicalName
DBCC Shrinkfile(@LogFileLogicalName,1024) 
GO
Alter database <DBNAME> Set Recovery full
GO

Di's natuurlijk niet echt netjes.

Weet iemand de nette manier om een transaction log te schonen door middel van een SQL script?

[Fanman]

Niemand?

[Turdie]

In SQL Server 2008 heet het shrinken:
How to: Shrink a File (SQL Server Management Studio)

Ik wil je trouwens afraden om dit te doen, je kunt beter gewoon je log file vergroten, omdat:

1. Je verliest de mogelijkheid voor Point-in-Time restores
2. Het veroorzaakt file-system fragmentatie, waardoor de performance van je database trager kan worden. Zie ook hier meer voor meer uitleg: SQL Server - Have you observed DBCC SHRINKFILE operation performance, on huge databases?

En via een SQL Server query's gaat het zo:

SQL:

USE DBNAME
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE DBNAME
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (DB_FILE_NAME, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE DBNAME
SET RECOVERY FULL;
GO

Hopelijk heb ik je hiermee wat op weg geholpen .

[Voor 38% gewijzigd door Turdie op 01-07-2011 06:59]

[JeroenV_]

Als je in principe geen transaction log nodig hebt kun je het recovery model van je database ook op simple zetten, die zal nu waarschijnlijk op full staan. Als je hem op simpel zet zal de log ook stukken minder hard groeien.

[Fanman]

shadowman12 schreef op donderdag 30 juni 2011 @ 23:21:
In SQL Server 2008 heet het shrinken:
How to: Shrink a File (SQL Server Management Studio)

Ik wil je trouwens afraden om dit te doen, je kunt beter gewoon je log file vergroten, omdat:

1. Je verliest de mogelijkheid voor Point-in-Time restores
2. Het veroorzaakt file-system fragmentatie, waardoor de performance van je database trager kan worden. Zie ook hier meer voor meer uitleg: SQL Server - Have you observed DBCC SHRINKFILE operation performance, on huge databases?

En via een SQL Server query's gaat het zo:

SQL:

USE DBNAME
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE DBNAME
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (DB_FILE_NAME, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE DBNAME
SET RECOVERY FULL;
GO

Hopelijk heb ik je hiermee wat op weg geholpen .

Helemaal Top!
THX

[Fanman]

JeroenV_ schreef op vrijdag 01 juli 2011 @ 07:41:
Als je in principe geen transaction log nodig hebt kun je het recovery model van je database ook op simple zetten, die zal nu waarschijnlijk op full staan. Als je hem op simpel zet zal de log ook stukken minder hard groeien.

Ik wil wel een transaction log, maar alleen voor overbrugging van 24 uur.
Daarbuiten heb ik altijd twee backups.
Één op tape & één disk.
Gebeurt er wat tussen de backups, heb ik altijd de transaction log nog

[Question Mark]

Wat voor backup-methode gebruik je nu? De meeste fatsoenlijke backupoplossingen kunnen ingesteld worden dat na een succesvolle DB backup automatisch de logfiles getruncated worden.

[Gé Brander]

Dit soort zaken zijn meestal het gevolg van een niet op orde hebben van een juiste inrichting van de SQL Server omgeving. Dit kan zijn:
1) Niet voldoende schijfruimte om de transactie log te hosten
2) Verkeerde keuze recovery model van de database
3) Erg grote transacties (te veel records in 1 transactie, beter om in batches te werken en per keer een x aantal records updaten in plaats van alle records in 1 keer doorlopen)
4) Verkeerde backup strategie (Full, T-Log, Differential backups)

Als je elke dag een backup maakt en niet geinteresseerd bent in point in time recovery, dan doe je elke dag of elke week een backup. Als er dan wat mis gaat dan kan je alleen terug naar de laatste full backup

Als je elke dag een backup maakt en wel geinteresseerd bent in point in time recovery, dan moet je elke dag of elke week een full backup maken, elk uur of elke dag een transaction log backup maken afhankelijk van de Recovery Point Objectives en Recovery Time Objectives. (dit verhaal kan aangevuld worden met differential backups indien nodig)

Het is dus van te voren belangrijk te bepalen wat de RPO en RTO doelen zijn.
1) Mag je data verliezen, zo ja hoeveel? (RPO)
2) Hoe lang mag je omgeving offline zijn bij problemen? (RTO)

Afhankelijk van je RPO richt je de backup strategie in.
Afhankelijk van je RTO bepaal je je restore strategie en eventuele High Availibility opties (log shipping, mirroring en clustering etc.)

Als je meer informatie of tips wil dan stuur je maar een DM of vraag je het hier.

[Voor 3% gewijzigd door Gé Brander op 02-07-2011 08:42]

[Question Mark]

c70070540 schreef op zaterdag 02 juli 2011 @ 08:41:
Als je meer informatie of tips wil dan stuur je maar een DM of vraag je het hier.

Graag de discussie op het forum houden, dan blijft alle info binnen het topic en is dan beschikbaar voor iedereen.