Re: The old raw devices chestnut.

Andy Kent wrote:
> 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.

That was never true, actually. Yes, if you were performing an O/S-based backup, you had to say 'alter tablespace X begin backup', and '...end backup' when you'd done. But in between those two statements, the tablespace remains completely and utterly open for business, and is read from and written to perfectly normally. It would be a sad backup mechanism indeed if it suddenly rendered half your database read only!

>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.

It is *sensible* to do one tablespace at a time, because by saying 'begin backup', you cause the first modification that takes place to a block of data to write the entire block into what we would call the redo logs (I think informix would call them the physical logs). Normally, the same piece of DML would only write a few bytes of redo. Suddenly, in backup mode, it is writing thousands of bytes. So to avoid your entire database suddenly swamping the redo logs, yes... the sensible approach is to do it one tablespace at a time.

> Has the basic backup tool moved on since then,

The basic 'begin backup... copy... end backup' mechanism hasn't changed *at all*.

>and does RMAN avoid any
> such limitations?

One of RMAN's *great* claims to fame is that, because it is an Oracle tool that understands the concept of an Oracle block (whereas the O/S is dumb, and only understands indiviudal O/S blocks), it "knows" when an Oracle block is in flux. Instead of therefore writing the entire thing to redo to make sure that there's a consistent image of the block, it simply bides its time, and waits until the Oracle block is *not* in flux before copying it. Therefore, there's no 'begin backup' or 'end backup' command, no massive amounts of redo generated, and no need to do one tablespace at a time.

And the command to make it happen used to be

run {
allocate channel d1 type disk;
backup database;
}

...but is now....

backup database;

Regards
HJR
>
> (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" <hjr_at_dizwell.com> wrote in message news:<407ce550$0$14771$afc38c87_at_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
Received on Wed Apr 14 2004 - 17:06:09 CDT