RE: share a new 11gR2 feature
- From: "Matthew Zito" <mzito@xxxxxxxxxxx>
- To: <dbvision@xxxxxxxxxxxx>
- Date: Fri, 4 Sep 2009 12:05:46 -0400
This would, indeed, be a useful feature if anyone these days actually ran their
data on physical disks. With today's world of wide-striping, massive array
caches, write re-ordering, and storage virtualization, I doubt it will make
much difference.
It IS very interesting, though, for the argument that Oracle is gonna continue
arguing that you can just buy lots of JBOD arrays and do data resiliency in
software, rather than investing in enterprise storage.
Matt
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx on behalf of Nuno Souto
Sent: Fri 9/4/2009 5:08 AM
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: share a new 11gR2 feature
Job Miller wrote,on my timestamp of 4/09/2009 12:16 AM:
> A few of the things from the 11gR2 new features guide that are interesting to
> me. i just cut and paste from the doc, so no value add but if anyone feels
> inspired to share the things from the 11gR2 new features guide that they have
> been waiting for or think they can immediately benefit from, I am sure the
> rest of us would gain a better appreciation for that new feature. So if you
> plan to read the guide, ignore this.
>
Here is one, very relevant to us:
http://dbasrus.blogspot.com/2009/09/11gr2-it-looks-like-someone-is.html
>
> 1.9.1.5 ASM Intelligent Data Placement
>
> Disk drives have higher transfer rates and bytes per track on the outer
> tracks. This makes it preferable to keep the hotter data closer to the edge
> of the disk; that is, the lower numbered blocks. This feature enables ASM to
> identify higher performance disk regions. Most frequently accessed ASM files
> can be marked to be moved into the hot region and take advantage of higher
> I/O performance (for example, hot tablespaces and indices) and able to better
> meet the application I/O demand. This feature is only applicable when whole
> physical disks are presented to ASM versus local unit numbers (LUN).
If only someone would explain this to the absolute incompetents who handle our
SAN config...
--
Cheers
Nuno Souto
in overcast Sydney, Australia
dbvision@xxxxxxxxxxxx
--
//www.freelists.org/webpage/oracle-l
Other related posts:
