Intrebare:

Administrez un server SQLSERVER2005. In ultima vreme(cam de o saptamana) constat ca fisierul de log asociat unei baze de date(*_log.ldf are aprox.131GB iar *.mdf are aprox 6GB ) creste mult prea mult fata de tranzactiile ce se desfasoara. Mentionez ca baza de date are taskuri de mentenanta ce se desfasoara zilnic,saptamanal si lunar(aceasta insemnand check database integrity, backup full, rebuild index, reorganize reindex, update database statistics si maintenance cleanup task) Lunar, rulez si un 'shrink databases'. Ultimul test care l-am facut a fost sa dau un shrink. Dupa acesta, spatiul liber pe HDD mi-a scazut si mai mult-cu aprox. 3GB. De fapt tot cu atat a crescut si fisierul de log. Practic, nu s-a eliberat spatiu ce ar fi trebuit pus la dispozitia sistemului de operare.Nu cred ca e normal ca un shrink sa imi mareasca fisierul de log cu atat de mult(3GB)!

Dacă Recovery Model este Full, atunci trebuie să faci periodic backup-uri pentru transaction log (în afară de backup-urile full, pe care le poţi face mai rar). Dacă nu vrei să faci backup-uri de transaction log, atunci poţi să treci pe Recovery Model Simple, dar în acest caz pierzi posibilitatea de point-in-time restore.

Pe de altă parte, la shrink s-a întâmplat creşterea fişierului de log pentru că atunci când a făcut shrink pt fişierul de date, a mutat la începutul fişierului toate datele care erau la sfârşitul fişierului (şi astfel a creat şi o fragmentare enormă). Această mutare (precum şi eventuala defragmentare ulterioară) a fost logata complet în fişierul de log, iar acesta nu putea fi eliberat până când nu faci un backup la transaction log. De-abia după ce faci backup de log, un shrink ar putea să micşoreze fişierul LDF.

Pentru mai multe informaţii despre creşterea log-ului, vezi:
http://jmkehayias.blogspot.com/2008/11/database-transaction-log-part-1.html
http://jmkehayias.blogspot.com/2008/11/database-transaction-log-part-2-how.html

Răzvan

Vezi si http://www.sqlskills.com/BLOGS/PAUL/category/Transaction-Log.aspx#p2. Despre cresterea exagerata a log-ului: http://www.sqlskills.com/BLOGS/PAUL/category/Transaction-Log.aspx#p22.

Pentru "intretinerea" log-ului: http://www.sqlskills.com/blogs/kimberly/post/8-Steps-to-better-Transaction-Log-throughput.aspx

Multumesc, am reusit sa rezolv. Aveam setat recovery model in full. Am facut backup la fisierele de log, am dat din nou un shrink si problema s-a rezolvat.