Cross Compare of SQL Server, MySQL, and PostgreSQL

Very nice comparision of SQL Server, MySQL and PostgreSQL servers.

oursql-conferences bi-monthly synopsis

Oursql-conferences is a discussion list for a community conf, not to compete with but augmenting the Sun/MySQL one. We're here to discuss such an event, its potential, dates/location, and get it going!

It's a public group, please blog & tell others about it!
Sheeri suggested OurSQL, like her podcast.

Members: 91

Discussions:

Conference Outline
By Eric Day - May 6 - 4 authors - 5 replies

Would a Virtual Conference Work?
By Sheeri K. Cabral - Apr 29 - 7 authors - 11 replies

How about a community build?
By Arjen Lentz - Apr 27 - 6 authors - 6 replies

Creation of oursql-sources Group
By Mark Schoonover - Apr 25 - 1 author - 0 replies

What about MySQL Camp?
By Keith Murphy - Apr 25 - 2 authors - 1 reply

And let's not forget languages!
By Parvesh Garg - Apr 24 - 9 authors - 11 replies

Using the Perl model
By Davide Ferrari - Apr 24 - 8 authors - 13 replies

-- Mark

oursql-sources bi-monthly synopsis

Oursql-sources email group was created to discuss community MySQL builds, patches and adding features using the GPL'd version of MySQL sourcecode.

Members: 27

Discussions:

The MySQL CLA - A barrier to community contributions?
Source trees, Public Development and Builds - Version control, community contributions.

-- Mark

Did You Pass MySQL Certification at the Conference?

If you've passed your CMA, CMDBA, CMDEV or the Cluster certification, be sure to signup for the MySQL Certified Professionals LinkedIn group. This group is for certified MySQL professionals, recruiters, human resource managers and other technical hiring managers.

This group is not affiliated with Sun or MySQL AB in any way.

Log Buffer #95: a Carnival of the Vanities for DBA

Welcome to the 95th edition of the Log Buffer, the weekly review of database blogs! The number 95 seems to be a popular number, as it's also the outside temperature here near San Diego, so grab something refreshing to drink, edition 95 is taking off.


In the MySQL 'sphere...

Discussions from the MySQL Conference continue. Arjen Lentz starts an email list for community organized conferences named OurSQL-conference. As open source projects go, the discussion turned to source code and to keep the discussion alive, OurSQL-sources was created. Thanks to Sheeri K. Cabral for the OurSQL name. If you haven't seen nor heard of Technocation, be sure to stop by and say hi to Dick. If you're a fan of cheatsheets, the EXPLAIN Cheatsheet is available for download.

MySQL monitoring is a hot topic, with Baron Schwartz blogging about Cacti and monitoring MySQL. This is one area of MySQL that needs a boost from the community.

A technology I've enjoyed using, and have blogged about, is DRBD and its application to MySQL. Florian writes in response to DRBD and MySQL Just Say No, with the appropriate response of DRBD and MySQL Just Say Yes! MySQL Performance Blog also weighs in on the DRDB vs Replication Battle.

When your database performance needs to heat up, be sure to investigate how disk performance can benefit single client workloads from MySQL Performance Blog. InnoDB tables are MySQL's default transaction oriented storage engine. Two in depth articles on InnoDB Plugin Part I and Part II compression performance may stoke the fire in your server.

High temps tend to kill servers, and having backups is very important. We've all heard of SQL injections, but not in the context of having reliable backups, as well as tested procedures to restore your system. Farhan blogs about being prepared for SQL injection attacks roasting your database. Be prepared.

Is there a positive SQL Injection attack? Bruce Schneier thinks so.

Pythian announces a multitude of videos from MySQL Conference 2008 are available!

Alan Hargreaves' blog discusses the biggest news from the MySQL Conference 2008.

Lenz Grimmer blogs about 186 MySQL Gems from Sun bloggers.


On to Oracle...

Jarneil writes about moving data within disk groups inside of Oracle. Jonathan Lewis gives a rundown where order by is causing issues.

Oracle licensing is hitting the blogs at Radio Free Tooting.


SQL Server

Kimberly L. Tripp provides a plethora of SQL related links with her accidental DBA workshop. Aaron Bertrand shares his opinion on money, the money data type that is and follows that up with SQL Injection and how to protect your SQL server. Later in the week, Port25 shares some more info on SQL injection.

