La un portal SharePoint (2007) baza de date WSS_Content a ajuns la 5 GB iar logul la 4GB.

Cum pot face shrink la log pentru ca am mari probleme la backup?

Am incercat din SQL Server Management Studio (Shrink File) si cu DBCC SHRINKFILE dar nu vrea.

Am facut si un backup full dar nimic. Ramane la aceeasi valoare.

Exista o alta solutie ?

Sorin Sandu

 

---

Sorin Sandu

Incercati un backup de log cu optiunea "with no_log"  si dbcc shrinkfile cu optiunea notruncate si apoi truncateonly (altfel , operatia de shrink e bine sa o puneti intr-un maintenance plan pentru la noapte cand nu e nimeni pe baza de obicei)

---

Gheorghe Ciubuc,SQL Server Influencer, MCP(SQL 2000), MCTS (SQL Server 2005) , OCA(Oracle 9i), Sybase(Brainbench)

La o bază de date din producţie cel mai bine e să se facă regulat backup-uri la transaction log (nu doar backup-uri full). După ce faceţi un prim backup de transaction log, puteţi să-i daţi DBCC SHRINKFILE şi ar trebui să se micşoreze (dacă nu, poţi să mai faci un backup de transaction log şi imediat după aceea DBCC SHRINKFILE). Dacă e o bază de date de test, atunci se poate pune pe Simple Recovery Model şi nu mai e nevoie să se facă backup-uri la transaction log.

Răzvan

Prima solutie a mers perfect.

Am facut un script pe care l-am prins in fostul MaintenancePlan (acolo era srinkul implicit care nu mergea).

 

---

Sorin Sandu

Dacă faceţi "BACKUP LOG bazadedate WITH NO_LOG" atunci se şterge transaction log-ul fără a se face un backup al lui într-un fişier şi astfel pierdeţi posibilitatea de a face "point-in-time restore", adică restaurarea bazei de date aşa cum era la un moment oarecare în trecut (puteţi să o restauraţi doar în starea în care era la momentele în care aţi făcut backup full). Dacă într-adevăr nu aveţi nevoie de această facilitate, puteţi studia oportunitatea adoptării Recovery Model-ului "Simple".

Răzvan

Este valabil si ptr SQL Server 2008 (nu mai are NO_LOG sau TRUNCATE_ONLY) ?
Ce recomanzi ?
DBCC SHRINKFILE nu merge decat daca recovery model e SIMPLE.

---

Sorin Sandu

Eu nu recomand BACKUP WITH NO_LOG (sau TRUNCATE_ONLY) nici în versiunile anterioare. Dacă e vorba de o bază de date de test, recomand recovery model-ul SIMPLE. Dacă e vorba de o bază de date de producţie, recomand backup-uri de log periodice.

Dacă se doreşte totuşi să se facă ceva echivalent cu BACKUP WITH NO_LOG pe SQL Server 2008, atunci se poate schimba recovery model-ul din FULL în SIMPLE şi apoi la loc în FULL.

Răzvan

ssandu:

Este valabil si ptr SQL Server 2008 (nu mai are NO_LOG sau TRUNCATE_ONLY) ?
Ce recomanzi ?
DBCC SHRINKFILE nu merge decat daca recovery model e SIMPLE.

Ai incercat ceea ce se recomanda aici ?

Backup and restore	BACKUP LOG WITH NO_LOG	None. The transaction log is automatically truncated when the database is using the simple recovery model. If you must remove the log backup chain from a database, switch to the simple recovery model.
Backup and restore	BACKUP LOG WITH TRUNCATE_ONLY	None. The transaction log is automatically truncated when the database is using the simple recovery model. If you must remove the log backup chain from a database, switch to the simple recovery model.

Vezi daca te ajuta "punctul" 8 din lista:

http://sqlskills.com/blogs/kimberly/2005/06/25/8StepsToBetterTransactionLogThroughput.aspx

As fi vrut sa evit si un backup de log deoarece fac doar un backup full.
ce parere aveti de
ALTER DATABASE .... SET RECOVERY SIMPLE WITH NO_WAIT
si apoi
DBCC SHRINKFILE('fisierlog', 0, TRUNCATEONLY)
si iar
ALTER DATABASE .... SET RECOVERY FULL WITH NO_WAIT

---

Sorin Sandu

Dacă nu faci backup-uri de log, trecerea înapoi pe recovery model-ul FULL este inutilă. Ar fi mai uşor să îl treci pe recovery model-ul SIMPLE şi apoi să-l laşi aşa (astfel nu o să mai ai probleme cu creşterea fişierului de log). Bineînţeles, asta înseamnă că renunţi la posibilitatea de a face point-in-time restore, dar dacă nu făceai backup-uri de log (ci doar full), oricum nu era posibil să faci point-in-time restore.

Răzvan