> From what I remember of Oracle's "basic" backup tool (and I haven't
> had much to do with it since 8.1.6) you have to put tablespaces
> (equivalent to our dbspaces) into "backup mode" before you can back
> them up which means they can't be written to. It's also typical to do

This is a myth.

Backup mode doesn't stall any writes to the tablespaces - you can perfectly
do all of the read/write operations on a tablespace in backup mode just as
on a tablesace not in backup mode. Oracle just may do some additional redo
logging if necessary to guarantee the consistency of the database.

This has worked such way since version 7, maybe even before...

Tanel.

Niall Litchfield wrote:

> "Andrew Hamm" <ahamm@mail.com> wrote in message
> news:c5ksg3$2p91m$1@ID-79573.news.uni-berlin.de...
>> Further (with Informix, once again) the engine can use KAIO, and with the
>> architecture of Informix, this can lead to further significant
> improvements.
>> It all adds up. Why do you think F1 now make their pedals out of carbon
>> fibre? And they *still* drill 'em out for extra lightness. An Informix
>> engine using raw with KAIO and a decent layout of spaces on the disk can
>> feel very spiffy indeed even compared to one that merely drops KAIO and
> raw.
>
> A dangerous analogy, the formula 1 one. An F1 Car is made to last a
> weekend - used to be a race - and to be rebuilt after that. This is not a
> desirable* thing in a database. Robustness and reliability are important
> as well as performance - probably more so.

I am thinking extra performance for no loss relaibility is also good, no?
KAIO not make database less relaible.

--
Enor

"Paul Watson" <paul@oninit.com> wrote in message
news:407D3202.E6E8B0A4@oninit.com...

> > Absolutely not. Cache access is faster. And it has nothing to do
> > with fs or raw I/O. You get EXACTLY the same speed regardless
> > of where you got the data from.
> [cutting]
>
> But if the cache is too small or being turned over very quickly the
> cache will be slower 'cos you to copy from disk to cache and then
> copy from cache to the app.

Disagree. The cache access from a given db process will still be at the same
speed: it's a memory-to-memory copy, the cache size means nothing in that
context.

Of course, the db processes MAY have to wait for real I/O to fill up the cache.
But that doesn't mean "the cache is slower".



> Interestingly on the bigger Sun servers the absolute bandwidth to
> disk is significantly larger than the bandwidth to memory so, in
> theory, you can the data from disk faster than from memory - I remain
> unconvinced:-)

Yup!
I'd guess what they mean is the overall *aggregate* I/O bandwidth is
faster than memory access speed. This because in some of the 64 CPU boxes,
it may actually be quite slower for a given CPU to access memory belonging
to another CPU quad card. While the I/O speed stays the same as it goes
directly to each quad CPU/memory card as requested.

Still, a strange claim by any standard. I've worked with a 64CPU ES10K Sun
and its I/O speed for single disk access was nothing to write home about...

--
Cheers
Nuno Souto
wizofoz2k@yahoo.com.au.nospam

"Niall Litchfield" <niall.litchfield@dial.pipex.com> wrote in message news:<407e22ba$0$16835$cc9e4d1f@news-text.dial.pipex.com>...
> "Andrew Hamm" <ahamm@mail.com> wrote in message
> news:c5ksg3$2p91m$1@ID-79573.news.uni-berlin.de...
> > Further (with Informix, once again) the engine can use KAIO, and with the
> > architecture of Informix, this can lead to further significant
> improvements.
> > It all adds up. Why do you think F1 now make their pedals out of carbon
> > fibre? And they *still* drill 'em out for extra lightness. An Informix
> > engine using raw with KAIO and a decent layout of spaces on the disk can
> > feel very spiffy indeed even compared to one that merely drops KAIO and
> raw.
>
> A dangerous analogy, the formula 1 one. An F1 Car is made to last a
> weekend - used to be a race - and to be rebuilt after that. This is not a
> desirable* thing in a database. Robustness and reliability are important as
> well as performance - probably more so.

Good point, Niall (especially the *). I think the better analogy
might be fuel injection v. carburetors. Better performance AND gas
mileage AND reliability eventually takes over the consumer market and
the racing market (with some notable exceptions). So if raw is a
nearly-free 20% performance gain, especially during month-end serial
processing when people with purse strings are tapping their fingers on
their desks, then it's likely to take over. And in a way it is, with
the newfangled filesystems. But managing raw filesystems manually is
like mulitple carburetors - great performance if you have the right
tools, risky if you don't. Ever hear a six-carb V12? Hooo-mama.

>
>
> --
> Niall Litchfield
> Oracle DBA
> Audit Commission UK
> http://www.niall.litchfield.dial.pipex.com
> *****************************************
> Please include version and platform
> and SQL where applicable
> It makes life easier and increases the
> likelihood of a good answer
> ******************************************
>
> *actually it is desirable in one situation - when running a TPC or similar
> benchmark. Again you engineer the product to last pretty much for the life
> of the performance test and sacrifice everything else for speed.

jg
--
@home.com is bogus.
http://www.forbes.com/2002/08/13/0813vow.html