IDS disk layout

Back in the bad old days, we put a lot of effort into attempting to balance the spindle load for SE databases, and to start with this practise has hung on with IDS databases. But is it really necessary now? We will be upgrading from 7.31 to (probably) 11.x, and it would be *so* easy just to have one huge dbspace for the application database (plus root dbspace, temp dbspace and so on). Is this a reasonable way to go now, performance-wise? It will certainly be easier to administer in terms of creating slices and so on, especially since we have a duplicate set on the development sever so adding a new slice on the live machine means adding one there as well.

Cats wrote: > Back in the bad old days, we put a lot of effort into attempting to > balance the spindle load for SE databases, and to start with this > practise has hung on with IDS databases. > > But is it really necessary now? We will be upgrading from 7.31 to > (probably) 11.x, and it would be *so* easy just to have one huge > dbspace for the application database (plus root dbspace, temp dbspace > and so on). Is this a reasonable way to go now, performance-wise? It > will certainly be easier to administer in terms of creating slices and > so on, especially since we have a duplicate set on the development > sever so adding a new slice on the live machine means adding one there > as well. I don't know much about SE but do know C-ISAM which I think is similar in this regard. We have also done performance tests on both IDS and C-ISAM applications. C-ISAM databases date from the days when RAID controllers were too expensive for many mid-range servers. Furthermore there were no cached reads or writes (buffers) beyond OS caching and maybe a small hard disc cache. Therefore disc performance is critical to these databases and solid state discs, more disc controllers, more disc, a better load balance, anything that improved disc performance helped greatly. As there was often no RAID balancing spindles had to be done manually. With IDS things are a little different. There are buffers, checkpoints, cached reads and writes, and large amounts of memory available in modern servers to facilitate these things. With IDS10 you can set DS_NONPDQ_MEM high to avoid temporary dbspaces more often. Therefore writing and especially reading from disc can be greatly reduced. We tried a solid state disc with our application (which is OLTP and write-intensive) with IDS and the performance lift was under 10%, which was very bad value for money given the high cost of solid state. It's worth pointing out that this small gain was against a RAID-10 set and fragment elimination and other tricks were in use in both cases. With our C-ISAM product the lift was enormous, I forget the exact figure now but 100% probably would be in the right ball park. I would expect any decent IDS installation these days to be using a RAID-10 array in which case you would simply let the RAID controller spread the load around the discs unless there was a good reason to do otherwise. In your case if you wanted to create one big dbspace on top of a RAID system performance would be just fine. If you don't have RAID then you will still get some benefit from a good balanced disc layout, it just isn't as critically important as it was. Regards, Ben.

> Cats wrote: >> Back in the bad old days, we put a lot of effort into attempting to >> balance the spindle load for SE databases, and to start with this >> practise has hung on with IDS databases. >> >> But is it really necessary now? > I would expect any decent IDS installation these days to be using a > RAID-10 array in which case you would simply let the RAID controller > spread the load around the discs unless there was a good reason to do > otherwise. In your case if you wanted to create one big dbspace on top of > a RAID system performance would be just fine. If you don't have RAID then > you will still get some benefit from a good balanced disc layout, it just > isn't as critically important as it was. Exactly.

my 2 0.01 i would not create a huge dbspace because of paralel backup and restores if something is bad in that dbspace you will have a long reload time.... so i would stick with a few(10+ ) not so big dbspaces.... Superboer. On 4 sep, 14:02, Ben Thompson <b...@nomonitorsoftspam.com> wrote: > Cats wrote: > > Back in the bad old days, we put a lot of effort into attempting to > > balance the spindle load for SE databases, and to start with this > > practise has hung on with IDS databases. > > > But is it really necessary now? We will be upgrading from 7.31 to > > (probably) 11.x, and it would be *so* easy just to have one huge > > dbspace for the application database (plus root dbspace, temp dbspace > > and so on). Is this a reasonable way to go now, performance-wise? It > > will certainly be easier to administer in terms of creating slices and > > so on, especially since we have a duplicate set on the development > > sever so adding a new slice on the live machine means adding one there > > as well. > > I don't know much about SE but do know C-ISAM which I think is similar > in this regard. We have also done performance tests on both IDS and > C-ISAM applications. > > C-ISAM databases date from the days when RAID controllers were too > expensive for many mid-range servers. Furthermore there were no cached > reads or writes (buffers) beyond OS caching and maybe a small hard disc > cache. Therefore disc performance is critical to these databases and > solid state discs, more disc controllers, more disc, a better load > balance, anything that improved disc performance helped greatly. As > there was often no RAID balancing spindles had to be done manually. > > With IDS things are a little different. There are buffers, checkpoints, > cached reads and writes, and large amounts of memory available in modern > servers to facilitate these things. With IDS10 you can set DS_NONPDQ_MEM > high to avoid temporary dbspaces more often. Therefore writing and > especially reading from disc can be greatly reduced. We tried a solid > state disc with our application (which is OLTP and write-intensive) with > IDS and the performance lift was under 10%, which was very bad value for > money given the high cost of solid state. It's worth pointing out that > this small gain was against a RAID-10 set and fragment elimination and > other tricks were in use in both cases. With our C-ISAM product the lift > was enormous, I forget the exact figure now but 100% probably would be > in the right ball park. > > I would expect any decent IDS installation these days to be using a > RAID-10 array in which case you would simply let the RAID controller > spread the load around the discs unless there was a good reason to do > otherwise. In your case if you wanted to create one big dbspace on top > of a RAID system performance would be just fine. If you don't have RAID > then you will still get some benefit from a good balanced disc layout, > it just isn't as critically important as it was. > > Regards, Ben.

