dbTalk Databases Forums  

Number of dbspaces

comp.databases.informix comp.databases.informix


Discuss Number of dbspaces in the comp.databases.informix forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Peternt
 
Posts: n/a

Default Number of dbspaces - 11-03-2010 , 06:04 PM






Hi,

I have a database of 250 GB of user data. How many dbspaces is
suitable for optimal performance:
- For OLTP transactions ?
- For queries ?
- For backup using onbar ?
Currently, I have 30 dbspaces configured.
Is there any strategy or tip that I can use?

Please, provide any information according your experience.
Thanks in advance

Peter

Reply With Quote
  #2  
Old   
Art Kagel
 
Posts: n/a

Default Re: Number of dbspaces - 11-03-2010 , 06:23 PM






More important than dbspaces are the underlying disk structures. You need
to keep the rootdb space independent of the physical log, the physical log
independent of the logical logs, the logical logs independent of the high
access tables, high access tables apart from each other and from their
indexes, etc. If it's all on the same SAN array, it really doesn't matter
that much.

That said, if you are using dbspaces for fragmenting tables to take
advantage of more parallelism or less contention during massive updates,
then the more dbspaces the better up to the limits of the parallelism you
can muster on your machine. So if you only have a single 1GHZ CPU core you
won't get much parallel processing done compared to a 4GHZ 256 core
machine..

All in life and databases is balance. There are no hard and fast rules.
Your workload and equipment will be the deciding factors in determining the
optimum configuration. Personally, given my preferences, I want to
configure a machine with as many CPU cores as I can cram into the box and
attach as many small drive spindles as I can. Give me a machine with 128
cores and 256 disk drives and I'll build you a database box that will
SCREAM! Alas, I mostly get to deal with 3 cores and a SAN with a single
array built from 6 2TB drives that's being shared with a bunch of Windows7
filesystems.

Art

Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
IIUG Board of Directors (art (AT) iiug (DOT) org)
Blog: http://informix-myview.blogspot.com/

Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
organization with which I am associated either explicitly, implicitly, or by
inference. Neither do those opinions reflect those of other individuals
affiliated with any entity with which I am affiliated nor those of the
entities themselves.



On Wed, Nov 3, 2010 at 8:04 PM, Peternt <roger_vilca (AT) yahoo (DOT) es> wrote:

Quote:
Hi,

I have a database of 250 GB of user data. How many dbspaces is
suitable for optimal performance:
- For OLTP transactions ?
- For queries ?
- For backup using onbar ?
Currently, I have 30 dbspaces configured.
Is there any strategy or tip that I can use?

Please, provide any information according your experience.
Thanks in advance

Peter
_______________________________________________
Informix-list mailing list
Informix-list (AT) iiug (DOT) org
http://www.iiug.org/mailman/listinfo/informix-list

Reply With Quote
  #3  
Old   
John Carlson
 
Posts: n/a

Default Re: Number of dbspaces - 11-08-2010 , 05:57 PM



On 11/3/2010 8:23 PM, Art Kagel wrote:
Quote:
More important than dbspaces are the underlying disk structures. You
need to keep the rootdb space independent of the physical log, the
physical log independent of the logical logs, the logical logs
independent of the high access tables, high access tables apart from
each other and from their indexes, etc. If it's all on the same SAN
array, it really doesn't matter that much.

That said, if you are using dbspaces for fragmenting tables to take
advantage of more parallelism or less contention during massive updates,
then the more dbspaces the better up to the limits of the parallelism
you can muster on your machine. So if you only have a single 1GHZ CPU
core you won't get much parallel processing done compared to a 4GHZ 256
core machine..

All in life and databases is balance. There are no hard and fast
rules. Your workload and equipment will be the deciding factors in
determining the optimum configuration. Personally, given my
preferences, I want to configure a machine with as many CPU cores as I
can cram into the box and attach as many small drive spindles as I can.
Give me a machine with 128 cores and 256 disk drives and I'll build you
a database box that will SCREAM! Alas, I mostly get to deal with 3
cores and a SAN with a single array built from 6 2TB drives that's being
shared with a bunch of Windows7 filesystems.

And the screaming is of a different type?

JWC

Reply With Quote
  #4  
Old   
Art Kagel
 
Posts: n/a

Default Re: Number of dbspaces - 11-08-2010 , 06:46 PM



Fewer spindles, less screaming.

Art

Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
IIUG Board of Directors (art (AT) iiug (DOT) org)
Blog: http://informix-myview.blogspot.com/

Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
organization with which I am associated either explicitly, implicitly, or by
inference. Neither do those opinions reflect those of other individuals
affiliated with any entity with which I am affiliated nor those of the
entities themselves.



On Mon, Nov 8, 2010 at 6:57 PM, John Carlson
<jwcarlson1 (AT) yahoo (DOT) com.invalid>wrote:

Quote:
On 11/3/2010 8:23 PM, Art Kagel wrote:
More important than dbspaces are the underlying disk structures. You
need to keep the rootdb space independent of the physical log, the
physical log independent of the logical logs, the logical logs
independent of the high access tables, high access tables apart from
each other and from their indexes, etc. If it's all on the same SAN
array, it really doesn't matter that much.

That said, if you are using dbspaces for fragmenting tables to take
advantage of more parallelism or less contention during massive updates,
then the more dbspaces the better up to the limits of the parallelism
you can muster on your machine. So if you only have a single 1GHZ CPU
core you won't get much parallel processing done compared to a 4GHZ 256
core machine..

All in life and databases is balance. There are no hard and fast
rules. Your workload and equipment will be the deciding factors in
determining the optimum configuration. Personally, given my
preferences, I want to configure a machine with as many CPU cores as I
can cram into the box and attach as many small drive spindles as I can.
Give me a machine with 128 cores and 256 disk drives and I'll build you
a database box that will SCREAM! Alas, I mostly get to deal with 3
cores and a SAN with a single array built from 6 2TB drives that's being
shared with a bunch of Windows7 filesystems.


And the screaming is of a different type?

JWC
_______________________________________________
Informix-list mailing list
Informix-list (AT) iiug (DOT) org
http://www.iiug.org/mailman/listinfo/informix-list

Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.