Hapja e fajllit LDf dhe shikimi i përmbajtjës së fajllit LDF

Cdo SQL Server databazë është e lidhur përmes një grumbulli të fajllave të sistemit operativ. Këto fajlla ruajnë të dhëna dhe regjistrojnë informata. Nga një databazë përdorën fajlla individual dhe të dhënat me informatat e regjistruara nuk përzihen asnjëherë në fajllin e njëjtë. Për derisa të dhënat ruhen në një MDF fajll, të gjitha transakcionet dhe modifikimet në SQL Server databazë ruhen në një LDF fajll – një transaction log fajll i cili është një prej komponenteve esenciale të databazës. Konceptualisht, fajlli i regjistrimeve paraqet një vargë të regjistrimit të rekordeve. Fizikisht, regjistrimet e rekordeve janë të ruajtura në një apo më shumë fajlla fizik LDF të cilat regjistrojnë transakcionet apo zbatojnë atë që bënë transaction log.

Aryseja kryesore e një LDF fajlli është që të siguroj konceptin ACID – Atomicity, Consistency, Isolation dhe Durability.

• Atomicity: nëse njëra pjesë e transakcionit dështon, i tërë transackioni do të jetë i dështuar dhe databaza do të jetë prap në gjendje të pandryshueshme.
• Consistency: Sjellja e databazë prej një gjendje valide në një gjendje tjetër poashtu valide, varësisht prej cilitdo transakcion që vepron në databazë.
• Isolation: Ekzekutimi i transakcioneve e sjellin databazën në atë gjendje ku transakcionet ekzekutohen në seri, një nga një.
• Durability: Transakcioni është i qëndrueshëm pas përfundimit dmth do të qëndroj ashtu sic ka përfunduar edhe nëse paraqitet ndonjë gabim, ndalet rryma apo ka dëmtime.

Një LDF fajll ruan informacion të mjfatueshëm për të ribërë apo rikthyer ndryshimet, ose për të rikthyer databazën në një kohë të caktuar. Prandaj varësisht nga kontrollet e ndryshme ose kërkesave për rikthim, paraqitet nevoja e shpeshtë për të hapur LDF fajllin dhe për të shikuar përmbajtjën e saj. Por shikimi i përmbajtjës së LDF fjallit nuk është një punë e lehtë.

Ka disa nga SQL Server funksionet dhe komandat (psh. fn_dblog, fn_dump_dblog and DBCC PAGE) të cilat potencialisht na sigurojnë mënyrën për të shikuar përmbajtjën e LDF fajllit. Megjithatë, kërkohet njohuri e lartë e kodit T-SQL, pasi që disa janë të padokumentuara, dhe rezultatet që ato japin janë të vështira për t’i kthyer në një format të kuptueshëm. Në vijim janë disa shembuj ku shikohet përmbajtja e LDF fajllit duke përdorur SQL Server funksione dhe komanda:

1. Ja ku e keni shembullin e leximit të një transaction log fajlli aktiv (online) duke përdorur fn_dblog, me rezultat të 129 kolonave (këtu janë paraqitur vetëm 7 prej tyre).

   

2. Është përdorur funksioni fn_dump_dblog për të lexuar një kopje të transaction log të rregulltë ose të kompresuar. Rezultate jan të ngjajshme:

   

   Fatëkeqësisht, nuk ka dokumentim zyrtar për funksionet fn_dblog dhe fn_dump_dblog. Ju do të duhej të jeni të familjarizuar me strukturat e brendshme të të dhënave si dhe formatin e të dhënave në mënyrë që t’i përktheni kolonat në mënyrë adekuate.

3. DBCC PAGE përdoret për të lexuar përmbajtjën e fajllave aktiv të databazës – MDF dhe LDF. Rezultati është një paraqitje heksadecimale që për derisa nuk keni ndonjë editor për të lexuar vlerat heksadecimale, vështirë do të jetë interpretimi i tyre.

   

Duke përdorur ApexSQL Log si një lexues për LDF fajlla

ApexSQL Log është një lexues i SQL Server transaction log-ut i cili lexon transaction log fajllat aktiv (online), transaction log fajllat e shkëputur (detached) dhe kopjet e transaction log (backup) – duke përfshirë edhe ato të kompresuara. Si një LDF lexues, ai është i fokusuar në operacionet (që të dy llojet DML dhe DDL, 45 në total) dhe gjithcka që është ndryshuar nga ekzekutimi i këtyre operacioneve.

