Jeg har tidligere skrevet et par tip om at slette rækker hurtigt i DB2 tabeller. I den forbindelse overså jeg fuldstændig, at en DELETE FROM uden WHERE på en tabel i et såkaldt segmented tablespace går rasende stærkt. DB2 snyder og skriver kun en enkelt log-record uanset antallet af rækker i tabellen. Rækkerne markeres kun som slettet, men fjernes ikke. Men hvad er nu lige et segmented tablespace for en størrelse.
Faktisk har man kunnet lave segmented tablespaces lige så længe jeg kan huske, måske kom de med DB2 version 3 i starten af 1990'erne. De blev primært opfundet, fordi DB2 har det skidt med flere tabeller i samme tablespace, når tablespacet ikke er segmented, idet enhver tablespacescan er en scan af samtlige tabeller i tablespacet. Det er faktisk den primære grund til at stort set alle DB2 installationer kører med een tabel i hvert tablespace. Med segmented tablespaces scanner en tablespacescan kun selve tabellen.
Hvis man ønsker at definere mange tabeller i samme tablespace, så er der ingen vej uden om at lave et segmented tablespace. Eller hvis man ønsker at speede sin DELETE FROM uden WHERE clause op, så er segmented tablespaces vejen frem. Et segmented tablespace oprettes som et almindeligt tablespace, hvor man tilføjer parameteren SEGSIZE nn, hvor nn er et tal, der kan deles med 4, men nn må ikke være større end 64. Det store spørgsmål er nu, hvad man skal sætte nn til. nn angiver antallet af pages i hvert segment og alle rækker i samme segment tilhører samme tabel. Hvis tabellerne i tablespacet er små, så er en lille SEGSIZE et godt valg. Hvis de er store, så er en stor SEGSIZE et godt valg, og hvis de både er store og små, ja så er det først rigtig svært.
Man kan læse en masse om valg af SEGSIZE og dens betydning for sequential prefetch i Administration Guide. Min konklusion ovenpå alt læseriet er, at man er nødt til at vælge en SEGSIZE efter tabellernes størrelse og adskille store og små tabeller i hver sit segmented tablespace. Praktisk erfaring har også vist mig, at man under ingen omstændigheder skal vælge en stor SEGSIZE til små tabeller. Især ikke hvis man fastholder princippet om een tabel pr. tablespace. Så snart man angiver en SEGSIZE større end 8, så allokerer DB2 tablespacet på minimum 2 tracks, selv om man angiver PRIQTY som 48 eller mindre. Hvis SEGSIZE er oppe på 64, så snupper DB2 minimum 7 tracks. DB2 respekterer skam PRIQTY, så de ekstra tracks bliver skam allokeret efter størrelsen af SECQTY.
Man skal atså passe lidt på med disse segmented tablespaces. Men de har deres store fordele. Faktisk har diverse brugerorganisationer længe ønsket at man kan gøre sine partitioner segmented, netop for at kunne slette hurtigt, men det er ikke lykkes endnu, og det er vist heller ikke på trapperne i version 8.
Det mest kedelige ved segmented tablespaces er, at man ikke sådan lige kan ændre SEGSIZE. Man SKAL droppe og create for at ændre SEGSIZE. Og man kan ikke snyde en image copy med den gamle SEGSIZE ind i det nye tablespace med en anden SEGSIZE vha. DSN1COPY. Det har jeg prøvet. Derfor er det vigtigt at vælge den rigtige SEGSIZE fra starten, da den er besværlig at ændre bagefter.