![]() | |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
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 |
#3
| |||
| |||
|
|
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. |
#4
| |||
| |||
|
|
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 |
![]() |
| Thread Tools | |
| Display Modes | |
| |