Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: raw devices

RE: raw devices

From: Valuthur, Srikanth <SValuthur_at_erac.com>
Date: Mon, 20 Aug 2001 09:09:02 -0700
Message-ID: <F001.003710E0.20010820092211@fatcity.com>

Don & Oracle Gurus,

Going by your answers, I have a question for you? What you have explained is excatly the same environment we had back in our previous work place. But here we have everything what you have MINUS the raw devices. The question I have for Don and the forum folks is, What is the benefits of having flat files over raw? I have been working with RDBMS for over 10 years and I have always worked with RAw and I have raw as recommended by MS,SYBASE and INformix.

The reason for this question is because we are moving to RMAN/Veritas and EMC Timefinder, I suggested things would be better if we move to raw. But I could not prove for the fact that Raw is better of Flat FS.

Please Suggest from your past experiences.

Thanx

Srikanth

-----Original Message-----
Sent: Monday, August 20, 2001 9:46 AM
To: Multiple recipients of list ORACLE-L

I don't know about NT, but on Solaris you should have some sort of cluster volume manager - Veritos is the most common. Rather than repeat all the information for vxva, vxprint, etc. here, just read the manuals - "$ man vxva". Another option is to run the vxva GUI and capture the commands it issues. When setting up non-trivial systems with Veritos, I typically script everything rather than wade through hours in the GUI.

Since we don't know yet what you have - for a volume manager, for backup utilities, and other such information, it is going to be impossible to give you the detailed technical information, scripts, etc. that you desire.

Establish a helpful naming convention - for disks, volumes, etc.

Adding a datafile is just like adding any other datafile. Using the Veritos volume manager example again, you would need to:

  1. Create the volume in the vxva GUI or by using the vxassist command
  2. Assign ownership of the volume to oracle:dba using the vxva GUI or the vxedit command
  3. SQL> alter tablespace add datafile '/dev/vx/rdsk/oradg/volume_name' size 100M;

Contrary to popular conception, you can expand a datafile inside a raw device - if there is space available. For example, assume you have created a 2001 MB raw device, and have created a 1001 MB datafile on that raw device. You could:
SQL> alter database datafile '/dev/vx/rdsk/oradg/volume_name' resize 2001 MB;

You can also autoextend within a raw device, but set a maximum size! If it tries to extend beyond the available space for the raw, it will error out. (I prefer not to use autoextend anyway - for other reasons).

To drop a tablespace, reclaim the space, and build a new tablespace, do it exactly as you would with filesystems - unless you want to combine datafiles. Only the file names are different.

If you want to, for example, combine two smaller raw volumes into one larger raw volume, you will need to drop the tablespace, drop the smaller raw devices, create a larger raw volume in their place (if possible) via the volume manager utility, then create the new tablespace on the new raw volume.

For backups, you need something that can back up raw devices. dd is the lowest common denominator utility in Unix. On Solaris PDB OPS clusters with large raw databases, I have always used Veritos NetBackup combined with RMAN or EBU. There are a number of other choices though. One caveat is to understand how your backup utility works in a clustered environment. For example, consider this scenario. You have a two node OPS cluster, with database MYORA and nodes named mynode1 running instance MYORA1, and mynode2 running instance MYORA2. You always run NetBackup/RMAN backups from mynode1. If mynode1 crashes and you now have to run backups or restores from mynode2, you will need to modify the bp.conf configuration file for NetBackup. This is something you want to know how to do BEFORE you loose the node from which you have been doing backups and have to perform a restore from another node!

Sorry if these are not the easy unambiguous answers you were seeking, but setting up a good OPS environment is not trivial. Intelligent and well-considered configuration and design is essential to make administration manageable. Raw devices are not really that difficult, but do require significant understanding. One of the signature distinctions between a well-designed OPS system and a maintenance nightmare is in how well all the physical infrastructure (disks, volumes, stripes, mirrors, etc.) are laid out since these are the hardest things to change once it is operational. Backup utilities and other such things must be chosen with raw devices, OPS, the cluster software, the volume manager, and other critical infrastructure elements in consideration.

These systems require much more front-end planning than most. Shops that typically operate in fire fighting mode, rather than fire prevention mode, will most likely find OPS and/or raw devices to be inappropriate choices. It is my considered opinion that this is why both (OPS and raw) have long suffered in reputation.

-Don Granaman
[certifiable OraSaurus]

> Dear gurus !
> I have inherited several OPS databases on both NT & Sun Solaris cluster.
> Although i have had some experience in basic ongoing maintenance of OPS ,
i
> have never went a "coast to coast" with it alone.
> The most problematic issue , as i currently see it , is raw devices.
> How do i manipulate raw devices on NT & Solaris ? (Commands , utilities
> etc.. - real hands on , technical stuff , not the theory )
> How do i add / enlarge a data file residing on a raw device ?
> How should i backup this OPS DB ?
> What should i do if i want to drop a tablespace , reclaim the space
occupied
> by it's datafiles and then build another tablespace (with new datafiles)
> using this reclaimed space ?
> Would U please also point me to some GOOD technical materials on the web .
> Thank U very much in advance !!!
>
> Andrey.

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Don Granaman
  INET: granaman_at_home.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Valuthur, Srikanth
  INET: SValuthur_at_erac.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
Received on Mon Aug 20 2001 - 11:09:02 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US