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]


----- Original Message -----
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: Monday, August 20, 2001 7:41 AM


> 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: [EMAIL PROTECTED]

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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED]

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: [EMAIL PROTECTED] (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).

Reply via email to