Re: Oralce 10gR2 Setup questions
Date: Tue, 31 Mar 2009 10:10:37 -0500
Message-ID: <QoqAl.22431$c45.19580_at_nlpi065.nbdc.sbc.com>
johnbhurley_at_sbcglobal.net wrote:
> On Mar 31, 12:44 am, bw <b..._at_abc.com> wrote:
>> I have been running Oraclee 9.2 in WIndow2000 Server. I have the
>> folowinf setup: Drive C: Oracle Home; Drive D: Tablespace for Data;
>> Drive E: Tablespace for Index; Drive F: Archive redo Log; Drive G:
>> RMAN Backup location. This database supports a busy on-line system
>> with 24X7 update. The transactions are regular text data.
>>
>> It worked very well for many years. C, D, E, F, G are different
>> volumes on different physical drives to enhance repsonse time,
>> reliability and recoverability. Each volume will not be too big,
>> probably around 80G, except the G which may house 2 or 3 copies of
>> RMAN.
>>
>> And we are upgrading to Oracl 10g R2 on Window 2003 very soon. We
>> will be purchasing Blade Servers. Wonder if there is need to separate
>> the database components as now.
>>
>> If we are moving to SAN, do I need to carve the SAN similarly ? Do we
>> need to separate Data and Index Tablspaces on different LUN (it then
>> carved uder different physical drives). I heard that SAN have the
>> Cache, and this steps may not be needed.
>>
>> I probably set up the Flash Recovery Area in F drive to hold the
>> Archive Logs. Should I use this area for RMAN files as well ? I
>> recalled it was recommanded to separate Archived Logs and Rman files
>> to make recoverability better.
>>
>> I have one last questions on where I should place Oracle Home. If I
>> install Oracle on drive D in SAN, what if the System drive C fails.
>> After I reinstall WIndow 2003, do I just update the PATH to point to
>> the Oracle Home in drive D in SAN, and recreate the instance using
>> oradim ?
>>
>> Thanks
>>
>> BW
> > It all depends on what your definition of a "buy online system" is and > there are lots of ways to measure that. > > Obviously one choice is to "not do very much at all" as you move to a > SAN. Another choice is to drink heavily of the Oracle Kool aid and go > ASM etc. ( We moved into ASM and it is working well for us ... ). > > You don't really need to use a flash recovery are but you certainly > can if you want to. > > Many people feel that data and index tablespaces do not need to be > separated out ( but ours still are ) especially once ASM is > considered. Lots of choices in the ASM world including using external > redundancy ... etc. > > If you have the time ... do some setup in different ways and do some > benchmarking of performance in different setups. I guess one should > argue that without doing benchmarking and checking out different > possible setups you are just shooting in the dark.
I have recently worked on a RAC cluster with several-hundred TB all on ASM. It was initially deployed on EMC - we used ASM rebalance feature to move it from EMC to NetApp filers and added an additional couple-of-hundred TB of storage to the system. The move took 27.5 days. AND we even had someone do something stupid and crashed the ASM instance during the move (day 22 IIRC)- the other node took over and finished the job without so much as a hiccup.
There are several very good books out there, one is by 2 of the Architects/primary developers something like "ASM- under-the-hood...". ASM, if properly deployed and utilized will all but eliminate any of those "let's keep the dba from getting sleep" problems that deal with space issues. On the systems where it was deployed, we never saw any more of those issues.
Is it Koolaid? probably, but it works so well you don't mind it... :)
On performance, one of my last task involved benchmarking ASM vs. cooked. ASM performed only slightly better. - Oh and this was behind IBM SVC (been compared to an array agnostic NetApp filer) which does its own stripping in addition to the ASM stripping. Received on Tue Mar 31 2009 - 10:10:37 CDT