Den simpleste og sikreste måde at slette alle rækker i en DB2-tabel på er med SQL-kaldet DELETE FROM <tabel>. Da sikkerheden skal være i top, så tager det også tid. Er man i den heldige situation, at den tabel, der skal have slettet alle sine rækker, har sit helt eget tablespace, så kan man bruge LOAD-utility'en til at slette med.

Det kan kun betale sig at benytte LOAD, når tabellen indeholder mange rækker. Afhængig af rækkelængden vil jeg tro, at et sted mellem 50.000 og 500.000 rækker berettiger brugen af LOAD. Følgende step viser, hvordan det gøres:

//DELETE   EXEC PGM=DSNUTILB,REGION=6M,
//         PARM='DB2,LOAD.EMPTY'
//SYSIN    DD *
   LOAD LOG NO REPLACE REUSE
   ENFORCE NO SORTDEVT SYSDA SORTNUM 6
   INTO TABLE MY.TABLE
/*
//SYSPRINT DD SYSOUT=*
//UTPRINT  DD SYSOUT=*
//SYSREC   DD DSN=MY.LOAD.DATA,DISP=SHR
//SYSUT1   DD UNIT=VIO,SPACE=(TRK,(1,1))
//SORTOUT  DD UNIT=VIO,SPACE=(TRK,(1,1))

Dette step fjerner samtlige rækker fra det tablespace, som MY.TABLE findes i. Det er derfor, at metoden kun må anvendes for tablespaces med kun een tabel i. Parameteren REUSE kan undværes og virker for iøvrigt ikke altid i DB2 version 5, da det afhænger af hvilket PTF-level, man har opgraderet DB2 til. REUSE bevirker, at den normale DELETE/DEFINE af VSAM-datasettet, som tablespacet findes i, springes over. I stedet laver DB2 en reset af VSAM-datasettet.

Man kan faktisk med ovennævnte metode slette en enkelt partition i et tablespace. Det giver endnu en forbedring i forhold til tippet i uge 23. Men igen, det er kun en god ide, hvis samtlige rækker i partitionen skal slettes.

Bemærk for iøvrigt, at tabellen vil stå i COPYPENDING status efter LOAD'en. Man skal altså efterfølgende enten fjerne COPYPENDING status (det mest hensigtsmæssige i et testmiljø) eller tage en IMAGECOPY (det mest hensigtsmæssige i produktionsøjemed). Hvis der er defineret referential integrity (RI) på tabellen, så vil nogen andre tabeller sandsynlig stå i CHECKPENDING, og det skal der også gøres noget ved.