{"id":5878,"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:31:01","modified_gmt":"2026-06-16T16:31:01","slug":"mssql-transaction-log-full-strategjit%c3%ab-e-parandalimit-dhe-rikuperimit-t%c3%ab-shpejt%c3%ab","status":"publish","type":"post","link":"https:\/\/cloudsave.app\/sq\/knowledge-base\/mssql-transaction-log-full-strategjit%c3%ab-e-parandalimit-dhe-rikuperimit-t%c3%ab-shpejt%c3%ab\/","title":{"rendered":"MSSQL Transaction Log Full: Strategjit\u00eb e parandalimit dhe rikuperimit t\u00eb shpejt\u00eb"},"content":{"rendered":"

P\u00ebr Administrator\u00ebt e Bazave t\u00eb t\u00eb Dh\u00ebnave (DBA) dhe inxhinier\u00ebt DevOps q\u00eb menaxhojn\u00eb Microsoft SQL Server, pak alarme shkaktojn\u00eb aq ankth t\u00eb menj\u00ebhersh\u00ebm sa Gabimi 9002: Regjistri i transaksioneve p\u00ebr baz\u00ebn e t\u00eb dh\u00ebnave ‘X’ \u00ebsht\u00eb plot<\/em>. Kur regjistri i transaksioneve mbushet dhe nuk mund t\u00eb rritet, baza e t\u00eb dh\u00ebnave b\u00ebhet efektivisht vet\u00ebm p\u00ebr lexim. T\u00eb gjitha operacionet INSERT<\/code>, UPDATE<\/code> dhe DELETE<\/code> ndalen, transaksionet e aplikacionit d\u00ebshtojn\u00eb dhe prodhimi ndalet plot\u00ebsisht.<\/p>\n

Kuptimi i arkitektur\u00ebs themelore t\u00eb regjistrit t\u00eb transaksioneve t\u00eb SQL Server, diagnostikimi i sakt\u00eb i shkakut rr\u00ebnj\u00ebsor dhe ekzekutimi i procedurave t\u00eb shpejta t\u00eb rikuperimit jan\u00eb aft\u00ebsi kritike p\u00ebr ruajtjen e disponueshm\u00ebris\u00eb s\u00eb lart\u00eb. Ky udh\u00ebzues gjith\u00ebp\u00ebrfshir\u00ebs eksploron mekanik\u00ebn e regjistrit t\u00eb transaksioneve, si t\u00eb zgjidhni nj\u00eb regjist\u00ebr t\u00eb plot\u00eb n\u00eb nj\u00eb emergjenc\u00eb dhe praktikat m\u00eb t\u00eb mira arkitekturore p\u00ebr t\u00eb parandaluar p\u00ebrs\u00ebritjen e k\u00ebsaj situate.<\/p>\n

Kuptimi i Arkitektur\u00ebs s\u00eb Regjistrit t\u00eb Transaksioneve t\u00eb SQL Server<\/h2>\n

P\u00ebr t\u00eb zgjidhur n\u00eb m\u00ebnyr\u00eb efektive nj\u00eb regjist\u00ebr transaksionesh t\u00eb plot\u00eb, s\u00eb pari duhet t\u00eb kuptoni se si SQL Server shkruan dhe menaxhon t\u00eb dh\u00ebnat.<\/p>\n

Regjistrimi me Shkrim p\u00ebrpara (Write-Ahead Logging – WAL)<\/h3>\n

SQL Server p\u00ebrdor nj\u00eb protokoll t\u00eb Regjistrimit me Shkrim p\u00ebrpara (WAL). Sa her\u00eb q\u00eb ndodh nj\u00eb modifikim i t\u00eb dh\u00ebnave, ndryshimi shkruhet fillimisht n\u00eb regjistrin e transaksioneve n\u00eb memorie, pastaj derdhet n\u00eb skedarin fizik t\u00eb regjistrit n\u00eb disk p\u00ebrpara se faqet aktuale t\u00eb t\u00eb dh\u00ebnave t\u00eb p\u00ebrdit\u00ebsohen n\u00eb skedar\u00ebt e baz\u00ebs s\u00eb t\u00eb dh\u00ebnave (MDF\/NDF). Kjo garanton pajtueshm\u00ebrin\u00eb ACID (Atomicitet, Konsistenc\u00eb, Izolim, Q\u00ebndrueshm\u00ebri), duke siguruar q\u00eb n\u00eb rast t\u00eb nj\u00eb p\u00ebrplasjeje, SQL Server mund t\u00eb riprodhoj\u00eb (roll forward) ose zhb\u00ebj\u00eb (roll back) transaksionet.<\/p>\n

Skedar\u00ebt Log Virtual\u00eb (VLFs) dhe Regjistrimi Rrethor<\/h3>\n

Brend\u00ebsisht, skedari fizik i regjistrit t\u00eb transaksioneve (LDF) \u00ebsht\u00eb i ndar\u00eb n\u00eb segmente m\u00eb t\u00eb vogla, logjike t\u00eb quajtura Skedar\u00eb Log Virtual\u00eb (VLF). Regjistri i transaksioneve funksionon n\u00eb m\u00ebnyr\u00eb rrethore. Nd\u00ebrsa regjistrimet e log-ut shkruhen, ato mbushin nj\u00eb VLF dhe kalojn\u00eb te tjetri.<\/p>\n

Kur regjistri arrin n\u00eb fund t\u00eb skedarit fizik, ai p\u00ebrpiqet t\u00eb kthehet n\u00eb fillim. Megjithat\u00eb, ai mund t\u00eb mbishkruaj\u00eb nj\u00eb VLF vet\u00ebm n\u00ebse ai VLF \u00ebsht\u00eb sh\u00ebnuar si joaktiv<\/strong>. N\u00ebse t\u00eb gjith\u00eb VLF-t\u00eb jan\u00eb aktiv\u00eb (q\u00eb do t\u00eb thot\u00eb se ato p\u00ebrmbajn\u00eb regjistrime t\u00eb log-ut q\u00eb k\u00ebrkohen ende nga SQL Server), regjistri nuk mund t\u00eb mbyllet. N\u00ebse rritja automatike (auto-growth) \u00ebsht\u00eb e aktivizuar dhe hap\u00ebsira n\u00eb disk \u00ebsht\u00eb e disponueshme, skedari fizik rritet. N\u00ebse disku \u00ebsht\u00eb plot ose rritja automatike \u00ebsht\u00eb e kufizuar, ju hasni Gabimin 9002.<\/p>\n

Trunkimi i Regjistrit kundrejt Zvog\u00eblimit t\u00eb Regjistrit<\/h3>\n

Nj\u00eb keqkuptim i zakonsh\u00ebm \u00ebsht\u00eb se trunkimi i regjistrit zvog\u00eblon madh\u00ebsin\u00eb fizike t\u00eb skedarit.
\n* Trunkimi i Regjistrit (Log Truncation):<\/strong> Procesi i sh\u00ebnimit t\u00eb VLF-ve aktive si joaktive, duke e b\u00ebr\u00eb hap\u00ebsir\u00ebn t\u00eb disponueshme p\u00ebr rip\u00ebrdorim. Ai nuk<\/em> zvog\u00eblon madh\u00ebsin\u00eb e skedarit LDF n\u00eb disk.
\n* Zvog\u00eblimi i Regjistrit (Log Shrinking):<\/strong> Procesi i zvog\u00eblimit fizik t\u00eb madh\u00ebsis\u00eb s\u00eb skedarit LDF dhe kthimit t\u00eb hap\u00ebsir\u00ebs n\u00eb sistemin operativ.<\/p>\n

N\u00eb modelin e Rikuperimit t\u00eb Plot\u00eb (Full Recovery), trunkimi i regjistrit ndodh vet\u00ebm<\/em> kur nj\u00eb kopje rezerv\u00eb (backup) e regjistrit t\u00eb transaksioneve p\u00ebrfundohet me sukses (duke supozuar se asnj\u00eb proces tjet\u00ebr nuk po e mban regjistrin aktiv).<\/p>\n

Diagnostikimi i Gabimit “Regjistri i Transaksioneve \u00ebsht\u00eb Plot” (Gabimi 9002)<\/h2>\n

Kur regjistri \u00ebsht\u00eb plot, hapi juaj i par\u00eb nuk \u00ebsht\u00eb t\u00eb shtoni verb\u00ebrisht hap\u00ebsir\u00eb n\u00eb disk ose t\u00eb zvog\u00ebloni skedar\u00ebt. Ju duhet t\u00eb identifikoni pse<\/em> regjistri nuk mund t\u00eb trunkoj\u00eb. SQL Server ofron nj\u00eb mekaniz\u00ebm t\u00eb integruar p\u00ebr t’ju treguar sakt\u00ebsisht se \u00e7far\u00eb po pengon rip\u00ebrdorimin e regjistrit p\u00ebrmes pamjes s\u00eb katalogut sys.databases<\/code>.<\/p>\n

Ekzekutoni komand\u00ebn e m\u00ebposhtme T-SQL p\u00ebr t\u00eb identifikuar penges\u00ebn:<\/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
Ju gjithashtu mund t\u00eb kontrolloni p\u00ebrdorimin aktual t\u00eb hap\u00ebsir\u00ebs s\u00eb regjistrave t\u00eb transaksioneve duke p\u00ebrdorur:<\/p>\n
DBCC SQLPERF(LOGSPACE);\n<\/code><\/pre>\n
Gjendjet e zakonshme t\u00eb log_reuse_wait_desc<\/code><\/h3>\n
    \n
  1. LOG_BACKUP:<\/strong> Baza e t\u00eb dh\u00ebnave \u00ebsht\u00eb n\u00eb modelin e rikuperimit Full ose Bulk-Logged dhe nj\u00eb kopje rezerv\u00eb e regjistrit t\u00eb transaksioneve nuk \u00ebsht\u00eb marr\u00eb koh\u00ebt e fundit. Ky \u00ebsht\u00eb shkaku m\u00eb i zakonsh\u00ebm.<\/li>\n
  2. ACTIVE_TRANSACTION:<\/strong> Nj\u00eb transaksion q\u00eb zgjat shum\u00eb (p.sh., nj\u00eb rind\u00ebrtim masiv i indeksit ose nj\u00eb transaksion i harruar i pakonfirmuar) po e mban regjistrin aktiv.<\/li>\n
  3. REPLICATION \/ CDC:<\/strong> Replikimi i transaksioneve ose Change Data Capture (CDC) \u00ebsht\u00eb i aktivizuar dhe Agjenti i Lexuesit t\u00eb Regjistrit (Log Reader Agent) nuk i ka p\u00ebrpunuar ende transaksionet.<\/li>\n
  4. AVAILABILITY_REPLICA:<\/strong> N\u00eb nj\u00eb Grup Disponueshm\u00ebrie AlwaysOn, nj\u00eb replik\u00eb dyt\u00ebsore \u00ebsht\u00eb shk\u00ebputur ose sinkronizohet shum\u00eb ngadal\u00eb, duke detyruar replik\u00ebn kryesore t\u00eb mbaj\u00eb regjistrimet e log-ut derisa ato t\u00eb forcohen n\u00eb replik\u00ebn dyt\u00ebsore.<\/li>\n<\/ol>\n
    Strategjit\u00eb e Rikuperimit t\u00eb Shpejt\u00eb: Zgjidhja e Problemit n\u00eb Prodhim<\/h2>\n
    N\u00eb var\u00ebsi t\u00eb log_reuse_wait_desc<\/code> t\u00eb kthyer, p\u00ebrgjigja juaj e urgjenc\u00ebs do t\u00eb ndryshoj\u00eb. K\u00ebtu jan\u00eb strategjit\u00eb e rikuperimit t\u00eb shpejt\u00eb p\u00ebr skenar\u00ebt m\u00eb t\u00eb zakonsh\u00ebm.<\/p>\n
    Skenari 1: Kopjet rezerv\u00eb t\u00eb regjistrit mungojn\u00eb ose d\u00ebshtojn\u00eb (LOG_BACKUP<\/code>)<\/h3>\n
    N\u00ebse lloji i pritjes \u00ebsht\u00eb LOG_BACKUP<\/code>, zgjidhja \u00ebsht\u00eb e thjesht\u00eb: duhet t\u00eb b\u00ebni nj\u00eb kopje rezerv\u00eb t\u00eb regjistrit t\u00eb transaksioneve.<\/p>\n
    BACKUP LOG [YourDatabaseName] \nTO DISK = 'N:BackupsYourDatabaseName_EmergencyLog.trn' \nWITH COMPRESSION, STATS = 10;\n<\/code><\/pre>\n
    Pasi t\u00eb p\u00ebrfundoj\u00eb kopja rezerv\u00eb, VLF-t\u00eb joaktive do t\u00eb trunkohen dhe SQL Server do t\u00eb rifilloj\u00eb operacionet normale. N\u00ebse disku juaj i kopjeve rezerv\u00eb \u00ebsht\u00eb plot, mund t’ju duhet t\u00eb b\u00ebni kopje rezerv\u00eb n\u00eb nj\u00eb ndarje rrjeti t\u00eb p\u00ebrkohshme ose n\u00eb nj\u00eb pajisje null (nuk rekomandohet fort p\u00ebrve\u00e7 n\u00ebse baza e t\u00eb dh\u00ebnave \u00ebsht\u00eb leht\u00ebsisht e riprodhueshme, pasi kjo prish zinxhirin e regjistrit):<\/p>\n
    -- KUJDES: Kjo prish zinxhirin e regjistrit dhe komprometon rikuperimin n\u00eb nj\u00eb pik\u00eb kohore.\n-- P\u00ebrdoreni vet\u00ebm n\u00ebse \u00ebsht\u00eb absolutisht e nevojshme dhe ndiqeni menj\u00ebher\u00eb me nj\u00eb kopje rezerv\u00eb FULL.\nBACKUP LOG [YourDatabaseName] TO DISK = 'NUL';\n<\/code><\/pre>\n
    Skenari 2: Transaksionet aktive q\u00eb zgjasin shum\u00eb (ACTIVE_TRANSACTION<\/code>)<\/h3>\n
    N\u00ebse nj\u00eb transaksion i vet\u00ebm ka zgjatur p\u00ebr or\u00eb t\u00eb t\u00ebra, ai parandalon trunkimin e regjistrit p\u00ebr t\u00eb gjith\u00eb koh\u00ebzgjatjen. S\u00eb pari, identifikoni transaksionin problematik:<\/p>\n
    DBCC OPENTRAN('YourDatabaseName');\n<\/code><\/pre>\n
    Kjo komand\u00eb kthen transaksionin m\u00eb t\u00eb vjet\u00ebr aktiv dhe ID-n\u00eb e Procesit t\u00eb Serverit (SPID). Ju mund t\u00eb mblidhni m\u00eb shum\u00eb detaje rreth asaj q\u00eb po b\u00ebn SPID duke pyetur pamjet e menaxhimit dinamik (DMVs):<\/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
    N\u00ebse transaksioni \u00ebsht\u00eb nj\u00eb pyetje e gabuar ose nj\u00eb proces i ngecur, mund t’ju duhet ta nd\u00ebrprisni at\u00eb p\u00ebr t\u00eb liruar regjistrin.<\/p>\n
    KILL <SPID>;\n<\/code><\/pre>\n
    Sh\u00ebnim: Nd\u00ebrprerja e nj\u00eb transaksioni masiv do t\u00eb shkaktoj\u00eb nj\u00eb rikthim (rollback), i cili mund t\u00eb marr\u00eb nj\u00eb koh\u00eb t\u00eb konsiderueshme dhe do t\u00eb gjeneroj\u00eb p\u00ebrkoh\u00ebsisht aktivitet shtes\u00eb t\u00eb regjistrit. Mos e rinisni sh\u00ebrbimin e SQL Server gjat\u00eb nj\u00eb rikthimi, p\u00ebrndryshe baza e t\u00eb dh\u00ebnave do t\u00eb hyj\u00eb n\u00eb modalitetin e rikuperimit pas rinisjes.<\/em><\/p>\n
    Skenari 3: Alokimi i hap\u00ebsir\u00ebs s\u00eb urgjenc\u00ebs (Disku \u00ebsht\u00eb 100% plot)<\/h3>\n
    N\u00ebse skedari LDF ka konsumuar t\u00eb gjith\u00eb diskun, nuk mund as t\u00eb ekzekutoni nj\u00eb kopje rezerv\u00eb sepse SQL Server k\u00ebrkon nj\u00eb sasi t\u00eb vog\u00ebl hap\u00ebsire regjistri p\u00ebr t\u00eb regjistruar vet\u00eb ngjarjen e kopjes rezerv\u00eb. N\u00eb k\u00ebt\u00eb skenar, duhet t\u00eb shtoni nj\u00eb skedar regjistri dyt\u00ebsor n\u00eb nj\u00eb disk tjet\u00ebr me hap\u00ebsir\u00eb t\u00eb disponueshme.<\/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
    Kjo i siguron menj\u00ebher\u00eb SQL Server-it hap\u00ebsir\u00eb p\u00ebr t\u00eb marr\u00eb frym\u00eb. Pasi baza e t\u00eb dh\u00ebnave t\u00eb jet\u00eb n\u00eb linj\u00eb, b\u00ebni nj\u00eb kopje rezerv\u00eb t\u00eb regjistrit t\u00eb transaksioneve, zbrazni skedarin dyt\u00ebsor t\u00eb regjistrit dhe hiqeni at\u00eb:<\/p>\n
    -- 1. B\u00ebni nj\u00eb kopje rezerv\u00eb t\u00eb regjistrit p\u00ebr t\u00eb trunkuar regjistrin\nBACKUP LOG [YourDatabaseName] TO DISK = '...';\n\n-- 2. Zbrazni skedarin e p\u00ebrkohsh\u00ebm t\u00eb regjistrit\nDBCC SHRINKFILE (N'YourDatabaseName_Log2', EMPTYFILE);\n\n-- 3. Hiqni skedarin e p\u00ebrkohsh\u00ebm t\u00eb regjistrit\nALTER DATABASE [YourDatabaseName] REMOVE FILE [YourDatabaseName_Log2];\n<\/code><\/pre>\n
    Praktikat m\u00eb t\u00eb mira p\u00ebr parandalimin dhe menaxhimin e regjistrit t\u00eb transaksioneve<\/h2>\n
    Zgjidhja reaktive e problemeve \u00ebsht\u00eb stresuese dhe ndikon n\u00eb SLA. Zbatimi i praktikave m\u00eb t\u00eb mira arkitekturore dhe operacionale proaktive \u00ebsht\u00eb thelb\u00ebsor p\u00ebr stabilitetin e baz\u00ebs s\u00eb t\u00eb dh\u00ebnave t\u00eb nd\u00ebrmarrjes.<\/p>\n
    1. Zbatoni nj\u00eb strategji t\u00eb fuqishme dhe t\u00eb automatizuar t\u00eb kopjeve rezerv\u00eb<\/h3>\n
    N\u00ebse nj\u00eb baz\u00eb t\u00eb dh\u00ebnash \u00ebsht\u00eb n\u00eb modelin e rikuperimit Full, kopjet rezerv\u00eb t\u00eb shpeshta t\u00eb regjistrit t\u00eb transaksioneve jan\u00eb t\u00eb detyrueshme. N\u00eb var\u00ebsi t\u00eb Objektivit tuaj t\u00eb Pik\u00ebs s\u00eb Rikuperimit (RPO) dhe v\u00ebllimit t\u00eb transaksioneve, kopjet rezerv\u00eb t\u00eb regjistrit duhet t\u00eb ndodhin \u00e7do 5 deri n\u00eb 15 minuta.<\/p>\n
    Zgjidhjet e kopjeve rezerv\u00eb t\u00eb nd\u00ebrmarrjeve si CloudSave e thjeshtojn\u00eb k\u00ebt\u00eb proces ndjesh\u00ebm. Duke u integruar drejtp\u00ebrdrejt me SQL Server p\u00ebrmes VDI (Virtual Device Interface), CloudSave u lejon DBA-ve t\u00eb konfigurojn\u00eb kopje rezerv\u00eb t\u00eb regjistrit t\u00eb transaksioneve me frekuenc\u00eb t\u00eb lart\u00eb, t\u00eb drejtuara nga politika. Kjo siguron q\u00eb regjistrat t\u00eb trunkohen vazhdimisht, t\u00eb enkriptohen n\u00eb m\u00ebnyr\u00eb t\u00eb sigurt dhe t\u00eb ruhen jasht\u00eb vendit ose n\u00eb ruajtje cloud t\u00eb pandryshueshme, duke parandaluar gjendjen e pritjes LOG_BACKUP<\/code> pa pasur nevoj\u00eb p\u00ebr pun\u00eb komplekse t\u00eb personalizuara t\u00eb SQL Agent.<\/p>\n
    2. P\u00ebrcaktoni madh\u00ebsin\u00eb e duhur t\u00eb regjistrit t\u00eb transaksioneve dhe menaxhoni VLF-t\u00eb<\/h3>\n
    Mb\u00ebshtetja te rritja automatike p\u00ebr t\u00eb menaxhuar madh\u00ebsin\u00eb e regjistrit t\u00eb transaksioneve \u00ebsht\u00eb nj\u00eb anti-model i rreziksh\u00ebm. Operacionet e rritjes automatike jan\u00eb t\u00eb shtrenjta dhe ndalojn\u00eb p\u00ebrpunimin e transaksioneve nd\u00ebrsa disku inicializohet me zero (p\u00ebrve\u00e7 n\u00ebse \u00ebsht\u00eb aktivizuar Inicializimi i Shpejt\u00eb i Skedarit, i cili nuk<\/em> zbatohet p\u00ebr skedar\u00ebt e regjistrit).<\/p>\n
    P\u00ebr m\u00eb tep\u00ebr, rritjet automatike t\u00eb shpeshta dhe t\u00eb vogla (p.sh., rritja me 10% ose 50MB n\u00eb t\u00eb nj\u00ebjt\u00ebn koh\u00eb) \u00e7ojn\u00eb n\u00eb fragmentim t\u00eb VLF-ve<\/strong>. Nj\u00eb regjist\u00ebr transaksionesh me mij\u00ebra VLF t\u00eb vogla do t\u00eb degradoj\u00eb r\u00ebnd\u00eb koh\u00ebn e nisjes s\u00eb baz\u00ebs s\u00eb t\u00eb dh\u00ebnave, performanc\u00ebn e kopjeve rezerv\u00eb dhe vones\u00ebn e replikimit.<\/p>\n
      \n
    • P\u00ebrcaktoni paraprakisht madh\u00ebsin\u00eb e regjistrit:<\/strong> Analizoni operacionet tuaja m\u00eb t\u00eb m\u00ebdha t\u00eb mir\u00ebmbajtjes (si rind\u00ebrtimet e indekseve) dhe p\u00ebrcaktoni paraprakisht madh\u00ebsin\u00eb e skedarit LDF p\u00ebr t’i akomoduar ato pa u rritur.<\/li>\n
    • Vendosni rritje automatike fikse:<\/strong> Ndryshoni rritjen automatike nga nj\u00eb p\u00ebrqindje n\u00eb nj\u00eb madh\u00ebsi fikse (p.sh., 1GB ose 5GB) p\u00ebr t\u00eb siguruar q\u00eb VLF-t\u00eb t\u00eb krijohen n\u00eb nj\u00eb madh\u00ebsi t\u00eb sh\u00ebndetshme.<\/li>\n<\/ul>\n
      Ju mund t\u00eb kontrolloni numrin tuaj t\u00eb VLF-ve duke p\u00ebrdorur pyetjen e m\u00ebposhtme (p\u00ebr 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
      N\u00ebse numri juaj i VLF-ve \u00ebsht\u00eb mbi 500, konsideroni t\u00eb prisni p\u00ebr nj\u00eb periudh\u00eb t\u00eb qet\u00eb, t\u00eb zvog\u00ebloni regjistrin n\u00eb nj\u00eb madh\u00ebsi minimale dhe ta rritni manualisht p\u00ebrs\u00ebri n\u00eb madh\u00ebsin\u00eb e k\u00ebrkuar n\u00eb pjes\u00eb t\u00eb m\u00ebdha.<\/p>\n
      3. Optimizoni operacionet e mir\u00ebmbajtjes s\u00eb indekseve<\/h3>\n
      Rind\u00ebrtimet e indekseve jan\u00eb operacione t\u00eb regjistruara plot\u00ebsisht, madje edhe n\u00eb modelin e rikuperimit Bulk-Logged (n\u00eb var\u00ebsi t\u00eb llojit t\u00eb indeksit). Rind\u00ebrtimi i nj\u00eb indeksi 500GB do t\u00eb gjeneroj\u00eb t\u00eb pakt\u00ebn 500GB regjistrime t\u00eb regjistrit t\u00eb transaksioneve.<\/p>\n
      P\u00ebr t\u00eb zbutur fryrjen e regjistrit gjat\u00eb mir\u00ebmbajtjes:
      \n*   P\u00ebrdorni SORT_IN_TEMPDB = ON<\/code> kur rind\u00ebrtoni indekset. Kjo shkarkon faz\u00ebn e renditjes n\u00eb TempDB, duke reduktuar barr\u00ebn n\u00eb regjistrin e transaksioneve t\u00eb baz\u00ebs s\u00eb t\u00eb dh\u00ebnave t\u00eb p\u00ebrdoruesit.
      \n*   Kaloni nga rind\u00ebrtimi<\/em> i indekseve n\u00eb riorganizimin<\/em> e indekseve ku \u00ebsht\u00eb e mundur, pasi riorganizimet jan\u00eb m\u00eb efikase n\u00eb regjistrim dhe mund t\u00eb nd\u00ebrpriten pa rikthyer t\u00eb gjith\u00eb operacionin.
      \n*   Grumbulloni operacionet e m\u00ebdha DELETE<\/code> ose UPDATE<\/code>. N\u00eb vend q\u00eb t\u00eb fshini 10 milion\u00eb rreshta n\u00eb nj\u00eb transaksion, fshini ato n\u00eb grupe prej 50,000, duke konfirmuar dhe duke lejuar kopjet rezerv\u00eb t\u00eb regjistrit t\u00eb trunkojn\u00eb regjistrin midis grupeve.<\/p>\n
      4. Monitoroni topologjit\u00eb e Disponueshm\u00ebris\u00eb s\u00eb Lart\u00eb dhe Replikimit<\/h3>\n
      N\u00eb Grupet e Disponueshm\u00ebris\u00eb AlwaysOn, replika kryesore nuk mund t\u00eb trunkoj\u00eb regjistrin e saj derisa regjistrimet e regjistrit t\u00eb jen\u00eb forcuar n\u00eb t\u00eb gjitha replikat dyt\u00ebsore sinkrone dhe asinkrone.<\/p>\n
      N\u00ebse nj\u00eb replik\u00eb dyt\u00ebsore shkon jasht\u00eb linje, ose n\u00ebse gjer\u00ebsia e brezit t\u00eb rrjetit nuk mund t\u00eb p\u00ebrballoj\u00eb shkall\u00ebn e gjenerimit t\u00eb transaksioneve t\u00eb replik\u00ebs kryesore, radha e d\u00ebrgimit t\u00eb replik\u00ebs kryesore do t\u00eb rritet dhe regjistri do t\u00eb mbushet (lloji i pritjes AVAILABILITY_REPLICA<\/code>).<\/p>\n
      Zbatoni monitorim t\u00eb fuqish\u00ebm p\u00ebr num\u00ebruesin e performanc\u00ebs SQLServer:Replica > Log Send Queue<\/code>. N\u00ebse nj\u00eb replik\u00eb dyt\u00ebsore humbet p\u00ebrgjithmon\u00eb, duhet ta hiqni at\u00eb nga Grupi i Disponueshm\u00ebris\u00eb ose t\u00eb pezulloni l\u00ebvizjen e t\u00eb dh\u00ebnave p\u00ebr t\u00eb lejuar trunkimin e regjistrit kryesor.<\/p>\n
      P\u00ebrfundim<\/h2>\n
      Hasja e nj\u00eb regjistri transaksionesh t\u00eb plot\u00eb \u00ebsht\u00eb nj\u00eb rit kalimi p\u00ebr administrator\u00ebt e bazave t\u00eb t\u00eb dh\u00ebnave, por nuk duhet t\u00eb rezultoj\u00eb domosdoshm\u00ebrisht n\u00eb koh\u00eb joproduktive t\u00eb zgjatur. Duke kuptuar mekanik\u00ebn e Regjistrimit me Shkrim p\u00ebrpara dhe VLF-ve, mund t\u00eb diagnostikoni shpejt shkakun rr\u00ebnj\u00ebsor duke p\u00ebrdorur sys.databases<\/code> dhe t\u00eb aplikoni strategjin\u00eb e duhur t\u00eb rikuperimit t\u00eb shpejt\u00eb.<\/p>\n
      Stabiliteti afatgjat\u00eb mb\u00ebshtetet n\u00eb largimin nga rregullimet reaktive. P\u00ebrcaktimi paraprak i madh\u00ebsis\u00eb s\u00eb skedar\u00ebve t\u00eb regjistrit, optimizimi i rutinave t\u00eb mir\u00ebmbajtjes dhe p\u00ebrdorimi i platformave t\u00eb kopjeve rezerv\u00eb t\u00eb nivelit t\u00eb nd\u00ebrmarrjes si CloudSave p\u00ebr t\u00eb zbatuar orare strikte dhe t\u00eb automatizuara t\u00eb kopjeve rezerv\u00eb t\u00eb regjistrit do t\u00eb siguroj\u00eb q\u00eb regjistrat tuaj t\u00eb transaksioneve t\u00eb mbeten t\u00eb sh\u00ebndetsh\u00ebm, t\u00eb trunkuar dhe gati p\u00ebr t\u00eb mb\u00ebshtetur ngarkesat e pun\u00ebs s\u00eb prodhimit me xhiro t\u00eb lart\u00eb.<\/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":[287],"tags":[808,3926,3927,3928,3929,3930,3931],"class_list":["post-5878","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\/sq\/knowledge-base\/mssql-transaction-log-full-strategjit%c3%ab-e-parandalimit-dhe-rikuperimit-t%c3%ab-shpejt%c3%ab\/\" \/>\n<meta property=\"og:locale\" content=\"sq_AL\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"MSSQL Transaction Log Full: Strategjit\u00eb e parandalimit dhe rikuperimit t\u00eb shpejt\u00eb\" \/>\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\/sq\/knowledge-base\/mssql-transaction-log-full-strategjit%c3%ab-e-parandalimit-dhe-rikuperimit-t%c3%ab-shpejt%c3%ab\/\" \/>\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:31:01+00:00\" \/>\n<meta name=\"author\" content=\"shervinrv\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"shervinrv\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"12 minuta\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/cloudsave.app\\\/sq\\\/knowledge-base\\\/mssql-transaction-log-full-strategjit%c3%ab-e-parandalimit-dhe-rikuperimit-t%c3%ab-shpejt%c3%ab\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/cloudsave.app\\\/sq\\\/knowledge-base\\\/mssql-transaction-log-full-strategjit%c3%ab-e-parandalimit-dhe-rikuperimit-t%c3%ab-shpejt%c3%ab\\\/\"},\"author\":{\"name\":\"shervinrv\",\"@id\":\"https:\\\/\\\/cloudsave.app\\\/sq\\\/#\\\/schema\\\/person\\\/286beefe68281d868e87f46603a7ae4d\"},\"headline\":\"MSSQL Transaction Log Full: Strategjit\u00eb e parandalimit dhe rikuperimit t\u00eb shpejt\u00eb\",\"datePublished\":\"2026-06-16T16:15:28+00:00\",\"dateModified\":\"2026-06-16T16:31:01+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/cloudsave.app\\\/sq\\\/knowledge-base\\\/mssql-transaction-log-full-strategjit%c3%ab-e-parandalimit-dhe-rikuperimit-t%c3%ab-shpejt%c3%ab\\\/\"},\"wordCount\":2190,\"publisher\":{\"@id\":\"https:\\\/\\\/cloudsave.app\\\/sq\\\/#\\\/schema\\\/person\\\/286beefe68281d868e87f46603a7ae4d\"},\"keywords\":[\"Database Administration\",\"Error 9002\",\"Log Backup\",\"MSSQL\",\"SQL Recovery\",\"SQL Server\",\"Transaction Log\"],\"articleSection\":[\"Database Backup\"],\"inLanguage\":\"sq\"},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/cloudsave.app\\\/sq\\\/knowledge-base\\\/mssql-transaction-log-full-strategjit%c3%ab-e-parandalimit-dhe-rikuperimit-t%c3%ab-shpejt%c3%ab\\\/\",\"url\":\"https:\\\/\\\/cloudsave.app\\\/sq\\\/knowledge-base\\\/mssql-transaction-log-full-strategjit%c3%ab-e-parandalimit-dhe-rikuperimit-t%c3%ab-shpejt%c3%ab\\\/\",\"name\":\"MSSQL Transaction Log Full: Prevention & Recovery\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/cloudsave.app\\\/sq\\\/#website\"},\"datePublished\":\"2026-06-16T16:15:28+00:00\",\"dateModified\":\"2026-06-16T16:31:01+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\\\/sq\\\/knowledge-base\\\/mssql-transaction-log-full-strategjit%c3%ab-e-parandalimit-dhe-rikuperimit-t%c3%ab-shpejt%c3%ab\\\/#breadcrumb\"},\"inLanguage\":\"sq\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/cloudsave.app\\\/sq\\\/knowledge-base\\\/mssql-transaction-log-full-strategjit%c3%ab-e-parandalimit-dhe-rikuperimit-t%c3%ab-shpejt%c3%ab\\\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/cloudsave.app\\\/sq\\\/knowledge-base\\\/mssql-transaction-log-full-strategjit%c3%ab-e-parandalimit-dhe-rikuperimit-t%c3%ab-shpejt%c3%ab\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/cloudsave.app\\\/sq\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"MSSQL Transaction Log Full: Strategjit\u00eb e parandalimit dhe rikuperimit t\u00eb shpejt\u00eb\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/cloudsave.app\\\/sq\\\/#website\",\"url\":\"https:\\\/\\\/cloudsave.app\\\/sq\\\/\",\"name\":\"CloudSave\",\"description\":\"CloudSave\",\"publisher\":{\"@id\":\"https:\\\/\\\/cloudsave.app\\\/sq\\\/#\\\/schema\\\/person\\\/286beefe68281d868e87f46603a7ae4d\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/cloudsave.app\\\/sq\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"sq\"},{\"@type\":[\"Person\",\"Organization\"],\"@id\":\"https:\\\/\\\/cloudsave.app\\\/sq\\\/#\\\/schema\\\/person\\\/286beefe68281d868e87f46603a7ae4d\",\"name\":\"shervinrv\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"sq\",\"@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\\\/sq\\\/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\/sq\/knowledge-base\/mssql-transaction-log-full-strategjit%c3%ab-e-parandalimit-dhe-rikuperimit-t%c3%ab-shpejt%c3%ab\/","og_locale":"sq_AL","og_type":"article","og_title":"MSSQL Transaction Log Full: Strategjit\u00eb e parandalimit dhe rikuperimit t\u00eb shpejt\u00eb","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\/sq\/knowledge-base\/mssql-transaction-log-full-strategjit%c3%ab-e-parandalimit-dhe-rikuperimit-t%c3%ab-shpejt%c3%ab\/","og_site_name":"CloudSave","article_published_time":"2026-06-16T16:15:28+00:00","article_modified_time":"2026-06-16T16:31:01+00:00","author":"shervinrv","twitter_card":"summary_large_image","twitter_misc":{"Written by":"shervinrv","Est. reading time":"12 minuta"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/cloudsave.app\/sq\/knowledge-base\/mssql-transaction-log-full-strategjit%c3%ab-e-parandalimit-dhe-rikuperimit-t%c3%ab-shpejt%c3%ab\/#article","isPartOf":{"@id":"https:\/\/cloudsave.app\/sq\/knowledge-base\/mssql-transaction-log-full-strategjit%c3%ab-e-parandalimit-dhe-rikuperimit-t%c3%ab-shpejt%c3%ab\/"},"author":{"name":"shervinrv","@id":"https:\/\/cloudsave.app\/sq\/#\/schema\/person\/286beefe68281d868e87f46603a7ae4d"},"headline":"MSSQL Transaction Log Full: Strategjit\u00eb e parandalimit dhe rikuperimit t\u00eb shpejt\u00eb","datePublished":"2026-06-16T16:15:28+00:00","dateModified":"2026-06-16T16:31:01+00:00","mainEntityOfPage":{"@id":"https:\/\/cloudsave.app\/sq\/knowledge-base\/mssql-transaction-log-full-strategjit%c3%ab-e-parandalimit-dhe-rikuperimit-t%c3%ab-shpejt%c3%ab\/"},"wordCount":2190,"publisher":{"@id":"https:\/\/cloudsave.app\/sq\/#\/schema\/person\/286beefe68281d868e87f46603a7ae4d"},"keywords":["Database Administration","Error 9002","Log Backup","MSSQL","SQL Recovery","SQL Server","Transaction Log"],"articleSection":["Database Backup"],"inLanguage":"sq"},{"@type":"WebPage","@id":"https:\/\/cloudsave.app\/sq\/knowledge-base\/mssql-transaction-log-full-strategjit%c3%ab-e-parandalimit-dhe-rikuperimit-t%c3%ab-shpejt%c3%ab\/","url":"https:\/\/cloudsave.app\/sq\/knowledge-base\/mssql-transaction-log-full-strategjit%c3%ab-e-parandalimit-dhe-rikuperimit-t%c3%ab-shpejt%c3%ab\/","name":"MSSQL Transaction Log Full: Prevention & Recovery","isPartOf":{"@id":"https:\/\/cloudsave.app\/sq\/#website"},"datePublished":"2026-06-16T16:15:28+00:00","dateModified":"2026-06-16T16:31:01+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\/sq\/knowledge-base\/mssql-transaction-log-full-strategjit%c3%ab-e-parandalimit-dhe-rikuperimit-t%c3%ab-shpejt%c3%ab\/#breadcrumb"},"inLanguage":"sq","potentialAction":[{"@type":"ReadAction","target":["https:\/\/cloudsave.app\/sq\/knowledge-base\/mssql-transaction-log-full-strategjit%c3%ab-e-parandalimit-dhe-rikuperimit-t%c3%ab-shpejt%c3%ab\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/cloudsave.app\/sq\/knowledge-base\/mssql-transaction-log-full-strategjit%c3%ab-e-parandalimit-dhe-rikuperimit-t%c3%ab-shpejt%c3%ab\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/cloudsave.app\/sq\/"},{"@type":"ListItem","position":2,"name":"MSSQL Transaction Log Full: Strategjit\u00eb e parandalimit dhe rikuperimit t\u00eb shpejt\u00eb"}]},{"@type":"WebSite","@id":"https:\/\/cloudsave.app\/sq\/#website","url":"https:\/\/cloudsave.app\/sq\/","name":"CloudSave","description":"CloudSave","publisher":{"@id":"https:\/\/cloudsave.app\/sq\/#\/schema\/person\/286beefe68281d868e87f46603a7ae4d"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/cloudsave.app\/sq\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"sq"},{"@type":["Person","Organization"],"@id":"https:\/\/cloudsave.app\/sq\/#\/schema\/person\/286beefe68281d868e87f46603a7ae4d","name":"shervinrv","image":{"@type":"ImageObject","inLanguage":"sq","@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\/sq\/knowledge-base\/author\/shervinrv\/"}]}},"_links":{"self":[{"href":"https:\/\/cloudsave.app\/sq\/wp-json\/wp\/v2\/posts\/5878","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cloudsave.app\/sq\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cloudsave.app\/sq\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cloudsave.app\/sq\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/cloudsave.app\/sq\/wp-json\/wp\/v2\/comments?post=5878"}],"version-history":[{"count":1,"href":"https:\/\/cloudsave.app\/sq\/wp-json\/wp\/v2\/posts\/5878\/revisions"}],"predecessor-version":[{"id":5942,"href":"https:\/\/cloudsave.app\/sq\/wp-json\/wp\/v2\/posts\/5878\/revisions\/5942"}],"wp:attachment":[{"href":"https:\/\/cloudsave.app\/sq\/wp-json\/wp\/v2\/media?parent=5878"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cloudsave.app\/sq\/wp-json\/wp\/v2\/categories?post=5878"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cloudsave.app\/sq\/wp-json\/wp\/v2\/tags?post=5878"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}