Posted by Kellyn Pedersen on Feb 9, 2011
No, not that kind of trigger this time around… :)
Anyone can fall into this scenario. Everyone is carefully taking time to test before applying a couple patches to address an async I/O issue in Oracle to ensure all testing environments are exact, all patching is approved by everyone that would like to review it. No one is willing to pull this trigger and apply the patches until they are absolutely sure they have every SQL statement, every network tweak, every application scenario looked over and over again.
Suddenly, the database reaches what every DBA dreads- that threshold where standard processing is now in the range of the I/O bug, not once a month but multiple times a week due to one or two queries that are pivotal to production processing. The good intentions, hoping to avoid a production outage has now inadvertently caused them. The customer is frantic, (as expected) and you, as the DBA, are the one quickly expected to assess the situation and attempt to come up with a battle plan.
Read the rest of this entry . . .
Posted by Alex Gorbachev on Jun 28, 2010
Updated: 29-Jun-2010, 30-Jun-2010.
For me, ODTUG Kaleidoscope 2010 started on Friday with the ACE Directors briefing. Best practices topic was touched there slightly and I twitted about it. I decided that the feedback deserves a blog post so I’m simply quoting the conversation here. If you have anything to add, you know where to find the comment box.
Posted by Sheeri Cabral on Apr 16, 2008
Yesterday I presented “Best Practices for Database Administrators” at the MySQL User Conference and Expo. I was successful in streaming the live video on www.ustream.tv, and you can see it in totality at http://www.ustream.tv/recorded/352479.
The slides are available in pdf form. And here are some of the links I spoke about:
cacti
nagios
rt
MySQL 5.0 manual
explain
show variables
show status
data types
procedure analyse()
mysqldumpslow‘s manual page says “Use mysqldumpslow –help to see the options that this command supports.”
mysqlsla
mysqlreport
Maatkit, contains mk-query-profiler and mk-table-sync
mytop
innotop
Posted by Shakir Sadikali on Mar 12, 2008
I’ve found lately that munching on carrots with French dressing is more satisfying than broccoli. Maybe it’s the tang-and-crunch combination. In any case, I was crunching away yesterday while thinking about how to answer a question one of our newer start-up clients asked me.
No one has ever come out and formally asked me for a document that states “Best Practices to Scale Application X”. It is an unusual demand, since it’s something many of us at Pythian have implemented, but it’s been more of an ad hoc, iterative process — and rightly so, since architectures must be so organic, and so tailored to the application. What’s more, no one has ever brought us on board so early in the game that we have a hand in actually — gasp! — doing the design and data-model from the get-go. Woo hoo!
Now, a little background. I have built and maintained a few systems. Some of them even supported over 100k concurrent users. These databases didn’t run RAC either (although I do support two very high profile RAC environments now). So, having been in the trenches and knowing what it takes to make a DB move, I got to thinking about some of the basic fundamentals. There are always rules of thumb, right? This is what you need to know to start with building a scalable high-performance system based on stuff that I’ve seen. Obviously, this assumes a database-centric app. Let’s start with the first ten principles.
Read the rest of this entry . . .
