Re: Re: What do others do for database file mounts
Date: Wed, 18 Feb 2015 11:47:51 -0600
Message-ID: <CALrB5poHZKncCsq5AX_RrZs6mEeyOZk--DD7+0K6ViZiSxRdLw_at_mail.gmail.com>
Keep in mind that if you plan to use NetApp Snap Manager for Oracle (SMO) that I believe as a best practice they recommend separate volumes for TEMP, REDO, CTRL, ARCH and DATA.
Alfredo
On Wed, Feb 18, 2015 at 11:01 AM, Wayne Smith <wts_at_maine.edu> wrote:
> I meant this for the group...
> ---------- Forwarded message ----------
> From: "Wayne Smith" <wts_at_maine.edu>
> Date: Feb 18, 2015 12:00 PM
> Subject: Re: What do others do for database file mounts
> To: <rjoralist3_at_society.servebeer.com>
> Cc:
>
> You'll want to have an understanding of the performance of various disk
> spaces your storage people can allocate. Some of your NetApp may have many
> smaller disk and some fewer very large disks. I want my redo logs in the
> former, generally. Some space may have differing performance due to
> cache. Some will have differing performance due to your sharing space,
> under the covers, with other activity. This will vary over time!
> Performance will not be constant as days and months proceed. Also, the
> other applications will have bursts of activity and calm. Most of all,
> perhaps, if NetApp dedup is turned on, you may experience significant
> performance degradation during the scheduled dedup times.
>
> Your space may actually move, under the covers, as your storage admin
> manages everyone's space (assuming you have the new "cluster" capability
> enabled).
>
> We're moving most of our space from lun to NFS (dNFS), for
> manageability. Thin provisioning, auto grow, and online growth are
> wonderful.
>
> One thing to be aware of is how and where space for snapshots is
> accomplished. Frequent automatic snapshots on an active volume can take a
> lot of space, and with NFS, the space may be configured to come from the
> allocation your op/sys sees. It was really weird to see my redo space
> fill, just because the database became more active (snapshots were on by
> mistake).
>
> In general, the only non RMAN backup of my database spaces is
> /oracle/diag.
>
> To the more direct question of mounts, I like nothing interfering with
> redo and redo on 2 separate everything and very fast write. I like archive
> redo about the opposite.. cheap, performance not a concern, but with 2
> separate destinations, if possible. Control files and redo don't mix in my
> book ;-)
>
> Cheers, Wayne
> On Feb 13, 2015 5:06 PM, "Rich Jesse" <rjoralist3_at_society.servebeer.com>
> wrote:
>
>> Andy posts:
>>
>> > We are moving to Fibre Channel connections with all of our storage on a
>> Net
>> > App storage unit. One of the questions we got from our system admins
>> was if
>> > we could limit the number of mounts that they provide us for out
>> datafiles.
>> > With the newer disk technology that we all use, is it still important to
>> > segregate mounts for redo, CFs, datafiles, Archive logs, etc? I know
>> Oracle
>> > stands firm that best practices are to segregate these files into
>> separate
>> > mounts. I’m wondering what others do and if there is a compelling
>> reason
>> > to continue this practice?
>>
>> The main reason I kept the split on a new AIX v7.1 server is because the
>> old
>> AIX 5.3 server had experienced JFS2 filesystem corruption. Luckily this
>> was
>> easily correctable with a fsck, but it scared me enough to still keep
>> everybody separated, including mountpoints for each of the three
>> controlfiles. This is on an LPAR, so all storage is on the SAN (XIV).
>>
>> Also, in a disk space emergency, I don't want to worry about trying to
>> figure out what could be filling a mountpoint that's shared by redos,
>> archived redos, RMAN backups, MP4s of kittens, etc., or the ramifications
>> to
>> all of the above should the MP fill completely. One bucket per item makes
>> targeting potential problems and their respective solutions easier.
>>
>> For this solo DBA, at least. YMMV.
>>
>> My $.02,
>> Rich
>>
>>
>>
>> --
>> http://www.freelists.org/webpage/oracle-l
>>
>>
>>
-- http://www.freelists.org/webpage/oracle-lReceived on Wed Feb 18 2015 - 18:47:51 CET