473,883 Members | 1,750 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

The old raw devices chestnut.

Note the cross-posting - but no flame wars please.

This question was prompted by a thread on the a postgres mailing list
during which someone (Gregory Williamson) claimed

<quote>
raw devices, at least on Solaris, are about 10 times as fast as cooked
file systems for Informix.
<quote>

This made me think about the old arguments, and I wondered about the
current state of thinking. Some of my knowledge will be a bit out of
date.

Oracle: (my main experience)
At various times Oracle have claimed (talking to consultants, not
marketers) that raw devices are 5-20% faster than filesystems. This may
vary on the current state of the oracle code and/or the filesystem being
compared against. Veritas seem to agree by producing QuickIO for Oracle,
claiming "performanc e of raw with the management of filesystem".

I have never been sufficiently convinced to implement a major system
with raw.

Sybase: (some experience)
Sybase claim filesystems are faster, because of OS buffering, but unsafe
for the same reason. They only ever suggest filesystem for tempdb. They
don't seem to have heard of fsync()[1]

DB2:
No idea

Informix:
No idea beyond the claim which started this off.

What is the latest thinking, both in terms of vendor claims and
practical experience?

[1] or whatever system call forces write-through caching
--
Jim Smith
Because of their persistent net abuse, I ignore mail from
these domains (among others) .yahoo.com .hotmail.com .kr .cn .tw
For an explanation see <http://www.jimsmith.de mon.co.uk/spam>
Nov 12 '05
42 4707
rkusenet wrote:
"Data Goob" <da******@hotma il.com> wrote
One other thing you might find attractive to plain ole files
instead of raw devices is the ability to clone databases. You
can get quite creative with plain files in ways that you cannot
with raw devices because of the lock-in of raw-devices.

Please elaborate.

If you use symbolic links for raw devices, then there is no lock-in
of raw devices, or am I missing something.


I don't think so. Even with cooked files I'd be using symlinks; you never
know when you need to put a lump onto another file system. Speaking only
Informixly here, I can clone a live engine with symlinks and a simple
procedure, and only a temporary outage to bounce the parent engine, so once
again I don't see any administrative dramas with raw spaces. I think I just
need to shrug and move on; nobody seems to have concrete facts to backup the
claim. [about to reply to Data Goobs original message on that one - there's
something in there that hints at something.]

Also different engines will have different issues, so we've got to keep a
careful distance from any specific engine on this cross-posted thread.
Further, talking about restores rather than raw devices is straying a bit
too far from the thread.
Nov 12 '05 #21
Data Goob wrote:
Andrew,

Fair enough considerations, and you hit the point on
the head, the backup and restore.

We have always set up backup of logs and data to a real
backup, but considering all the options I might 'need'
in the event of system failure, or migration, or cloning,
raw devices are an added risk. We use a third-party backup
tool to backup our SQL-Server databases, as well as EMC
Timefinder to flash-copy databases into production environments.
We will apply the same methods with DB2 or MySQL for that
matter. The raw-disk paradigm adds only extra trouble/work.
OK - so you are talking about SQL-Server and various issues related to a
backup tool you use? If so, we have no argument; I know nothing of your
tools, and am speaking from an Informix + UNIX point of view. Our beloved
symlinks on UNIX are not available to NT servers, so suggestions on this
cannot help. I'm also of the opinion (only from reading) that unbuffered
NTFS files are equivalent in performance and reliability to raw spaces on
NT:

Even with Informix on NT (of which i have almost no experience) symlinks are
not available, and further, the recommendations from Informix states that
you can use normal files (O/S buffered and capable of going onto FAT), or
normal files on NTFS (which will be used unbuffered) or a raw partition on
NT. Further, the documentation says that on NT, the use of unbuffered NTFS
files is of equal performance to NT raw spaces, therefore it's not worth
using raw spaces on NT. But that's NT, something I don't play with.
The real question is, how will you backup, much less restore
raw device databases? Are you prepared to deal with the
inflexibility it presents? Have you ever run Informix or
other vendor database through a complete backup and restore,
testing all the options with raw-device dbspaces?
Absolutely. Sometimes under great duress. The use of raw spaces has always
made the restores faster too. Jonathan Leffler (c.d.i stalwart and Informix
Insider) has disputed the claim someone made that raw can be 5-10 TIMES
faster, and I have to agree on that. Except for two points [once again,
Informix+UNIX specific]:

