Kako je ova tema uopste zavrsila u Java delu kad sam je postavio u sekcije Baze - MSSQL ??????????

Najjednostavnije ti je da prodješ kroz Database Maintenance Plan Wizard i setuješ full backup baze i backup loga u odredjenim vremenskim intervalima. Ukoliko posle backupa loga ti se log ne smanjuje to znači da imaš nekih aktivnih transakcija pa ti se zbog toga ne smanjuje log da bi video otvorene transakcije u nekoj bazi koristi DBCC OPENTRAN

I ja sam imao problema sa logom nad jednom bazom, bio je velicine kao i baza a nije imalo otvorenih transakcija (nisam razumeo zbog cega bi mogla da raste toliko).
Trazio sam resenje kako da smanjim i svi su upucivali na radjenje full backup-a ili koristiti DBCC SHRINKDATABASE medjutim nista nije pomagalo.

Jedino sto je pomoglo je: detach baze, obrisem log, odradim attach single file. Proverio sam podatke i sve je bilo OK.



Pre nego sto ista pokusas ipak odradi full backup.

Hvala momci! Ovo sa brisanje log fajla je pomoglo. Novokreirani je imao svega 500K.

Interesuje me jos jedna stvar, probao sam i shrink baze i smanjio sam je za jedno 20%, da li je to stetno po podatke??? Mislim koliko je dobro praktikovati tu opciju?

I druga stvar kad smo vec kod loga, koja je osnovna uloga loga? ako je, bar kako ja mislim, da mozes vratiti neke transakcije unazad, interesujeme kako bi to moglo da se uradi?

Pozdrav drustvo!

Ja sam imao jednu bazu, nad kojom nisam radio nikakav backup pa mi je log veoma brzo rastao.

Uradio sam sledeće:

Napravi alert koji ce se aktivirati kada log poraste iznad neke vrednosti npr. 100Mb ili vec koliko ti mislis da je dovoljna velicina i podesi da kada se taj alert aktivira pokrece job koji ces takodje napraviti a koji ce imati sledece korake za izvrsavanja
(ako ti se baza zove npr prodaja)

--korak 1
backup log prodaja with truncate_only

--korak 2
DBCC shrinkdatabase(N'prodaja', TRUNCATEONLY )

--korak 3
backup log prodaja with truncate_only

--korak 4
DBCC shrinkdatabase(N'prodaja', TRUNCATEONLY )

p.s. nije greska koraci se dupliraju

@DarkMan
Kako ti je setovan recovery model nad tom bazom?

Ako ti je baza indeksirana i ako radiš defragmentaciju indeksa što je neophodno kako bi održao performanse SELECT upita onda nikako netreba shrinkovati bazu jer to ponovo stvara fragmentaciju indeksa tako da se anulira poboljašanje sa DBCC DBREINDEX ili DBCC INDEXDEFRAG.



U logu se dešava rollback neizvršenih transakcija i rollforward izvršenih transakcija ali kada dodje do recovery baze (kada radiš RESTORE ili kada restartuješ SQL Server) ali to sve radi SQL Server ti nemaš kontrolu nad time. Postoje alati koji omogućavaju da se radi sa transakcijama u logu recimo Log Explorer od Lumigenta.
Inače što se tiče uloge loga, najkraće rečeno kada korisnik promeni podatke onda se ta transakcija najpre upisuje u log i tek kad je ona upisana u log onda se smatra da se ona desila (bilo da je commited ili rollbacked), u toku rada SQL Server "ispaljuje" dogadjaj koji se zove checkpoint (a može i user da ga izvrši komandom CHECKPOINT iz QA) i tada se izmenjene stranice-podaci (dirty pages) iz memorije upisuju u data pages same baze tj. .mdf odnosno .ndf fajl.
Na taj način se dobija na performansama i na konzistentnosti podataka u bazi.

Ima tu još mnogo što šta da se kaže ali ovo je u najkraćim crtama. Nadam se da sam bio jasan.

U potpunosti dekibre!
Ustvari ako sam dobro razumeo ja oko log fajla nebih trebao nista da cackam... To u principu radi sve sam sqlserver.

Pozdrav!

U principu netreba ništa čačkati, osim što radiš redovno bakcup loga, a ako hoćeš nešto da čačkaš onda koristiš 3rd part alate za takve intervencije. Što bi reko jedan moj kolega tu ne pomaže doktor opšte prakse pa mora da dodje specijalista.

Ako Vam se log širi u nedogled znači da nemate backup-a što
je, malo je reći, ozbiljan nedostatak
A kada uspostavite backup trebate da znate gde ga držite i šta ćete raditi sa njim
ako nešto krene ukrivo, a krenuće (Marfi)

Shrink baze nije štetan, dobro je smanjiti bazu jer i backup-i budu manji