-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Alexei,
I read about the SuSe async io bug. Would you happen to
have
more information so that I can look this up ? Bug Number ?
Also, our Veritas license is old and we no longer have
support, so
my migration would have to be different.
I'm looking into how to convert the endian format from Big
(Sun) to
little (Linux) and migrate the database with as little
downtime as
possible.
Can you tell me what you mean by "cold heartbeat
cluster". I'm not
sure what you are referring to ?
- -peter
Alexei_Roudnev wrote:
> 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 ???
>
>
> 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
iD8DBQFFnQ8loyy5QBCjoT0RAoIrAJ9GduJS+dUYd9yBIcRE1ixTHBN27gCf
QQbE
7CHhAi4jWOauev2VDDzhr8U=
=dQf0
-----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
|