On Sep 4, 1:31 pm, "Neil Truby" <neil.tr...@ardenta.com> wrote: > > Cats wrote: > >> Back in the bad old days, we put a lot of effort into attempting to > >> balance the spindle load for SE databases, and to start with this > >> practise has hung on with IDS databases. > > >> But is it really necessary now? > > I would expect any decent IDS installation these days to be using a > > RAID-10 array in which case you would simply let the RAID controller > > spread the load around the discs unless there was a good reason to do > > otherwise. In your case if you wanted to create one big dbspace on top of > > a RAID system performance would be just fine. If you don't have RAID then > > you will still get some benefit from a good balanced disc layout, it just > > isn't as critically important as it was. > > Exactly. So, in your view, given we have RAID 1+0 in a modern machine, there's no point in spending ages concocting a 'cool' disk layout? My own thinking was that while there is a great pile of data, it's a small proportion of it that's used most of the time and if we have lots of buffers, that is where it will get read from most of the time.

On Sep 4, 2:44 pm, Superboer <superbo...@t-online.de> wrote: > my 2 0.01 > > i would not create a huge dbspace because of paralel backup and > restores > > if something is bad in that dbspace you will have a long reload > time.... > so i would stick with a few(10+ ) not so big dbspaces.... > We have one database in one instance, and only every do a level 0 archive. Therefore we only every do a level 0 restore - and that has only happened once for the live system. So, to my way of thinking, we should be worrying about run-time performance as that is what it does early all the time. For doing a level 0 archive I can't see that loads of dbspaces is any better (faster) than one large one, but I could be wrong there.

"Cats" <ramwater@uk2.net> wrote in message news:1188920265.200963.86750@g4g2000hsf.googlegroups.com... > On Sep 4, 2:44 pm, Superboer <superbo...@t-online.de> wrote: >> my 2 0.01 >> >> i would not create a huge dbspace because of paralel backup and >> restores >> >> if something is bad in that dbspace you will have a long reload >> time.... >> so i would stick with a few(10+ ) not so big dbspaces.... >> > We have one database in one instance, and only every do a level 0 > archive. Therefore we only every do a level 0 restore - and that has > only happened once for the live system. So, to my way of thinking, we > should be worrying about run-time performance as that is what it does > early all the time. For doing a level 0 archive I can't see that > loads of dbspaces is any better (faster) than one large one, but I > could be wrong there. Well, you *may* be wrong! If you use ontape then you're reasoning is fine. But if you use onbar and a Storage Manager, or the provided ISM, you can use onbar to take parallel backups across dbspaces. To take full advantage of this you would need to spread your application across mutiple dbspaces and - provided you have multiple backup devices - these can be done in parallel.

On Sep 4, 8:14 pm, "Neil Truby" <neil.tr...@ardenta.com> wrote: > "Cats" <ramwa...@uk2.net> wrote in message > > news:1188920265.200963.86750@g4g2000hsf.googlegroups.com... > > > > > > > On Sep 4, 2:44 pm, Superboer <superbo...@t-online.de> wrote: > >> my 2 0.01 > > >> i would not create a huge dbspace because of paralel backup and > >> restores > > >> if something is bad in that dbspace you will have a long reload > >> time.... > >> so i would stick with a few(10+ ) not so big dbspaces.... > > > We have one database in one instance, and only every do a level 0 > > archive. Therefore we only every do a level 0 restore - and that has > > only happened once for the live system. So, to my way of thinking, we > > should be worrying about run-time performance as that is what it does > > early all the time. For doing a level 0 archive I can't see that > > loads of dbspaces is any better (faster) than one large one, but I > > could be wrong there. > > Well, you *may* be wrong! If you use ontape then you're reasoning is fine. > But if you use onbar and a Storage Manager, or the provided ISM, you can use > onbar to take parallel backups across dbspaces. To take full advantage of > this you would need to spread your application across mutiple dbspaces and - > provided you have multiple backup devices - these can be done in parallel. I am pretty sure that ontape is what's used as the IT department have never asked me about anything else!

"Cats" <ramwater@uk2.net> wrote in message news:1188940282.438318.30760@d55g2000hsg.googlegroups.com... > On Sep 4, 8:14 pm, "Neil Truby" <neil.tr...@ardenta.com> wrote: >> "Cats" <ramwa...@uk2.net> wrote in message >> >> news:1188920265.200963.86750@g4g2000hsf.googlegroups.com... >> >> >> >> >> >> > On Sep 4, 2:44 pm, Superboer <superbo...@t-online.de> wrote: >> >> my 2 0.01 >> >> >> i would not create a huge dbspace because of paralel backup and >> >> restores >> >> >> if something is bad in that dbspace you will have a long reload >> >> time.... >> >> so i would stick with a few(10+ ) not so big dbspaces.... >> >> > We have one database in one instance, and only every do a level 0 >> > archive. Therefore we only every do a level 0 restore - and that has >> > only happened once for the live system. So, to my way of thinking, we >> > should be worrying about run-time performance as that is what it does >> > early all the time. For doing a level 0 archive I can't see that >> > loads of dbspaces is any better (faster) than one large one, but I >> > could be wrong there. >> >> Well, you *may* be wrong! If you use ontape then you're reasoning is >> fine. >> But if you use onbar and a Storage Manager, or the provided ISM, you can >> use >> onbar to take parallel backups across dbspaces. To take full advantage >> of >> this you would need to spread your application across mutiple dbspaces >> and - >> provided you have multiple backup devices - these can be done in >> parallel. > > I am pretty sure that ontape is what's used as the IT department have > never asked me about anything else! Well parallel backups are an irrelevance then.

On 4 Sep, 22:41, "Neil Truby" <neil.tr...@ardenta.com> wrote: > "Cats" <ramwa...@uk2.net> wrote in message > > news:1188940282.438318.30760@d55g2000hsg.googlegroups.com... > > > > > > > On Sep 4, 8:14 pm, "Neil Truby" <neil.tr...@ardenta.com> wrote: > >> "Cats" <ramwa...@uk2.net> wrote in message > > >>news:1188920265.200963.86750@g4g2000hsf.googlegroups.com... > > >> > On Sep 4, 2:44 pm, Superboer <superbo...@t-online.de> wrote: > >> >> my 2 0.01 > > >> >> i would not create a huge dbspace because of paralel backup and > >> >> restores > > >> >> if something is bad in that dbspace you will have a long reload > >> >> time.... > >> >> so i would stick with a few(10+ ) not so big dbspaces.... > > >> > We have one database in one instance, and only every do a level 0 > >> > archive. Therefore we only every do a level 0 restore - and that has > >> > only happened once for the live system. So, to my way of thinking, we > >> > should be worrying about run-time performance as that is what it does > >> > early all the time. For doing a level 0 archive I can't see that > >> > loads of dbspaces is any better (faster) than one large one, but I > >> > could be wrong there. > > >> Well, you *may* be wrong! If you use ontape then you're reasoning is > >> fine. > >> But if you use onbar and a Storage Manager, or the provided ISM, you can > >> use > >> onbar to take parallel backups across dbspaces. To take full advantage > >> of > >> this you would need to spread your application across mutiple dbspaces > >> and - > >> provided you have multiple backup devices - these can be done in > >> parallel. > > > I am pretty sure that ontape is what's used as the IT department have > > never asked me about anything else! > > Well parallel backups are an irrelevance then.- Hide quoted text - > > - Show quoted text - However checkpoint times are not. With one dbspace you only get one thread submitting the writes for the checkpoint. On a top end HP Superdome with an XP12000 disk array capable of >500,000 i/os per second when loading100 million rows of data we were getting >5 minute checkpoints with an checkpoint interval of 5 minutes. Out of every 5 minutes we spent about 30 seconds loading and the rest checkpointing! We changed to >20 dbspaces and the checkpoint time went to a few seconds and instead of bursts of only one cpu being at 100% we had all cpus busy at checkpoint time. I would have several dbspaces just use larger devices now, maybe 8GB or 32GB.

Cats wrote: > So, in your view, given we have RAID 1+0 in a modern machine, there's > no point in spending ages concocting a 'cool' disk layout? My own > thinking was that while there is a great pile of data, it's a small > proportion of it that's used most of the time and if we have lots of > buffers, that is where it will get read from most of the time. You might want to consider fragmenting some of your data to get parallel operations and/or fragment elimination but with IDS10 this can be done within the same dbspace. Also as someone else has pointed out parallel backup and restore might be an issue. Ben.