Med DB2 følger en række såkaldte DB2 stand alone utilities. Disse utilities er kendetegnet ved, at de kan køre selv om DB2 er nede. De opererer direkte på de VSAM-datasets, som DB2 baserer sig på. En af disse utilities hedder DSN1COPY og kan blandt andet bruges til at restore et tablespace ud fra en DB2 image copy. Faktisk kan man restore en image copy i et hvilket som helst DB2 tablespace. Det vil virke under forudsætning af, at definitionerne af det pågældende tablespace og tilhørende tabeller svarer til det tablespace, image copy'en oprindeligt blev taget af.

Dette tip vil udelukkende omhandle brugen af DSN1COPY til at restore en image copy i et andet tablespace end det oprindelige. Jeg vil forudsætte, at tablespacet ikke er partitioneret, at det kun indeholder een tabel og, at det er en full image copy, der bliver restoret. Jeg vil også forudsætte, at navnet på det dataset, der indeholder image copy'en er blevet fundet i SYSIBM.SYSCOPY. Før man overhovedet kaster sig ud at eksekvere DSN1COPY er der også andre ting, der skal være opfyldt:

• Man skal vide, hvad VSAM-datasettet hedder, som indeholder tablespacet.
• Man skal have ALTER-adgang til det pågældende VSAM-dataset.
• Man skal udstede en STOP af tablespacet.

Man skal selvfølgelig også have noget JCL. Det kan eksempelvis se således ud:

//DSN1COPY EXEC PGM=DSN1COPY,PARM='FULLCOPY,OBIDXLAT,RESET'
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD DISP=SHR,DSN=MIN.IMAGE.COPY
//SYSUT2   DD DISP=OLD,DSN=MIT.DSNDBC.DBNAME.TSNAME.I0001.A001
//SYSXLAT  DD *
1,27
1,15
1,16
/*

Parameteren FULLCOPY angiver, at datasettet MIN.IMAGE.COPY er en full image copy. OBIDXLAT angiver, at vi ønsker at restore i et andet tablespace end det oprindelige og RESET angiver, at diverse LOG informationer bliver nulstillet. Det er nødvendigt, når vi restorer i et andet tablespace end det oprindelige. DD-navnet SYSUT2 angiver navnet på det VSAM-dataset, som indeholder selve tablespacet. SYSXLAT indeholder i første linie to DBID'er adskilt af et komma. I anden linie er det to PSID'er og i sidste linie er det to OBID'er. Det første ID (source) skal svare til det ID, som image copy'en har. Det andet ID (target) skal svare til det som tablespacet skal have. Target ID'erne kan findes vha. følgende SQL-kald, som udstedes mod det DB2-subsystem, som tabelspacet er defineret i:

SELECT TS.DBID, TS.PSID, TB.OBID
FROM SYSIBM.SYSTABLESPACE TS, SYSIBM.SYSTABLES TB
WHERE TS.DBNAME = 'DBNAME'
  AND TS.NAME = 'TSNAME'
  AND TS.DBID = TB.DBID
  AND TS.DBNAME = TB.DBNAME
  AND TS.NAME = TB.TSNAME
  AND TB.TYPE = 'T'

Hvis dette SQL-kald returnerer mere end een række, så indeholder tablespacet mere end een tabel. Betingelsen TS.DBID = TB.DBID kan virke overflødig, men den modvirker en tablespacescan på SYSTABLES, der ikke har index på DBNAME, TSNAME (med mindre din installation har defineret et). I JCL eksemplet har SQL-kaldet returneret DBID=27, PSID=15 og OBID=16. Vi er nu klar til at køre vores DSN1COPY step. Fidusen er, at vi ikke behøver at kende source-ID'erne, da DSN1COPY fejler, hvis de ikke svarer overens med dem i image copy datasettet, og derfor udskriver det rigtige ID på SYSPRINT. Det kræver tre eksekveringer af DSN1COPY før alle tre source-ID'er er fundet. For hver eksekvering tilrettes 1-tallet til det korrekte ID i den rigtige linie. Når alle tre linier i SYSXLAT er rettet til, så vil DSN1COPY foretage kopieringen fra image copy'en over i table spacet.

Efter endt eksekvering af DSN1COPY skal man gøre to ting før table spacet med tilhørende tabeller og indexes kan benyttes igen. Man skal først og fremmest starte tablespacet igen. Herefter skal man køre en RECOVER af indexerne, for ellers er de totalt ubrugelige, da de peger på rækker, der hørte hjemme i tablespacet før det blev overskrevet. Og hvis man vil kunne lave normal recovery på tablespacet, så er det også en god ide at tage en full image copy.

Det kan godt være, at man får en masse underlige fejl, når man prøver at benytte tabellen i tablespacet efterfølgende. Så er det, fordi der er en eller anden forskel på definitionerne i det oprindelige tablespace, hvor image copy'en kom fra i forhold til det tablespace, som image copy'en har overskrevet. Kontroller, at begge tablespaces har samme SEGSIZE og samme COMPRESSION. Kontroller, at der kun er een tabel i begge tablespaces, og at disse tabeller har samme kolonnedefinitioner i samme rækkefølge. Eksempelvis kan image copy'en være taget på et tidspunkt, hvor kolonnerne så anderledes ud.

Hvis du er nået så langt i læsningen af dette tip som hertil, er det nok gået op for dig, at man skal passe rigtig godt på, når man bruger DSN1COPY. Man kan komme til at lave de frygteligste ulykker og opleve, at DB2 siger mærkelige ting, som ikke fortæller dig noget som helst om, hvad der i virkeligheden gik galt. Du kan i øvrigt læse mere om DSN1COPY i DB2-manualen Utility Guide and Reference.