Ellenőrzés és javítás
A kérdések, a fejlesztők létre kell hozni a kliens-szerver alkalmazások az Firebird adatbázis, amely a fejlesztés adatbázisok Borland Interbase 6 Áttekintést ad a fogalmak és modellek a kliens / szerver architektúra, valamint gyakorlati tanácsokat dolgozik a kliens könyvtárat Firebird. Jellemzők részletesen SQL adattípusok adatkezelési nyelvet (Adatkezelő nyelv, DML), valamint a szintaxis és az adatok meghatározása nyelv (Data Definition Language, DDL). Nagy figyelmet fordítanak a leírás a tranzakciók és tanácsokat ad ezek alkalmazása alkalmazások fejlesztését. Leírt programozás a kliens oldalon, és a szerver írásban kiváltó és tárolt eljárások létrehozása és használata adatbázis események, hibakezelés a kódot a szerveren, és még sok más. Az anyagot számos példa, tipp és gyakorlati javaslat kíséri.
Adatbázisfejlesztők számára
Könyv: Firebird DATABASE DEVELOPER'S GUIDE
Ellenőrzés és javítás
Ezen az oldalon található részek a következők:
Ellenőrzés és javítás
A Firebird segédprogramokat biztosít az adatbázis logikai struktúráinak ellenőrzésére és kisebb problémák azonosítására, valamint néhány javításra. Sok ilyen hiba előfordulhat időről időre, különösen olyan környezetben, ahol a hálózat instabil vagy zajos, vagy az áramellátás instabil. A felhasználó viselkedése, valamint az alkalmazás vagy az adatbázis kialakításában fellépő hibák gyakran logikus zavarokhoz vezetnek.
Az ügyfélkapcsolatok rendellenes megszüntetése nem érinti az adatbázis integritását, mivel a Firebird kiszolgáló ellenőrzi a kapcsolat elvesztését. Ez megmenti a megerősített adatok változásait, és visszaállítja az összes olyan adatot, amelyre a megerősítés folyamatban van. A takarítás fontos karbantartási probléma, mivel a nem megerősített adatokhoz rendelt adatlapok "árva" formájában maradnak. Az ellenőrzés azonosítja az ilyen oldalakat és kiadja azokat későbbi felhasználásra.
Az érvényesítési eszközök azonosítják és kiküszöbölik azokat az apró rendellenességeket, amelyek az operációs rendszer vagy a hardverhibák következményei. Az ilyen hibák általában adatbázis-integritással kapcsolatos problémákhoz vezetnek, amelyek az adatok adatlapokra vagy adatlapok vagy indexek elvesztésére vezethetők vissza.
Mikor kell ellenőrizni az érvényességet és miért
Az időszakos érvényesítésnek az adatbázis-kezelő karbantartási tevékenységének részét kell képeznie a lemezterület újbóli használatával kapcsolatos apró rendellenességek azonosításában és kiküszöbölésében. Ez akkor is szükséges, ha strukturális károkat azonosítanak vagy gyanítják, hogy jelen vannak. A tünetek a következők:
* "korrupt adatbázis" vagy "konzisztencia ellenőrzés" hibák;
* a szünetmentes tápegység (UPS) hiányában vagy az UPS meghibásodásának feltételezése esetén a tápfeszültség meghibásodása vagy megváltoztatása;
* A rendszer várható vagy bejelentett rendszerhibája a merevlemezen, a hálózaton vagy a memóriában;
* az árnyékmásolat az adatbázis megsemmisítése után helyettesíti az adatbázist;
* Az adatbázist áthelyezték egy másik platformról vagy tárolórendszerről;
* Várható jogosulatlan hozzáférés a hálózathoz vagy adatbázishoz külső támadásokkal szemben.
A gfix használatának az adatbázis-hitelesítés végrehajtására vonatkozó részleteit lásd a 39. fejezetben.
Mi a teendő a törött adatbázissal?
Ha gyanítja, hogy adatbázisát megsemmisítették, fontos, hogy kövesse a helyreállítási lépések helyes sorrendjét, hogy megakadályozza a további megsemmisítést. Az első és legfontosabb dolog az összes felhasználó kikapcsolása és az adatbázisból való leválasztása.
A 4. melléklet részletes leírást tartalmaz a megsemmisített adatbázis javítására vonatkozó eljárásokról.
Hogyan lehet megsemmisíteni a Firebird adatbázisát?
A rendszertáblák módosítása
A Firebird tárolja és karbantartja az összes metaadatot és a felhasználó által definiált objektumokat. Firebird adatbázis! Pontosabban, azokat a kapcsolatokban (táblázatokban) közvetlenül az adatbázisban tárolja. A rendszertáblák, azok oszlopai és más típusú rendszertárgyak azonosítói az "RDB $" szimbólumokkal kezdődnek.
Mivel ezek közönséges adatbázis objektumok, ezek lekérdezhetők és manipulálhatók felhasználó által definiált objektumokként. Azonban, amit tudsz. nem jelenti azt, hogy kellene.
Nem javasolhatja, hogy csak a DDL-operátorokat használja - közvetett SQL műveletek a rendszertáblákon -, amikor módosítani vagy törölni kell a metaadatokat. A "közvetlen változások" elhalasztása addig, amíg az SQL készségek és a Firebird kiszolgáló ismeretei teljesebbé válnak. A baleseti adatbázis sem kellemes elmélkedésnek, sem könnyű javításnak nem minősül.
A Firebird 1.0.x-ben való kényszerített írása a Windows rendszerben
A Firebird alapértelmezés szerint telepítve van az írási képességgel (szinkron írással). Megváltozott és új adatok íródnak a lemezre közvetlenül a művelet befejezése után (post).
Lehetőség van egy adatbázis konfigurálására az aszinkron adatírás megváltoztatásakor, vagy az új adatok tárolása a gyorsítótárban és az operációs rendszer I / O alrendszere által periodikusan lemásolt lemezre. Az ilyen konfiguráció általános feltétele a kényszerbevitel törlése. Néha ezt az értéket visszaállítják a nagy tételes műveletek teljesítményének javítására.
A Win32 platformszerver nem ment a Firebird 1.0.x kiszolgáló gyorsítótárba a lemezen, amíg a Firebird szolgáltatás nem zárul le. Nem is beszélve az áramkimaradásról, sok olyan dolog van, ami rossz a Windows szerverénél. Ha összeomlik, akkor az I / O rendszer leáll, és a felhasználó munkája elveszik az újraindítás során.
Ehhez a gyakorlatban javasoljuk, hogy helyreállítsa az adatbázist biztonsági mentési lemezterületre a gbak -c [reate] használatával. Mielőtt a visszaállított adatbázis aktív lenne, ellenőrizze a tartalékterületen az isql vagy az előnyben részesített rendszergazdai eszközt.
Lehetővé teszi a felhasználók számára, hogy csatlakozzanak az adatbázishoz a visszaállítási folyamat során
Ha a szervezete szeretne élni a kés éle, használja -visszaállítás kapcsoló, és lehetővé teszi a felhasználóknak, hogy csatlakozni az adatbázishoz, és változtatni. A visszaállítási folyamat létrehoz egy adatbázist a föld alap, és amint létre egy táblázatot, akkor a felhasználók képesek lesznek (legalábbis potenciálisan, vagy ha mégis minden SYSDBA) hivatkozni rájuk a műveletek a DML, míg referenciális integritás és egyéb korlátozások is a megközelítésről. A legjobb, kapnak egy kivételt, és sok meg nem erősített tranzakciók részben épített adatbázisban. Legrosszabb esetben teljesen tönkre a az adatok sértetlenségét.