{"id":5889,"date":"2026-06-16T16:15:28","date_gmt":"2026-06-16T16:15:28","guid":{"rendered":"https:\/\/cloudsave.app\/knowledge-base\/mssql-transaction-log-full-recovery\/"},"modified":"2026-06-16T16:40:59","modified_gmt":"2026-06-16T16:40:59","slug":"mssql-transakcijski-dnevnik-pun-strategije-sprje%c4%8davanja-i-brzog-oporavka","status":"publish","type":"post","link":"https:\/\/cloudsave.app\/hr\/knowledge-base\/mssql-transakcijski-dnevnik-pun-strategije-sprje%c4%8davanja-i-brzog-oporavka\/","title":{"rendered":"MSSQL transakcijski dnevnik pun: Strategije sprje\u010davanja i brzog oporavka"},"content":{"rendered":"

Za administratore baza podataka (DBA) i DevOps in\u017eenjere koji upravljaju Microsoft SQL Serverom, malo upozorenja izaziva toliko trenutne tjeskobe kao Pogre\u0161ka 9002: Transakcijski dnevnik za bazu podataka ‘X’ je pun<\/em>. Kada se transakcijski dnevnik napuni i ne mo\u017ee se pove\u0107ati, baza podataka efektivno postaje samo za \u010ditanje (read-only). Sve INSERT<\/code>, UPDATE<\/code> i DELETE<\/code> operacije se zaustavljaju, transakcije aplikacije ne uspijevaju, a produkcija staje.<\/p>\n

Razumijevanje temeljne arhitekture transakcijskog dnevnika SQL Servera, to\u010dna dijagnoza temeljnog uzroka i provo\u0111enje brzih postupaka oporavka klju\u010dne su vje\u0161tine za odr\u017eavanje visoke dostupnosti. Ovaj sveobuhvatni vodi\u010d istra\u017euje mehaniku transakcijskog dnevnika, kako rije\u0161iti puni dnevnik u hitnim slu\u010dajevima i arhitektonske najbolje prakse kako se to ne bi ponovilo.<\/p>\n

Razumijevanje arhitekture transakcijskog dnevnika SQL Servera<\/h2>\n

Da biste u\u010dinkovito otklonili pote\u0161ko\u0107e s punim transakcijskim dnevnikom, prvo morate razumjeti kako SQL Server zapisuje i upravlja podacima.<\/p>\n

Write-Ahead Logging (WAL)<\/h3>\n

SQL Server koristi protokol Write-Ahead Logging (WAL). Kad god do\u0111e do izmjene podataka, promjena se prvo zapisuje u transakcijski dnevnik u memoriji, a zatim ispire u fizi\u010dku datoteku dnevnika na disku prije nego \u0161to se stvarne stranice podataka a\u017euriraju u datotekama baze podataka (MDF\/NDF). Ovo jam\u010di ACID (atomi\u010dnost, dosljednost, izolacija, trajnost) uskla\u0111enost, osiguravaju\u0107i da u slu\u010daju pada, SQL Server mo\u017ee ponoviti (roll forward) ili poni\u0161titi (roll back) transakcije.<\/p>\n

Virtualne datoteke dnevnika (VLF) i kru\u017eno zapisivanje<\/h3>\n

Interno, fizi\u010dka datoteka transakcijskog dnevnika (LDF) podijeljena je na manje, logi\u010dke segmente koji se nazivaju virtualne datoteke dnevnika (VLF). Transakcijski dnevnik radi kru\u017eno. Kako se zapisi dnevnika pi\u0161u, oni popunjavaju jedan VLF i prelaze na sljede\u0107i.<\/p>\n

Kada dnevnik dosegne kraj fizi\u010dke datoteke, poku\u0161ava se vratiti na po\u010detak. Me\u0111utim, mo\u017ee prebrisati VLF samo ako je taj VLF ozna\u010den kao neaktivan<\/strong>. Ako su svi VLF-ovi aktivni (\u0161to zna\u010di da sadr\u017ee zapise dnevnika koji su jo\u0161 uvijek potrebni SQL Serveru), dnevnik se ne mo\u017ee omotati. Ako je omogu\u0107eno automatsko pove\u0107anje i prostor na disku je dostupan, fizi\u010dka datoteka raste. Ako je disk pun ili je automatsko pove\u0107anje ograni\u010deno, nailazite na pogre\u0161ku 9002.<\/p>\n

Skra\u0107ivanje dnevnika (Truncation) naspram smanjivanja dnevnika (Shrinking)<\/h3>\n

\u010cesta je zabluda da skra\u0107ivanje dnevnika smanjuje fizi\u010dku veli\u010dinu datoteke.
\n* Skra\u0107ivanje dnevnika (Log Truncation):<\/strong> Proces ozna\u010davanja aktivnih VLF-ova kao neaktivnih, \u010dine\u0107i prostor dostupnim za ponovnu upotrebu. To ne<\/em> smanjuje veli\u010dinu LDF datoteke na disku.
\n* Smanjivanje dnevnika (Log Shrinking):<\/strong> Proces fizi\u010dkog smanjenja veli\u010dine LDF datoteke i vra\u0107anja prostora operativnom sustavu.<\/p>\n

U modelu potpunog oporavka (Full Recovery model), skra\u0107ivanje dnevnika doga\u0111a se samo<\/em> kada je sigurnosna kopija transakcijskog dnevnika uspje\u0161no dovr\u0161ena (pod pretpostavkom da nijedan drugi proces ne dr\u017ei dnevnik aktivnim).<\/p>\n

Dijagnosticiranje pogre\u0161ke “Transakcijski dnevnik pun” (Pogre\u0161ka 9002)<\/h2>\n

Kada je dnevnik pun, va\u0161 prvi korak nije slijepo dodavanje prostora na disku ili smanjivanje datoteka. Morate identificirati za\u0161to<\/em> se dnevnik ne mo\u017ee skratiti. SQL Server nudi ugra\u0111eni mehanizam koji vam to\u010dno govori \u0161to sprje\u010dava ponovnu upotrebu dnevnika putem sys.databases<\/code> katalo\u0161kog prikaza.<\/p>\n

Pokrenite sljede\u0107u T-SQL naredbu kako biste identificirali usko grlo:<\/p>\n

SELECT \n    name AS DatabaseName, \n    recovery_model_desc AS RecoveryModel, \n    log_reuse_wait_desc AS LogReuseWaitReason\nFROM sys.databases\nWHERE name = 'YourDatabaseName';\n<\/code><\/pre>\n
Tako\u0111er mo\u017eete provjeriti trenutnu upotrebu prostora va\u0161ih transakcijskih dnevnika koriste\u0107i:<\/p>\n
DBCC SQLPERF(LOGSPACE);\n<\/code><\/pre>\n
Uobi\u010dajena stanja log_reuse_wait_desc<\/code><\/h3>\n
    \n
  1. LOG_BACKUP:<\/strong> Baza podataka je u modelu potpunog ili skupno bilje\u017eenog oporavka (Full ili Bulk-Logged), a sigurnosna kopija transakcijskog dnevnika nije nedavno napravljena. Ovo je naj\u010de\u0161\u0107i uzrok.<\/li>\n
  2. ACTIVE_TRANSACTION:<\/strong> Transakcija koja dugo traje (npr. masovna obnova indeksa ili zaboravljena nepotvr\u0111ena transakcija) dr\u017ei dnevnik aktivnim.<\/li>\n
  3. REPLICATION \/ CDC:<\/strong> Omogu\u0107ena je transakcijska replikacija ili Change Data Capture (CDC), a Log Reader Agent jo\u0161 nije obradio transakcije.<\/li>\n
  4. AVAILABILITY_REPLICA:<\/strong> U AlwaysOn grupi dostupnosti, sekundarna replika je isklju\u010dena ili se presporo sinkronizira, prisiljavaju\u0107i primarnu repliku da zadr\u017ei zapise dnevnika dok se ne potvrde na sekundarnoj.<\/li>\n<\/ol>\n
    Strategije brzog oporavka: Rje\u0161avanje problema u produkciji<\/h2>\n
    Ovisno o vra\u0107enom log_reuse_wait_desc<\/code>, va\u0161 odgovor na hitne slu\u010dajeve \u0107e varirati. Evo strategija brzog oporavka za naj\u010de\u0161\u0107e scenarije.<\/p>\n
    Scenarij 1: Nedostaju\u0107e ili neuspjele sigurnosne kopije dnevnika (LOG_BACKUP<\/code>)<\/h3>\n
    Ako je vrsta \u010dekanja LOG_BACKUP<\/code>, rje\u0161enje je jednostavno: morate napraviti sigurnosnu kopiju transakcijskog dnevnika.<\/p>\n
    BACKUP LOG [YourDatabaseName] \nTO DISK = 'N:BackupsYourDatabaseName_EmergencyLog.trn' \nWITH COMPRESSION, STATS = 10;\n<\/code><\/pre>\n
    Nakon \u0161to se sigurnosna kopija dovr\u0161i, neaktivni VLF-ovi \u0107e se skratiti i SQL Server \u0107e nastaviti s normalnim radom. Ako je va\u0161 pogon za sigurnosne kopije pun, mo\u017eda \u0107ete morati napraviti sigurnosnu kopiju na privremenu mre\u017enu dijeljenu mapu ili null ure\u0111aj (strogo se ne preporu\u010duje osim ako se baza podataka lako mo\u017ee reproducirati, jer to prekida lanac dnevnika):<\/p>\n
    -- UPOZORENJE: Ovo prekida lanac dnevnika i ugro\u017eava oporavak do odre\u0111ene to\u010dke u vremenu.\n-- Koristite samo ako je apsolutno potrebno i odmah nakon toga napravite POTPUNU sigurnosnu kopiju.\nBACKUP LOG [YourDatabaseName] TO DISK = 'NUL';\n<\/code><\/pre>\n
    Scenarij 2: Dugotrajne aktivne transakcije (ACTIVE_TRANSACTION<\/code>)<\/h3>\n
    Ako jedna transakcija traje satima, ona sprje\u010dava skra\u0107ivanje dnevnika tijekom cijelog trajanja. Prvo identificirajte problemati\u010dnu transakciju:<\/p>\n
    DBCC OPENTRAN('YourDatabaseName');\n<\/code><\/pre>\n
    Ova naredba vra\u0107a najstariju aktivnu transakciju i njezin ID procesa poslu\u017eitelja (SPID). Mo\u017eete prikupiti vi\u0161e detalja o tome \u0161to SPID radi upitom na dinami\u010dke prikaze upravljanja (DMV):<\/p>\n
    SELECT \n    s.session_id,\n    s.login_name,\n    s.host_name,\n    r.start_time,\n    r.status,\n    r.command,\n    t.text AS QueryText\nFROM sys.dm_exec_sessions s\nJOIN sys.dm_exec_requests r ON s.session_id = r.session_id\nCROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t\nWHERE s.session_id = <SPID_FROM_DBCC_OPENTRAN>;\n<\/code><\/pre>\n
    Ako je transakcija neispravan upit ili zaustavljeni proces, mo\u017eda \u0107ete ga morati prekinuti kako biste oslobodili dnevnik.<\/p>\n
    KILL <SPID>;\n<\/code><\/pre>\n
    Napomena: Prekidanje masivne transakcije pokrenut \u0107e povratak (rollback), \u0161to mo\u017ee potrajati zna\u010dajno vrijeme i privremeno \u0107e generirati dodatnu aktivnost dnevnika. Nemojte ponovno pokretati uslugu SQL Servera tijekom povratka, ina\u010de \u0107e baza podataka u\u0107i u na\u010din oporavka nakon ponovnog pokretanja.<\/em><\/p>\n
    Scenarij 3: Hitna dodjela prostora (Disk je 100% pun)<\/h3>\n
    Ako je LDF datoteka zauzela cijeli pogon, ne mo\u017eete \u010dak ni pokrenuti sigurnosnu kopiju jer SQL Server zahtijeva malu koli\u010dinu prostora u dnevniku da bi zabilje\u017eio sam doga\u0111aj sigurnosne kopije. U ovom scenariju morate dodati sekundarnu datoteku dnevnika na drugi pogon s dostupnim prostorom.<\/p>\n
    ALTER DATABASE [YourDatabaseName]\nADD LOG FILE \n(\n    NAME = N'YourDatabaseName_Log2',\n    FILENAME = N'E:TempLogsYourDatabaseName_Log2.ldf',\n    SIZE = 5GB,\n    MAXSIZE = 50GB,\n    FILEGROWTH = 1GB\n);\n<\/code><\/pre>\n
    Ovo odmah daje SQL Serveru prostora za rad. Kada baza podataka bude na mre\u017ei, napravite sigurnosnu kopiju transakcijskog dnevnika, ispraznite sekundarnu datoteku dnevnika i uklonite je:<\/p>\n
    -- 1. Napravite sigurnosnu kopiju dnevnika za skra\u0107ivanje\nBACKUP LOG [YourDatabaseName] TO DISK = '...';\n\n-- 2. Ispraznite privremenu datoteku dnevnika\nDBCC SHRINKFILE (N'YourDatabaseName_Log2', EMPTYFILE);\n\n-- 3. Uklonite privremenu datoteku dnevnika\nALTER DATABASE [YourDatabaseName] REMOVE FILE [YourDatabaseName_Log2];\n<\/code><\/pre>\n
    Najbolje prakse za prevenciju i upravljanje transakcijskim dnevnikom<\/h2>\n
    Reaktivno otklanjanje pote\u0161ko\u0107a je stresno i utje\u010de na SLA. Implementacija proaktivnih arhitektonskih i operativnih najboljih praksi klju\u010dna je za stabilnost baze podataka u poduze\u0107u.<\/p>\n
    1. Implementirajte robusnu, automatiziranu strategiju sigurnosnog kopiranja<\/h3>\n
    Ako je baza podataka u modelu potpunog oporavka, \u010deste sigurnosne kopije transakcijskog dnevnika su obavezne. Ovisno o va\u0161em cilju to\u010dke oporavka (RPO) i volumenu transakcija, sigurnosne kopije dnevnika trebale bi se odvijati svakih 5 do 15 minuta.<\/p>\n
    Enterprise rje\u0161enja za sigurnosno kopiranje kao \u0161to je CloudSave zna\u010dajno pojednostavljuju ovaj proces. Izravnom integracijom sa SQL Serverom putem VDI-a (Virtual Device Interface), CloudSave omogu\u0107uje administratorima baza podataka konfiguriranje sigurnosnih kopija transakcijskog dnevnika visoke frekvencije vo\u0111enih politikama. To osigurava da se dnevnici kontinuirano skra\u0107uju, sigurno \u0161ifriraju i pohranjuju izvan lokacije ili u nepromjenjivu pohranu u oblaku, sprje\u010davaju\u0107i stanje \u010dekanja LOG_BACKUP<\/code> bez potrebe za slo\u017eenim prilago\u0111enim SQL Agent poslovima.<\/p>\n
    2. Pravilno dimenzionirajte transakcijski dnevnik i upravljajte VLF-ovima<\/h3>\n
    Oslanjanje na automatsko pove\u0107anje za upravljanje veli\u010dinom transakcijskog dnevnika opasan je anti-uzorak. Operacije automatskog pove\u0107anja su skupe i pauziraju obradu transakcija dok se disk ne inicijalizira nulama (osim ako je omogu\u0107ena trenutna inicijalizacija datoteka, \u0161to se ne<\/em> odnosi na datoteke dnevnika).<\/p>\n
    Nadalje, \u010desta, mala automatska pove\u0107anja (npr. pove\u0107anje za 10% ili 50MB odjednom) dovode do fragmentacije VLF-a<\/strong>. Transakcijski dnevnik s tisu\u0107ama si\u0107u\u0161nih VLF-ova ozbiljno \u0107e degradirati vrijeme pokretanja baze podataka, performanse sigurnosnog kopiranja i latenciju replikacije.<\/p>\n
      \n
    • Prethodno dimenzionirajte dnevnik:<\/strong> Analizirajte svoje najve\u0107e operacije odr\u017eavanja (poput obnove indeksa) i prethodno dimenzionirajte LDF datoteku kako bi ih primila bez rasta.<\/li>\n
    • Postavite fiksno automatsko pove\u0107anje:<\/strong> Promijenite automatsko pove\u0107anje iz postotka u fiksnu veli\u010dinu (npr. 1GB ili 5GB) kako biste osigurali da se VLF-ovi stvaraju u zdravoj veli\u010dini.<\/li>\n<\/ul>\n
      Mo\u017eete provjeriti svoj broj VLF-ova pomo\u0107u sljede\u0107eg upita (za SQL Server 2017+):<\/p>\n
      SELECT \n    db_name(database_id) AS DatabaseName,\n    COUNT(vlf_sequence_number) AS VLF_Count\nFROM sys.dm_db_log_info(DB_ID('YourDatabaseName'));\n<\/code><\/pre>\n
      Ako je va\u0161 broj VLF-ova ve\u0107i od 500, razmislite o \u010dekanju na mirno razdoblje, smanjivanju dnevnika na minimalnu veli\u010dinu i ru\u010dnom pove\u0107anju natrag na potrebnu veli\u010dinu u velikim komadima.<\/p>\n
      3. Optimizirajte operacije odr\u017eavanja indeksa<\/h3>\n
      Obnove indeksa su operacije koje se u potpunosti bilje\u017ee, \u010dak i u modelu skupno bilje\u017eenog oporavka (ovisno o vrsti indeksa). Obnova indeksa od 500GB generirat \u0107e najmanje 500GB zapisa transakcijskog dnevnika.<\/p>\n
      Za ubla\u017eavanje pretrpanosti dnevnika tijekom odr\u017eavanja:
      \n*   Koristite SORT_IN_TEMPDB = ON<\/code> prilikom obnove indeksa. Ovo prebacuje fazu sortiranja u TempDB, smanjuju\u0107i optere\u0107enje na transakcijski dnevnik korisni\u010dke baze podataka.
      \n*   Prebacite se s obnove<\/em> indeksa na reorganizaciju<\/em> indeksa gdje je to mogu\u0107e, jer su reorganizacije u\u010dinkovitije u pogledu dnevnika i mogu se prekinuti bez povratka cijele operacije.
      \n*   Grupno izvr\u0161avajte velike DELETE<\/code> ili UPDATE<\/code> operacije. Umjesto brisanja 10 milijuna redaka u jednoj transakciji, bri\u0161ite ih u komadima od 50.000, potvr\u0111uju\u0107i (commit) i dopu\u0161taju\u0107i sigurnosnim kopijama dnevnika da skrate dnevnik izme\u0111u serija.<\/p>\n
      4. Nadzirite visoku dostupnost i topologije replikacije<\/h3>\n
      U AlwaysOn grupama dostupnosti, primarna replika ne mo\u017ee skratiti svoj dnevnik dok se zapisi dnevnika ne potvrde na svim sinkronim i asinkronim sekundarnim replikama.<\/p>\n
      Ako sekundarna replika ode izvan mre\u017ee, ili ako mre\u017ena propusnost ne mo\u017ee pratiti brzinu generiranja transakcija primarne replike, red \u010dekanja za slanje primarne replike \u0107e rasti, a dnevnik \u0107e se napuniti (vrsta \u010dekanja AVAILABILITY_REPLICA<\/code>).<\/p>\n
      Implementirajte robusno pra\u0107enje za broja\u010d performansi SQLServer:Replica > Log Send Queue<\/code>. Ako je sekundarna replika trajno izgubljena, morate je ukloniti iz grupe dostupnosti ili obustaviti premje\u0161tanje podataka kako biste omogu\u0107ili skra\u0107ivanje primarnog dnevnika.<\/p>\n
      Zaklju\u010dak<\/h2>\n
      Susret s punim transakcijskim dnevnikom je obred prolaska za administratore baza podataka, ali ne mora rezultirati dugotrajnim prekidom rada. Razumijevanjem mehanike Write-Ahead Logginga i VLF-ova, mo\u017eete brzo dijagnosticirati temeljni uzrok koriste\u0107i sys.databases<\/code> i primijeniti ispravnu strategiju brzog oporavka.<\/p>\n
      Dugoro\u010dna stabilnost oslanja se na odmak od reaktivnih popravaka. Prethodno dimenzioniranje datoteka dnevnika, optimizacija rutina odr\u017eavanja i kori\u0161tenje platformi za sigurnosno kopiranje na razini poduze\u0107a kao \u0161to je CloudSave za provo\u0111enje strogih, automatiziranih rasporeda sigurnosnog kopiranja dnevnika osigurat \u0107e da va\u0161i transakcijski dnevnici ostanu zdravi, skra\u0107eni i spremni za podr\u0161ku produkcijskim radnim optere\u0107enjima visokog propusnog kapaciteta.<\/p>\n","protected":false},"excerpt":{"rendered":"
      ** Discover expert strategies for preventing and resolving MSSQL transaction log full errors (Error 9002). Learn rapid recovery techniques, VLF management, and architectural best practices for DBAs.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rank_math_title":"MSSQL Transaction Log Full: Prevention & Recovery","rank_math_description":"** Discover expert strategies for preventing and resolving MSSQL transaction log full errors (Error 9002). Learn rapid recovery techniques, VLF management, and architectural best practices for DBAs.","rank_math_focus_keyword":"MSSQL transaction log full","footnotes":""},"categories":[375],"tags":[885,3992,3993,3994,3995,3996,3997],"class_list":["post-5889","post","type-post","status-publish","format-standard","hentry","category-database-backup","tag-database-administration","tag-error-9002","tag-log-backup","tag-mssql","tag-sql-recovery","tag-sql-server","tag-transaction-log"],"yoast_head":"\nMSSQL Transaction Log Full: Prevention & Recovery<\/title>\n<meta name=\"description\" content=\"** Discover expert strategies for preventing and resolving MSSQL transaction log full errors (Error 9002). Learn rapid recovery techniques, VLF management, and architectural best practices for DBAs.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/cloudsave.app\/hr\/knowledge-base\/mssql-transakcijski-dnevnik-pun-strategije-sprje%c4%8davanja-i-brzog-oporavka\/\" \/>\n<meta property=\"og:locale\" content=\"hr_HR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"MSSQL transakcijski dnevnik pun: Strategije sprje\u010davanja i brzog oporavka\" \/>\n<meta property=\"og:description\" content=\"** Discover expert strategies for preventing and resolving MSSQL transaction log full errors (Error 9002). Learn rapid recovery techniques, VLF management, and architectural best practices for DBAs.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/cloudsave.app\/hr\/knowledge-base\/mssql-transakcijski-dnevnik-pun-strategije-sprje%c4%8davanja-i-brzog-oporavka\/\" \/>\n<meta property=\"og:site_name\" content=\"CloudSave\" \/>\n<meta property=\"article:published_time\" content=\"2026-06-16T16:15:28+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-06-16T16:40:59+00:00\" \/>\n<meta name=\"author\" content=\"shervinrv\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Napisao\/la\" \/>\n\t<meta name=\"twitter:data1\" content=\"shervinrv\" \/>\n\t<meta name=\"twitter:label2\" content=\"Procijenjeno vrijeme \u010ditanja\" \/>\n\t<meta name=\"twitter:data2\" content=\"10 minuta\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/cloudsave.app\\\/hr\\\/knowledge-base\\\/mssql-transakcijski-dnevnik-pun-strategije-sprje%c4%8davanja-i-brzog-oporavka\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/cloudsave.app\\\/hr\\\/knowledge-base\\\/mssql-transakcijski-dnevnik-pun-strategije-sprje%c4%8davanja-i-brzog-oporavka\\\/\"},\"author\":{\"name\":\"shervinrv\",\"@id\":\"https:\\\/\\\/cloudsave.app\\\/hr\\\/#\\\/schema\\\/person\\\/286beefe68281d868e87f46603a7ae4d\"},\"headline\":\"MSSQL transakcijski dnevnik pun: Strategije sprje\u010davanja i brzog oporavka\",\"datePublished\":\"2026-06-16T16:15:28+00:00\",\"dateModified\":\"2026-06-16T16:40:59+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/cloudsave.app\\\/hr\\\/knowledge-base\\\/mssql-transakcijski-dnevnik-pun-strategije-sprje%c4%8davanja-i-brzog-oporavka\\\/\"},\"wordCount\":1656,\"publisher\":{\"@id\":\"https:\\\/\\\/cloudsave.app\\\/hr\\\/#\\\/schema\\\/person\\\/286beefe68281d868e87f46603a7ae4d\"},\"keywords\":[\"Database Administration\",\"Error 9002\",\"Log Backup\",\"MSSQL\",\"SQL Recovery\",\"SQL Server\",\"Transaction Log\"],\"articleSection\":[\"Database Backup\"],\"inLanguage\":\"hr\"},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/cloudsave.app\\\/hr\\\/knowledge-base\\\/mssql-transakcijski-dnevnik-pun-strategije-sprje%c4%8davanja-i-brzog-oporavka\\\/\",\"url\":\"https:\\\/\\\/cloudsave.app\\\/hr\\\/knowledge-base\\\/mssql-transakcijski-dnevnik-pun-strategije-sprje%c4%8davanja-i-brzog-oporavka\\\/\",\"name\":\"MSSQL Transaction Log Full: Prevention & Recovery\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/cloudsave.app\\\/hr\\\/#website\"},\"datePublished\":\"2026-06-16T16:15:28+00:00\",\"dateModified\":\"2026-06-16T16:40:59+00:00\",\"description\":\"** Discover expert strategies for preventing and resolving MSSQL transaction log full errors (Error 9002). Learn rapid recovery techniques, VLF management, and architectural best practices for DBAs.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/cloudsave.app\\\/hr\\\/knowledge-base\\\/mssql-transakcijski-dnevnik-pun-strategije-sprje%c4%8davanja-i-brzog-oporavka\\\/#breadcrumb\"},\"inLanguage\":\"hr\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/cloudsave.app\\\/hr\\\/knowledge-base\\\/mssql-transakcijski-dnevnik-pun-strategije-sprje%c4%8davanja-i-brzog-oporavka\\\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/cloudsave.app\\\/hr\\\/knowledge-base\\\/mssql-transakcijski-dnevnik-pun-strategije-sprje%c4%8davanja-i-brzog-oporavka\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/cloudsave.app\\\/hr\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"MSSQL transakcijski dnevnik pun: Strategije sprje\u010davanja i brzog oporavka\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/cloudsave.app\\\/hr\\\/#website\",\"url\":\"https:\\\/\\\/cloudsave.app\\\/hr\\\/\",\"name\":\"CloudSave\",\"description\":\"CloudSave\",\"publisher\":{\"@id\":\"https:\\\/\\\/cloudsave.app\\\/hr\\\/#\\\/schema\\\/person\\\/286beefe68281d868e87f46603a7ae4d\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/cloudsave.app\\\/hr\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"hr\"},{\"@type\":[\"Person\",\"Organization\"],\"@id\":\"https:\\\/\\\/cloudsave.app\\\/hr\\\/#\\\/schema\\\/person\\\/286beefe68281d868e87f46603a7ae4d\",\"name\":\"shervinrv\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"hr\",\"@id\":\"https:\\\/\\\/cloudsave.app\\\/wp-content\\\/uploads\\\/2026\\\/02\\\/Logo_Name-2.png\",\"url\":\"https:\\\/\\\/cloudsave.app\\\/wp-content\\\/uploads\\\/2026\\\/02\\\/Logo_Name-2.png\",\"contentUrl\":\"https:\\\/\\\/cloudsave.app\\\/wp-content\\\/uploads\\\/2026\\\/02\\\/Logo_Name-2.png\",\"width\":859,\"height\":150,\"caption\":\"shervinrv\"},\"logo\":{\"@id\":\"https:\\\/\\\/cloudsave.app\\\/wp-content\\\/uploads\\\/2026\\\/02\\\/Logo_Name-2.png\"},\"sameAs\":[\"http:\\\/\\\/cloudsave.app\"],\"url\":\"https:\\\/\\\/cloudsave.app\\\/hr\\\/knowledge-base\\\/author\\\/shervinrv\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"MSSQL Transaction Log Full: Prevention & Recovery","description":"** Discover expert strategies for preventing and resolving MSSQL transaction log full errors (Error 9002). Learn rapid recovery techniques, VLF management, and architectural best practices for DBAs.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/cloudsave.app\/hr\/knowledge-base\/mssql-transakcijski-dnevnik-pun-strategije-sprje%c4%8davanja-i-brzog-oporavka\/","og_locale":"hr_HR","og_type":"article","og_title":"MSSQL transakcijski dnevnik pun: Strategije sprje\u010davanja i brzog oporavka","og_description":"** Discover expert strategies for preventing and resolving MSSQL transaction log full errors (Error 9002). Learn rapid recovery techniques, VLF management, and architectural best practices for DBAs.","og_url":"https:\/\/cloudsave.app\/hr\/knowledge-base\/mssql-transakcijski-dnevnik-pun-strategije-sprje%c4%8davanja-i-brzog-oporavka\/","og_site_name":"CloudSave","article_published_time":"2026-06-16T16:15:28+00:00","article_modified_time":"2026-06-16T16:40:59+00:00","author":"shervinrv","twitter_card":"summary_large_image","twitter_misc":{"Napisao\/la":"shervinrv","Procijenjeno vrijeme \u010ditanja":"10 minuta"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/cloudsave.app\/hr\/knowledge-base\/mssql-transakcijski-dnevnik-pun-strategije-sprje%c4%8davanja-i-brzog-oporavka\/#article","isPartOf":{"@id":"https:\/\/cloudsave.app\/hr\/knowledge-base\/mssql-transakcijski-dnevnik-pun-strategije-sprje%c4%8davanja-i-brzog-oporavka\/"},"author":{"name":"shervinrv","@id":"https:\/\/cloudsave.app\/hr\/#\/schema\/person\/286beefe68281d868e87f46603a7ae4d"},"headline":"MSSQL transakcijski dnevnik pun: Strategije sprje\u010davanja i brzog oporavka","datePublished":"2026-06-16T16:15:28+00:00","dateModified":"2026-06-16T16:40:59+00:00","mainEntityOfPage":{"@id":"https:\/\/cloudsave.app\/hr\/knowledge-base\/mssql-transakcijski-dnevnik-pun-strategije-sprje%c4%8davanja-i-brzog-oporavka\/"},"wordCount":1656,"publisher":{"@id":"https:\/\/cloudsave.app\/hr\/#\/schema\/person\/286beefe68281d868e87f46603a7ae4d"},"keywords":["Database Administration","Error 9002","Log Backup","MSSQL","SQL Recovery","SQL Server","Transaction Log"],"articleSection":["Database Backup"],"inLanguage":"hr"},{"@type":"WebPage","@id":"https:\/\/cloudsave.app\/hr\/knowledge-base\/mssql-transakcijski-dnevnik-pun-strategije-sprje%c4%8davanja-i-brzog-oporavka\/","url":"https:\/\/cloudsave.app\/hr\/knowledge-base\/mssql-transakcijski-dnevnik-pun-strategije-sprje%c4%8davanja-i-brzog-oporavka\/","name":"MSSQL Transaction Log Full: Prevention & Recovery","isPartOf":{"@id":"https:\/\/cloudsave.app\/hr\/#website"},"datePublished":"2026-06-16T16:15:28+00:00","dateModified":"2026-06-16T16:40:59+00:00","description":"** Discover expert strategies for preventing and resolving MSSQL transaction log full errors (Error 9002). Learn rapid recovery techniques, VLF management, and architectural best practices for DBAs.","breadcrumb":{"@id":"https:\/\/cloudsave.app\/hr\/knowledge-base\/mssql-transakcijski-dnevnik-pun-strategije-sprje%c4%8davanja-i-brzog-oporavka\/#breadcrumb"},"inLanguage":"hr","potentialAction":[{"@type":"ReadAction","target":["https:\/\/cloudsave.app\/hr\/knowledge-base\/mssql-transakcijski-dnevnik-pun-strategije-sprje%c4%8davanja-i-brzog-oporavka\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/cloudsave.app\/hr\/knowledge-base\/mssql-transakcijski-dnevnik-pun-strategije-sprje%c4%8davanja-i-brzog-oporavka\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/cloudsave.app\/hr\/"},{"@type":"ListItem","position":2,"name":"MSSQL transakcijski dnevnik pun: Strategije sprje\u010davanja i brzog oporavka"}]},{"@type":"WebSite","@id":"https:\/\/cloudsave.app\/hr\/#website","url":"https:\/\/cloudsave.app\/hr\/","name":"CloudSave","description":"CloudSave","publisher":{"@id":"https:\/\/cloudsave.app\/hr\/#\/schema\/person\/286beefe68281d868e87f46603a7ae4d"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/cloudsave.app\/hr\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"hr"},{"@type":["Person","Organization"],"@id":"https:\/\/cloudsave.app\/hr\/#\/schema\/person\/286beefe68281d868e87f46603a7ae4d","name":"shervinrv","image":{"@type":"ImageObject","inLanguage":"hr","@id":"https:\/\/cloudsave.app\/wp-content\/uploads\/2026\/02\/Logo_Name-2.png","url":"https:\/\/cloudsave.app\/wp-content\/uploads\/2026\/02\/Logo_Name-2.png","contentUrl":"https:\/\/cloudsave.app\/wp-content\/uploads\/2026\/02\/Logo_Name-2.png","width":859,"height":150,"caption":"shervinrv"},"logo":{"@id":"https:\/\/cloudsave.app\/wp-content\/uploads\/2026\/02\/Logo_Name-2.png"},"sameAs":["http:\/\/cloudsave.app"],"url":"https:\/\/cloudsave.app\/hr\/knowledge-base\/author\/shervinrv\/"}]}},"_links":{"self":[{"href":"https:\/\/cloudsave.app\/hr\/wp-json\/wp\/v2\/posts\/5889","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cloudsave.app\/hr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cloudsave.app\/hr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cloudsave.app\/hr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/cloudsave.app\/hr\/wp-json\/wp\/v2\/comments?post=5889"}],"version-history":[{"count":1,"href":"https:\/\/cloudsave.app\/hr\/wp-json\/wp\/v2\/posts\/5889\/revisions"}],"predecessor-version":[{"id":5954,"href":"https:\/\/cloudsave.app\/hr\/wp-json\/wp\/v2\/posts\/5889\/revisions\/5954"}],"wp:attachment":[{"href":"https:\/\/cloudsave.app\/hr\/wp-json\/wp\/v2\/media?parent=5889"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cloudsave.app\/hr\/wp-json\/wp\/v2\/categories?post=5889"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cloudsave.app\/hr\/wp-json\/wp\/v2\/tags?post=5889"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}