Re: ASM and SAN Layout
- From: "Frits Hoogland" <frits.hoogland@xxxxxxxxx>
- To: greg@xxxxxxxxxxxxxxxxxx
- Date: Wed, 26 Sep 2007 10:57:06 +0200
commens inline
On 9/26/07, Greg Rahn <greg@xxxxxxxxxxxxxxxxxx> wrote:
>
> comments in-line
>
> On 9/25/07, ryan_gaffuri@xxxxxxxxxxx <ryan_gaffuri@xxxxxxxxxxx> wrote:
> > 1. One bigfile tablespace for my data and one for my indexes. Is this
> > appropriate?
>
> One disadvantage to bigfile tablespaces is the creation is done by a
> single process. For example, if you needed 1TB, one process would
> make this datafile. If you were to use smallfile tablespaces
> (assuming 8k db_block) you could create a tablespace with a single
> 32GB file and then kick off 31 sqlplus sessions all adding a 32GB
> datafile, thus doing the operation in parallel.
>
> Separating index/data is an organization thing, probably not a
> performance thing.
agree
> 2. Is it preferable to create one diskgroup for each LUN? Or is one
> > diskgroup per the following more appropriate
>
> I would recommend 1 diskgroup composed of several luns. There is no
> reason for a 1:1 relationship for tablespace to diskgroup. In fact, it
> would probably perform worse.
oracle recommends just 2 diskgroups, one for redo/flashback and one for
data
> 3. Should I keep all of the above on dedicated spindles? I was told that
> > since redo and archive logs do serial writes and data files do random
> reads
> > and writes, performance is better if these are on seperate dedicated
> > spindles? What about seperating out my indexes from data on different
> > spindles? Along with the rest of them?
>
> There is probably very little to gain by separating out data/index
> onto dedicated spindles, especially if using ASM (which I would
> strongly recommend.) Same goes for redo.
I think seperation of data (data+index) and online redo could be feasible
depending on your SAN configuration.
Transactional performance is depended upon redo write actions, which are
typically smal(lish) writes to the online redologfiles.
> It appears that the major advantage with ASM for me would be the reduction
> > in datafiles to manage.
>
> IMHO, the biggest advantage of ASM is the striping of data evenly over
> all the ASM disks in the ASM diskgroup. It is very difficult to do
> this by hand, as well as time consuming. And not to mention the very
> nice feature of rebalancing when new ASM disks are added to the
> diskgroup. This generally done on non-ASM filesystems by adding new
> mount points and then moving datafiles by hand.
Please mind that every 'slice' given to ASM is seen as a (seperate) disk by
ASM.
That is why rebalancing is taking place, to spread the IO's out even over
the disks.
Most SAN's are configured in a way that slices are not seperate groups of
disks, but spread among all disks in the SAN.
If so, the striping has already taken place. Rebalancing in ASM means that
it is being redone.
I've heard rumours of ASM failing in high volume environments.
If you haven't, go to
> http://www.oracle.com/technology/products/database/asm and check out
> some of the whitepapers.
>
> --
> Regards,
>
> Greg Rahn
> http://structureddata.org
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
Other related posts:
