InterBase и Firebird водич за опоравак

NAPOMENA: Ovaj dokument je poglavlje iz knjige „The InterBase World" koju su napisali Aleksej Kovyazin i Serg Vostrikov.

Poglavlje iz knjige „The InterBase World" posvećeno popravci baze podataka.

1. Istorija ovog vodiča

Ruska knjiga „The InterBase World" objavljena je u septembru 2002. godine.

Njen tiraž bio je 3000 primeraka. Nakon 3 meseca rasprodata je i drugo, poboljšano izdanje objavljeno je u aprilu 2003. godine sa tiražom od 5000 primeraka.

Sada je na vrhu liste u najvećim ruskim onlajn knjižarama i nameravamo da će se vrlo brzo rasprodati.

Autori knjige su Aleksej Kovyazin, developer IBSurgeon-a i

poznati ruski InterBase stručnjak, i Serg Vostrikov, direktor kompanije Devrace

www.devrace.com

Zanimljivo je da nijedna knjiga posvećena InterBase-u nije objavljena na engleskom jeziku!

Hiljade i hiljade developera koristi InterBase i Firebird, raspravljaju o

temi na raznim konferencijama (pogledajte ovde: Linkovi).

Zajednica InterBase developera u proseku broji desetine hiljada

ljudi. Velika potražnja za InterBase knjigama u raznim zemljama dokazuje da je InterBase zajednica zaista velika.

Možemo se kladiti u kutiju piva da će izdanje od 10000 primeraka biti pometeno sa Amazon.com-a za mesec dana. Ali ljudi u izdavačkim kompanijama

„znaju sve" i sigurni su da niko neće kupiti knjigu o InterBase-u. To je zaista šteta.

Ovde bismo želeli da vam ponudimo nacrt jednog poglavlja ove knjige posvećenog oporavku InterBase/Firebird baza podataka.

2. Kako oporaviti InterBase/Firebird bazu podataka

2.1. Pregled glavnih uzroka oštećenja baze podataka

Nažalost, uvek postoji verovatnoća da će bilo koje skladište informacija biti

oštećeno i da će neke informacije iz njega biti izgubljene. Baza podataka nije izuzetak od ovog pravila. U ovom poglavlju razmotrićemo glavne uzroke koji dovode do oštećenja InterBase baze podataka, neke metode popravke baza podataka i izvlačenja informacija iz njih. Takođe ćemo se upoznati sa preporukama i merama predostrožnosti koje će minimizovati verovatnoću gubitka informacija iz baze podataka.

Pre svega, ako govorimo o popravci baze podataka, treba da razjasnimo pojam

„oštećenje baze podataka". Baza se obično naziva oštećenom ako se pri pokušaju izvlačenja ili modifikacije nekih informacija pojave greške i/ili se ispostavi da su izvučene informacije izgubljene, nepotpune ili potpuno pogrešne. Postoje slučajevi kada su oštećenja baze podataka skrivena i otkrivaju se samo testiranjem posebnim sredstvima, ali postoje i stvarna oštećenja baze podataka kada je nemoguće povezati se sa bazom, kada prilagođeni programi-klijenti pokazuju čudne greške (kada nisu izvršene nikakve manipulacije sa bazom), ili kada je nemoguće restaurirati bazu iz rezervne kopije.

2.2. Glavni uzroci oštećenja baze podataka su:

Nenormalan prekid rada serverskog računara, posebno prekid napajanja električnom energijom. Za IT industriju to je prava pošast i zato se nadamo da nema potrebe da vas ponovo podsećamo na neophodnost posedovanja izvora neprekidnog napajanja na serveru.
Defekti i kvarovi serverskog računara, posebno HDD (hard disk), kontrolera diskova, glavne memorije računara i keš memorije RAID kontrolera.
Nepravilna connection string sa višeklijentskom bazom podataka jednog ili više korisnika (u verzijama pre 6.x). Pri povezivanju preko TCP/IP-a, putanja do baze podataka mora ukazivati na ime servera: disk:/putanja/imebaze (za servere na UNIX platformi imeservera: /putanja/imebaze), prema NETBEUI protokolu \\imeservera\disk:\putanja\imebaze. Čak i pri povezivanju baze sa računara na kome se baza nalazi i na kome server radi, treba koristiti istu liniju zamenjujući ime servera sa localhost. Ne može se koristiti mapirani disk u liniji za povezivanje. Ako prekršite neko od ovih pravila, server smatra da radi sa različitim bazama podataka i oštećenje baze je zagarantovano.
Kopiranje datoteke ili drugi pristup datoteci baze podataka dok server radi. Izvršavanje komande „shut-down" ili isključivanje korisnika na uobičajen način nije garancija da server ne radi ništa sa bazom, ako interval sweep-a nije podešen na „0", može se izvršiti garbage collection. Obično se garbage collection izvršava odmah nakon što se poslednji korisnik isključi iz baze. Obično traje nekoliko sekundi, ali ako su pre toga potvrđene mnoge DELETE ili UPDATE operacije, proces može biti duži.
Korišćenje nestabilnih InterBase server verzija 5.1-5.5. Kompanija Borland je zvanično priznala da je postojalo nekoliko grešaka u ovim serverima i stabilna nadogradnja 5.6 uklonjena je tek nakon izlaska sertifikovanog InterBase 6 u slobodnom režimu rada za sve klijente servera 5.1-5.5 na svom sajtu.
Prekoračenje ograničenja veličine datoteke baze podataka (ne baze!). Za verzije pre InterBase 6 i neke InterBase 6 beta verzije ograničenje datoteke baze je 4Gb, za InterBase 6.5 i sva izdanja Firebird-a (1.0, 1.5, 2.0, 2.1) - 32Tb. Kada se veličina baze približi graničnoj vrednosti, mora se kreirati dodatna datoteka.
Iscrpljivanje slobodnog prostora na disku pri radu sa bazom podataka.
Za Borland InterBase servere verzije ispod 6.0.1.6 - prekoračenje ograničenja broja generatora prema definiciji Borland InterBase R & D (pogledajte tabelu 1).


Verzija	Veličina stranice=1024	Veličina stranice=2048	Veličina stranice=4096	Veličina stranice=8192
Pre 6	248	504	1016	2040
6.0.x	124	257	508	102

Tabela 1: Kritičan broj generatora u ranim InterBase verzijama

• Za sve Borland InterBase servere - prekoračenje dozvoljenog broja

transakcija bez izvršavanja backup/restore. Broj transakcija koje su se desile u bazi od trenutka poslednjeg kreiranja može se saznati pozivanjem uslužnog programa gstat sa ključem - h - parametar NEXT TRANSACTION ID biće željeni broj transakcija. Prema Ann W. Harrison, kritičan broj transakcija zavisi od veličine stranice i ima sledeće vrednosti (pogledajte tabelu 2):


Veličina stranice baze	Kritičan broj transakcija
1024 bajta	131 596 287
2048 bajta	265 814 016
4096 bajta	534 249 472
8192 bajta	1 071 120 384

Tabela 2: Kritičan broj transakcija u Borland InterBase serverima

Ograničenja Borland InterBase servera navedena gore ne odnose se na

Firebird servere osim na najranije verzije 0.x., čije je postojanje već postalo istorija. Ako koristite finalnu verziju Firebird 1.0 ili InterBase 6.5-7.x, ne treba da brinete o tačkama 5, 6, 8 i 9 i trebalo bi da usmerite svoje napore na druge uzroke. Sada ćemo detaljnije razmotriti najčešće od njih.

2.3. Prekid napajanja

Kada se isključi napajanje na serveru, sve aktivnosti obrade podataka se

prekidaju na najneočekivanijim i (prema Marfijevom zakonu) najopasnijim mestima. Kao rezultat toga, informacije u bazi podataka mogu biti izobličene ili izgubljene. Najjednostavniji slučaj je kada su svi nepotvrđeni podaci iz klijentskih aplikacija izgubljeni kao rezultat hitnog gašenja servera. Nakon ponovnog pokretanja nakon prekida napajanja, server analizira podatke, primećuje nepotpune transakcije koje se ne odnose ni na jednog klijenta i poništava sve modifikacije izvršene u okviru tih „mrtvih" transakcija. Zapravo, takvo ponašanje je normalno i predviđeno od samog početka od strane InterBase developera.

Međutim, prekid napajanja nije uvek praćen samo tako beznačajnim gubicima. Ako je server izvršavao proširenje baze podataka u trenutku prekida napajanja, postoji velika verovatnoća pojave „orphan" stranica u datoteci baze (stranica koje su fizički alocirane i registrovane na stranici inventara stranica (PIP), na koje je upis podataka nemoguć). Ako želite da saznate više o „orphan" stranicama, pogledajte poglavlje „Struktura InterBase baze podataka".

Samo alat za popravku i modifikaciju gfix (razmotrićemo ga u nastavku) može da se bori protiv „orphan" stranica u datoteci baze. Zapravo, „orphan" stranice dovode do nepotrebnog trošenja prostora na disku i kao takve nisu uzrok gubitka podataka ili oštećenja.

Gubitak napajanja dovodi do ozbiljnijih oštećenja. Na primer, nakon isključivanja

napajanja i ponovnog pokretanja, velika količina podataka, uključujući i potvrđene, može biti izgubljena (nakon dodavanja ili modifikacije za koje je izvršena komanda «commit transaction»). To se dešava jer potvrđeni podaci nisu direktno upisani u datoteku baze podataka na disku. Za tu svrhu se koristi keš datoteka operativnog sistema (OS). Proces servera je dao komandu za upis podataka OS-u. Zatim je OS uverio server da su svi podaci sačuvani na disku, a u stvarnosti su podaci bili sačuvani u kešu datoteka. OS ne žuri da upiše te podatke na disk, jer smatra da je ostalo još mnogo glavne memorije i odlaže spore operacije upisa na disk dok se glavna memorija ne napuni.

2.4. Forsirani upisi - dvosmerni mač

Da bi se uticalo na situaciju, u InterBase 6 je obezbeđeno podešavanje načina upisa podataka. Ovaj parametar se zove forsirani upisi (FW) i ima 2 načina - ON (sinhroni) i OFF (asinhroni). FW načini definišu kako InterBase komunicira sa diskom. Ako je FW uključen, podešavanje sinhronog upisa na disk se aktivira, kada se potvrđeni podaci upisuju na disk odmah nakon komande commit, server čeka da se upis završi i tek onda nastavlja sa obradom. Ako je FW isključen, InterBase ne žuri da upiše podatke na disk nakon komande potvrde transakcije i delegira ovaj zadatak paralelnoj niti dok glavna nit nastavlja obradu podataka ne čekajući da se upisi završe na disku. Sinhroni način upisa je jedan od najpažljivijih i minimizira svaki mogući gubitak podataka, međutim može izazvati izvestan gubitak performansi. Asinhroni način upisa povećava verovatnoću gubitka velike količine podataka. Da bi se postigle maksimalne performanse, obično se postavlja FW Off način. Ali kao rezultat prekida napajanja, mnogo veća količina podataka se gubi tokom asinhronog upisa nego tokom sinhronog. Prilikom podešavanja načina upisa treba odlučiti da li je nekoliko procenata performansi značajnije od nekoliko sati rada ako dođe do neočekivanog prekida napajanja.

Vrlo često su korisnici nemarni prema InterBase-u. Male organizacije štede na svakoj sitnici, često na računaru-serveru gde su instalirani i DBMS server i različiti serverski programi (i ne samo serverski). Ako se oni zakače, ljudi ne razmišljajući dugo pritisnu RESET (to se dešava nekoliko puta dnevno). Iako je InterBase veoma stabilan na takve aktivnosti u poređenju sa drugim DBMS-ovima i omogućava početak rada sa bazom podataka odmah nakon hitnog ponovnog pokretanja, takva upotreba nije poželjna. Broj siročadi stranica se povećava i podaci gube vezu među sobom kao rezultat pogrešnih ponovnih pokretanja.

To može da traje dugo, ali pre ili kasnije doći će do kraja. Kada se oštećene stranice pojave među PIP ili generator stranicama, ili ako je zaglavlje stranice baze podataka oštećeno, baza podataka se možda nikada više neće otvoriti i postaće veliki komad odvojenih podataka iz kojih se ne može izvući nijedan bajt korisnih informacija.

2.5. Oštećenje hard diska

Oštećenja hard diska dovode do nestanka važnih sistemskih stranica baze podataka i/ili oštećenja veza među preostalim stranicama. Takva oštećenja su jedan od najtežih slučajeva, jer gotovo uvek zahtevaju intervenciju na niskom nivou da bi se baza podataka obnovila.

2.6. Greške u dizajnu baze podataka

Neophodno je da znate za neke greške koje prave programeri baza podataka

koje mogu dovesti do nemogućnosti oporavka baze podataka iz rezervne kopije (*.gbk datoteke kreirane programom gbak). Pre svega, to je nemarno korišćenje ograničenja na nivou baze podataka. Tipičan primer su ograničenja NOT NULL. Pretpostavimo da imamo tabelu ispunjenu brojem zapisa. Sada ćemo ovoj tabeli dodati pomoću komande ALTER TABLE još jednu kolonu i naznačiti da ona ne sme da sadrži nedefinisane vrednosti NULL. Nešto poput ovoga:

ALTER TABLE sometable Field/INTEGER NOT NULL

I u ovom slučaju neće biti greške servera kao što bi se očekivalo. Ova

modifikacija metapodataka će biti potvrđena i nećemo dobiti nikakvu poruku o grešci ili upozorenju što stvara iluziju normalnosti ove situacije.

Međutim, ako napravimo rezervnu kopiju baze podataka i pokušamo da je obnovimo iz rezervne kopije, dobićemo

poruku o grešci u fazi obnavljanja (jer se NULL vrednosti ubacuju u kolonu koja ima NOT NULL ograničenje, i proces obnavljanja će biti prekinut. (Važna napomena koju je dao Craig Stuntz - sa verzijom InterBase 7.1 ograničenja se po podrazumevanoj vrednosti ignorišu tokom obnavljanja (ovo se može kontrolisati prekidačem komandne linije) i gotovo svaka neoštećena rezervna kopija može biti obnovljena. Uvek je dobra ideja uraditi test obnavljanja nakon pravljenja rezervne kopije, ali ovaj problem bi trebalo da uglavnom nestane u verziji 7.1.) Ova rezervna kopija se ne može obnoviti. Ako je obnavljanje usmereno na datoteku sa istim imenom kao postojeća baza podataka (tokom obnavljanja radna datoteka postojeće baze podataka je prepisivana), izgubićemo sve informacije.

To je povezano sa činjenicom da su ograničenja NOT NULL implementirana sistemskim okidačima koji proveravaju samo pristigle podatke. Tokom obnavljanja podaci iz rezervne kopije se ubacuju u prazne, tek kreirane tabele - ovde možemo pronaći nedozvoljene NULL vrednosti u koloni sa ograničenjem NOT NULL.

Neki programeri smatraju da je takvo ponašanje InterBase-a netačno, ali drugi neće moći da dodaju polje sa NOT NULL ograničenjem u tabelu baze podataka.

Pitanje o podrazumevanoj vrednosti i popunjavanju njome u trenutku

kreiranja je široko diskutovano od strane Firebird arhitekata, ali nije prihvaćeno zbog činjenice da programer očigledno namerava da je popuni prema algoritmu, prilično složenom i možda iterativnom. Ali nema garancije da li će moći da razlikuje zapise ignorisane prethodnom iteracijom od nepopunjenih zapisa ili ne.

Sličan problem može biti izazvan greškom u sakupljanju smeća zbog postavljanja netačne putanje do baze podataka (uzrok oštećenja 3) u trenutku povezivanja i pristupa datotekama baze podataka kada server radi sa njom (uzrok oštećenja 4) i zapisi potpuno ispunjeni Null vrednostima mogu se pojaviti u nekim tabelama. Veoma je teško otkriti ove zapise, jer ne odgovaraju ograničenjima kontrole integriteta, a operator Select ih jednostavno ne vidi, iako ulaze u rezervnu kopiju. Ako je nemoguće obnoviti iz tog razloga, treba pokrenuti program gfix (pogledajte ispod), pronaći i obrisati ove zapise koristeći neindeksirana polja kao uslove pretrage, nakon toga ponovo napraviti rezervnu kopiju i obnoviti bazu podataka iz nje. U zaključku možemo reći da postoji veliki broj uzroka oštećenja baze podataka i uvek treba biti spreman za najgore - da će vaša baza podataka biti oštećena iz ovog ili onog razloga. Takođe morate biti spremni da obnovite i sačuvate vredne informacije. A sada ćemo razmotriti mere predostrožnosti koje garantuju sigurnost InterBase baze podataka, kao i metode popravke oštećenih baza podataka.

2.7. Mere predostrožnosti protiv oštećenja InterBase baze podataka

Da bi se sprečilo oštećenje baze podataka, uvek treba praviti rezervne kopije (ako želite da saznate više o rezervnim kopijama, pogledajte poglavlje „Rezervna kopija i obnavljanje“). To je najpouzdaniji način protiv oštećenja baze podataka. Samo rezervna kopija daje 100% garanciju sigurnosti baze podataka. Kao što je gore opisano, kao rezultat rezervne kopije možemo dobiti beskorisnu kopiju (kopiju koja se ne može obnoviti), zato obnavljanje baze iz kopije ne sme da se vrši prepisivanjem skripte i rezervna kopija mora biti napravljena prema određenim pravilima. Prvo, rezervna kopija mora biti izvršena što je češće moguće, drugo, mora biti serijska i treće, rezervne kopije moraju biti proverene na mogućnost obnavljanja.

Često rezervna kopija znači da je neophodno praviti rezervnu kopiju prilično često, na primer jednom u dvadeset četiri sata. Što je manji period podataka između rezervnih kopija baze podataka, manje podataka će biti izgubljeno kao rezultat greške. Sekvencijalnost rezervne kopije znači da broj rezervnih kopija mora da raste i mora biti čuvan najmanje nedelju dana. Ako postoji mogućnost, neophodno je pisati rezervne kopije na posebne uređaje poput strimera, ali ako ne postoji - samo ih kopirati na drugi računar. Istorija rezervnih kopija će pomoći da se otkriju skrivena oštećenja i izbori sa greškom koja je nastala davno i pokazala se neočekivano. Treba proveriti da li je moguće obnoviti primljenu rezervnu kopiju bez grešaka ili ne. To se može proveriti samo na jedan način - kroz proces test obnavljanja. Treba reći da proces obnavljanja traje 3 puta duže od rezervne kopije, i teško je izvršiti validaciju obnavljanja svaki dan za velike baze podataka, jer može prekinuti rad korisnika na nekoliko sati (noćni prekid možda neće biti dovoljan).

Било би боље да велике организације не штеде на „мечевима“ и оставе један рачунар за ове намене.

У овом случају, ако сервер мора да ради са озбиљним оптерећењем 24 сата 7 дана у недељи, можемо користити SHADOW механизам за прављење снимака базе података и даље операције бекапа са непосредне копије. Процес бекапа и рестаурације базе података је детаљно описан у поглављу „Бекап и рестаурација“. Када се направи бекап и затим рестаурира база података из њега, долази до рекреације свих података у бази. Овај процес (бекап/рестаурација или б/р) доприноси исправљању већине нефаталних грешака у бази, повезаних са оштећењем хард диска, откривању проблема са интегритетом у бази, чишћењу базе од смећа (старе верзије и фрагменти записа, непотпуне трансакције), значајно смањујући величину базе.

Редовни б/р је гаранција сигурности InterBase базе података. Ако база ради, препоручује се извршавање б/р сваке недеље. Истини за вољу, постоје примери InterBase база које се интензивно користе годинама без бекапа/рестаурације.

Ипак, да бисте били сигурни, пожељно је извршити ову процедуру, посебно јер се лако може аутоматизовати (погледајте поглавље „Бекап“).

Ако је из неког разлога немогуће често вршити бекап/рестаурацију, онда се може користити алат gfix за проверу и рестаурацију базе. gfix омогућава проверу и уклањање многих грешака без б/р.

2.8. Алат командне линије gfix

Алат командне линије gfix се користи за проверу и рестаурацију базе података. Поред тога, gfix може извршавати и различите активности контроле базе: промену дијалекта базе, постављање и отказивање режима „само за читање“, постављање величине кеша за конкретну базу, као и неке важне функције (о њима можете сазнати у InterBase 6 Operations Guide [4.). gfix се покреће у режиму командне линије и има следећу синтаксу:

Gfix [ опције] име_базе

Опције - скуп опција за извршавање gfix-а, име_базе је име базе над којом ће се извршити операције, дефинисано скупом опција. Табела 3 представља опције gfix-а везане за поправку базе:


Опција	Опис
-f[ull]	Ова опција се користи у комбинацији са -v и значи да је време да се провере сви фрагменти записа
-i[gnore]	Опција чини да gfix игнорише грешке контролних сума при валидацији или чишћењу базе
-m[end]	Означава оштећене записе као недоступне, као резултат чега ће бити обрисани током наредног бекапа/рестаурације. Опција се користи у време припреме оштећене базе за б/р.
-n[o_update]	Опција се користи у комбинацији са -v за валидацију базе само за читање без исправљања оштећења
-pas[sword]	Опција омогућава постављање лозинке при повезивању на базу. (Имајте на уму да је ово грешка у InterBase документацији -pa[ssword], али пречица “-pa” неће радити - користите “-pas”)
-user	Опција омогућава постављање имена корисника који се повезује на базу
-v[alidate]	Опција која подешава валидацију базе на начин на који се откривају грешке
-m[ode]	Опција која поставља режим писања за базу - само за читање или читање/писање. Овај параметар може прихватити 2 вредности - read write или read only.
-w[rite] {sync \| async}	Опција која укључује и искључује режим синхроних/асинхроних принудних уписа у базу. sync - укључивање синхроних уписа (FW ON); async - укључивање асинхроних уписа (FW OFF);

Табела 1: Опције алата gfix за рестаурацију базе података

Постоје неки типични примери коришћења gfix-а:

gfix -w sync -user SYSDBA -pass masterkey firstbase.gdb

У овом примеру постављамо за нашу тест базу firstbase.gdb режим синхроних уписа (FW ON). (Наравно, корисно је пре него што дође до оштећења). А испод је прва команда коју треба користити за проверу базе након што дође до оштећења:

gfix -v -full -user SYSDBA -pass masterkey firstbase.gdb

У овом примеру покрећемо проверу наше тест базе (опција -v) и указујемо да се морају проверити и фрагменти записа (опција -full). Наравно, погодније је поставити различите опције за процес провере и рестаурације помоћу било ког GUI-ја, али ћемо размотрити функције опоравка базе помоћу алата командне линије. Ови алати су укључени у InterBase и можете бити сигурни да ће њихово понашање бити исто на свим ОС-има који покрећу InterBase. Веома је важно да увек буду при руци.

Поред тога, постојећи алати који омогућавају администрирање базе са клијентског рачунара користе Services API за то, који није подржан од стране InterBase сервера са Classic архитектуром. То значи да можете користити производе трећих страна са серверском архитектуром SuperServer.

2.9. Поправка оштећене базе података

Претпоставимо да постоје неке грешке у нашој бази. Прво морамо проверити постојање ових грешака; друго, морамо покушати да исправимо ове грешке. Треба да се придржавате следећих упутстава.

Треба да зауставите InterBase сервер ако још увек ради и направите копију фајла или фајлова базе. Све активности рестаурације треба извршити само са копијом базе, јер изабрани начин може довести до лошег резултата, и мораћете да поново покренете процедуру рестаурације (од почетне тачке). Након прављења копије извршићемо комплетну валидацију базе (проверу фрагмената записа).

За то треба да извршимо следећу команду:

gfix -v - full corruptbase gdb -user SYSDBA - password

У овом случају corruptbase.gdb - је копија оштећене базе. Команда ће проверити базу на било какво оштећење структуре и дати листу нерешених проблема. Ако се такве грешке открију, мораћемо да обришемо оштећене податке и припремимо се за бекап/рестаурацију користећи следећу команду:

gfix -mend -user SYSDBA -password your_masterkey corruptbase gdb

Након извршавања команде треба проверити да ли је остало грешака у бази. Морате покренути gfix са опцијама -v -full за то, и када процес заврши, извршити бекап базе:

gbak -b -v -ig -user SYSDBA -password corruptbase.gdb corruptbase.gbk

Ова команда ће извршити бекап базе (опција - b то указује) и добићемо детаљне информације о извршавању процеса бекапа (опција -v). Грешка у вези са контролним сумама ће бити игнорисана (опција - ig). Ако желите више информација о опцијама алата командне линије gbak, можете их наћи у поглављу „Бекап и рестаурација“. Ако постоје грешке са бекапом, треба га покренути у другој конфигурацији:

gbak -b -v -ig -g -user SYSDBA -password corruptbase.gdb

corruptbase.gbk

Где опција - g искључује сакупљање смећа током бекапа. То често помаже у решавању проблема са бекапом.

Такође је могуће направити бекап базе ако је пре тога поставимо у режим само за читање. Овај режим спречава упис било каквих измена у базу и понекад помаже у извршавању бекапа оштећене базе. За постављање базе у режим само за читање, треба користити следећу команду: gfix -m read _only

-user SYSDBA -password masterkey Disk:\Path\file.gdb

Након тога треба поново покушати извршити бекап базе користећи горе наведене параметре.

Ако је бекап успешно обављен, треба рестаурирати базу из бекап копије. Треба користити следећу команду:

gbak -c -user SYSDBA -password masterkey Disk:\Path\backup.gbk

Disk:\Path\newbase,gdb

Када рестаурирате базу, можете имати неке проблеме, посебно при креирању индекса. У овом случају опције -inactive и -one_at_a_time треба додати команди за рестаурацију. Ове опције деактивирају индексе при креирању из бекапа базе и потврђују податке за сваку табелу.

2.10. Како можете покушати да извучете податке из оштећене базе

Могуће је да горе наведене операције неће довести до опоравка базе.

То значи да је база података озбиљно оштећена или се не може обновити као јединствена целина, или је потребно уложити велики труд за њен опоравак. На пример, може се извршити модификација системских метаподатака, користити недокументоване функције и слично. То је веома тежак, дуготрајан и незахвалан посао са сумњивим изгледима за успех. И ако је могуће, покушајте да га избегнете и користите друге методе. Ако се оштећена база отвара и омогућава операције читања и модификације са неким подацима, требало би да искористите ту могућност и сачувате податке копирањем у нову базу, а стару заувек „испратите“.

Дакле, пре преноса података из старе базе, неопходно је креирати одредишну базу. Ако база није дуго мењана, можете користити стару резервну копију из које се могу извући метаподаци за креирање одредишне базе. На основу тих метаподатака треба креирати одредиште података и започети копирање података. Главни задатак је извући податке из оштећене базе. Затим ћемо морати да распоредимо податке у нову базу, али то није тешко, чак и ако морамо да обновимо структуру базе из сећања. Приликом извлачења података из табела, требало би да користите следећи алгоритам операција:

Прво треба покушати да извршите SELECT* из табеле N. Ако је прошло нормално, можете сачувати податке које сте добили у спољни извор. Боље је чувати податке у скрипти (скоро сви GUI-јеви дају ову функцију), само ако табела не садржи BLOB поља. Ако у табели постоје BLOB поља, онда податке из њих треба сачувати у другу базу помоћу клијентског програма који ће играти улогу посредника. Можда ћете морати да напишете овај тривијални програм посебно за потребе опоравка података.
Ако нисте успели да преузмете све податке, требало би да обришете све индексе и покушате поново. У ствари, индекси се могу обрисати из свих табела од почетка обнављања, јер више неће бити потребни. Наравно, ако немате структуру метаподатака, исту као оштећена, неопходно је унети протокол свих операција које радите са оштећеном изворном базом.
Ако не успевате да прочитате све податке из табеле након брисања индекса, можете покушати да урадите упит опсега по примарном кључу. То значи изабрати одређени опсег података. На пример:

SELECT * FROM table N WHERE field_PK >=0 and field_PK <=10000 Field_PK

овде је примарни кључ. InterBase има организацију података по страницама и зато упит опсега вредности може бити прилично ефикасан, иако делује као нека врста шаманизма. Ипак, то функционише јер можемо избацити податке из упита са оштећених страница и прочитати, на срећу, остале. Можете се подсетити наше тезе да не постоји дефинисан редослед чувања записа у SQL-у. Заиста, нико не гарантује да ће неуређени упит током поновног покретања вратити записе у истом редоследу, али ипак се физички записи чувају у бази у дефинисаном унутрашњем редоследу. Очигледно је да сервер неће мешати записе само да би се придржавао SQL стандарда. Можете покушати да искористите овај унутрашњи редослед за извлачење података из оштећене базе (ако желите да сазнате више информација о страницама података и њиховим корелацијама, погледајте поглавље „Структура InterBase базе података“).

Виталиј Бармин, један од искусних руских InterBase програмера, известио је да је на овај начин успео да обнови до 98% информација из неповратне базе (било је велики број оштећених страница). Дакле, подаци из оштећене базе морају се преместити у нову базу или у спољне изворе попут SQL скрипти. Када копирате податке, обратите пажњу на вредности генератора у оштећеној бази (оне морају бити сачуване за поновно покретање исправног рада у новој бази. Ако немате комплетну копију метаподатака, требало би да извучете текстове сачуваних процедура, окидача, ограничења и дефиниције индекса.

2.11. Обнављање безнадежне базе

Уопштено, обнављање базе може бити веома проблематично и тешко и зато је боље направити резервну копију базе него обнављати оштећене податке и шта год да се догоди, не би требало да очајавате јер се решење може наћи у најтежим ситуацијама. А сада ћемо размотрити 2 случаја.

Први случај (класичан проблем). Резервна копија која се не може обновити због NULL вредности у колони са ограничењима NOT NULL (процес обнављања је покренут над радном датотеком). Радна датотека је обрисана и процес обнављања је прекинут због грешке. И као резултат непромишљених радњи добили смо велики број бескорисних података (који се не могу обновити) уместо резервне копије. Али решење је пронађено. Програмер је успео да се сети која табела и која колона су имале ограничења NOT NULL. Датотека резервне копије је учитана у хексадецимални едитор. И комбинација бајтова, која одговара дефиницији ове колоне, пронађена је тамо претрагом. Након безбројних експеримената испоставило се да ограничење NOT NULL додаје 1 негде близу имена колоне. У HEX едитору ова „1“ је исправљена на „0“ и резервна копија је обновљена. Након тог случаја програмер је заувек запамтио како се извршава процес прављења резервне копије и обнављање.

Други случај. Ситуација је била катастрофална. База је оштећена у фази проширења због недостатка простора на диску. При повећању величине базе, сервер креира низ критично важних страница (на пример, страницу инвентара трансакција и страницу инвентара страница, додатне странице за релацију RDB$Pages) и уписује их на крај базе. Као резултат, база се није отварала ни административним алатима ни услужним програмом GBAK. И када смо покушали да се повежемо на базу, појавила се порука о грешци („Unexpected end of file“).

Када смо покренули услужни програм gfix, дешавале су се чудне ствари: програм је радио у бесконачној петљи. Док је gfix радио, сервер је уписивао грешке у дневник (датотеку InterBase log) великом брзином (око 100 Kb у секунди). Као резултат, датотека дневника је веома брзо попунила сав слободан простор на диску. Морали смо чак да напишемо програм који је брисао овај дневник по тајмеру. Овај процес је трајао дуго - gfix је радио више од 16 сати без икаквих резултата. Дневник је био испуњен грешкама следећег облика: „Page XXX doubly allocated“. У почетним InterBase изворима (у датотеци val.#) постоји кратак опис ове грешке. Каже се да се ова грешка појављује када се иста страница података користи два пута. Очигледно је да је ова грешка резултат оштећења критично важних страница.

Као резултат, након неколико дана неуспешних експеримената, напуштени су покушаји обнављања података на стандардне начине. И зато смо морали да користимо анализу на ниском нивоу података ускладиштених у оштећеној бази.

Александар Козелски, шеф одељења информационих технологија компаније East View Publications Inc, аутор је идеје како извући информације из сличних неповратних база.

Метод обнављања који смо добили као резултат истраживања заснован је на чињеници да база има организацију по страницама и да су подаци из сваке табеле сакупљени по страницама података. Свака страница података садржи идентификатор табеле за коју чува податке. Посебно је било важно обновити податке из неколико критичних табела. Постојали су подаци из сличних табела, добијени из старе резервне копије која је савршено радила и могла је бити образац. База-образац је учитана у едитор хексадецималних извора и затим смо тражили обрасце оних података који су нас занимали. Ови подаци су копирани у бафер у хексадецималном формату, а затим су остаци оштећене базе учитани у едитор. Секвенца бајтова која одговара обрасцу пронађена је у оштећеној бази, и страница је анализирана (на којој је ова секвенца пронађена).

Прво смо дефинисали почетну страницу, али то није било тешко јер је величина датотеке базе дељива са величином странице података. Број тренутног бајта подељен са величином странице - 8192 бајта, приближава резултат целом броју (и добија се број тренутне странице). Затим смо помножили број тренутне странице са величином странице и добили број бајта који одговара почетку тренутне странице. Након анализе заглавља, дефинисали смо тип странице (за странице са подацима тип је 5 - погледајте датотеку ods.h из скупа почетних InterBase извора, као и поглавље „Структура InterBase базе података“) као и идентификатор потребне табеле.

Затем была написана программа, которая анализировала всю базу данных, собирала все страницы необходимой таблицы в один единый фрагмент и перемещала его в файл.

Таким образом, когда мы получили нужные данные в первую очередь, мы начали анализировать содержимое выбранных страниц. InterBase широко использует сжатие данных для экономии места. Например, строка типа VARCHAR, содержащая строку «ABC», хранит последовательность следующих значений: длину строки (2 байта), в нашем случае это 0003, затем сами символы и контрольную сумму. Нам пришлось написать анализатор строк, а также других типов базы данных, который преобразовывал данные из шестнадцатеричного формата в обычный вид. Нам удалось извлечь до 80% информации из нескольких критических таблиц с помощью «ручного» метода анализа содержимого базы данных. Позже, на основе этого опыта, Олег Кульков и Алексей Ковязин, один из авторов этой книги, разработали утилиту InterBase Surgeon, которая выполняет прямой доступ к базе данных, минуя движок InterBase, и позволяет правильно читать и интерпретировать данные внутри базы данных InterBase.

С помощью InterBase Surgeon нам удается обнаруживать причины повреждений и восстанавливать до 90% абсолютно невосстановимых баз данных, которые не могут быть открыты InterBase и восстановлены стандартными методами.

Вы можете скачать эту программу с официального сайта программы www.ib-aid.com.

3. Благодарности

Я хотел бы выразить благодарность всем, кто помог мне создать это руководство:

Крейг Стунц, Александр Невский, Константин Сипачев, Татьяна Сипачева и все другие добрые и знающие люди из сообщества InterBase и Firebird.

Если у вас есть какие-либо предложения или вопросы по этой главе, пожалуйста, не стесняйтесь писать по электронной почте.