RE: Oracle vs SQL Server
- From: "Peter McLarty" <Peter_McLarty@xxxxxxxxxxxxxxxxxxxxx>
- To: <sbecker6925@xxxxxxxxx>
- Date: Mon, 2 Oct 2006 12:45:11 +1000
Hi
We supply applications that run on both platforms and I would have to
say that firstly that you need to assess all your requirements
thoroughly up front. You are not comparing apples to apples when you
compare SQL server to Oracle. There are a lot of things that you have to
do differently to get it to behave. If all of your apps are COTS then it
is somewhat easy as you simply arrange the vendors to migrate the apps
to SQL server and then you shuffle off to SQL Server School and learn
about its odd behaviours like locking.
If you have in house applications then depending on your application
complexity you might have some long lead time to recode and test against
SQL server and without adequate resources that may be a very long time.
Your cost of migration for in house apps may be a lot less than Oracles
pricing.
If you have to go this path then I suggest you get the training up
front.
As you mention Java, remember that for Microsoft that Java is only
supported to keep it's a out of the noose over its stoush with Sun not
because its want you too use it. So support from MS with Java issues and
MS databases may be a little problematic.
Peter McLarty
Technical Consultant
Service Delivery
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of stephen booth
Sent: Monday, 2 October 2006 2:40 AM
To: sbecker6925@xxxxxxxxx
Cc: oracle-l
Subject: Re: Oracle vs SQL Server
On 01/10/06, Sandra Becker <sbecker6925@xxxxxxxxx> wrote:
> My boss believes that if Oracle can't come down in price to that of
SQL
> Server, we should just switch. I have never used SQL Server so I had
> nothing to draw on other than what I've heard. We're a small company
with
> limited financial resources, but I believe the decision should be
based on
> more than strictly price. To that end I have three questions.
>
> 1. Is there an article comparing either 9i or 10g (currently on 9i
Standard
> One Edition preparing to migrate to 10g Standard Edition) with SQL
Server
> 2005? We run on RHEL3 and will be moving to RHEL4 within then
next
> month or so on a Dell 64 bit dual core server. I have reviewed the
articles
> mentioned on Tom Kyte's website, but nothing did a comparison of
Oracle
> and SQL Server 2005, which is the release my boss is considering.
If you're using Linux then you cannot use SQLServer, it only runs on
Windows! This could be a consideration if you don't already have a
Windows Server estate. Not just the costs of procuring the hardware
and OS but also the costs of hiring training up Windows sysadmins
(being able to admin Windows desktops is a start on admining Windows
server products but only a slight one, it's a very different ball
game).
I've not seen much information comparing Oracle 9i/10g vs
SQLServer2005. some about earlier versions a while back (mostly FUD
from Microsoft or their shills). I do have a book which covers how to
admin SQLServer2005 from the point of view of an Oracle DBA. Not read
much of it but what i read seems to indicate that SQLServer is a pig
to administer properly, if all you need is the defaults then it's fine
but if you need to get 'under the hood' then you're fighting it all
the way (I get the impression that 'Performance tuning' = 'Buy bigger
hardware').
Where I work about half of our database server estate (number of
installations) is Oracle, about one third SQLServer and the remainder
a mixture of legacy and just plain wierd systems (e.g. CICS, Tamino,
DB2, PACBASE &c). Of these it is SQLServer that gives us the most
hassle and suport calls by far. As I'm purely Oracle I don't know if
this is due to inherant faults in the product or the administrators.
If your manager thinks that Oracle is expensive then he should
consider the cost of a major loss of functional uptime or a few days'
transactions on core business systems due to databases locking up,
corrupting themselves and needing to be restored from backup with no
way to roll forward.
>
> 2. I know absolutely nothing about Java code. We develop and deploy
Java
> code for a very specific application for a specific industry. The
code uses
> PL/SQL procedures and sequences extensively. It also uses a
db_link to
> move data from production to a demo database for our new customers and
> for demonstrating new features for current customers. What might
be
> involved in changing the code? Would it need to be changed at all?
> Obivously,
> it would have be tested under load.
>
Moving RDBMS will result in code changes. SQLServer does not use
PL/SQL and has many other differences that would require code changes
in migrating applications.
If you're going to put yourself through the pain and expense of
migration then you'd probably be best served widening your options and
looking at MySQL, PostgresSQL and others. If you're already using
RHEL then the odds are you already have access to MySQL and/or
PostgresSQL and may be able to get then supported through your RHEL
support contract for minimal or zero extra cost.
Stephen
--
It's better to ask a silly question than to make a silly assumption.
http://stephensorablog.blogspot.com/
'nohup cd /; rm -rf * > /dev/null 2>&1 &'
(There's a strong arguement for the belief that running a command
without first knowing what it does is 'Darwin in action')
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