A close cousin to Carsten's pop quizzes, Denis Gobo gives a quick teaser on ISNUMERIC, what's your answer? (Don't peek at the comments!)

Microsoft has big plans on keeping SQL server updated, and Benjamin Jones follows up with SP3 for SQL Server 2005.

Aussie SQL Server Bloggers write about dealing with duplicate indexes on tables with precisely identical definitions.

We all know MySQL has a query optimizer, and Craig Freedman's blog discusses SQL Server optimizer with conversion and arithmetic errors.


Returning closer to the Sun, PostgreSQL

Most of us have to work in a mixed open source and Microsoft environment. Postgres Online Journal blogs about setting up PostgreSQL as a linked server to 64bit SQL Server, and discusses calculating running totals and sums too.

Finding MySQL DBAs is a challenge. Josh Berkus tackles the exact same issues in finding PostgreSQL talent.

In the not sure where to fit this dept...

The age old debate: is it "See-qwel" or "S-Q-L"? from the OracleSponge blog. I know some say "MySeeQwel" or "MyS-Q-L", but "MeSQL"?? Check out 451 CAOS Theory on their take.


Overflow

I'd like to thank Dave at the Pythian Group for inviting me to edit this week's Log Buffer. All typos, deliberate mispelings, grammatical or punctuational errors are features, that are copyrighted and trademarked entities of Mark Schoonover. :-)

New Community Mailing Lists

Discussion on community builds, patches, adding features, etc using GPL version of MySQL source code. It's also a public group, and if you're interested in hacking MySQL source code, please join.


oursql-sources

It's been mentioned before, but I'll mention it again. There's been talk of a community conference, not to compete with but augmenting the Sun/MySQL one. We're here to discuss such an event, its potential, dates/location, and get it going! It's a public group, please blog & tell others about it! Sheeri suggested OurSQL, like her podcast. Created and managed by Arjen Lentz

oursql-conference

New Poll: Will MySQL Closing Enterprise Source Impact You?

MySQL announcement during the 2008 User Conference really sparked some responses from the community. Many comments on Slashdot. More on Jeremy's blog, and still more on Mike Krukenberg's blog.

Will MySQL closing enterprise source impact you? Please take the poll, it's open until 06/01/08!

How to Hire a Great MySQL DBA

Hiring a MySQL DBA can be challenging, especially when the demand for MySQL DBAs is greater than there are qualified people to fill those positions. This article will go into some details on how to recruit, recognize, and interview a great MySQL DBA. (For the rest of this article, MySQL DBA and DBA are the same.)


1. Preparation

It's very important to determine your company's needs before starting your search for a DBA. Is your company a small start up, or a mature company that has a large replicated or clustered environment? Is this DBA position needed to support developers? Will this position support 24/7 operations? Will a smart candidate be able to learn as they go, or do you need a rockstar now that can handle your requirements from day one? By brain storming with various department managers or technical staff, the requirements will become clear as to what's expected for this position. Just like a software project, determining "what" the software needs to do leads to developing the requirements for the project. Knowing "what" the DBA needs to do will help drive the requirements to find the right DBA. Take as much time as possible to develop these requirements, this is no time to rush. Yes CEO/COO/CFO/CIO, it's that important. Be sure to look at the dynamics of the team or teams that will interface with this person. Fitting well within the team is just as important, or possibly more important than technical requirements. Technical aspects can be learned, but trying to change the wrong personality is near impossible. It always costs less to plan for the right candidate than it is to hire off the cuff, then let someone go later on. Not only will you suffer having to hire twice, you'll find out the hard way just how much damage the wrong person can do to a company.

Someone in your company has been doing the DBA role as an additional duty. This person could be your system administrator, or maybe a developer and they would be great at helping to develop the requirements for the DBA position. They already know which aspects of MySQL impacts the company the greatest, and they especially know which parts they don't like doing, not skilled for, or their time is better spent doing what they were originally hired to do! Use them to help prepare to write the job description.


2. Writing the Job Description

Now that you have all the details in front of you, it's time to tackle the job description. It's very important to keep in mind that the job description is your first contact with a potential DBA. If the description shows a lack of organization, wrong terminology, or requirements that don't make sense, for example - 10 years experience with MySQL 6.0 - it'll be a red flag to potential candidates that your company doesn't know what they are doing. I know this is harsh, but you never get a second chance to make a first impression. You want your company to stand out from the crowd of the other DBA positions. You want your description to yell out "Hey, you want to work for us! We're a smart company looking for a smart DBA."

The format of the job description should be in the same standard format that's used by your company to advertise any other IT position. How should you describe your job requirements? This is all based on step 1. Some managers might say they need to have someone with 4 years experience with version 5.x replication, or whatever. What if you get a candidate that only has 2 years experience, but you recognize that this person is really intelligent and highly motivated? Can you relax that requirement? Personally, I don't put a bunch of emphasis on years of experience. The smart DBA will master most things in 18 to 24 months working full time, the exceptional DBA in less time. Stick with the requirements, don't add a lot of fluff to the description. Say something about your company, outline the job details, mention who this DBA will report to, describe the team, and the working hours. If it's 24/7, carry a cellphone, say so. If there's relocation, say that too right up front. Benefits are important as well. Think of this job description as your lure to catch the attention of a DBA. The job description is as much marketing as it is technical!


3. Where to Post Your DBA Opening

