[es] - Divljanje log fajla

M E N E
borislav
Temerin

Član broj: 30434
Poruke: 231
*.static.isp.telekom.rs.

+1 Profil

^{31.08.2009. u 10:29 - pre 178 meseci}

Da li neko vidi problem u tome da svaku noc u uobicajenom JOBu odrzavanja pokrecem DEKIBRE skript (onaj sa 2x ponovljenim istim korakom), a ne da cekam da LOG naraste?
Nocu nemam otvorenih logova, nemam nakacenih korisnika.... mislim da mi je bolje da se tada pokrene, nego na alert, kad server moze biti opterecen?

_{[Ovu poruku je menjao mmix dana 31.08.2009. u 15:54 GMT+1]}

Uhvatili ste me nespremnog

Odgovor na temu

Koce
DBA
Serbia, Belgrade

Član broj: 59217
Poruke: 144
*.static.isp.telekom.rs.

+1 Profil

Re: Divljanje log fajla

^{31.08.2009. u 13:34 - pre 178 meseci}

Mozes da ga pokreces nocu, neces imati stete od toga, ali ni previse koristi jer je ideja da ti u toku dana on (job tj alert) ocisti log. Tako da ako si stavio da je maximum 10 GB i log vise puta u toku dana predje tu vrijednost, vise puta ce se i pokrenuti i ocistiti. Ali ako ti to podesis da se radi nocu, u toku dana log moze da ti predje tu granicu bez problema.
Ako ti vec ne treba log, a stice se utisak jer radis truncate_only, zasto ne stavis bazu na SIMPLE recovery, radice ti i brze i nece ti smetati (skoro nikad, u odredjenim slucajevima log raste i u SIMPLE al pretpostavljam da ti nemas takav slucaj)

Odgovor na temu

M E N E
borislav
Temerin

Član broj: 30434
Poruke: 231
*.static.isp.telekom.rs.

+1 Profil

Re: Divljanje log fajla

^{31.08.2009. u 13:53 - pre 178 meseci}

Pa, stavio sam da mi radi backup transaction LOGa na svakih 30 minuta, u slucaju nekog pada sistema da mogu sto blize da oporavim podatke.
Ipak je produkcija u pitanju.

Medjutim, prilikom tih bekapa, on ne smanjuje sam log (eto, ja sam mislio da odradjuje to!), nego se on nesmetano povecava.
Za samo pitanje, mislim da bi bilo dovoljno da smanji log nocu, jer ne verujem... prakticno je nemoguce... da u toku JEDNOG RADNOG DANA baza dodje do kriticnih vrednosti (bar u ovom slucaju za koji ja pitam)

Uhvatili ste me nespremnog

Odgovor na temu

mmix
Miljan Mitrović
Profesorkin muz
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6042

+4631 Profil

Re: Divljanje log fajla

^{31.08.2009. u 14:06 - pre 178 meseci}

nadam se da ne pozivas ovu skriptu u produkciji jer truncate_only znaci da odbacujes log (sta vise u sql 2008 je ova opcija izbacena upravo zato sto su je ljudi "zloupotrebljavali") samim tim ako se ista desi mozes da zabroavis na recovery.

_{[Ovu poruku je menjao mmix dana 31.08.2009. u 15:54 GMT+1]}

Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan, sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv… - Z.Đinđić

Odgovor na temu

M E N E
borislav
Temerin

Član broj: 30434
Poruke: 231
*.static.isp.telekom.rs.

+1 Profil

Re: Divljanje log fajla

^{31.08.2009. u 14:25 - pre 178 meseci}

Hm.
Ako je ova gore recenica istinita, da gubim podatke prilikom te opcije, onda je sasvim svejedno da li cu je ispaljivati na alert ili na schedule, zar ne? Mislim, ne valja ni u jednom ni u drugom slucaju?

S druge strane, neposredno pre poziva ove sekvence, ja bih odradio FULL BACKUP, zatim ovo (odacivanje loga).... mislim da bi prethodni log sadrzavao sve sto mi treba za recovery, zar ne?