Përvec paraqitjës logjike të përmbajtjës së një LDF fajlli, ApexSQL Log siguron disa nga tiparet shtesë sikurse është krijimi i skriptave për rikthim/ribërje, historiku i një rreshti nga operacionet DML dhe më shumë

Që të hapim dhe të shikojmë LDF fajllin duke përdorur ApexSQL Log:

1. Lidhu në databazën që i takon fajlli LDF

   

2. Hapi i radhës është që të shtojmë kopjet e LDF fajllave dhe/ose LDF fajllat e shkëputur (detached) që përmbajnë informacionin të cilin keni nevoj ta shihni. Sigurohuni që ato të jenë nga vargu i rregullt i renditjës së tyre. Një varg i rregulltë paraqet sekuencën e vazhdueshme të kopjeve të transaction log-ut. Ajo fillon me një kopje të plotë të databazës apo Full Database Backup duke u përcjellur në mënyrë sekuenciale nga të gjitha kopjet e transaction log deri te pika ku po dëshirojmë të kthemi me kopjet. Nëse kjo paraqet thyerje të ndërsekuencave, vetëm transakcionet nga kopja e fundit prej së cilës mungon transaction log i radhës mund të shihen informatat (psh. një skemë dhe emri i një objekti ose historiku i rreshtave apo rekordeve).

   Ndryshe nga operacionet INSERT dhe DELETE të cilat regjistrohen në mënyrë të plotë në LDF fajll, operacionet UPDATE regjistrohen në mënyrë minimale – dmth vetëm ndryshimet e bëra regjistrohen, ndërsa vlera e twrwsishme, e vjetër dhe e re nuk regjistrohet. Kur regjistrohen operacionet UPDATE, SQL Server nuk regjistron gjendjën para dhe pas, të rekordit por vetëm ndryshimin në rritje që ka ndodhur në rekord. Për shembull, nëse fjala “log” është freskuar me vlerë të re në fjalën “blog” SQL Server në rastin e përgjithshëm do të regjistroj vetëm shkronjën “b” si Index 0. Kjo është e mjaftueshme për t’u siguruar qëllimi i ACID por jo e mjaftueshme për të paraqitur në mënyrë të lehtë gjendjën para dhe pas, të rekordit apo rreshtit. Në këtë mënyrë, për ta kuptuar se cfarë ka ndohur me të vërtetë, ApexSQL Log do të bëjë rikonstruktimin në kontekstin e së cilës ka ndodhur ndryshimi nga transaction log dhe/ose kopja apo të dhënat nga databaza aktive (online).

   Për të arritur këtë, ApexSQL Log përdorë teknika të ndryshme, reciproke si dhe plotësuese për rikonstruktim të gjendjës së rreshtave apo rekordeve, njëra prej së cilave është rikonstruktimi duke përdorur vargun e plotë të renditjës së transaction log fajllave. Duke e caktuar vargun e plotë zinxhiror, së bashku më kopjën e plotë të fundit dhe kopjet e diferencuara apo differential bakcup, lejojnë ApexSQL Log të rikonstrukton UPDATE operacionet duke filluar nga gjendja fillestare e rreshtave që nga kopja e fundit dhe duke i rikonstruktuar të gjitha operacionet e rekordeve që jan prekur deri atëherë. Në shembulliin tonë, ApexSQL Log do të gjejë gjendjën e rreshtave në kohën kur është bërë kopja e fundit, shikohet vlera në atë fushë që ka qenë “log” dhe nga aty vie në përfundim se gjurma e ndryshimit qenka shtimi i “b” në index 0 e cila e ka transformuar në vlerën e re “blog”

   Për më tepër, një varg i regjistrimeve mundëson leximin e transakcioneve shumë më shpejtë duke përdorur disa kopje të transaction log fajllave se sa në vend të saj të lexohet një transaction log fajll i vetëm i cili është për disa herë më i madhë se sa të gjitha kopjet e transaction log që janë përdorur. Përvec kësaj, një fjall LDF i shkëputur (detached) mund të përdoret si burim informate për të lexuar në të – ApexSQL Log do të analizoj të gjitha burimet në atë mënyrë që të na japë informatë të saktë rreth transakcioneve të ruajtura në LDF fajlla.

   Për ta bërë këtë, përdorni butonin Add tek hapi Select SQL logs to analyze

   

