SQL Server Transaction logs përmbajnë rekordet që përshkruajnë ndryshimet e bëra në databazë. Ato posedojnë informacion të mjaftueshëm për ta kthyer databazën në kohë të caktuar, ribërjën ose rikthimin e ndryshimeve. Por, si duhet shikuar se cfarë kan ato, si duhet gjetur transakcionin specifik, si duhet shikuar se cfarë ka ndodhur dhe kthimin e ndryshimeve si psh kthimin e rekordeve të fshira aksidentalisht.
Për të shikuar se cfarë ruhet drejpërdrejtë në një transaction log, ose në një transaction log të bërë kopje (backup), nuk është aq e lehtë.
Hapja e fajllave LDF dhe TRN me ndonjë editor binary tregon rekorde të pakuptueshme të cilat nuk mund të lexohen në mënyrë të drejpërdrejtë. Për shembull, kjo është një pjesë nga LDF fajlli:
Përdorimi i fn_dblog
fn_dblog është një nga funksionet e padokumentuara në SQL Server i cili lexon pjesën aktive të një transaction log.
Le të shohim hapat që ju duhet t’i ndërmerrni dhe mënyrën se si paraqitën rezultatet:
- Ekzekuto fn_dblog funksionin
-
Nga rezultati i paraqitur prej fn_dblog, gjeni traksakcionet që dëshironi t’i shihni.
-
Gjeni kolonën e cila ruan vlerën e futur ose te fshirë – kontrolloni RowLog Contents 0, RowLog Contents 1, RowLog Contents 2, RowLog Contents 3, RowLog Contents 4, Përshkrimin dhe Log Record.
- Konvertimi i të dhënave binare në tabela me të dhëna merret parasysh nga tabela dhe tipi i të dhënave. Mekanizmat per konvertim mund të jenë të ndryshme varësisht prej tipit të të dhënave.
Select * FROM sys.fn_dblog(NULL,NULL)
Funksioni në fjalë sjellë 129 kolona, por është e rekomanduar që të sjellën kolonat e caktuara si dhe të caktohet lloji i transakcioneve nëse mund të jetë e aplikueshme.
Që të shohim traksakcionet për rekordete e future (INSERT), ekzekutoni:
SELECT [Current LSN], Operation, Context, [Transaction ID], [Begin time] FROM sys.fn_dblog (NULL, NULL) WHERE operation IN ('LOP_INSERT_ROWS');
Që të shohim transakcionet për rekorded e fshira (DELETE), ekzekutoni:
SELECT [begin time], [rowlog contents 1], [Transaction Name], Operation FROM sys.fn_dblog (NULL, NULL) WHERE operation IN ('LOP_DELETE_ROWS');
Rreshti i një të dhëne është i vendosur në kolona të ndryshme për tipet e ndryshme te operacioneve. Që të kemi mundësi për të shikuar saktësisht se cka kemi nevojë duke e përdorur funksionin fn_dblog, ju duhet ta dini përmbajtjën e kolonës për cdo tip të transakcionit. Pasi që nuk ka dokumentim zyrtar për këtë funksion, nuk do të jetë edhe aq e lehtë.
Rreshtat e futur apo të fshirë janë të paraqitura në vlera heksadecimale. Që të kemi mundësi që t’i ndajmë në fusha të caktuara, duhet ditur formatin që është përdorur, duhet kuptuar statusin, numrin total të kolonave etj.
Fn_dbLog është funksion shumë i fuqishëm dhe i përdorshëm por pak i limituar – leximi i rekordeve bëhet nga ndryshimi i strukturave në objekte dhe është kompleks pasi që zakonisht përfshinë rikonstruktimin e disa tabelave sistemore, ku vetëm një pjesë e Transaction Log lexohet drejtpërdrejtë dhe nuk ka Freskim (UPDATE)/BLOB të rikonstruktuar.
UPDATE operacioni është në mënyrë minimale i regjistruar në Transaction Log, pa vlera të vjetëra apo të reja, vetëm cka ka ndryshuar në rekord (p.sh. SQL Server regjistron që shkronja “G” ka ndryshuar në “F”, kur në fakt vlera “GLOAT” ka ndryshuar në “FLOAT”), ju duhet që në mënyrë manuale të rikonstruktoni gjendjën para freskimit e cila përfshinë rekonstruktimin e të gjitha gjendjeve në mes rekordeve që hyjnë në një “page” dhe freskimi që ju po tentoni ta bëni ose rikonstruktoni.
Kur fshihen BLOBs (imazhe-foto, audio ose multimedia), fshirja e BLOB nuk futet në Transaction Log, kështu që vetëm leximi i gjurmës së rekordit për BLOB të fshirë, nuk mund ta kthen shënimin BLOB prapa. Vetëm kur ka të dhënë Insert në leximin e rekordit për fshirje të BLOB dhe ju e menaxhoni që këto dy palë (Insert e Delete) t’i bashkoni, ju do të mund të ktheni BLOB të fshirë nga Transaction Log duke përdorur fn_dbLog.
Përdorimi fn_dump_dblog
Për të lexuar Transaction Log ose një kopje (backup) të kompresuar, madje edhe pa OnLine databazë, përdorni funksionin fn_dump_dblog. Prap, edhe ky funksion është i padokumentuar.
- Ekzekutoni funksionin fn_dump_dblog në një kopje të caktuar të Transaction Log. Ajo që duhet patur kujdes është që duhet specifikuar plot 36 parametra
- Të përcaktoni LSN për këtë transakcion
- Të konvertoni LSN në formatin WITH STOPBEFOREMARK = ‘<mark_name>’ shprehja, psh: 00000070:00000011:0001 duhet të transformohet në 112000000001700001
- Kthimi i vargut të Full Log Backup deri sa të arrini kohën kur transakcioni ka ndodhur. Përdorni WITH STOPBEFOREMARK = ‘
’ shprehja për të caktuar referencën e transakcionit LSN RESTORE LOG AdventureWorks2012 FROM DISK = N'E:\ApexSQL\backups\AW2012_05232013.trn' WITH STOPBEFOREMARK = 'lsn:112000000001700001', NORECOVERY;
SELECT * FROM fn_dump_dblog (NULL,NULL,N'DISK',1,N'E:\ApexSQL\backups\AdventureWorks2012_05222013.trn', DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT, DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT, DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT, DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT, DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT, DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT, DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT, DEFAULT);
Njejtë sikurse me fn_dbLog, 129 kolona paraqiten si rezultat, prandaj rekomandohet që këto kolona të specifikohen për rezultat të dëshiruar.
SELECT [Current LSN], Operation, Context, [Transaction ID], [transaction name], Description FROM fn_dump_dblog (NULL,NULL,N'DISK',1,N'E:\ApexSQL\backups\AdventureWorks2012_05222013.trn', DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT, DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT, DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT, DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT, DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT, DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT, DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT, DEFAULT);
Ju prap do të duheni që të deshifroni vlerat heksadecimale për të marr informacionin që jeni duke e kërkuar.
Dhe ju mund të ktheheni në një gjendje sikurse me fn_dblog – ku ju, duhet të rikonstruktoni të gjitha vlerat në mënyrë manuale, ju duhet të rikonstruktoni tërë vargun e operacioneve UPDATE dhe vlerave BLOB etj.
Nëse vërtetë ju nuk dëshironi t’i nxjerrni transakcionet nga kopja (backup) Transaction Log, por ta ktheni databazën në një pikë të caktuar para se të ndodhte operacioni i caktuar, ju mund:
Përdorimi i DBCC PAGE
Një tjetër komandë e fuqishme, poashtu e padokumentuar është DBCC PAGE. Përdorni këtë, për të lexuar përmbajtjën e fjallave MDF dhe LDF të një databaze online. Sintaksa është:
DBCC PAGE ( {'dbname' | dbid}, filenum, pagenum [, printopt={0|1|2|3} ])
Për të bërë paraqitjën e përmbajtjës së faqës (page) së transaction log fajllit në databazën AdventureWorks2012, përdorni:
SELECT FILE_ID ('AdventureWorks2012_Log') AS 'File ID' -- to determine Log file ID = 2 DBCC PAGE (AdventureWorks2012, 2, 0, 2)
Do të gjeni:
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Realisht, rezultati nuk paraqitet. Nëse ju duhet një rezultat në SQL Server Management Studio, duhet së pari, të aktivizoni Trace Flag me numër 3604.
DBCC TRACEON (3604, -1)
Dhe të ekzekutoni prap:
DBCC PAGE (AdventureWorks2012, 2, 0, 2)
Ju do të keni një grumbull të gabimeve dhe ju mund t’i injoroni të gjitha ato. Në fund, ju do të keni një përmbajtje heksadecimale nga fjalli LDF online:
I cili nuk është një prezantim i dëshiruar i të dhënave të databazës tuaj dhe ne faktë nuk ka ndonjë dukje ndryshe nga heksadecimal editorët (më shumë në mënyrë të papërshtatshme) edhe pse keni qasje në të dhëna online.
Përdorimi i ApexSQL Log
ApexSQL Log është një lexues i sql server transaction log-ut, i cili lexon transaction log aktiv (online), transaction log të shkëputura (detached) dhe kopje të transaction log (backup) – duke përfshirë rastet edhe kur jan të kompresuara. Kur nevojitet, ai do të lexoj edhe kopjet e databazave për të marr mjaftueshëm të dhëna për një rikonstruktim të të dhënave në mënyrë të suksesshme. Ky lexues mund të rilexoj të dhënat dhe ndryshimet ne objekte që jan prekur në databazë, përfshirë këtu edhe ato që kan ndodhur para se të instalohet. Ndryshe nga funksionet e padokumentuara dhe pa përkrahje që u përmendën më lartë, ju do të keni informacion qartë të kuptueshëm rreth asaj se cfarë ka ndodhur, në cilin objekt dhe cilat ishin vlerat e vjetëra dhe të reja.
- Fillon ApexSQL Log
-
Lidhu në databazën për të cilën dëshironi të lexoni Transaction Log.
-
Në hapin Select SQL logs to analyze, caktoni transaction log cilin dëshironi ta lexoni. Sigurohini që ato janë nga vargu (rendi) i plotë i tyre.
- Për të shtuar transaction log kopjet dhe për fajllat e shkëputur LDF, përdorni butonin Add.
-
Përdorni opcionin Filter setup për të kufizuar leximin e transakcioneve duke përdorur brezin kohor, tipin e operacioneve, tabelën dhe filtera të tjerë në dispozicion.
-
Klikoni Open
Rezultate të plota do të paraqitën në ApexSQL Log
Ju do të mund të shihni kohën e operacionit kur ka fillu dhe ka mbaru, llojin e operacionit, emri i skemës dhe objektit që është afektuar, emri i përdoruesit që ka ekzekutuar operacionin, cili kompjuter dhe aplikacion është përdorur për të ekzekutuar operacionin. Për ndryshimet (UPDATE’s) ju do të shihni vlerën e vjetër dhe të re në fushën ku është bërë freskimi apo ndryshimi.
Për të anashkaluar vlerat heksadecimale, funksionet e padokumentuara, përmbajtjën jo të qartë të kolonave, pyetësorët (queries) e gjatë, hapat e veprimeve komplekse, rikonstruktimet e pakompletuara për UPDATE dhe BLOB gjatë leximit të Transaction Log-ave përdorni ApexSQL Log. Do të lexoj Transaction Log-at për ju dhe do të prezantoj rezultate të qarta në gjuhën “sa më të thjeshtë”. Përveç kësaj, skriptat për kthim ose ribërje mund të bëhen vetëm me një klik përmes aplikacionit ApexSQL Log!
Përkthyes: Dukagjin Maloku
October 20, 2015