Re: Oracle out the door
- From: "Mark Brinsmead" <pythianbrinsmead@xxxxxxxxx>
- To: mccdba1@xxxxxxxxx
- Date: Wed, 30 Apr 2008 19:09:41 -0600
Fair enough. I have had my share of PHBs like this.
Sadly, though for many of the problems cited, the only real "fix" may be to
migrate from SQL server to Oracle. :-)
Of course, in this thread, we're not really talking about migrating from
Oracle to SQLserver, but rather from Oracle to MySQL. The cost "savings"
(on license fees) are even greater here, but then, so is the magnitude of
the differences in features and capabilities.
I've had the opportunity to see numerous production applications running on
MySQL, and many run quite well indeed. But I positively *cringe* at the
thought of running a production system on MySQL when management, end users,
and maybe even developers have expectations based on their old Oracle
environments.
Imaging a conversation with management that starts off with this statement
from a DBA: "I have found the cause of the huge performance problem with
the new application. All we need to do is add one index! When would you
like to book the 6 hour outage to do that?" :-)
Perhaps better is an example that I saw at the desk next to me today.
Coincidentally, I think it may actually have been an application recently
migrated from Oracle 8.1.6 to MySQL5. The DBAs were paged at 11:00 AM
because of a debilitating performance problem. After about an hour of
analysis (and not a little bit of guessing; MySQL has precious little
instrumentation) it was concluded that the "problem" was simply a missing
index.
It was estimated that the index could be created in 5 to 15 minutes, but the
entire table would be locked for duration -- in essence, the application
would have to be "down". This was definitely an "emergency", so management
agreed to the downtime, and the index was built.
Excellent news -- the index build took only 3 minutes; production seemed to
have faster storage than the test system. Sadly, the database crashed (on a
segmentation fault) almost immediately after the index build was completed.
On Wed, Apr 30, 2008 at 8:08 AM, dba1 mcc <mccdba1@xxxxxxxxx> wrote:
> O.K. Upper level management may NOT care what kind of problem on SQL
> Server.
> My boss always say: I make decision and you fix problem.
>
>
> *Rich Jesse <rjoralist@xxxxxxxxxxxxxxxxxxxxx>* wrote:
>
> Having added SQL Server 2K/2K5 to my resume in the past year I can offer a
> SQL Server hit list for the seasoned Oracle DBA:
>
> 10) Regular rebuilding of indexes and reclaiming space.
> 9) Temp "result" tables are the norm for programming.
> 8) Escalating Blocking Lock City!
> 7) Cursors are evil here.
> 6) Troubleshooting is easy: Reboot
> 5) A hier-WHO-cical query???
> 4) Indexes mixed in with table pages ("Charlie Foxtrot" in military
> jargon)
> 3) Corrupted pages ("blocks" to the Ora DBA).
> 2) Everything should be in "dbo", right?
> 1) Welcome to 1990!
> ...
>
>
--
Cheers,
-- Mark Brinsmead
Senior DBA,
The Pythian Group
http://www.pythian.com/blogs
Other related posts:
