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@(protected)>
To: <suse-oracle@(protected)>
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+AJ0QeCb6GAT375q0IYpvFOnMzsHp7wCdHSe4
5CmYA29B7rqtICdguUE9BZ0=
=WsLj
-----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
--
To unsubscribe, email: suse-oracle-unsubscribe@(protected)
For additional commands, email: suse-oracle-help@(protected)
Please see http://www.suse.com/oracle/ before posting
