Adathelyreállítás és megbízható elérhetőség

Biztonsági mentés áttekintése

Vegye figyelembe a következő korlátozásokat:

• Egy DMS táblaterület online biztonsági mentési műveletének indítása megengedett, ha ugyanazon táblaterület egy táblájának újraszervezése online módon folyik. A csonkolási fázisban lehet, hogy az újraszervezési művelet zárolására kell várakozni.
• Egy SMS táblaterület online biztonsági mentési műveletének indítása nem engedélyezett, ha ugyanazon táblaterület egy táblájának újraszervezése online módon folyik. Mindkét művelet kizárólagos zárolást igényel.

Biztonsági mentés használata

A következő korlátozások vonatkoznak a biztonsági mentés segédprogramjára:

• Táblaterület biztonsági mentési és helyreállítási művelete nem futtatható egyszerre, még akkor sem, ha különböző táblaterületeket érint.
• Ha előregörgető helyreállítást kíván végezni egy particionált adatbázis környezetben, rendszeresen el kell menteni az adatbázist a csomópontok listájára, és legalább egy biztonsági mentési képfájllal kell rendelkeznie a rendszer többi csomópontjáról (még azokról is, amelyek nem tartalmaznak felhasználói adatokat az adatbázishoz). Két eset követeli meg az adatbázis-partíció biztonsági mentési képfájlját az adatbázishoz felhasználói adatokat nem tartalmazó adatbázis partíció kiszolgálón:
  • Egy adatbázis partíció kiszolgálót vett fel az adatbázisrendszerbe az utolsó biztonsági mentés után, és ezen az adatbázis partíció kiszolgálón előregörgetéses helyreállítást kell végezni.
  • A visszaállítás az időpont alapján lehetőséget használja, amelyhez az szükséges, hogy a rendszer minden adatbázis-partíciója előregörgetés szükséges állapotban legyen.
  • A DMS táblaterületek online biztonsági mentési műveletei nem kompatibilisek a következő műveletekkel:
    • betöltés
    • újraszervezés (csak offline); (az éppen elmentett táblaterület egy táblájának online újraszervezése használható, habár előfordulhat, hogy az újraszervezési művelet csonkolási szakasza során várakozni kell a zárolásra).
    • táblaterület eldobása
    • tábla csonkolása
    • index létrehozása
    • kezdetben nem naplózott (a CREATE TABLE és ALTER TABLE utasításokkal használva)

Magas rendelkezésre állású, katasztrófa utáni helyreállítás áttekintése

START HADR, STOP HADR vagy TAKEOVER HADR parancs végrehajtásakor a rendszer létrehozhatja a vonatkozó hibakódokat: SQL01767N, SQL01769N vagy SQL01770N, 98-as okkód mellett. Az okkód azt jelzi, hogy a HADR nem rendelkezik telepített licenccel azon a kiszolgálón, melyen a parancs futtatása történt. A hiba javításához telepítsen érvényes HADR licencet a db2licm parancs segítségével vagy telepítse a kiszolgáló egy olyan verzióját, melynek kiadása rendelkezik érvényes HADR licenccel.

Platformok közötti biztonsági mentés és visszaállítás támogatása

A DB2 Universal Database (UDB) támogatja a különböző platformok közti biztonsági mentés és visszaállítási műveleteket.

Visszaállíthatók 32 bites Windows platformon futó, 8-as verziójú DB2 UDB rendszeren létrehozott adatbázisok 64 bites Windows platformon futó, 8-as verziójú DB2 UDB rendszerre, illetve ugyanez a másik irányban is lehetséges.

Visszaállíthatók a 32 bites Linux x86 platformon futó, 8-as verziójú DB2 UDB rendszeren létrehozott adatbázisok 64 bites Linux x86-64 vagy IA64 platformon futó, 8-as verziójú DB2 UDB rendszerre, illetve ugyanez a másik irányban is lehetséges.

Lehetőség van továbbá 8-as verziójú DB2 UDB programmal AIX, HP-UX, Linux PPC, Linux zSeries vagy Solaris Operating Environment (32 vagy 64 bites) platformon létrehozott adatbázis visszaállítására 8-as verziójú DB2 UDB rendszerre, mely AIX, HP-UX, Linux PPC, Linux zSeries vagy Solaris Operating Environment (32 vagy 64 bites) platformon fut.

Biztonsági mentés szalagra (Linux)

Linux rendszeren a 3480-as és 3490-es szalagos eszköz esetében a maximális blokkméret 61 440 bájt.

Tivoli Storage Manager

A BACKUP DATABASE vagy a RESTORE DATABASE parancs meghívásakor megadhatja, hogy a Tivoli Storage Manager (TSM) terméket kívánja használni az adatbázis vagy a táblaterület biztonsági mentés vagy visszaállítási műveletének kezeléséhez. A TSM ügyfél API minimálisan szükséges szintje: 4.2.0-s verzió, kivéve az alábbi rendszereket:

• 64 bites Solaris rendszerek, melyek a TSM ügyfél API 4.2.1-es vagy újabb verzióját követelik meg.
• 64 bites Windows NT operációs rendszerek, melyeknél 5.1-es TSM ügyfél API szükséges
• 32 bites Linux for iSeries and pSeries, amely a TSM ügyfél API 5.1.5-ös vagy újabb verzióját követeli meg.
• 64 bites Linux for iSeries and pSeries, amely legalább a TSM ügyfél API 5.3-as verzióját követeli meg.
• 64 bites Linux AMD Opteron rendszerek, melyek a TSM ügyfél API 5.2.0-ás vagy újabb verzióját követelik meg.
• 64 bites Linux for zSeries rendszerek, melyek esetében a TSM ügyfél API 5.2.2-es vagy újabb verziója szükséges.

