I was recently asked a question by someone who had attended my Shmoocon talk entitled “Why are Databases So Hard to Secure?”. (PDF slides are available). I was going to put this into a more formal structure, but the conversational nature works really well. I would love to see comments reflecting others’ thoughts.
This Sunday, March 9th, most locales in Canada and the US start to “save daylight” by “springing ahead” one hour. At 2 am local time (that would be “really late Saturday night” for the party-goers), the time jumps ahead one hour.
Have you ever heard the one about throwing hardware at a software problem? I have this nifty RAC system that supports some very public and very mission-critical apps, and one day (it was Sunday night) it starts choking. We’re getting enqueues. Slowly they start climbing. Ten nodes came to a crashing halt. I have now seen a ten-node RAC cluster come to crashing halt and completely lock up. Why, you ask? A simple SQL statement: DELETE FROM a WHERE b=c AND d=e;.
I’m a member of the Oak Table Network now! I’m so delighted and proud to be the part of that group and also very grateful for the invitation to join those bright people.
ASM is definitely one of the coolest technologies inside the Oracle Database. On the other hand, the ability of the storage arrays to provide a read/write access to a copy or a “snapshot” of its content is something we can easily leverage as an Oracle DBA. For a couple of weeks, I wanted to copy a database stored in an ASM Disk Group with one of those storage technologies and mount it on the same server; unfortunately, this is not supported even with 220.127.116.11. The good news is that I finally overcame all the obstacles to do it in a specific case. This post relates a couple of the tips I used to get to that result.
The database schema really should be source controlled in the same place as the application code, because otherwise how do you know what changes happened when, and which version of the code goes with which version of the schema. The problem I have is this — being a purist (and by the way, *not* a programmer so there could very well be concepts I’m missing), I really want to source control the DDL/GRANT statements and whatever that are applied to the production database, because that way anyone can see exactly what was run, and I can do a schema backup and compare to the source controlled version.
Please join me in encouraging Cary Millsap in making regular appearances on his new blog. Cary, my personal story – one of my first and most vivid memories of taking on a DBA role was when my mentor, Guy Arteau, bringing me a copy of your OFA paper with great awe and reverence and suggesting I study it carefully.
Well, Paul Vallee tagged me, and as I haven’t yet passed my probationary period I should probably answer the call…..Eight things about me that aren’t common knowledge:
n Stuffing Six Million Pages Down Google’s Throat, Tim O’Reilly brings up a point, and some questions. . . just how poorly the big search engines index small sites with large collections of data . . .But it’s worth thinking about absolute (and temporary) limits to the growth of Web 2.0. What constraints do we take for granted? What constraints are invisible to us? Read more.
The latest release of DBD::Oracle is now ready and can be found at: CPAN DBD::Oracle. It is a Perl module that works with the DBI module to provide access to Oracle databases. It is maintained by me, John Scoles as open source/free software, under the auspices of The Pythian Group.
The release has been fully tested with the latest version of DBI (1.601). A list of the changes and/or fixes in this release are included.