Re: Stripe and Mirror Everything?

Thank you for your comments. >For the database as a whole - undoubtedly. However, if any single >table reaches a certain size, it becomes to big to fit into a single >dbspace (under 9.40). You must then fragment the table, and (under >9.40 and earlier), each fragment must go into a separate dbspa I guess I need to go hit the docs... Are you saying that a non-fragmented table can not fill the dbspace in which it was created? So, lets say I have a 72GB dbspace, consisting of a single 72GB chunk. What is the larges table I can put in it? Thank you. > However, the more practical difficulty on non-RAID systems is that you > can usually only partition a disk into 8 partitions - one of which is > the whole disk. So, if you had an 18 GB disk, you could create 7x2GB > partitions for use by IDS, but the remaining 4GB was useless (2 GB if > you were very careful). People objected to being unable to use large > percentages of their disk drives. If large chunks hadn't come along, we would have tried to use Veritas or DiskSuite. But, I guess fewer layers is better. By the way (sidebar)... I've always treated slice 2 as just another slice. If I was running short of partitions, and needed another one, I just used slice 2 for whatever set of cylinders I wanted-- just like any other slice. Was/am I actually jeopardizing anything? We are comfortable accepting the limitation of <4TB chunk. :-) >assume you lay the partitions out with the > whole drive starting at offset 0 (of necessity), Was I needlessly concerned to always make sure I avoided incorporating any cylinder 0 into a raw device (to avoid overwriting VTOC). Maybe the devices "know" to avoid the VTOC, and I didn't really have to worry?? Thanks again for your helpful thoughts. DG