Dear Informixers,

I'm about to install IDS 10 on a shiny new server running under SuSE Linux
Enterprise Server 10 (SP1). The predecessor machine had IDS 7.31 under SuSE
7.2, so I was restricted to 2GB chunk size.

There are about 20 different databases, many of them rather small and
infrequently used. The total size of all the databases together is
about 4GB, which is of course tiny compared to what many of the pros in this
group are used to ;-) , but also makes it unnecessary to squeeze the last
bit of performance out of the server since even our 7-year-old machine
performs rather well, and the new one has MUCH more power.

My question is about disk layout: Should I bother splitting up the available
disk space in to several dbspaces and separate the more heavily used databases
into different spaces, or might I just as well throw them all together into
one big data space? Of course I will separate root-dbspace from the rest,
but is there any reasonable benefit from creating several chunks/dbspaces
for the data?

BTW: I'm using ontape to disk for backup. Under 7.31, the ability to
restore individual dbspaces was something I considered important. With
arcchecker's ability to restore even individual tables, this seems less
so.

What are your suggestions?

Regards, Richard

On Jan 16, 6:16 pm, Richard Spitz <Richard.Sp...@med.uni-muenchen.de>
wrote:
> Dear Informixers,
>
> I'm about to install IDS 10 on a shiny new server running under SuSE Linux
> Enterprise Server 10 (SP1). The predecessor machine had IDS 7.31 under SuSE
> 7.2, so I was restricted to 2GB chunk size.
>
> There are about 20 different databases, many of them rather small and
> infrequently used. The total size of all the databases together is
> about 4GB, which is of course tiny compared to what many of the pros in this
> group are used to ;-) , but also makes it unnecessary to squeeze the last
> bit of performance out of the server since even our 7-year-old machine
> performs rather well, and the new one has MUCH more power.
>
> My question is about disk layout: Should I bother splitting up the available
> disk space in to several dbspaces and separate the more heavily used databases
> into different spaces, or might I just as well throw them all together into
> one big data space? Of course I will separate root-dbspace from the rest,
> but is there any reasonable benefit from creating several chunks/dbspaces
> for the data?
>
> BTW: I'm using ontape to disk for backup. Under 7.31, the ability to
> restore individual dbspaces was something I considered important. With
> arcchecker's ability to restore even individual tables, this seems less
> so.
>
> What are your suggestions?
>
> Regards, Richard


You may consider to separate more heavily used databases to dbspaces
ON DIFFERENT DISKS, if that is possible (you didn't mention what is
your disk configuration). Also, logs should be located on separate
disk(s), especially if write activity is substantial.

If you don't have any external backups, it is good to have backups on
separate disks from database, to lessen the risk of losing the data
completely.

Darko Krstic

Richard Spitz wrote:
> Dear Informixers,
>
> I'm about to install IDS 10 on a shiny new server running under SuSE Linux
> Enterprise Server 10 (SP1). The predecessor machine had IDS 7.31 under SuSE
> 7.2, so I was restricted to 2GB chunk size.
>
> There are about 20 different databases, many of them rather small and
> infrequently used. The total size of all the databases together is
> about 4GB, which is of course tiny compared to what many of the pros in this
> group are used to ;-) , but also makes it unnecessary to squeeze the last
> bit of performance out of the server since even our 7-year-old machine
> performs rather well, and the new one has MUCH more power.
>
> My question is about disk layout: Should I bother splitting up the available
> disk space in to several dbspaces and separate the more heavily used databases
> into different spaces, or might I just as well throw them all together into
> one big data space? Of course I will separate root-dbspace from the rest,
> but is there any reasonable benefit from creating several chunks/dbspaces
> for the data?
>

I would just for the ease of managing the disk space of each DB
separately. You don't mention the disk farm layout. If you are using a
single massive SAN for all of the space (hopefully not RAID5 ;-) then
there's no performance difference to how you break up the disk space in
the engine with one exception. Keep in mind that at checkpoint time
dirty disk is cleaned chunk by chunk with CLEANERS number of chunks
flushed in parallel. The more chunks you have the more parallelism to
those flushes and the shorter your checkpoint durations will be. Within
the busiest databases separating volatile tables into separate dbspaces
will also enhance checkpoint performance. All this assumes that you are
not swamping the IO channels or the disk structures or disks themselves.

Art S. Kagel
Oninit
> BTW: I'm using ontape to disk for backup. Under 7.31, the ability to
> restore individual dbspaces was something I considered important. With
> arcchecker's ability to restore even individual tables, this seems less
> so.
>
> What are your suggestions?
>
> Regards, Richard
>


================================================== =========================================
Please access the attached hyperlink for an important electronic communications disclaimer:

http://www.oninit.com/home/disclaimer.php

================================================== =========================================