Ne znam nista o tome da toga nema u 2008? Ako je tako... sta da radim, da sprecim "divljanje" log fajla?

Uhvatili ste me nespremnog

Odgovor na temu

mmix
Miljan Mitrović
Profesorkin muz
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6042

+4631 Profil

Re: Divljanje log fajla

^{31.08.2009. u 14:51 - pre 178 meseci}

Ne gubis podatke, gubis recovery informacije, tj mogucnost da vratis bazu u stanje koje je bilo blizu trenutka kad je prsla. Ako radis full backup svakih 30 minuta onda imas kopiju koja nije starija od 30 minuta, ali onda ili nagomilavas pune backup-e baza (48 kopija dnevno) ili uvek brises stare kopije i preko njih nasnimavas nove backup-e. Ovakav metod nije bas odrziv kako baza raste vremenom (sta ces ako baza naraste na 10Gb? svakih pola sata novi backup od 10gb koji treba negde da sklonis sa masine i sacuvas?)

Pre nego resavas divljanje log fajla treba da vidis kakve su tvoje backup potrebe uopste? Dal tebi uopste treba full recovery log? Ako ti ionako njega samo odsecas onda je resenje prebacivanje baze u SIMPLE recovery, u tom slucaju ce sam SQL server da trunc-uje commited transakcije iz loga. Pogledaj Google: "SQL Server Database Recovery Models" i vidi koji od modela tebi najvise odgovara za produkcioni server pa onda mozemo da pricamo o best-practices, u svakom slucaju na BACKUP LOG WITH TRUNCATE_ONLY zaboravi odmah, to se vise ne radi ni na dev serverima.

Odgovor na temu

M E N E
borislav
Temerin

Član broj: 30434
Poruke: 231
*.static.isp.telekom.rs.

+1 Profil

Re: Divljanje log fajla

^{31.08.2009. u 15:11 - pre 178 meseci}

OK, hvala na trudu
ali doslo je zesceg nesporazuma (mozda sam i ja krivac... nije bitno)
NE RADIM full bekap svakih pola sata (naopako! nisam bas takav amater :-) ), vec svake noci. Svakih pola sata radim transakcioni bekap, koji u nizu, pocevsi od prethodnog nocnog full bekapa cine sve radjeno na bazi. Na ovaj nacin, ako se desi neki raspad sistema, pomocu prethodnog FULL BEKAPa i svih TRN bekapa od njega pa do trenutka sloma, mogu da povratim stanje do NAJVISE pola sata pre pada.
Kad uradim naredne noci novi full bekap, svih 48 TRN-ova (transakcionih bekapa) gube smisao i mogu da se brisu (osim ako nekome ne padne na pamet da povrati bazu, iz nekih razloga na "prekjuce, 14.30" - karikiram malo).
Dakle, TRNovi imaju funkciju, ne zelim da ih se skroz oslobodim, jer su mi bitni za hvatanje dnevnog rada. Zato ne mogu ici na SIMPLE.
Ali, i pored toga sto ih bekapujem svakih pola sata, + radim nocni full bekap, meni LOG fajl raste i dostize gigabajte i gigabajte...
Dalje, ako uradim FULL bekap, a potom krenem da odradim "odbacivanje" log fajla, mislim da nista nisam izgubio, zar ne?! (full bekap ima bas sve, u logu ostaju samo nezatvorene transakcije, kojih, u toku noci nema ili ima jako malo).

Nadam se da je sad malo jasnija situacija, sta radim i kako radim, samo i dalje stoji pitanje, sta cu sa LOG fajlom?

Uhvatili ste me nespremnog

Odgovor na temu

mmix
Miljan Mitrović
Profesorkin muz
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6042

+4631 Profil

Re: Divljanje log fajla

^{31.08.2009. u 18:28 - pre 178 meseci}

