Am o baza de date de Sharepoint pe un sql 2005 de 14 Mb iar fisierul de log al acesteia de 10Gb ! Am facut shrink, transaction bkp, dar marimea acestuia a ramas neschimbata . Si cum am nevoie de putin spatiu urgent va cer ajutorul !

Multumesc.

---

MCSE;MCITP

Presupun ca lucrezi pe recovery model full.
Vezi
http://sqlserver.ro/forums/thread/8306.aspx
http://www.sqlservercentral.com/Forums/Topic925739-391-1.aspx#bm925746
Daca stapanii tai accepta pierderea de date (depinde si de cat accepta), gandeste-te sa usurezi administrarea trecand pe "simplu".
Daca ramai pe full, vezi ca beckup-urile de log sa fie suficient de frecvente. Tranzactiile lungi, cele care raman deschise sau operatiunile bulk pot fi problematice.
Revezi in detaliu si BOL ---> DBCC SHRINKFILE

Aceeasi problema o avea Sorin. Faceti un full backup, treceti baza de date pe recovery model simple, folositi shrink database, treceti baza de date inapoi pe full recovery model.

---

Cristian Andrei Lefter, SQL Server MVP
MCT, MCSA, MCDBA, MCAD, MCSD .NET,
MCTS, MCITP - Database Administrator SQL Server 2005
http://sqlserver.ro

Fiind server de Sharepoint iti dai seama ca nimeni nu accepta nici cea mai mica pierdere ! Deja am vb sa mai achizitionam 2 diskuri ptr mirror si voi muta fisierele acolo !

Totusi nu este prima oara cand ma lovesc de aceasta problema ! Am mai intalnit-o la o baza de date creata de crm unde la 10Gb date aveam 12Gb log ! Am creat la recomandarea voastra tran log la fiecare 2 ore dar nici asa n-am rezolvat definitiv problema !

Stiu ca recomandarile MS sunt ca marimea fisierul de log sa fie < 75% m fisierului de date !

In cazul meu habar n-am cum voi reusi sa-l reduc atat !

---

MCSE;MCITP

xmldeveloper:

Aceeasi problema o avea Sorin. Faceti un full backup, treceti baza de date pe recovery model simple, folositi shrink database, treceti baza de date inapoi pe full recovery model.

Merci asa am sa fac :) !

---

MCSE;MCITP

Daca tot cumparati discuri - e bine ca logul sa stea pe un disc dedicat.

Da clar asta am sa si fac ! Doar ca fiind server de Sharepoint nu are o prea mare incarcare si merge f bine .Am sa le mut totusi din lipsa spatiului .

Multumesc ptr raspunsuri :) !

Rosql Rulzzz !

---

MCSE;MCITP

Te gandesti si la performanta (logul e secvential), si la spatiu si la redundanta (mirror sau RAID 10)

Pentru reducerea dimensiunii log-ului procedeaza asa(operezi doar pe fisierul de log cu SSMS):

Backup log file
Shrink log file
Backup log file
Shrink log file

Operatiile se dau exact in ordinea aceasta si de cate doua ori. Primul shrink pe log nu elibereaza integral spatiul catre SO. Al doilea shrink facut pe log, va aduce marimea acestuia chiar la 'initial size', daca se face si backup-ul de log anterior. E bine ca shrink-ul sa urmeze imediat backup-lui de log, pentru a minimiza aparitia de tranzactii in acesta, intre cele doua operatiuni
Daca vei da shrink pe intreaga baza de date (data&log) acest lucru se va jurnaliza din nou in log ducand la cresterea marimii sale.
Poti introduce aceste operatiuni in planul de mentenanta. Eu folosesc asa ceva permanent. Operatiuni de genul Reorganize sau Rebuild indexes duc la cresteri semnificative ale fisierelor de log

Problema cu marimea log-ului eu am rezolvat-o cum a spus Cristi : imediat dupa un Full Backup am trecut bazele in Simple Model Recovery --> Shrink Database --> Full Recovery Model inapoi si acum totul este OK.

---

Sorin Titu
MCITP Database Administrator
MCITP Enterprise Administrator