What's the best way to market your DBA position? First and foremost, on your company's website! After that, it's time to hit the streets. Talk with your current system administrator, or developers to find out if they know of someone that's a DBA. Most of the high end DBAs are already employed, and may not be on the market, but could be persuaded to move. Check if there's a MySQL Users Group in your area. If there isn't one, check to see if there's a Linux Users Group (LUG), or Perl/PHP Users Group. If your shop is based around software produced by the Redmond giant, research those user groups too. This is a grass roots search for just the right DBA. The MySQL conference is coming up in April, and that's a great place to recruit. If you have a developer or system administrator that can interview, send them to the conference and have them post the job opening on one of the public bulletin boards in the hallway. They could do initial interviews during the conference, and possibly bring back some resumes. Sometimes just chatting with someone they sit next to could be your next DBA. What a cost effective way to get the recruiting process going.

After exhausting the above, then you may have to turn to head hunters or posting the position on the various IT related websites. Having a clear job description helps here too. Just be prepared for an onslaught of resumes. There maybe other places to post your opening, just use your best judgment.


4. How to Tell if You Have a Great Candidate

This part of the search is where the rubber meets the road. You've got a few resumes of some highly qualified candidates. How can you tell which one is the really great candidate? Here are a few things to consider:


      A. Passion?

Do they have passion for the position? What I mean about passion is do they get excited about their work? Is being a DBA just a day job, or an obsession? Are they involved with various user groups, participate in MySQL mailing lists, blog about MySQL? Have they passed MySQL certification? I'm sure you get the idea, do they love what they do!


      B. Self Educating?

Highly important skill for your candidate. Sending them to the conference is great, but what about the rest of the year? Having the ability to read quickly and understand technical documentation is a must. Ask the candidate if they have a home lab to experiment with to learn new technology. What's on their reading list? Subjects outside of being a DBA are important too. The objective here is to see if the candidate is motivated to learn on their own and then apply what they've learned.

      C. Specific or General Skills?

Are you looking to fill a DBA position only? How about a generalist that could also backup your system administrator? Maybe someone with development skills? The required skills should be obvious from step 1.

      D. Team Player?

How well will the candidate fit and communicate with the team? Can you tell if there would be a personality clash with another team member? How well do they work under pressure?

      E. Outside Interests?

What's the candidates hobbies? Maybe they help with an open source project, or involved with something outside of IT. In any case, look for the passion they have with what they are doing. Well rounded individuals bring balance to teams.


      F. MySQL Skills?

Last but not least is the skill set. Being last might surprise you, but by now, your stack of resumes should have answered this part. If you happen to be a hiring manager, or recruiter and don't feel comfortable with this part, don't despair. If you need to verify these skills, but you can't do it yourself, consider outsourcing this part of the interview. There are several independent MySQL support companies that can handle the technical interview for you. Maybe you can contact Planet MySQL top posters and see if they'd be interested. If your candidate is already MySQL DBA certified, that's a huge plus!


5. The Phone Screen

Always conduct a phone screen! You need to be just as organized with your phone screen outline as you are with the job description. Remember, if you're unorganized on the phone, the company is unorganized. It's also harsh, but it's that simple. Maybe have multiple people participate in the phone screen. Have it organized by time and department. If you're hiring a DBA to support your programming staff, have the hiring manager, a system administrator and a developer participate. The phone screen is a great way to get an introductory feel for a candidate. You'll find out if they can communicate well verbally, and get an idea of what their personality is like. Whatever you end up doing, try to keep the phone screen no longer than an hour.


6. In Person Interview

You've narrowed down the potential candidates, and have invited them for an in person interview. Like the job description and the phone screen, the interview needs to be just as organized. If the candidate is coming from out of town, have them interview on a Friday. If you think this candidate is "the one" then have them stay over the weekend, all expenses paid. You want the candidate to like the new area they will have to move to. Maybe they have family they will also have to move. You want to know upfront that the candidate likes the area, and will stay. You don't want to find out 6 months from after they were hired that they really didn't like the area, quits, then moves back to where they came from.

Interviewing a local candidate can happen at anytime during the week. Take as much time as you need to conduct this interview. Do you need more than one interview to know if this is "the one"? That's up to you, but if you've done your homework from the previous steps, you'll have a good handle on who's "the one". All the candidates you've brought in to interview in person should be 90% to an offer. If you have any reservations that they are not at this level, don't interview them in person.


7. Reference Check

You do professional and personal reference checks, right?!


8. Make the Offer

You've made it! You've found your DBA, congrats! By now, you should be 100% comfortable with your decision. They have the skills, fits well within the team and organization. Your company is one of the lucky few that have been able to hire a great MySQL DBA.


Conclusion

Hopefully this will give you some ideas on how to attract, determine, and hire a great MySQL DBA. I've intentionally left out stuff like salary and benefit negotiations, how to handle relocation or exact details on how to conduct an interview. These topics vary greatly from company to company. There are plenty of resources on the web to help. Good luck in your search for a MySQL DBA.