RE: Oracle vs SQL Server

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_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of stephen booth Sent: Monday, 2 October 2006 2:40 AM
To: sbecker6925_at_gmail.com
Cc: oracle-l
Subject: Re: Oracle vs SQL Server

On 01/10/06, Sandra Becker <sbecker6925_at_gmail.com> 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')
--
http://www.freelists.org/webpage/oracle-l


--
http://www.freelists.org/webpage/oracle-l