AKo ti se LOG fajl i dalje siri i posle trunc TRN backup-a onda vrlo verovatno imas problem sa zivim transakcijama koje sprecavaju LOG fajl da se "premota" (sql ne moze da uradi reuse VLFa dok god je on aktivan)

Sta dobijas kao izlaz iz DBCC LOGINFO?

Odgovor na temu

M E N E
borislav
Temerin

Član broj: 30434
Poruke: 231
*.static.isp.telekom.rs.

+1 Profil

Re: Divljanje log fajla

^{01.09.2009. u 09:28 - pre 178 meseci}

ne radim ja trunc TRNa
vec radim transakcioni bekap na svakih 30 min.
Da li u sam posao transakcionog bekapa treba da ubacim nesto, da mi "sreze" log?

Uhvatili ste me nespremnog

Odgovor na temu

mmix
Miljan Mitrović
Profesorkin muz
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6042

+4631 Profil

Re: Divljanje log fajla

^{01.09.2009. u 10:00 - pre 178 meseci}

Nemoj brkati trunc i shrink, to su dve razlicite operacije, ako ti je fizicki log fajl na disku 1Gb, to ne znaci da je i sam logicki log fajl te velicine. Sam LDF fajl je podeljen u gomilu virtulenih log fajlova (VLFs) i trunc oslobadja VLFove ali ne oslobadja fizicku velicinu fajla (isto tako shrink nece smanjiti velicinu ldf fajla ako VLFovi nisu slobodni). Pogledaj malo ovaj link

BACKUP LOG uvek izaziva trunc log fajl zakljucno sa posednjim checkpointom (koji se desava periodicno, al mozes i ti da ga navedes kao deo backup log skripte) i markira kao slobodne one VLF-cije transakcije je backupovao (tj koji su sad neaktivni), kad SQL server "potrosi" svoj trenutni VLF, preci ce na prvi slobodni VLF fajl (ispravka, nece premotati na pocetak ldfa dok ne potrosi sve VLFove unrpade) i tako u vecnost, ldf ce se prosiriti fizicki na disku samo ako SQL server potrosi SVE VLF-ove i nema gde dalje da ide. Shrink sa druge strane pomeri sve aktivne VLFove (one sa status<>0) na pocetak ldf fajla tako da su na kraju ldf fajla samo VLFovi sa statusom 0 (narodski, defragmentira LDF fajl) i onda jednostavno odsece te status=0 VLFove i smanji velicinu ldf fajla.

DBCC LOGINFO ce ti dati spisak svih VLFova u tvom aktivnom ldf-u i njihov status. Ako su ti svi statusi = 2 onda server nije uspeo da uradi trunc i za to postoji dosta razloga. Da bi utvrdio sta sprecava trunc loga uradis sledecu skriptu:

Code:
select name, log_reuse_wait, log_reuse_wait_desc from sys.databases

Opis rezultata imas ovde a najcesci razloga koji sam ja sretao je ACTIVE_TRANSACTION zbog lose projektovanog ili izradjenog softvera koji se kaci na bazu.

Pogledaj i ovde za malo vise detalja o tome kako izgleda struktura ldf fajla i kako log radi:
http://msdn.microsoft.com/en-us/library/ms179355.aspx

_{[Ovu poruku je menjao mmix dana 01.09.2009. u 11:15 GMT+1]}

Odgovor na temu

M E N E
borislav
Temerin

Član broj: 30434
Poruke: 231
*.static.isp.telekom.rs.

+1 Profil

Re: Divljanje log fajla

^{02.09.2009. u 11:41 - pre 178 meseci}

Opet ja
Dakle, ako zelim da svake noci obavim bekap baze (FULL BEKAP), tada mogu da obrisem LOG fajl, pod uslovom da nema otvorenih transakcija?
Ili, da ne duzim... koji je BEST PRACTICE za odrzavanje velicine log fajla pod kontrolom

(primetio sam da dbcc shrinkdatabase ponekad odradi, ponekad ne)

Uhvatili ste me nespremnog

Odgovor na temu