SEO

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.googlegrou ps.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.googlegrou ps.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.googlegro ups.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.googlegrou ps.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.googlegro ups.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.googlegr oups.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.