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.