Re: RAC & RAW Question
- From: "Don Granaman" <granaman@xxxxxxx>
- To: <andert@xxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Mon, 25 Apr 2005 01:28:05 -0700
It seems that others have answered the questions about growing raw device
sizes. On some systems, raws can be enlarged and added on the fly, etc.
On some they can't. On our system (RH Linux, EMC Clariion, RAC), adding new
raws means shutting down Oracle first.
As for Q2 though, I didn't see an answer yet. You can "alter database
datafile ... resize .." on raws and can autoextend a datafile on a raw - up
to the available space on the raw device. For autoextend, set a maxsize -
and a reasonable next.
Q3: There are some out there, but I haven't read/seen them in years. Try
Jonathan's site or Steve's - or google. In my opinion, a few of the most
basic "best practices" for raw devices are:
1) Figure out a small set of distinct sizes for raws for the database, don't
over-customize. Maybe you need 100M, 2048M and 8192M (or whatever...). You
don't need 30M, 82M, 120M, 720M, 1250M, ad nauseum. There may be some
"wasted space", but call it "room for datafile growth" and write it off.
2) Have a few (or more) spares of each size you might need available. Don't
wait until you need them, especially if you have to shutdown/startup or jump
through other flaming hoops.
3) Make sure the sys admin knows where and what the datafiles are - or might
be! Preferably, put them in a blatantly-named disk group / volume group /
whatever you have (e.g. "oradg", "oravg", ...) and make it well-known that
dinking with them is serious business. One of the worst (and, in
retrospect, funnier) raw disasters I've ever seen was when a
new-to-the-company sys admin at a major telecom whacked some raw devices
with production database datafiles on them and mounted a filesystem up.
("It looked like free space.") The real kicker was that they also had no
usable backups.
Q4: "Reshaping" via judicious segment placement and tablespace construction
is preferred. I hope that "tablespaces with single files" isn't carved in
stone.
Export/import will likely take a *lot* longer than an RMAN restore with file
rename. Worse, all the exp/imp time is probably application downtime. I do
the RMAN thing occasionally to restore a raw database to a test database on
filesystems - either to clone or to test restore/recovery. If you really
want to get more sophisticated, you could do a "standby thing". In either
case, if it is well-planned, the only notable app downtime is during the
last bit of "archive/transfer/recover".
There really isn't as much challenge to raw devices anymore (nor as much
motivation for them). Modern backup utilities all have raw support. Volume
managers make setup easy. DBAs finally got over the "I have multiple
extents! I have to reorg!" dogma. "Autoextend forever" doesn't work, but
that could be considered a plus. In my opinion, the most significant
downside is that you have to be able to anticipate some segment space
requirements. If you sometimes come in on Monday to find that many-gigabyte
segment(s) unexpectedly doubled in size over the weekend, raws may not be
advisable...
-Don Granaman
OraSauRaws
----- Original Message -----
From: "Stephen Andert" <andert@xxxxxxxxx>
To: <oracle-l@xxxxxxxxxxxxx>
Sent: Friday, April 22, 2005 2:40 PM
Subject: RAC & RAW Question
> Hi all,=20
>
> I am working on getting RAC set up. It is sr mgmt's idea and I'm not
> sure that it will provide what they think it will.
>
> I have a question about growing with RAW.
>
> I read in a book that RAW partitions cannot be extended. After
> discussing this with my friendly neighborhood SysAdmin team, they have
> told me that growing a RAW partition/device is not a problem. They
> don't even think I need to bring down the database.
>
> My questions are:
>
> Q1. Is it possible that the author was speaking in general terms and
> that in my environment, we have an OS, etc that allows this (AIX,
> EMC)?
>
> Q2. Is it that the OS can do it, but the database cannot recognize
> it? (I thought a alter database datafile ... RESIZE would work)
>
> Q3. Can anyone point me towards a best practices with RAW white paper?
>
> Q4. Does anyone have any pointers towards converting a cooked
> database to RAW? It is large enough that export/import will take more
> time that I think we will get approved for. We are theorizing that if
> we "reshape" the database to tablespaces with single files that match
> the sizes of the RAW devices we will be getting, that an RMAN
> alternate node restore with file rename will work. Thoughts or
> comments on this?
>
> Thanks
> Stephen
> --
> //www.freelists.org/webpage/oracle-l
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
