Re: Oralce 10gR2 Setup questions
Date: Tue, 31 Mar 2009 06:49:46 -0700 (PDT)
Message-ID: <dbb44f1d-7206-4340-8258-5dcd1b3c4857_at_s28g2000vbp.googlegroups.com>
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
If you separate your table and index objects into table and index object tablespaces is a management decision and has little to no performance impact except in those cases where you have dedicated disk drives. When you move to a SAN how you spread your tablespaces to physical disks may be outside your ability to control depending on whose SAN and which model you buy. With some units you just tell it how many logical drives you want of what size and the SAN software determines which disks are used. In cases like this you are doing good to separate your database data files from your backups.
If you have a unit where the administrator can specifiy which physical unitis support which logical file systems then you have more options. There is a good chance depending on the size and activity patterns of your application that you would be just as well if not better off stripping the data and index tablespace data files across the same physical disks.
In fact you may not have a real choice as you may discover the only way the vendor sets up the unit is as a single RAID-5 stripe. Everything is really on the same physical disks.
Logically separating you file systems can still make sense for the day when you get a second stripe added to the SAN. Then you could at move move your logical device used to house the backups to the second stripe.
In other words find out what you can do with the SAN that you will be using before you make too many plans about how you want to use it. Your options depend on what is purchased.
Oracle's ASM on top of the SAN is another option that you should consider.
As far as using a database flashback recovery area, if you do then by default rman will write the backups there and your archived redo logs will also be written there. Having them together, flashback area or no flashback area, is fine. Always has been.
HTH -- Mark D Powell -- Received on Tue Mar 31 2009 - 08:49:46 CDT