-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Right, the ms times are from an AWR report which would include the overhead
you mentioned. I have been using this same method all along and have noticed
that overtime with more and more customer's joining the system and increase
workloads these times go up. (this makes sense)

These "ms" times are per datafile. In my environment a tablespace will have
say 10 datafiles, all on the same lun. As that tablespace becomes full I add
more datafiles .. on same lun. (A lun is typically made up of 10-12 disks setup
as raid 10).

You are right in that more recently inserted data will be "hot" as compared to
older data, and the newly added datafiles tend to have more io activity on them, but I'm
trying to find a way to become more evenly distributed ..other then rebuilding tables
every time I add 40GB to a tablespace. This way if I were to add more datafiles for
the same tablespace on a new lun (separate disks), I can be more sure that each lun
is doing the same amount of work.

I'm not sure if that makes sense.

- -peter




Kevin Closson wrote:
>  
> 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-----
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFnVX0oyy5QBCjoT0RAmZ7AJ9JHWjm+XKQjfI+k073lFxITyfg1gCfZKdL
PXextixtfDRrX1zyqCd/In0=
=WkEZ
-----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