How are you measuring that I/O? 100-900ms? Surely not measured with
iostat? No? The 0-5 profile would be the ones with the fortunate mix of
hits in the engenio array (IBM TotalStorage). I suspect you are
measuring the I/O with statspack and therefore the 100-900 are oracle
phys I/O waitstats which include scheduling overhead...but let us know.
Yes, ASM has ODDR capability. That fact just makes me more excited for
our version 2 product which will do ODDR at the file and/or directory
level in the same application-transparent way--for any sort of data
instead of just Oracle content... ahh...so many features...so little
time.
As an aside, are you sure you want all data redistributed in such a
frequent manner? Surely there will be hot and cold data, no?
Regarding your ASM comments, I guess I should have said that
some service times are 0-5 ms while others are 100-900ms. This
is
because it's hard to distribute extents across all datafiles as
more and
more customers come into our system ... so old datafiles don't
get accessed
as much and new data goes into new datafiles and these get hit
the hardest...
then I have to try and rebuild tables/indexes to redistribute
the data across
all the datafiles .. but with 70% growth .. i'm always playing
catchup.
My thought was with ASM, I could add a new storage unit of 13-14
36GB 15K RPM
drives .. create a volume and give to ASM to rebalance .. I
would expect to
see much more even distribution of service times.
My other concern was raised by our sysadmin. With our SUN
machine, if one of the
CPU boards crashes, the machine will not always crash (not sure
about this ..), but
he mentioned that with Linux a failed CPU will always crash the
machine .. any experience here?
Thanks again.
- -peter
Kevin Closson wrote:
> I'm considering the following environment:
> ===============================================
> - Dell 6800 (dual-core 64-bit Intel(r) Xeon(r) 7100 series
> processors) with 30GB RAM
> - Suse Enterprise 64bit (either 9 or 10)
> - Oracle 10.1.0.4 (this would be migrated)
> - ASM for database filesystem
> - Same storage as above
>
> ... I think you will be very impressed at the throughput of the Xeon
> "Tulsa" 7100 series. From what I see it is the formost way to get the
> best performance for your Oracle license dollars out there at the
moment
> (with x86_64)--a trend that will likely remain until AMD release HT
3.0.
>
> ... the Xeon 7100 processors are so much faster than US-III. You
didn't
> say how many Dell processors in total (e.g., RAC?). You may have a
> tremendous amount of idle CPU...
>
> I'm basically looking to improve service times on the disks
> (currently is can sometimes be up to 900 ms and averages at 100
> ms).
> I was hoping ASM would get me there .. ???
>
> ...ASM cannot improve disk service times--all things being equal. That
> is, if you send ASM via ASMlib or libaio to block 1042 in datafile 42,
> the service times will be the same. ASM isn't about faster I/O. It is
a
> space management offering.
>
>
> We are also growing and our data processing volumes has
> increased by 70% the last
> 2 years. The system is now running faster than ever, but with
> the expected growth,
>
> ...hmmm...that is faster than Moore's law.
>
> Any input would be greatly appreciated.
>
> ...if "any" input is appreciated, I'll recommend PolyServe...OK, I'll
> crawl back into my hole...
>
>
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFnQ2joyy5QBCjoT0RAhPzAJkBB9RMEexahq91GmcyBdiQ6PPdhACeJT3H
Sz+zMWLCQ+4yXdVKc3vEp4I=
=ZjeV
-----END PGP SIGNATURE-----
--
To unsubscribe, email: suse-oracle-unsubscribe@(protected)
For additional commands, email: suse-oracle-help@(protected)
Please see http://www.suse.com/oracle/ before posting
