<My humble opinions>
100+ extents for tablespace is not good idea because you can reach the
limit. No perceptible performance degradation could be observed however.
Ad 1. Yes, VTOC space depends on extents! But this is "weak dependence",
that means 1-3 extents occupy one VTOC block, next extents if available
occupy another VTOC block. In other words 100+ extents dataset occupy
the same VTOC space as 4 extent dataset.
Caution: VTOC space has very little to do with performance. We have VTOCIX.
Ad 2. AFAIK it is recorded in CATALOG, but in VVDS not BCS. However
information about extents is read/written during open/close/update. It
doesn't hurt, especially for DB2 tablespaces.
--
Radoslaw Skorupka
Lodz, Poland
Max Scarpa wrote:
Esteemed listers
I was asked by many people about extents in DB2 tablespace. From
literature and a wide number of observation in many shops I see that now
with modern disk systems it doesn't matter anymore and it's stated in many
papers,articles etc..
I saw big tablespace with 100+ extents working very well in disks were
VTOC and ICF catalogs were defined in many ways. I never detected any
degradation or problem i.e. I never saw and had (I worked and I work as a
storage manager as well) had a VTOC full or ICF catalog suffering the fact
there are many DB2 datasets with a lot of extents (as they are recorded in
VTOC and catalog entries) . I never saw any wait on catalog due to too
many extents (I saw other kinds of waits).
Recently I was blamed that all is wrong for the following reasons:
1) 'Too information on VTOC due to extents. This could create problems.'
- Actually I never saw a VTOC full error for this reason, only for many
small datasets generated by particular products that created a huge
number of VTOC entries. Or for VTOCs really small or defined in a very
bad manner. I mean that the critical factor is the number of dataset, not
extents.
2) ' Catalog can suffer as they have to register all extents.' - Never
seen it as well. I saw some other probems but no one was due to extents
number registered in the catalog.
I'd have expected some doubts on extents chain search or something else.
The person didn't mentioned VVDS as well It seems to me that the previous
are arguments like define VTOC in the 'middle' of a disk or using
imbed/replicate of some years ago.
Anyway, Is there anyone out there who had problems due to 1) and/or 2)
reasons ?
--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl
Sd Rejonowy dla m. st. Warszawy
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego,
nr rejestru przedsibiorców KRS 0000025237
NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w caoci
opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego
podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003
r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528
z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
