Steve Karam, The Oracle Alchemist, saved the skin of a harried LB administrator this week (that would be me), stepping up at the last moment to edit and publish the 60th edition of Log Buffer, the weekly review of database blogs. Thank you, Steve!
Now with the 11g we all can start the new release — at least on Linux x86 — so naturally, I was curious to see whether I was just throwing sparks without having a fire. Query Result Cache was the first new feature that I put to the test, only to discover that you can spend more than two minutes waiting on… guess what?
There’s an interesting dynamic going on right now in the DBA world. MySQL’s growth and installed base, as a function of its size three or five years ago, is perhaps five if not ten times larger than it was. In 2002 when Pythian’s MySQL services launched, we took on the platform at the explicit request of an existing customer that was primarily an Oracle shop, but that was adopting MySQL for some bolt-on systems. Today, MySQL is our fastest-growing practice in terms of new customer acquisition. The point I want you to take away from that is simply this: there are about five to ten times more high-value environments running MySQL in the world today than there were three years ago.
The 59th edition of Log Buffer has been published by Chen Shapira on I’m just a simple DBA on a complex production system.
Recently, I was asked to take a look at a query processing part of a client’s application which had started to perform slowly after the application had a maintenance downtime. The idea behind the processing was quite simple.The trick was to add a (redundant) CASE PROCESSED WHEN 0 THEN MOD(SUBS_ID, 7) end expression into ORDER BY clause..In this post I show you how I came to this solution.
The 58th edition of Log Buffer, the weekly review of database blogs, has been published by Jay Pipes (a.k.a J.Pipes) of MySQL AB on Design, Develop, Discover, Define.
For those of you expecting your weekly dose of Log Buffer in this space, it has been unavoidably delayed. It will appear around 3PM Eastern Time today. Hang tight!
So what is SQL Performance Analyzer (SQLPA)? The DBMS_SQLPA package enables you to register and compare the statistics of several SQL query executions stored in an SQL Tuning Set (STS). With SQL Performance Analyzer, you can compare the executions of queries before and after you make some changes to your database. As you might guess, I’m going to illustrate this new feature in Oracle 11g with a simple example.
So Management chooses to review the documentation generated from your database failover test and see that the time to switchover is slow and that there is still a possibility of losing some data. Enter standby redo logs. Rather than regurgitate the documentation, I have attached the links to the specific parts of the documentation. Since I’m focused on providing ways for you to “get the job done”, I have also included some SQL that uses dynamic SQL to generate a series of ALTER DATABASE ADD STANDBY LOGFILE commands to run on both the primary and standby databases. Have a look.
Wouldn’t “Automatic SQL Plan Management” be the 11g “killer app”? I’m just wondering… be careful it is part of Oracle Tuning Pack 11g! Before you answer this question, lets illustrate with an example how the “non-automatic”, “no tuning Pack” SQL Plan Management works.