MainframeSupports
tip uge 19/1999:

I sidste uge har vi erfaret, at DB2 ikke længere er uafhængig af CPU-tiden. Når DB2 bliver enablet for data sharing skifter DB2 fra at benytte RBA til at benytte LRSN i forbindelse med log og recovery. Det får den kedelige bivirkning, at DB2 ikke længere kan klare, at CPU-tiden går "baglæns".

CPU-tiden går typisk "baglæns" når man skifter fra sommertid til vintertid. Alle installationer, vi kender til, sørger for at holde sine CPU'er slukket eller ret inaktive i den time, så der ikke sker noget uforudset. Og det er også en god måde at gøre det på. I forbindelse med år2000-tests eksisterer denne mulighed bare ikke, når man skal stille CPU-tiden tilbage fra en gang i år 2000
til 1999. Her har DB2 vist sig at være ganske upåvirket, så længe man ikke kører med data sharing enablet.

Grunden til, at det går godt med RBA (relative byte adress) er, at RBA'er er uafhængige af tiden. Det er LRSN ikke. Faktisk er LRSN de første 6 bytes af STCK-formatet, også kendt som TOD (den der udløber engang i år 2047 eller 2048). DB2 gemmer LRSN dels på DB2-loggen, dels i SYSLGRNX og dels i sine tablespaces. Når DB2 vil logge ændringer til et tablespace danner den et LRSN og så tjekker den lige om det LRSN er dannet senere end det seneste LRSN i det tablespace, der ændres. Er det ikke tilfældet, antager DB2, at der er noget ret seriøst galt (f.eks. at "nogen" har pillet ved klokken) og man får en grim DB2-fejl på det pågældene tablespace.

Situationen kan reddes ved at køre en DSN1COPY, som er i stand til at nulstille RBA'er/LRSN'er på det pågældende tablespace. Når man går tilbage i tid i forbindelse med år2000-tests, så er der højst sandsynligt rigtig mange tablespaces, der skal igennem denne behandling. Derfor er det mest fornuftigt i stedet at restore en backup af hele sit DB2-system taget før det tidspunkt, man går tilbage til. Derved mister man selvfølgelig alle de ændringer, man har lagt på sit DB2-system efter denne backup. Og det er måske ikke altid det mest ønskværdige. År2000-test er ikke nemt.

Al balladen kan selvfølgelig undgås ved at køre DB2 uden data sharing enablet og der er faktisk beskrevet en fallback procedure i DB2-manualen om data sharing. Man kan for iøvrigt få et indtryk af problemets omfang (hvis man er uheldig) ved at kigge i SYSLGRNX. MainframeSupport har i anden anledning udviklet et værktøj, der gør det muligt at benytte informationerne i SYSLGRNX, og det vil vi gerne stille til andres rådighed. Ring eller skriv.

Sidste uges tip        Tip oversigten