C
ChUIMonster
Guest
Extent size is not related to -B or bitness. Nor does the db server need to use 32 bit executables just because clients use 32 bit DLLs. The db server can easily be 64 bits and you can leave the clients in the dark ages until the coders attain enlightenment. For such a small database I would strongly recommend that you use a single variable extent for each area. IOW: # b c:\dbs\mecsa # d "Schema Area":6,64;1 c:\dbs\mecsa # d "admin":7,256;8 c:\dbs\mecsa # d "contab":8,256;8 c:\dbs\mecsa ...and so on This will be much easier to manage. Fewer files and no need to monitor extent fullness and add new ones. That will be much more useful for a developer copy of a db. I also strongly dis-recommend the practice of creating areas based on "function" (admin etc...). Areas should be based on the technical attributes of the data that they contain. Attributes such as "data", "indexes", "LOBs", rows per block, size, and activity level. For a simple, small db you probably just need "data" and "indexes". If your application uses CLOBs or BLOBs then you ought to also create a "lob" area. These days I don't start thinking about using fixed extents until I start seeing variable extents larger than 32GB. You can argue that when extents get too big that you're making certain recovery operations more difficult than they would be with smaller extents (for instance, anything that requires scanning an extent will take longer). Note: There is a hard limit of 1TB for an extent -- so you can't quite go with "always use variable no matter what" even if you do think that it is the best idea since pre-sliced bread. Note 2: I'm assuming that "and so on..." obviously includes after-image extents.
Continue reading...
Continue reading...