Re: Losing out to SQL Server
From: Mark Strickland <strickland.mark_at_gmail.com>
Date: Tue, 19 Feb 2013 12:28:47 -0800
Message-ID: <CAB9NSfMvCPQXbK6GLXdU70VV3CiEFA4fFJgVq92eJyAm=CDK5Q_at_mail.gmail.com>
We're a small company but both a SQL Server and Oracle shop for various reasons. I was historically an Oracle DBA (and MySQL) but now I'm mostly a SQL Server DBA with about 10% Oracle. We're moving the Oracle side of the house to PostgreSQL because we're completely virtualized on VMWare and Oracle has unfortunately adopted an evil licensing scheme for VMWare. The license is based on the physical cores, not virtual. Unless you use Oracle's virtualization, that is. We're not interested in migrating to OVM and we're not interested in running a mixed-vritualization platform. PostgreSQL will do just fine for what we need in an RDBMS. For our Big Data needs, we're using Hadoop.
Regarding SQL Server, it's a perfectly adequate RDBMS, in my estimation, and I'm quite fine with having that experience on my resume, but there are some things that are suprising and annoying. SQL Server cursors are very slow. SQL Server escalates locks and we have had to use a traceflag (like setting an Oracle event) in order to keep SQL Server from doing that and causing blocking locks. I've had to get used to using NOLOCK hints in SELECTs. Something you never have to do with Oracle. Out of habit, I tried to use a NOLOCK hint in an Oracle query the other day and didn't get very far :-) Another thing is that we occasionally encounter process stalls related to parallelism. The process just sits there accumulating CX Packet waits. The I/O counters don't move. This can go on for many hours. As a result, we have to set parallelism to '1' in particular queries in our application and we've had to set up an monitoring job to alert us to process stalls. There's plenty of anecdotal evidence online that indicates that other customers are experiencing the same problem but we haven't found a solution. Just the DOP=1 workaround. Unfortunately, when we encounter a stall, it's SLA-threatening and we have to fix it immediately which means that we can't let it continue long enough to gather the diagnostic data that would be required by Microsoft Support.
Date: Tue, 19 Feb 2013 12:28:47 -0800
Message-ID: <CAB9NSfMvCPQXbK6GLXdU70VV3CiEFA4fFJgVq92eJyAm=CDK5Q_at_mail.gmail.com>
We're a small company but both a SQL Server and Oracle shop for various reasons. I was historically an Oracle DBA (and MySQL) but now I'm mostly a SQL Server DBA with about 10% Oracle. We're moving the Oracle side of the house to PostgreSQL because we're completely virtualized on VMWare and Oracle has unfortunately adopted an evil licensing scheme for VMWare. The license is based on the physical cores, not virtual. Unless you use Oracle's virtualization, that is. We're not interested in migrating to OVM and we're not interested in running a mixed-vritualization platform. PostgreSQL will do just fine for what we need in an RDBMS. For our Big Data needs, we're using Hadoop.
Regarding SQL Server, it's a perfectly adequate RDBMS, in my estimation, and I'm quite fine with having that experience on my resume, but there are some things that are suprising and annoying. SQL Server cursors are very slow. SQL Server escalates locks and we have had to use a traceflag (like setting an Oracle event) in order to keep SQL Server from doing that and causing blocking locks. I've had to get used to using NOLOCK hints in SELECTs. Something you never have to do with Oracle. Out of habit, I tried to use a NOLOCK hint in an Oracle query the other day and didn't get very far :-) Another thing is that we occasionally encounter process stalls related to parallelism. The process just sits there accumulating CX Packet waits. The I/O counters don't move. This can go on for many hours. As a result, we have to set parallelism to '1' in particular queries in our application and we've had to set up an monitoring job to alert us to process stalls. There's plenty of anecdotal evidence online that indicates that other customers are experiencing the same problem but we haven't found a solution. Just the DOP=1 workaround. Unfortunately, when we encounter a stall, it's SLA-threatening and we have to fix it immediately which means that we can't let it continue long enough to gather the diagnostic data that would be required by Microsoft Support.
On the other hand, SQL Server BULK INSERT is easier to use than SQL*Loader. SQL Server Management Studio makes it easier to learn SQL Server for a n00b (such as myself three years ago) although I am otherwise quite old-school when it comes to GUI tools.
Regards,
Mark
Seattle
-- http://www.freelists.org/webpage/oracle-lReceived on Tue Feb 19 2013 - 21:28:47 CET