1) during initialisation of an instance, if you initialise on cooked files,
the creation of the dbspaces and especially the physical and logical logs
takes an insufferable length of time. With raw spaces, creation of an engine
is quite a few times faster. That means a great deal in the middle of a
day's work.

2) During a restore, raw spaces are a few times faster.

and 3) during a mass load of data, raw spaces are a few times faster. So is
the proper use of PDQ and artificially inflated allocations of shared memory
for a few unstated reasons (informix, once again...)

4) There is no point 4.

All of these points are significant when major sequential writing is taking
place.

BTW I must also qualify that this experience applies to machines without
fancy storage managers. If you are using a machine with SCSI disks directly
connected to the SCSI bus or a straight-forward SCSI raid controller, then
you'll notice performance benefits from using raw with Informix (any other
engines?) If it's got a big fat storage manager, then it's implementation
will hide the benefits, in which case, you need to ask "I'm using Engine E
on platform P with storage manager SM, so what's the best storage model to
use?"
Most DBAs
I've run into have never had to restore a database at any
time in their career much less even test it. Is that amazing
or what!
It's more tragic than anything else. By a strange coincidence I'm in a
discussion on this subject in another forum, and we're swapping horror
stories, such as a customer who backed up to a cleaner tape for 2 weeks, or
a customer who needed a restore and discovered that their 3 year old tapes
cannot be read on their 5 year old tape drive which hasn't seen a cleaner
tape ever....

I've had to do restores on customer sites who could not or would not afford
disk mirrors, so we really did rely on the tapes for the redundancy. I've
seen power supplies blow up. All sorts of things can and do happen.
Consider too, clustering of systems and disks, and the
administrative challenges associated with that. Add raw
devices to multitudes of servers and it becomes more risky
and more to manage. It puts more opportunities for failure
in the administration path, and nobody in their right mind
wants to increase risk. Is the extra 10% in speed worth it?
Well, as I said, I don't understand the alleged extra administration.
Clearly it's an NT thing? Or an issue for people who don't use the magic of
symlinks? Pass. I'll stop asking now.
One other thing you might find attractive to plain ole files
instead of raw devices is the ability to clone databases. You
can get quite creative with plain files in ways that you cannot
with raw devices because of the lock-in of raw-devices. You
create more work for yourself in the long run with raw disks,
unless of course you're not as lazy as me and actually enjoy
the extra work. '-)


This is where the YMMV slogan comes into play. I would never setup an
Informix,UNIX,S CSI machine with anything else but symlinks and raw spaces.
If I ever setup a machine with a high performance storage box, I'll look
into the most appropriate mechanism for that. I'd probably setup any brand
of engine on UNIX with symlinks, unless experience or advice shows that it's
pointless.

As for administration of raw spaces, on UNIX it's trivial. Meaningless. Not
a problem. Do what your engine, backup tool and storage manager works best
with. Unless someone else chips in with some detailed advice about other
brands, the original poster will only be lurnin' about Informix engines
today. If the OP wants more advice about Informix, please we should stop
cross-posting and get into more detail only on comp.databases. informix, and
stop boring the other newsgroups.

Goob, I think you hang around c.d.i quite a bit, so if you wish, please
further my education about the pain of raw spaces on c.d.i. Perhaps some
specific stories are needed so I can undertand your experience.
Nov 12 '05 #22
"Andrew Hamm" <ah***@mail.com > wrote in message news:c5******** ****@ID-79573.news.uni-berlin.de...
OK - so you are talking about SQL-Server and various issues related to a
backup tool you use?
Yes, standard backup tools.
If so, we have no argument; I know nothing of your
tools, and am speaking from an Informix + UNIX point of view. Our beloved
symlinks on UNIX are not available to NT servers, so suggestions on this
cannot help. I'm also of the opinion (only from reading) that unbuffered
NTFS files are equivalent in performance and reliability to raw spaces on
NT:

SQL-Server is a dish best served, well, cooked. In most SQL-Server
situations, probably 95% or more, SQL-Server is stored in plain ole
files in a directory. You can create FILEGROUPS akin to containers
and dbspaces, but in the real world most SQL-Server people haven't
a clue about how to use FILEGROUPS so they simply stuff everything
in one big default filegroup called PRIMARY. It's the equivalent
in Informix of leaving everything in the rootdbs and never bothering
with it, letting it get larger and larger. SQL-Server databases can
be detached, that is, taken off-line, moved, copied, etc. But most
people don't ever bother with disk layout except in the larger shops.
As you suggest there are no linked files, this concept is completely
opaque to Windows people they just don't connect with it. Incidentally
if you use more than 16 files to build filegroups you cannot use the
GUI to reattach a database--very cool thing to learn in a down-server
situation. You instead have to use a script like the one below with
the syntax FOR ATTACH at the end. Really spiffy.

Example 1. Mydatabase with a lot of FILEGROUPS :

CREATE DATABASE [Mydatabase] ON PRIMARY
( NAME = 'MYDB_PRIMARY_0 0' , FILENAME = 'R:\DATA\MYDB_D ata\MYDB_PRIMAR Y_00.MDF' , SIZE = 2048 MB , FILEGROWTH = 0% ) ,
FILEGROUP DATA
( NAME = 'MYDB_01' , FILENAME = 'R:\DATA\MYDB_D ata\MYDB_01.NDF ' , SIZE = 4172 MB , FILEGROWTH = 20% ) ,
( NAME = 'MYDB_02' , FILENAME = 'R:\DATA\MYDB_D ata\MYDB_02.NDF ' , SIZE = 4483 MB , FILEGROWTH = 20% ) ,
( NAME = 'MYDB_03' , FILENAME = 'R:\DATA\MYDB_D ata\MYDB_03.NDF ' , SIZE = 3887 MB , FILEGROWTH = 20% ) ,
( NAME = 'MYDB_04' , FILENAME = 'R:\DATA\MYDB_D ata\MYDB_04.NDF ' , SIZE = 3991 MB , FILEGROWTH = 20% ) ,
( NAME = 'MYDB_05' , FILENAME = 'R:\DATA\MYDB_D ata\MYDB_05.NDF ' , SIZE = 7964 MB , FILEGROWTH = 20% )
FILEGROUP IDX
( NAME = 'MYDB_IDX_01' , FILENAME = 'R:\DATA\MYDB_D ata\MYDB_IDX_01 .NDF' , SIZE = 2048 MB , FILEGROWTH = 20% ) ,
( NAME = 'MYDB_IDX_02' , FILENAME = 'R:\DATA\MYDB_D ata\MYDB_IDX_02 .NDF' , SIZE = 2048 MB , FILEGROWTH = 20% ) ,
( NAME = 'MYDB_IDX_03' , FILENAME = 'R:\DATA\MYDB_D ata\MYDB_IDX_03 .NDF' , SIZE = 2048 MB , FILEGROWTH = 20% ) ,
( NAME = 'MYDB_IDX_04' , FILENAME = 'R:\DATA\MYDB_D ata\MYDB_IDX_04 .NDF' , SIZE = 2048 MB , FILEGROWTH = 20% ) ,
( NAME = 'MYDB_IDX_05' , FILENAME = 'R:\DATA\MYDB_D ata\MYDB_IDX_05 .NDF' , SIZE = 2048 MB , FILEGROWTH = 20% )
LOG ON
( NAME = 'MYDB_LOG_01' , FILENAME = 'R:\DATA\MYDB_L ogs\MYDB_LOG_01 .LDF' , SIZE = 56 MB , FILEGROWTH = 10% )
GO

Example 2. Mydatabase with no thought or plan, out of the box:

CREATE DATABASE [A] ON PRIMARY
( NAME = 'a_Data' , FILENAME = 'R:\Data\A\DATA \A_Primary.MDF' , SIZE = 4 MB , FILEGROWTH = 10% ) ,
LOG ON
( NAME = 'a_Log' , FILENAME = 'R:\DATA\A\LOG\ A_Log.ldf' , SIZE = 14 MB , FILEGROWTH = 10% )
GO

