Re: RAC & RAW Question

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_at_gmail.com> To: <oracle-l_at_freelists.org> 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
> --
> http://www.freelists.org/webpage/oracle-l
>

--
http://www.freelists.org/webpage/oracle-l