DB Sapces....
Hello Friends, I'm looking for the reasoning in deciding on how many DB Spaces to use on a given system. Specifically, if using a SAN where disk IO and LUN size isn't an issue, what would be the reason for using multiple DBSpaces as opposed to 1 large one? Also, is a 60/40 ration of data space to log space a valid one when sizing? I'm sure this is a pedestrian question for most of you, but I am currious. Tam.
Tam OShanter wrote: > Hello Friends, > > I'm looking for the reasoning in deciding on how many DB Spaces to use on a > given system. > > Specifically, if using a SAN where disk IO and LUN size isn't an issue, what > would be the reason for using multiple DBSpaces as opposed to 1 large one? > > > Also, is a 60/40 ration of data space to log space a valid one when sizing? > > I'm sure this is a pedestrian question for most of you, but I am currious. Improved parallelism when using PDQPRIORITY. Using multiple dbspaces/chunks will allow the engine to launch multiple threads. Unless you are using IDS 10.00+ (please specify version and platform in the future) you cannot take advantage of fragmentation to reduce search times in further increase parallelism. Also at checkpoint time dirty buffer flushing is handled by one flusher per dbspace. More dbspaces more flushers faster/shorter checkpoints. Art S. Kagel
On 09/11/06, Art S. Kagel <kagel@bloomberg.net> wrote: > Tam OShanter wrote: > > Hello Friends, > > > > I'm looking for the reasoning in deciding on how many DB Spaces to use on a > > given system. > > > > Specifically, if using a SAN where disk IO and LUN size isn't an issue, what > > would be the reason for using multiple DBSpaces as opposed to 1 large one? > > > > > > Also, is a 60/40 ration of data space to log space a valid one when sizing? > > > > I'm sure this is a pedestrian question for most of you, but I am currious. > > Improved parallelism when using PDQPRIORITY. Using multiple dbspaces/chunks > will allow the engine to launch multiple threads. > > Unless you are using IDS 10.00+ (please specify version and platform in the > future) you cannot take advantage of fragmentation to reduce search times in > further increase parallelism. > > Also at checkpoint time dirty buffer flushing is handled by one flusher per > dbspace. More dbspaces more flushers faster/shorter checkpoints. > > Art S. Kagel > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list > Multiple dbspaces can be spread across multiple spindles allowing separation of indexes from data. Separate spindles for logs also improve performance, espacially if they can be placed on fast disks. You need several logged and unlogged tempory spaces for sort/merge/indexing processes. Finally If you fill one big root dbspace you are stuffed. Fill a data dbspace but with space in root and you can continue Keith