Big bummer on FILEGROUPS, if you set up a clustered index guess where your
table goes? It gets moved into the same FILEGROUP as the index! Is this retarded
or what! All that planning, all that design, down the toilet. Detached indexes
are only valid on non-clustered indexes. ( And people say they will move to SQL
if Informix dies. Hee hee! We haven't even talked about logging... )
Even with Informix on NT (of which i have almost no experience) symlinks are
not available, and further, the recommendations from Informix states that
you can use normal files (O/S buffered and capable of going onto FAT), or
normal files on NTFS (which will be used unbuffered) or a raw partition on
NT. Further, the documentation says that on NT, the use of unbuffered NTFS
files is of equal performance to NT raw spaces, therefore it's not worth
using raw spaces on NT. But that's NT, something I don't play with.

Again with risk. SQL-Server docs specifically point to raw-disks as
an unsupported feature, so this is not really an option in Windows.
Who would be available to support it? Most Windows people wouldn't
even want to attempt this one. What about planning, migrations, etc?
There wouldn't be anyone around to admin a raw-disk SQL-Server. :-)

....

4) There is no point 4.

All of these points are significant when major sequential writing is taking
place.

BTW I must also qualify that this experience applies to machines without
fancy storage managers. If you are using a machine with SCSI disks directly
connected to the SCSI bus or a straight-forward SCSI raid controller, then
you'll notice performance benefits from using raw with Informix (any other
engines?) If it's got a big fat storage manager, then it's implementation
will hide the benefits, in which case, you need to ask "I'm using Engine E
on platform P with storage manager SM, so what's the best storage model to
use?"

I defer to K.I.S.S.
One other thing you might find attractive to plain ole files
instead of raw devices is the ability to clone databases. You
can get quite creative with plain files in ways that you cannot
with raw devices because of the lock-in of raw-devices. You
create more work for yourself in the long run with raw disks,
unless of course you're not as lazy as me and actually enjoy
the extra work. '-)


This is where the YMMV slogan comes into play. I would never setup an
Informix,UNIX,S CSI machine with anything else but symlinks and raw spaces.


If you have the time be my guest.
If I ever setup a machine with a high performance storage box, I'll look
into the most appropriate mechanism for that. I'd probably setup any brand
of engine on UNIX with symlinks, unless experience or advice shows that it's
pointless.

Welcome to my world.

As for administration of raw spaces, on UNIX it's trivial. Meaningless. Not
a problem. Do what your engine, backup tool and storage manager works best
with. Unless someone else chips in with some detailed advice about other
brands, the original poster will only be lurnin' about Informix engines
today. If the OP wants more advice about Informix, please we should stop
cross-posting and get into more detail only on comp.databases. informix, and
stop boring the other newsgroups.

Goob, I think you hang around c.d.i quite a bit, so if you wish, please
further my education about the pain of raw spaces on c.d.i. Perhaps some
specific stories are needed so I can undertand your experience.


I'm not arguing that maintaining symlinks or raw-disks are difficult. In
an environment where things are somewhat stable and you have the expertise
available I'm sure there are benefits. But in shops where the expertise is
not available raw disks are a luxury. The additional effort in setting
them up and getting people to take care of them adds risk. It's not a
competition either, every shop is different and has different needs. Me,
I'm lazy and concerned that the talent pool won't be able to manage them
properly. As fast as our environment changes we don't have the time for
luxuries. The expectations again are also something you manage. We are
seeing speed on Linux that is easily 10x faster than on Windows, and with
considerable hardware to compare with. This is with cooked files, so again,
we're already faster than windows, so how are raw-disks going to really
make a difference? 10%? Not enough to bother with, and with as many
servers as I manage, definitely more trouble than benefit.


Nov 12 '05 #23
Andrew Hamm wrote:
Mark Bole wrote:
I haven't worked with an Oracle raw device since version 7.3 seven
years ago, and would never go back. The administrative overhead is
just too much of a headache.

[Posting from comp.databases. informix]