3. Duke përdorur faqën Database backup sigurohuni që të jetë kopja e plotë e databazës apo Full Backup e cila do të përdoret si pikë fillestare e vargut prej ku do të fillojnë transakcionet

   

4. Në hapin e opcioneve Filter Setup, përdorni seksionin Time Range për të caktuar brezin kohor se kur ka ndodhur ekzekutimi i operacioneve. Kjo do të përshpejtoj procesin duke ngushtuar rezultatin e operacioneve që kërkohen.

   

5. Kur gjithcka është caktuar si më lartë, përdorni butonin Open për të filluar procesin e leximit të LDF fajllave.

   Të gjitha transakcionet, sipas burimeve dhe filterëve të caktuar do të shihen në pjesën kryesore të aplikacionit ApexSQL Log si një proces i përfunduar.

   

Përmbledhje rreth leximit të LDF fajllit

Sic është përshkruar, ka disa mënyra për të hapur LDF fajllin, dhe shumica prej tyre thjeshtë vetëm bëjnë hapjën e saj. Është e ndërlikuar që të merret një informacion i kuptueshëm dhe të përdoret.

Në anën tjetër, përvec hapjës së thjeshtë të fajllit LDF, ApexSQL Log shton vlerën e procesit, ku ju do të jeni në gjendje të lexoni transaction log fajllat dhe të shihni tipet e operacioneve, skemat dhe emrat e objekteve që janë prekur nga ndryshimet, kohën kur janë ekzekutuar operacionet, emri i përdoruesit që ka bërë ekzekutimin e operacioneve etj.

Përparsia kryesore e procesimit apo të leximit të LDF fajllave me ApexSQL Log në krahasim me hapjën e thjeshtë të tyre është se:

• Paraqet lexueshmëri me kuptim duke i lidhur dhe duke i paraqitur të dhënat (konvertime të vlerave heksadecimale dhe binare) nga 129 kolonat e njohura.
• Vargun e disa LDF fajllave në një të vetëm.
• Kombinimin e fajllave aktiv (online) dhe kopje (që të dyja, pra fajllin e databazës MDF dhe LDF fajllat), në mënyrë që të përmbajë më shumë detaje për cdo transakcion.
• Rikonstruktim të plotë të operacioneve UPDATE, duke përfshirë vlerat e vjetra (të mëhershme) dhe vlerat e reja (të pastajshme).
• Paraqitje të kompletuar të historiatit të ndryshimeve për operacionet DML (Data Manipulation Language) përfshirë edhe informatën e përdoruesve për cdo operacion dhe kohën e ekzekutimit të transakcionit.
• Mundësi filtrimi të informacionit që duhet lexuar në mënyrë që të shfrytëzohet më pak burime dhe të përshpejtohet procesi.
• Lidhshmëria e ID-ve të tabelave të vjetëra (të bëra DROP) për të lejuar rikthimin e të dhënave nga tabelat të cilat nuk ekzistojnë.
• Procesim dhe paraqitje të përmbajtjës së LDF fajllit pa e pasur njohurinë e skriptimit në T-SQL.

Përtej leximit, ApexSQL Log gjithashtu jepë mundësinë:

• E renditjës, filtrimit, kërkimit të avancuar që ju japë mundësinë e manipulimit me të dhënat në disa mënyra.
• Përvec paraqitjës së të dhënave në panel kryesor të aplikacionit – ApexSQL Log mund të konvertoj të dhënat në formatet CSV, HTML, XML ose SQL si dhe ju ndihmon që të menaxhoni exportet dhe të ruani përmbajtjën për analiza të mëvonshme.
• Krijimin e SQL skriptave për ribërje apo rikthim të transakcioneve të SQL Server – kjo është e dobishme për skenaret e rikthimit të të dhënave që mungojnë dhe duhe të rikthehen ose ndryshimeve në objekte/skema të cilat duhe të rikthehen pa bërë rikthim të kopjës së plotë të një databaze apo Full database Restore.
• Dokumentacioni zyrtar për të gjitha tiparet
• Përkrahja teknike , dhe më shumë

Autor: Ivan Stankovic

Përkthyes: Dukagjin Maloku