Re: How can I create DBSCAPES in 20GB RAW partition

Billy Wheeler <billy@west.co.za> wrote in article <6ditb7$ti$1@news.xmission.com>... > > On 4 Mar 98 at 3:00, Raj Goel wrote: > > > I'm going through Carlton's ODS Handbook and there's something I > > don't quite understand. > > > > I've got a 20GB partition that I've reserved for my DBspaces. > > As I understand it, the maximum size dbspace I can create under > > Solaris 2.5.1/OWS 7.20 is 2GB. > > > > So, how do I go about creating the 10 DB spaces I need for my > > application? Or am I consigned to using cooked spaces? > > No, you can use the OFFSET to make 10 DBspaces in the partition. In > fact, I would advise that you rather make 10 chunks which you can > allocate to dbspaces at will. > > chunk 1: offset 0 size 2GB > chunk 2: offset 2GB size 2GB > chunk 3: offset 4GB size 2GB > chunk 4: offset 6GB size 2GB > . > . > . > chunk 9: offset 16GB size 2GB > chunk 10: offset 18GB size 2GB > > <snip> Unless things have been fixed, this will not work. Although Informix may let you allocate the chunks this way, it will in fact have a lot of trouble accessing anything past the first 2GB chunk. I'm not familiar with Solaris, but on AIX or HP/UX the way I have done this is to use logical volume manager to define a set of 2GB logical volumes. I then point informix at the raw logical volumes. In this way no offset is needed for Informix. The unfortunate side effect of this is that Informix will think of each chunk as a separate physical disk, perhaps page cleaning on more than one simultaneously. Since all of the chunks are actually on one disk, this hurts performance rather than helping it. If you allocate more than one dbspace using these chunks you can further shoot yourself in the foot if you are using PDQ and fragmented tables. In this case, Informix may use parallel scans, again thinking it has more than one physical disk to work with. Since the data is actually all on one disk this will cause a lot of extra seeks and make performance worse than a non-parallel scan. The moral of the story -- lots of little disks are better than a few (or one) large one. The only case where I would recommend using disks above 2GB each is in a development or test environment where you want a "cheap" way of being able to duplicate a large production database, or in "light" production enviornments where the database may be large, but the query load is light. Irwin Goldstein Objective Software Systems, Inc. http://www.objectsoft.com Remove anti-spam characters when replying via e-mail.