I've never understood the "administra tive overhead" argument against raw
spaces. Can you elicidate on the administration you think needs to be
applied? In my experience, the only admin overhead is making sure that a
new, naive sysop doesn't try to turn a raw space into a filesystem - I saved
an engine by SECONDS once, by looking over the shoulder of said sysop as I
walked past....

Apart from that, I find that admin is slightly simpler simply because you
don't need to run a mkfs style of command ;-)

I have heard that Solaris (?) is in the habit of re-creating /dev at boot
time, and I know that DG-UX used to do the same thing. Therefore some sort
of tool is needed to make sure the raw devs exist after a boot. Is this what
you mean?


Gawd, this cross-posting is a little scary... I've touched DB2,
administered Sybase for four years in the mid-nineties, otherwise Oracle
is it... so take the following for whatever it's worth.

To answer the question above: no, actually my experiences with Oracle
raw devices were under DEC Ultrix, SGI Irix, and HP-UX. I've only
managed "normal" filesystems under Solaris, Linux, and Windows. To this
day the thought of messing with the /dev filesystem stresses me out... --)

Yes, I've had to recover production (Oracle, Sybase) systems in real
life disaster situations: Score: raw filesystems, W-1, L-1. cooked
filesystems, W-2, L-0. So you can see where I'm heading...

I use "adminstrat ion" in a very tool-oriented sense. With cooked file
systems (which I am defining as filesystems the OS is designed for...
tautology or no...), there are lots of tools: tools for timestamps,
tools for sizes, tools for checksums, tools for copying, tools for
finding, tools for checking open handles, and so on. With raw
filesystems, I have none of these tools. (OK, wrong if you consider
"dd" under Unix to be a tool....)

Your own example serves to make my point: the set of admins, naive or
otherwise, who stand a chance of disaster recovery with raw filesystems
in the 21st century is an order of magnitude less than those who stand a
chance of disaster recovery with "normal" filesystems.

And just to put the skin on the pudding, isn't the stated direction of
MSFT to turn the entire filesystem into a database? Whither raw
partitions then?

--Mark Bole

Nov 12 '05 #24
Mark Bole wrote:

Gawd, this cross-posting is a little scary...
Not wrong :) but we're being very well-behaved so far. I did see one slur
against Sybase's market position, but they've been patient and I thank them
for that. We still love you, folks... I was a big fan of Watcom 15 years
ago, and i believe it's the spiritual ancestor of Sybase and MS? Sybase
split from the Evil Empire, so that's a point in their favour, and in some
simple play with MS SQL, it looks like fun... Has that buttered up enough
people to keep things happy?
I've touched DB2,
administered Sybase for four years in the mid-nineties, otherwise
Oracle is it... so take the following for whatever it's worth.

To answer the question above: no, actually my experiences with Oracle
raw devices were under DEC Ultrix, SGI Irix, and HP-UX. I've only
managed "normal" filesystems under Solaris, Linux, and Windows. To
this day the thought of messing with the /dev filesystem stresses me
out... --)
True. If you MUST move a lump of data, which the engine thinks is called
/dev/rdk0101, then there's no way that can be renamed on many O/S due to
naming conventions. I got stuck with that several years ago. I actually
cheated and broke the O/S naming convention just to get things working. That
was an object lesson. However, common wisdom in the Informix world (probably
discovered 1000 times by different people) is to use symbolic links.
Personally I use something like /DBCHUNKS/enginename/lump01 -> /dev/blahblah
and then the engine can always use the logical name; the physical space will
be wherever it's pointed.
Yes, I've had to recover production (Oracle, Sybase) systems in real
life disaster situations: Score: raw filesystems, W-1, L-1. cooked
filesystems, W-2, L-0. So you can see where I'm heading...
OK - that's a warning from experience on them engines. OP take note. We have
a bunch of Oracle admins in this company, and I don't believe they use raw
spaces either. I don't know how they do backups either; I really should lurn
from them, but never quite get 'round to it.
I use "adminstrat ion" in a very tool-oriented sense. With cooked file
systems (which I am defining as filesystems the OS is designed for...
tautology or no...), there are lots of tools: tools for timestamps,
tools for sizes, tools for checksums, tools for copying, tools for
finding, tools for checking open handles, and so on. With raw
filesystems, I have none of these tools. (OK, wrong if you consider
"dd" under Unix to be a tool....)
ok - I've heard that Oracle has a "variety" of backup procedures, some of
them home-cooked, some of them tools you have to pay for. In that case, you
would need suitable tools to manage the objects. With Informix, it's shipped
with one (now two) tools that perform complete, live, point-in-time archives
along with continuous storage of logical logs. Any timestamps etc that need
touching are self-contained within the engine spaces, so it's completely
unnecessary and almost certainly destructive to do anything with informix
spaces apart from via the utilities provided.

