Re: oracle binaries and datafiles

From: Stefan Knecht <knecht.stefan_at_gmail.com>
Date: Thu, 29 Mar 2018 09:43:54 +0700
Message-ID: <CAP50yQ95_rWgzQGvhpTRPExLP03_8ZgxdrZg=+rm3wZKPnAXEQ_at_mail.gmail.com>



Some good points have been mentioned. Another that I haven't seen yet is the maintenance. The storage for data files isn't likely going to grow much over time. You give it a 100GB and you're likely fine for a long time. Datafiles however are more likely to require more storage over time. Separating them gives you more options on performing maintenance without having to take down the entire thing (this of course depends on file system types and technology used, some are more flexible than others).

Then, of course, there's the question that asks how much you care about this database. Is the LUN presented to the server redundant on the storage tier? RAID 1? RAID 10? RAID 5?
http://www.oaktable.net/content/baarf-battle-against-any-raid-5 comes to mind. Is the path redundant? If this is just a sandbox / toy database you may not care. If it's a production database that carries any kind of value your business cares about, you may want to think about those things a bit more closely.

Perhaps you want to at the very least separate out (and mirror) the online redo logs and control files to ensure you do not loose those easily if a LUN fails, more so if the underlying LUN isn't redundant on the array.

Here's how I generally start when I set up an OS / disks for a basic database with no specific load profile:

  • 20GB for root /
  • 20GB for /var (I always insist this is kept separate since I have seen Linux and Unix servers becoming inoperable when root becomes full and the logs in /var are a prime candidate that can cause that)
  • 100GB for /u00, the Oracle software
  • Several LUNs for the ASM DATA diskgroup, depending on database size
  • Several LUNs for the ASM RECO diskgroup (Recovery Area, Archive logs, again, depending on database size)

Nowadays, ASM is a very robust software and there isn't much that speaks against it. You also get the added benefit of having the clusterware stack that can automatically start the database, listener, and even third party services that may depend on the database.

It's potentially a long topic, but here's my THB 0.02

Stefan

On Thu, Mar 29, 2018 at 2:34 AM, Jeffrey Beckstrom <jbeckstrom_at_gcrta.org> wrote:

> We are migrating to Linux. We are planning on storing the Oracle binaries
> and datafiles on the same mount point. Should we rethink this and separate
> them. The mount point points to a SAN if that matters.
>
> Jeffrey Beckstrom
> Lead Database Administrator
> Information Technology Department
> Greater Cleveland Regional Transit Authority
> 1240 W. 6th Street
> <https://maps.google.com/?q=1240+W.+6th+Street+Cleveland,+Ohio+44113&entry=gmail&source=g>
> Cleveland, Ohio 44113
> <https://maps.google.com/?q=1240+W.+6th+Street+Cleveland,+Ohio+44113&entry=gmail&source=g>
>
>

-- 
//
zztat - The Next-Gen Oracle Performance Monitoring and Reaction Framework!
Visit us at zztat.net | _at_zztat_oracle | fb.me/zztat | zztat.net/blog/

--
http://www.freelists.org/webpage/oracle-l
Received on Thu Mar 29 2018 - 04:43:54 CEST

Original text of this message