I have simular old database on E4500 servers. DELL 2950
servers (2 x 2 core
CPU) or 2850 (2 x 1 core CPU) are much faster and much more
reliable.
We considering using RAC or splitting big database into a
few smaller ones
and using cold heartbeat cluster + dataguard, but still
staying on cheap 2
cpu servers (when you come out of 2 cpu, your price per CPU
growth
dramatically, and server's usability drops).
ASM don't buy much except flexibility and IO load balancing
- it will remind
your old veritas VM system with easy disk migration and so
on. Linux have
not LVM like Veritas (well integrated and with reliable
online disk
rearrangement).
We already migrated from old Hitachi 99xx storage to NetApp
920c cluster
(using the same FC network, and using Veritas for online
disk migration),
with 0% downtime, and without any loss in performance, on
the same E4500
servers. I believe that we will stay with software iSCSI on
Linux, except if
we need extremely high cpu performance (iSCSI eat some 10 -
15% of CPU and
disk io).
But we don't consider 10.1.0.4, we consider 10.2.0.2 or
later. The reason is
that 10.2.0.4 is better tuned for the 64 bit linux, and have
less bugs in
ASM.
ASM is an interesting beast. It is not normal file system
and cause a lot of
headache, esp. in non clustered (non RAC) case. I shpould
not use it, if
possible. But it have benefits of better disk load balancing
and online disk
relocation. You have not other choice in case of RAC (OCFSv2
is not stable
enough for the primary database; raw devices cause a
permanent support
headache), but for the stand alone DB, it is a big concern
(no direct access
to the files; depencency of cssd, broken shutdown sequence
in Linux; no
monitoring by system tools; and many other drawbacks). So,
it is not clean
for me, if we should use ASM or should not (if we will not
use a RAC) - may
be, I will use ReiserFS with lvm2 and with iSCSI (switching
from iSCSI to
FCP if required - I dont think so, but if necessary, we can
do it).
Don't forget, that SLES9 SP3 have async io bug until at
least build 282 (64
bit servers, I mean). I am not sure, if this bug is fixed in
the kernel 283.
----- Original Message -----
From: "Peter Santos" <psantos cheetahmail.com>
To: <suse-oraclesuse.com>
Sent: Wednesday, January 03, 2007 11:00 AM
Subject: [suse-oracle] re: 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
--
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
|