Aquest
document planteja les consideracions a fer i els passos a seguir per tal
d’utilitzar el sistema d’’After image’ ofert per PROGRESS.
Conceptes de seguretat en PROGRESS
Podem
dividir el sistema de seguretat en les bases de dades PROGRESS en tres nivells;
el bàsic i que es fa automàticament anomenat ‘before image’, el mitjà-alt
anomenat ‘after image’ i el més alt anomenat ‘Two phase commit’.
El sistema
‘before image’ protegeix de la pèrdua d’integritat de les dades en cas de
caiguda de la base de dades (apagada de llum del servidor o del client que
estava gravant dades en aquell moment, shutdown de la base de dades quan hi
havia usuaris treballant-hi, error de disc, etc.). El sistema actua en el
moment de tornar a connectar la base de dades (ja sigui en multi o mono-usuari)
i consisteix en què les transaccions que no estaven tancades en el moment de la
caiguda es restauren a la situació anterior a la seva obertura, havent, per
tant, de refer la feina de les transaccions obertes.
El sistema
‘after image’ ha d’actuar conjuntament amb el sistema de còpies de seguretat i
protegeix la base de dades de fallades físiques de la base de dades (errors de
disc, corrupció del fitxer, etc.). Si el disc on hi ha la base de dades falla,
la informació queda inaccessible. En aquest cas cal recuperar l’última còpia de
seguretat vàlida i passar el procés ‘roll-forward’ a partir dels fitxers
d’after image. És per aquesta raó que és fonamental que els fitxers d’’after
image’ resideixin en discos físics diferents i si és possible que estiguin
connectats a controladores diferents.
Un sistema
d’’after Image’ es basa en què cada transacció tancada contra una base de dades
es grava, realment, dues vegades; la primera en el fitxer de base de dades real
(db) i la segona (però simultània) en el fitxer d’’after image’ (ai). Aquest
mecanisme, per tant, incrementa substancialment la utilització de disc, tant
d’espai com d’entrades/sortides.
El sistema
de ‘Two phase commit’ actua d’àrbitre en un sistema de transaccions
distribuïdes, és a dir, on les dades que es modifiquen o es creen resideixen en
bases de dades diferents (noteu que parlem de bases de dades, no d’extensions
d’una base de dades multi-volum). Quan el sistema detecta que es vol tancar una
transacció que afecta a dues o més bases de dades, primer controla que cada una
d’elles doni el ‘OK’ de gravació i quan totes les bases de dades implicades han
contestat ‘OK’, el sistema llança l’ordre de gravació definitiva. Si una de les
bases de dades implicades no dóna l’OK, la transacció es desfà pel conjunt de
bases de dades, deixant, per tant, la informació completament íntegre. Si el
sistema, tot i tenir vàries bases de dades, no té transaccions distribuïdes,
podem prescindir d’aquest sistema, tot i que si s’activa l’’after image’ és
recomanable activar-lo.
Per poder
garantir la seguretat de les dades i alhora tenir el sistema permanentment
disponible als usuaris, hem de fer treballar cada una de les eines ofertes per
PROGRESS, tal i com presentem en el següent esquema:
-
Backup complet de la base de dades
regularment
-
Activar l’’after image’ immediatament
després de copiar la base de dades
-
Fer copia dels fitxers d’’after image’
quan esdevenen plens.
-
Fer backups on-line (incrementals o
totals) entremig del període de backup total.
Un sistema
d’’after image’ té tot el seu sentit si la base de dades no s’ha d’aturar mai, o almenys, no cal aturar-la per poder
fer les operacions amb els fitxers d’’after image’ (còpia, truncat, etc.).
PROGRESS ofereix en aquests casos la possibilitat de treballar amb un sistema
d’’after image’ multi-volum. Per què no calgui aturar la base de dades, cada un
dels volums ha de ser de longitud fixa. Això implica dues coses; que s’ha de
calcular molt acuradament la longitud de cada un dels volums i que s’ha de fer
una tasca extra d’administració d’aquests volums.
El sistema
es basa en què les transaccions que es puguin fer entre períodes de backup
puguin ser emmagatzemades en una – o vàries –
extensions de l’’after image’. Després de fer la còpia de la base de
dades, ordenarem a PROGRESS que comenci a gestionar l’’after image’ en el
següent ‘extent’ buit que tingui el sistema (per tant hem de controlar que n’hi
hagi algun en aquesta situació). Quan el sistema estigui treballant contra el
nou volum d’’after image’, copiarem a un medi segur (i diferent d’on hem copiat
la base de dades) el volum d’’after image’ que s’acaba de tancar. Una vegada
copiat, marcarem aquest volum com lliure per tal de preparar la situació per
quan tornem a necessitar l’extensió.
Tot i tenir
activats tots els sistemes exposats, en cas de ‘crash’ del sistema s’haurà de
procedir a recuperar les dades fent unes operacions o unes altres, depenent del
tipus de ‘crash’. Per veure aquestes diferents situacions, si us plau consulteu
el capítol 10 del manual ‘Administrator Guide’.
Consideracions a eines de còpia no-PROGRESS
1.
Per fer els backup diaris on-line només
es pot utilitzar la utilitat PROBKUP de PROGRESS
2.
Per fer els backups totals off-line,
podem utilitzar qualsevol eina. Si s’utilitza PROBKUP ella mateixa s’encarrega
de copiar tots els fitxers que formen part de la base de dades (.db, .bi, .lg i
tots els volums que s’hagin pogut definir).
3.
El sistema PROBKUP no copia els fitxers
d’’after image’, perquè han d’anar a un mitjà de còpia diferent que la base de
dades. Per tant, tot i fer PROBKUP cal copiar mitjançant la comanda externa
triada els fitxers d’’after image (.ai).
4.
Si es fa servir una eina no-PROGRESS
assegureu-vos que es copien tots aquests fitxers (*.dn, *.bn, *.lg, *.tl) per
la base de dades i (*.ai) per l’’after image’, i que havent acabat es marca la base de dades com copiada. Si això
últim no es fa, PROGRESS serà incapaç de poder fer un backup incremental,
perquè no sabrà quan es va fer l’última còpia i fer tant no podrà decidir
quines pàgines cal copiar.
Consideracions del sistema multi-volum
Recomanaríem
no definir una mida de volums exagerada per la mida de la base de dades. Això
pot implicar un temps de CPU extra i innecessari del motor de base de dades en
gestionar volums que en la pràctica restaran buits durant molt de temps, a més
d’incrementar el temps de còpia i de restauració.
Per tant si
la base de dades bruta té una mida de 3Gb, podem definir volums per un total de
5Gb.
Cada volum
el farem d’una mida d’entre 0.5Gb i 1Gb. Considerem que fer els volums més
petits repercuteix en un augment de la gestió de fitxers del sistema operatiu i
en una pèrdua de temps innecessari en gestionar tants ‘petits’ fitxers. És més
interessant, en quant a rendiment, tenir pocs volums però que estiguin en molts
discos físics diferents que tenir molts volums en pocs discos.