Quantcast
Viewing all articles
Browse latest Browse all 18769

Pen and paper as a DBA tool

“Hey DBA!  Remember that change you made for my group  four or five months ago? Well, we were waiting for things to get better but they have not. Can you change it back ASAP?!?”

I know several of you  DBAs after reading the above are reaching for their antacids.  OR something stronger.

Keeping track of what changes were made to which systems in your head is bound to bite a hard working DBA sooner or later.

This is one of those oh-so-obvious tips that will be ignored by many but it will come back to haunt like a cheap RAID array.   Get a notebook, a pen, and keep it by you when you work.  Now anytime you make a material change or perform a maintenance function on one of your systems, note what EXACTLY the change you made, the reason for the change,  plus the day and date.  It will take some effort to do this the first two times but you this to become an ingrained habit.  Keeping track of running myisamcheck, changing the IP address of a replication slave, or setting up a MyIsam buffer cache is tedious but it will pay off when you are assailed with something similar to the sentence that starts this entry.

And for those of us with poor rotten hand writing — take the effort to make it legible.  You may need to read it at 3AM after twenty hours of fighting a problem. Or  the poor person covering for you while you are on vacation can not tell if you changed max_connections or max_connect_errors and decides to set them both to zero.

So why not store this data electronically?  Well, Murphy’s Law aside,  it is very handy to have something to refer to that is portable, does not need electrons to read, and is based on a technology even the most pointy haired boss can understand.

And it helps to have a print out of your my.cnfs taped into the back of the notebook.

Here are the last two entries in my log.

  • August 30, 2010 — Installed UDF for calculating median value on IBMtest1.
  • September 10, 2010 — System ‘A1′ : changed DBBC.NumBlocksPCT from 66 to 20 in Calpont.xml. PrimProc process was not able to allocate 66% but was able to get 20%. Will slowly walk up setting until it fails again to determine maximum setting.

Image may be NSFW.
Clik here to view.
Image may be NSFW.
Clik here to view.
Image may be NSFW.
Clik here to view.
Image may be NSFW.
Clik here to view.
Image may be NSFW.
Clik here to view.
Image may be NSFW.
Clik here to view.
Image may be NSFW.
Clik here to view.
Image may be NSFW.
Clik here to view.

PlanetMySQL Voting: Vote UP / Vote DOWN

Viewing all articles
Browse latest Browse all 18769

Trending Articles