Re: Re : Losing out to SQL Server
Date: Sun, 17 Feb 2013 09:31:58 -0600
Message-ID: <CAFH+iffYDqGjqY0fAG-1iPFKP3nCh8iA1dvLqHg-5bRmERS8Gg_at_mail.gmail.com>
William,
Comparisons between Oracle and SQLServer used to start with "Oracle has row-level locking" and continue from there. It's no longer quite that easy. For many applications, SQLServer has become a viable alternative. But it isn't Oracle. Take a look at the comparison Dan Morgan has posted at http://www.morganslibrary.org/reference/sqlserver.html.
I tend to discard much (all?) of the hype surrounding benchmarks and focus on what the database is supposed to do for my customer - be it internal or external. Due the very real differences in the way Oracle and SQLServer are structured, the performance of the product in question can be tremendously impacted by the type of data, frequency of use and degree of data manipulation required including conversions and sorts. As Dan points out:
" In SQL Server, a table is basically a big linked-list and the data blocks are essentially the leaf-blocks of the cluster index. Those blocks are then doubly-linked back and forth so you can traverse the table in a full table scan or in an index range scan. In fact, an index range scan of the whole table is essentially (physically) the same as a full table scan. I'm not sure exactly why, but SQL Server has always had trouble with corruption of these link-list pointers. Run DBCC to check (and fix) problems with these pointers. No comparable issue exists within Oracle."
Additionally, Oracle is still way ahead of SQLServer when it comes to Scalability, Load Balancing, High Availability, and Recoverability.
Yes, there are plenty of 'workarounds' in SQLServer to produce functionality that approaches Oracle in these areas (see MSDN or just Google) but many involve a degree of cost or management expertise/attention that makes them somewhat unsatisfactory. As an example, remembering that a SQLServer 'Database' equates to a tablespace in Oracle, Darin Strait at http://serverfault.com/questions/385818/alwayson-sql-server-2012-any-option-for-true-active-activepoints out:
" Microsoft SQL Server does not support a 'real' load balancing scheme out of the box. AFAIK, this is still true with SQL Server 2012. (Someone will enlighten me if I'm wrong.) It doesn't matter if we are talking about database mirroring or AlwaysOn or clusters.
If you want to load balance your databases, you have to do the hard work yourself with some sort of sharing, federation or replication. (Note that federation (by views) has been in the product since SQL Server 2000, it just wasn't very popular.) And, of course, that would mean modifying either your databases or the apps themselves, which is almost always either too much work or violates your vendor agreements. With 150 databases, it's just that much more insurmountable.
You can have an active-active cluster, but the thing is that you would have to carefully distribute your databases on your nodes to divvy up the load. With 150 databases, this might be more granular than if you just had five databases, but if you have one database that is a ton of load and 149 that are light-weight or rarely used, you might still find one machine bogged down and the other isn't. And, some databases are busy sometimes and hardly busy at other times. Which means that everything might come down to when a user decides to run some heavy process.
Of course, you have to be able to support all of that load on a single node when you fail over, for whatever reason, even if it is something mundane like patching Windows. If you only patch during known slow traffic periods, that's great. If you don't have slow periods, or if the failover occurs because the hardware actually has a fault, the other node might not take the load and your users will be out of luck. If you think about it like that, having the second machine "doing nothing" isn't quite so irritating. At least you know that it will take all of the traffic that the primary usually does."
With respect to price, it is true that SQLServer is less expensive when you compare MSRP for the database product alone, but this difference may be diminished somewhat as Microsoft has changed the pricing formula for SQLServer 2012 to a 'per core' model which may come as a shock when it's time to upgrade from SQLServer 2008. You also need to negotiate. Oracle pricing can be flexible if you work with your sales rep. By utilizing the appropriate version of database software for the appropriate task (i.e. SE for development databases, etc.) and application requirements, you can minimize the cost differential. As previously mentioned, having multiple databases (not schemas) per server is also an option. Although SQLServer can have multiple instances per server, in practice this is much more difficult to manage than having multiple Oracle DBs per server. There is no comparable equivalent for an Oracle 'service', although my guess is a work-around exists.
Overall, the I think the answer to "How do I convince management to use Oracle instead of SQLServer?" comes down to "It depends."
On Sat, Feb 16, 2013 at 9:19 AM, David Robillard <david.robillard_at_gmail.com>wrote:
> Hi WGB,
> > Trying to sell a $1 million dollar solution that SQL Server can cover for
> > a few hundred thousand is killing me.
>
> I've been in your position often and it's not easy. One thing that worked
> well for me was to use the existing Oracle infrastructure for the new
> project. Consolidate various applications into a single database using
> different schemas. This way management was happy because their investment
> in Oracle was being leveraged for more than one business requirements. And
> you as a DBA get to keep working with Oracle.
>
> Also, in your cost analysis, don't forget to factor in the install time,
> knowledge/strenght of the sysadmin/DBA team on the product, time to
> write/update the documentation, effort required to setup and test the
> various failure scenarios with the related backup and restore operations to
> fix them, HA setup and testing, cost and time of training personnel or devs
> on the product along with possible marketing benefits/issues for your
> corporation if using Oracle vs. another RDBMS. That last part may sound
> strange, but one of my previous job they had to run Oracle for the «
> prestige » of telling their potential customers that they were using
> Oracle. Hey, every trick counts no? :)
>
> If all else fdails and you're ready to try another RDBMS then maybe check
> PostgreSQL [1] which IMHO is better and has more features than MySQL. Or
> consider EnterpriseDB [2] which is a commercial product built on top of
> PostgreSQL, but with Oracle-like commands which makes the learning curve
> easy and drives the cost way down.
>
> HTH,
>
> David
>
> [1] http://www.postgresql.org/
> [2] http://www.enterprisedb.com/
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>
-- http://www.freelists.org/webpage/oracle-lReceived on Sun Feb 17 2013 - 16:31:58 CET