Possibly migrating from Solaris to Suse + ASM ???

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

Folks,
	I'm considering moving our production database (800GB)
	from Solaris to SuSe.  We are hoping to alleviate
	some io and cpu bottlenecks by going to faster hardware. We
	are actively working on developing a new system, and I just
	need to keep the current one going for another year.

	I'm wondering if anyone has had any experience with this
	type of migration .. including ASM io performance with SUSE
and
	how SuSE handles CPU failures.

	Current Production Environment Looks like this
	===============================================
	- Solaris 5.8 on Sun 4500 with 10 400Mhz processors + 12GB
RAM
	- Oracle 10.1.0.4
	- Filesystem - veritas (older version not sure which), but
NOT the
	  Quick IO version.
	- Storage is IBM FAStT600 - DS4300 (FC drives - 14 36GB
drives per unit)

	Our system does lots of random io generated by batch jobs
.. lots of single
	record lookups, modifications (80 read/ 30 write).  We can
generate 600MB of
	redo log sometimes in as little as 3-5 minutes.

	At the same time, the system also does lots of large read
only operations, joins
	2 large datasets via full table scans/index fast full scans
and some hash joins.
	These queries run throughout the day and typically can
select anywhere between
	100 rows and 5MM.

	I'm considering the following environment:
	===============================================
	- Dell 6800 (dual-core 64-bit Intel®  Xeon®  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'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 .. ???

	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,
	I don't know how the system will perform during the holiday
season (our busiest time).

	Any input would be greatly appreciated.

- -peter

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


iD8DBQFFm/1Woyy5QBCjoT0RAlL+AJ0QeCb6GAT375q0IYpvFOnMzsHp7wCd
HSe4
5CmYA29B7rqtICdguUE9BZ0=
=WsLj
-----END PGP SIGNATURE-----

-- 
To unsubscribe, email: suse-oracle-unsubscribesuse.com
For additional commands, email: suse-oracle-helpsuse.com
Please see http://www.suse.com/oracl
e/ before posting

	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...



-- 
To unsubscribe, email: suse-oracle-unsubscribesuse.com
For additional commands, email: suse-oracle-helpsuse.com
Please see http://www.suse.com/oracl
e/ before posting

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

Kevin,
	thanks for the quick response..

	My SUN E4500 has 10 400 MHz processors.  I would guestimate
	that 1 Xeon processor would probably equate to 2-3 400MHz
processors, but
	I'm not sure.
	
	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


iD8DBQFFnQ2joyy5QBCjoT0RAhPzAJkBB9RMEexahq91GmcyBdiQ6PPdhACe
JT3H
Sz+zMWLCQ+4yXdVKc3vEp4I=
=ZjeV
-----END PGP SIGNATURE-----

-- 
To unsubscribe, email: suse-oracle-unsubscribesuse.com
For additional commands, email: suse-oracle-helpsuse.com
Please see http://www.suse.com/oracl
e/ before posting

> -----Original Message-----
> From: Peter Santos [mailto:psantoscheetahmail.com] 
snip
> 	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?
Snip
If one of your CPU boards fails outright, I dare say the OS
will crash
with it. Sun apparently does have some predictive failure
technology
that allows the OS to monitor CPU cache problems and map out
the CPU
preemptively, but that is only one of MANY things that could
go wrong.

Commodity Intel boxes don't have that capability, you are
right (some of
the Fujitsu super computers might).

My experience:
I've never had a modern Intel box (Dell 2650, 2850, 6650's
and 2950's)
with a CPU or motherboard failure. It happens don't get me
wrong, just
apparently not to me. On the other hand, when I was admin of
a Sun E10K
and several smaller boxes we had MULTIPLE "CPU
board" failures. I'm
investing in Linux on Intel based on my experience.

In my opinion IT IS FAR MORE LIKELY that you will experience
a software
failure or other human failure that causes your server to
crash or
malfunction than it is for your motherboards (good quality
manufacturer)
to fail.

Andy

-- 
To unsubscribe, email: suse-oracle-unsubscribesuse.com
For additional commands, email: suse-oracle-helpsuse.com
Please see http://www.suse.com/oracl
e/ before posting

	
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


iD8DBQFFnQ2joyy5QBCjoT0RAhPzAJkBB9RMEexahq91GmcyBdiQ6PPdhACe
JT3H
Sz+zMWLCQ+4yXdVKc3vEp4I=
=ZjeV
-----END PGP SIGNATURE-----

-- 
To unsubscribe, email: suse-oracle-unsubscribesuse.com
For additional commands, email: suse-oracle-helpsuse.com
Please see http://www.suse.com/oracl
e/ before posting

-----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

> 
>
iD8DBQFFnQ2joyy5QBCjoT0RAhPzAJkBB9RMEexahq91GmcyBdiQ6PPdhACe
JT3H
> 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+k073lFxITyfg1gCf
ZKdL
PXextixtfDRrX1zyqCd/In0=
=WkEZ
-----END PGP SIGNATURE-----

-- 
To unsubscribe, email: suse-oracle-unsubscribesuse.com
For additional commands, email: suse-oracle-helpsuse.com
Please see http://www.suse.com/oracl
e/ before posting