Értékkorlátozások a HADR helyi gazdagép és helyi szolgáltatás paraméterekhez

Amikor értéket ad meg a HADR helyi gazdagép és helyi szolgáltatás paramétereknek (HADR_LOCAL_SVC és HADR_REMOTE_SVC) egy update database configuration parancs előkészítése során, az értékeknek olyan portokat kell jelenteniük, amelyeket semmilyen más szolgáltatás nem használ. Ha a paraméterek konfigurálása a Linux vagy UNIX parancssor segítségével történik, az értékeket meg kell adni az /etc/services fájlban is.

További rendszerkövetelmények a HADR-hez

Ha létrehoz egy táblaterületet az elsődleges adatbázison és a készenléti adatbázison meghiúsul a naplóismétlés, mert a konténerek nem elérhetők, az elsődleges adatbázis nem kap a naplóismétlés sikertelenségéről tájékoztató hibaüzenetet.

A naplóismétlési hibákat úgy ellenőrizheti, hogy az új táblaterületek létrehozása során figyeli a db2diag.log fájlt és az adminisztrációs naplót a készenléti adatbázison.

Ha átvételi művelet történik, a létrehozott új táblaterület nem elérhető az új elsődleges adatbázison. Ezt a helyzetet úgy lehet megoldani, hogy a táblaterületet visszaállítja az új adatbázison egy biztonsági mentési képfájlból.

Az alábbi példában a TABLATERÜLET táblaterület visszaállításra kerül az ADATBAZIS adatbázison, még mielőtt azt új elsődleges adatbázisként használná:

1. db2 connect to adatbazis
2. db2 list tablespaces show detail
   Megjegyzés:
   A db2 list tablespaces show detail parancsot azért kell kiadni, hogy megjelenjen az összes táblaterület állapota, és leolvashassa a táblaterület azonosító számát, amelyre az 5. lépésben lesz majd szükség.
3. db2 stop hadr on database adatbazis
4. db2 "restore database adatbazis tablespace (tablaterulet) online redirect"
5. db2 "set tablespace containers for tablaterulet_azonosito_# ignore rollforward container operations using (path '/uj_tarolo_utvonala/')"
6. db2 "restore database adatbazis continue"
7. db2 rollforward database adatbazis to end of logs and stop tablespace "(tablaterulet)"
8. db2 start hadr on database adatbazis as primary

Nem többszörözött műveletek HADR-hez

A 8.2-es verzió dokumentációjában ez szerepel:

A BLOB-ok és CLOB-ok nem kerülnek többszörözésre, a terület azonban le lesz foglalva számukra a készenléti adatbázison.

Ez a mondta helyesen így hangzik:

A nem naplózott BLOB-ok és CLOB-ok nem kerülnek többszörözésre, a terület azonban le lesz foglalva számukra a készenléti adatbázison.

HADR nem támogatja a nyers naplókat

A HADR nem támogatja a nyers I/O műveleteket (közvetlen lemezelérést) az adatbázis naplófájljainál. Ha a HADR elindul a START HADR parancs hatására vagy az adatbázist újraindítják a HADR konfigurálásával, és a rendszer nyers naplókat talál, a társított parancs sikertelen lesz (SQL1768N okkód:"9").

Hibamegfigyelés és állapotmegfigyelés összehasonlítása

Az állapotmegfigyelés és a hibamegfigyelés egyedülálló adatbázis |példányokon működő eszközök. Az állapotmegfigyelés |állapotjelzéseket használ az adatbáziskezelő |teljesítmény vagy az adatbázis teljesítmény bizonyos szempontjainak |kiértékelésére. Az állapotjelzés méri bizonyos adatbázisobjektum |osztályok egyes szempontjait, például a táblázatterületet. Az |állapotjelzéseket adott feltételek ellen lehet kiértékelni, az adatbázis |objektum osztály egészségének (állapotának) meghatározására. Az állapotjelzések ezen kívül |figyelmeztetéseket is előállíthatnak, hogy értesítéseket küldhessenek, |amikor egy jelzés túllépi a küszöbértéket, vagy ha egy adatbázis objektum |állapota eltér a normálistól.

Összehasonlítva ezzel, a hibamegfigyelés csak a megfigyelt és futtatott |egyedért felelős. Ha a megfigyelt DB2 UDB egyed váratlanul befejeződik, |akkor a hibamegfigyelés újraindítja az egyedet. A hibamegfigyelés Windows |rendszeren nem elérhető.

Hibamegfigyelés kikapcsolása

A DB2INST1 adatbázis példány hibamegfigyelésének kikapcsolásához írja |be az alábbi parancsot a DB2 UDB parancsablakban:

   db2fm -i db2inst1 -f no

Annak megerősítésére, hogy a DB2INST1 hibamegfigyelése már nem fut, írja |be az alábbi parancsot UNIX rendszeren:

   ps -ef|grep -i fm

Linux rendszeren írja be a következő parancsot:

   ps auxw|grep -i fm

A db2fmd és DB2INST1 egyedeket megjelenítő bejegyzés jelzi, hogy a |hibamegfigyelés még mindig fut azon a példányon. A hibamegfigyelés |kikapcsolásához a példány tulajdonosaként írja be a következő parancsot:

   db2fm -i db2inst1 -D