By the way, you can still perform something like

cksum < /dev/rawspace

or

dd if=/dev/rawspace bs=64k count=XXXk | cksum

and so on. Raw devices on unix are still just files. They are just not
appropriate to use without some smart access algorithms, such as might be
found in database engines... Sure, dd is a wierd utility that doesn't match
typical unix command line syntax, but it can still move "files" around. Not
that I ever need to do that.

Haven't heard any opinions from a DB/2 bod yet.
Your own example serves to make my point: the set of admins, naive or
otherwise, who stand a chance of disaster recovery with raw
filesystems in the 21st century is an order of magnitude less than
those who stand a chance of disaster recovery with "normal"
filesystems.
By the same token, a dumb-**** naive sysadmin could easily destroy cooked
files in their desperate and thoughtless search for more space. An
inexperienced but over-confident admin is a dangerous creature no matter
what product they are near. I don't think anyone could do a recovery using
the cleaning tapes I mentioned in another reply. Murphy's law at work there.
And just to put the skin on the pudding, isn't the stated direction of
MSFT to turn the entire filesystem into a database? Whither raw
partitions then?


MSFT? ?? Micro Soft Something Something? Not interested !:) UNIX and Linux
suits me, our application and our customers well. Good luck to Microsoft
with their FT, whatever that might be.

I'm waiting for any Informix users to contradict me about always using raw
with Informix. When the subject comes up over in c.d.i, we get 3
counter-responses. One is the "complicate d" argument. One is about certain
platforms which contain system calls and filesystems which are specifically
tailored for write-through and no buffering. I've seen Solaris has a
filesystem option to apply that on the entire file system. On such a
machine, you'd only have to ensure contiguity, and to keep other peoples
dirty hands out of your spaces. The third counter argument to raw is large
high performance storage boxes - good luck to you if your customers or site
can afford them. I think a few of our customers should be using them, but
aren't.

I think a history and principles of raw space on UNIX is worth posting, so
the OP can make his/her own decisions... [looks - ok, him, Jim] That will
have to wait a few hours, and be yet another oversized posting :-) There are
many interesting points and developments along the way, not to mention big
fast storage boxes.
Nov 12 '05 #25
Andrew Hamm wrote:

[snip]
ok - I've heard that Oracle has a "variety" of backup procedures, some of
them home-cooked, some of them tools you have to pay for. In that case, you
would need suitable tools to manage the objects. With Informix, it's shipped
with one (now two) tools that perform complete, live, point-in-time archives
along with continuous storage of logical logs. Any timestamps etc that need
touching are self-contained within the engine spaces, so it's completely
unnecessary and almost certainly destructive to do anything with informix
spaces apart from via the utilities provided.


[snip]

For many aeons, it has been this on Oracle. Shell-scripted backups,
with commands provided by the database to make the O/S-produced backup
recoverable and usable. But since version 8.0 (and we've had 8.1.5,
8.1.6, 8.1.7, 9.0.1, 9.2, and 10g since then), Oracle has provided RMAN
-for free- which does cleverer and safer backups than any shell script
could manage. It's a command-line tool for the scripting addicts, but
has a GUI front-end for those so inclined. Works very nicely.

The emphasis is very much on using RMAN these days (when first released
it was a bit rough round the edges!), and O/S-based backups are
gradually becoming a thing of the past, or at least not too well looked
upon, generally (though it's nice to have the choice).

Point is, given the context of this discussion, RMAN works just as well
with raw devices as it does with file systems, and will happily backup a
raw-based database onto a file system, or vice versa.

Raw isn't the utterly inflexible nightmare in Oracle it's sometimes made
out to be.

Regards
HJR
Nov 12 '05 #26
"Jim Smith" <ji*@jimsmith.d emon.co.uk> wrote in message
news:hq******** ******@jimsmith .demon.co.uk...

Is it faster I/O requests?
Or faster I/O overall?
Or less CPU used?

None of the above. A faster response and or throughput from a user point
of view.


Nope. That has nothing to do with I/O speed.
eminently STUPID to claim "file system I/O" is faster: there is
no I/O in that case, just in-memory access!


But it will give a faster response therefore "file systems are faster".


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.

But, database blocks will often be buffered in the db buffer cache so
the file system buffer may be irrelevant or even an overhead. I vaguely
remember on VMS it was recommended you disable disk caching and used
oracle's buffer cache.


Depends on what the OS can do. Some don't work all that well at
doing direct I/O to/from buffer cache. And if they copy from another
buffer, you end up with CPU use instead of I/O use.

--
Cheers
Nuno Souto
wi*******@yahoo .com.au.nospam

Nov 12 '05 #27
Sorry, I meant "to/from db buffer cache".

--
Cheers
Nuno Souto
wi*******@yahoo .com.au.nospam
"Noons" <wi*******@yaho o.com.au> wrote in message
news:40******** *************** @news.optusnet. com.au...
Depends on what the OS can do. Some don't work all that well at
doing direct I/O to/from buffer cache.


Nov 12 '05 #28
[cutting]
eminently STUPID to claim "file system I/O" is faster: there is
no I/O in that case, just in-memory access!


But it will give a faster response therefore "file systems are faster".


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.

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:-)
--
Paul Watson #
Oninit Ltd # Growing old is mandatory
Tel: +44 1436 672201 # Growing up is optional
Fax: +44 1436 678693 #
Mob: +44 7818 003457 #
www.oninit.com #
Nov 12 '05 #29
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
all this one tablespace at a time. If my memory is serving me
correctly (and I'm quite open to being told it isn't) this is a vastly
more primitive mechanism than either ontape or onbar.

Has the basic backup tool moved on since then, and does RMAN avoid any
such limitations?

(Sorry to drift off-topic but it's always useful to know what else is
out there. Hell, I might need a job with that stuff some day.)

Andy
"Howard J. Rogers" <hj*@dizwell.co m> wrote in message news:<40******* *************** *@news.optusnet .com.au>...
Andrew Hamm wrote:

[snip]
ok - I've heard that Oracle has a "variety" of backup procedures, some of
them home-cooked, some of them tools you have to pay for. In that case, you
would need suitable tools to manage the objects. With Informix, it's shipped
with one (now two) tools that perform complete, live, point-in-time archives
along with continuous storage of logical logs. Any timestamps etc that need
touching are self-contained within the engine spaces, so it's completely
unnecessary and almost certainly destructive to do anything with informix
spaces apart from via the utilities provided.


[snip]

For many aeons, it has been this on Oracle. Shell-scripted backups,
with commands provided by the database to make the O/S-produced backup
recoverable and usable. But since version 8.0 (and we've had 8.1.5,
8.1.6, 8.1.7, 9.0.1, 9.2, and 10g since then), Oracle has provided RMAN
-for free- which does cleverer and safer backups than any shell script
could manage. It's a command-line tool for the scripting addicts, but
has a GUI front-end for those so inclined. Works very nicely.

The emphasis is very much on using RMAN these days (when first released
it was a bit rough round the edges!), and O/S-based backups are
gradually becoming a thing of the past, or at least not too well looked
upon, generally (though it's nice to have the choice).

Point is, given the context of this discussion, RMAN works just as well
with raw devices as it does with file systems, and will happily backup a
raw-based database onto a file system, or vice versa.

Raw isn't the utterly inflexible nightmare in Oracle it's sometimes made
out to be.

Regards
HJR

Nov 12 '05 #30

This thread has been closed and replies have been disabled. Please start a new discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.