Gjenoppretting av data og høy tilgjengelighet

Oversikt over reservekopiering

Legg merke til følgende begrensninger:

• Oppstart av en tilkoblet reservekopiering av en DMS-tabellplass er tillatt når en tabell i samme tabellområde blir omorganisert tilkoblet (online). Det kan oppstå lock wait-situasjoner for omorganiseringsoperasjonen i TRUNCATE-fasen.
• Oppstart av en tilkoblet reservekopiering av en SMS-tabellplass er ikke tillatt når en tabell i samme tabellområde blir omorganisert tilkoblet (online). Begge operasjonene krever en ekskluderende lås.

Bruke reservekopiering

Disse begrensningene gjelder for reservekopieringsfunksjonen:

• Det er ikke mulig å kjøre både en reservekopiering av en tabellplass og en gjenoppretting av en tabellplass samtidig, selv om det gjelder forskjellige tabellplasser.
• Hvis du vil ha mulighet til gjenoppretting ved fremlengs rulling i en partisjonert database, må du reservekopiere databasen på listen over noder jevnlig, og du må ha minst en reservekopi av resten av nodene i systemet (også de som ikke inneholder brukerdata for den databasen). Det er to situasjoner som krever reservekopien av en databasepartisjon på en databasepartisjonstjener som ikke inneholder brukerdata for databasen:
  • Du tilføyde en databasepartisjonstjener til databasesystemet etter den siste reservekopien som er tatt, og du må utføre en fremlengs gjenoppretting på denne databasepartisjonstjeneren.
  • Det er brukt gjenoppretting til et bestemt tidspunkt, noe som krever at alle databasepartisjoner i systemet har status "fremlengs rulling venter".
  • Tilkoblet reservekopiering for DMS-tabellplasser er ikke kompatibelt med disse operasjonene:
    • innlasting
    • Omorganisering (bare frakoblet); (tilkoblet omorganisering av en tabell i tabellplassen som blir reservekopiert kan brukes, selv om det kan forekomme venting på låser under avkuttingsfasen (truncate) av omorganiseringsoperasjonen).
    • sletting av tabellplass
    • avkutting av tabell
    • opprettelse av indeks
    • ikke logget opprinnelig (brukes sammen med CREATE TABLE- og ALTER TABLE-setningene)

Oversikt over High Availability Disaster Recovery (HADR)

Når du bruker kommandoene START HADR, STOP HADR eller TAKEOVER HADR, blir de tilhørende feilkodene kanskje generert: SQL01767N, SQL01769N eller SQL01770N med årsakskode 98. Årsakskoden viser at det ikke er installert lisens for HADR på tjeneren der kommandoen ble kjørt. Du løser problemet ved å installere en gyldig HADR-lisens ved hjelp av db2licm eller ved å installere en versjon av tjeneren som inneholder en gyldig HADR-lisens som en del av distribusjonen.

Støtte for reservekopiering og gjenoppretting på tvers av plattformer

DB2 Universal Database (UDB) har støtte for reservekopiering og gjenoppretting på tvers av plattformer.

Du kan gjenopprette DB2 UDB versjon 8-databaser som er opprettet på en 32-bits Windows-plattform, til DB2 UDB versjon 8 på en 64-bits Windows-plattform, og omvendt.

Du kan gjenopprette DB2 UDB versjon 8-databaser som er opprettet på en 32-bits Linux x86-plattform, til DB2 UDB versjon 8 på en 64-bits Linux x86-64- eller IA64-plattform, og omvendt.

Du kan gjenopprette DB2 UDB versjon 8-databaser som er opprettet på AIX, HP-UX, Linux PPC, Linux zSeries eller Solaris Operating Environment, 32-bits eller 64-bits, til DB2 UDB versjon 8 på AIX, HP-UX, Linux PPC, Linux zSeries eller Solaris Operating Environment (32-bits eller 64-bits).

Reservekopiere til magnetbånd (Linux)

Den maksimale blokkstørrelsen for magnetbåndenhetene 3480 og 3490 på Linux er 61 440 byte

Tivoli Storage Manager

Når du bruker kommandoene BACKUP DATABASE og RESTORE DATABASE kan du oppgi at du vil bruke produktet Tivoli Storage Manager (TSM) til å administrere reservekopiering og gjenoppretting av databaser og tabellplasser. Minimumskravet til nivå på TSM-klientens API er versjon 4.2.0, unntatt for:

• 64-bits Solaris-systemer, som krever TSM Client API versjon 4.2.1.
• 64-bits Windows NT-operativsystemer, som krever TSM Client API versjon 5.1.
• 32-bits Linux for iSeries og pSeries, som krever minimum TSM Client API versjon 5.1.5
• 64-bits Linux for iSeries og pSeries, som krever minimum TSM Client API versjon 5.3
• 64-bits Linux på AMD Opteron-systemer, som krever minimum TSM Client API versjon 5.2.0.
• 64-bits Linux for zSeries, som krever minimum TSM Client API versjon 5.2.2.

Verdibegrensninger for HADR-parameterne for lokal vert og lokal tjeneste

Når du oppgir verdier for HADR-parameterne for lokal vert og lokal tjeneste (HADR_LOCAL_SVC og HADR_REMOTE_SVC) mens du klargjør kommandoen update database configuration, må verdiene være porter som ikke blir brukt for andre tjenester. Hvis parameterne konfigureres på kommandolinjen i Linux eller UNIX, må verdiene også defineres i filen /etc/services.

Tilleggskrav til systemet for HADR (High Availability Disaster Recovery)

Hvis du oppretter en tabellplass på primærdatabasen og loggavspilling mislykkes på reservedatabasen fordi containerne ikke er tilgjengelige, mottar ikke primærdatabasen en feilmelding om at loggavspillingen mislyktes.

Hvis du skal kontrollere om det oppstår feil ved loggavspilling, må du overvåke db2diag.log og administrasjonsloggen på reservedatabasen når du oppretter nye tabellplasser.

Hvis en takeover-operasjon blir utført, vil ikke den nye tabellplassen du opprettet være tilgjengelig på den nye primærdatabasen. Du kan løse denne situasjonen ved å gjenopprette tabellplassen på den nye primærdatabasen fra en reservekopi.

I eksemplet nedenfor gjenopprettes tabellplassen MY_TABLESPACE på databasen MY_DATABASE før den blir brukt som ny primærdatabase:

1. db2 connect to my_database
2. db2 list tablespaces show detail
   Merk:
   Kjør kommandoen db2 list tablespaces show detail for å vise statusen til alle tabellplasser og for å skaffe ID-nummeret for tabellplassen som kreves i trinn 5.
3. db2 stop hadr on database my_database
4. db2 "restore database my_database tablespace (my_tablespace) online redirect"
5. db2 "set tablespace containers for my_tablespace_ID_# ignore rollforward container operations using (path '/my_new_container_path/')"
6. db2 "restore database my_database continue"
7. db2 rollforward database my_database to end of logs and stop tablespace "(my_tablespace)"
8. db2 start hadr on database my_database as primary

Ikke-replikerte operasjoner for HADR (High Availability Disaster Recovery)

I dokumentasjonen for versjon 8.2 står det:

BLOBs and CLOBs are not replicated; however, the space for them will be allocated on the standby database.

Det skal i stedet stå:

Non-logged BLOBs and CLOBs are not replicated; however, the space for them will be allocated on the standby database.

HADR støtter ikke ubehandlede logger

HADR (High Availability Disaster Recovery) støtter ikke bruk av ubehandlet I/U (direkte lagertilgang) for databaseloggfiler. Hvis HADR startes med kommandoen START HADR, eller hvis databasen startes på nytt med HADR konfigurert, og ubehandlede logger blitt oppdaget, vil den tilknyttede kommandoen mislykkes med SQL1768N årsakskode "9".

Sammenlikning av feilovervåker og helseovervåker

Helseovervåkeren og feilovervåkeren er verktøyer som brukes et en enkelt |databaseforekomst. Helseovervåkeren bruker helseindikatorer til å |evaluere helsen for bestemte aspekter ved databasesystemets ytelse eller en |databases ytelse. En helseindikator måler helsen for noen aspekter ved en |bestemt klasse med databaseobjekter, for eksempel en tabellplass. Helseindikatorer kan |evalueres mot bestemte kriterier for å fastslå helsen for den klassen av |databaseobjekter. I tillegg kan helseindikatorer generere varsler for å gi deg beskjed |når en indikator overskrider en terskel eller indikerer at et databaseobjekt er i en |unormal tilstand.

Til sammenlikning er feilovervåkeren alene ansvarlig for å sørge for at forekomsten den |overvåker, fungerer som den skal. Hvis DB2 UDB-forekomsten den overvåker, blir avbrutt, |starter feilovervåkeren den på nytt. Feilovervåkeren er ikke tilgjengelig i |Windows.

Slå av feilovervåking

Hvis du vil slå av feilovervåking for databaseforekomsten DB2INST1, skriver du denne |kommandoen fra et DB2 UDB-kommandovindu:

   db2fm -i db2inst1 -f no

Hvis du vil kontrollere at feilovervåkingen ikke lenger i gang for DB2INST1, skriver du |denne kommandoen på UNIX-systemer:

   ps -ef|grep -i fm

På Linux-systemer skriver du denne kommandoen:

   ps auxw|grep -i fm

En post som viser db2fmd og DB2INST1, indikerer at feilovervåkingen fremdeles |er aktiv på den forekomsten. Du slår av feilovervåkingen ved å skrive denne |kommandoen som forekomsteier:

   db2fm -i db2inst1 -D