PlanetMysql.ru — информация о СУБД MySQL

If you are a director, manager or project manager who works with DBAs, you probably have had the nagging suspicion at one time or another that a DBA’s assertions regarding his or her practices lack an empirical or scientific basis, or are simply deflections intended to pass the buck.

Manager: Mr. DBA, the application is really slow. Do you have any idea what’s wrong?

DBA: Oracle is very complex. It could be any of 100 different possible causes. I will begin checking each. Anyhow, what makes you think it is the database?

Some DBAs are professional, thoughtful scientific-minded contributors. But the sad truth is that many DBAs lack the skills to professionally manage their systems. To cover, they use deflections such as the example above, or fall back on old, long-disproved practices without the benefit of evidence. Why is this true of DBAs?  One reason is that the standard education options are poor.

To help non-DBAs realize that they are being subjected to misdirection, obsolete advice, or simply ignorance, we have compiled a list of common ways that DBAs cover for their shortcomings, and avoid legitimate empirical investigation and analysis of problems and solutions.

Take notice when a DBA:

1. Cites “best practices,” or advice from a particular guru or website, as the sole reason for doing something.
2. States that “this is how we have always done it” as the sole reason for doing something.
3. Claims that reducing “head movement” by changing file or disk layout will improve performance.
4. Blames “fragmentation” for performance problems and states the database must be taken down for “defragmentation.”
5. Spends lots of time (and compute resources) rebuilding indexes.
6. States he/she must do things to improve the “buffer cache hit ratio.”
7. Discourages the use of RMAN or ASM because they are “too complex.”
8. Insists on separating indexes from tables physically, despite a modern caching SAN.
9. Blames performance problems on a SQL statement’s length, apparent complexity, length of execution plan or number of joins.
10. Says that there is no conclusive way to determine the cause of slowness.
11. Claims certain actions are “dangerous” without having a cogent technical explanation of why.
12. States it is necessary to perform manual tasks upon database startup, or at any regular scheduled interval
13. Accounts for time by listing the procedures/checks he/she manually runs on a daily/weekly/monthly basis

At Blue Gecko, our remote DBA services are based in proven, evidence-based standards.  When we assert that something must be done, we will always be able to provide a cogent reason, and cite evidence for our actions. We don’t do things without a good reason.  We find that pat advice from “gurus” often lacks a basis in evidence.  We deal in databases. We should always be able to cite data!

Related posts:

1. New whitepaper: Common Oracle Misconceptions
2. Jeremiah Wilton published in the latest Oak Table press book!
3. Proactive support

Blue Gecko works with clients who run many different operating systems.  Our preference generally is RedHat Enterprise Linux or CentOS, but we have customers who range far and wide from there including Solaris, Windows, SuSE, and (more and more) Debian and Ubuntu.

As we’ve become more familiar with Debian and Ubuntu we have found that those customers who use the MySQL packages that are distributed with these OSs have a few quirks to be aware of.

Baron Schwartz posted a long description of one of these, the challenge with /etc/mysql/debian-start at the MySQL Performance Blog.  In the short version, if this script isn’t disabled, it will run a mysqlcheck each time /etc/init.d/mysql start is invoked.  This has been changed in later versions of Debian, but legacy systems may still have this issue.  We’ve run into it with new clients (bringing us older systems) as recently as this week.

Another gotcha that we’ve run into is the default behavior of putting an include at the bottom of the /etc/my.cnf.  Since we often come into machines that have been set up by someone else, we start with an audit of the database.  When we went to make some changes to /etc/my.cnf to tune some variables there was some initial confusion since those configuration changes had been made in an included file.   Easily sorted out,  but momentarily annoying none the less.

And lastly, Debian’s MySQL is configured to send all the MySQL logs to syslog.  Now, I’m generally in favor of using the syslog infrastructure for logging where possible, but it is definitely non-standard for MySQL.   On the positive side, it does add the benefit of rotating the error logs for you.

I’d love to hear about other non-standard customizations in the MySQL packages for Debian and Ubuntu and other distributions.  Drop them in the comments.  To simplify management, we generally use the packages from MySQL in order to have the most recent GA version as well as a standard filesystem layout.

Related posts:

1. MySQL 5.1GA
2. MySQL Editions and Support- what do I get with community?
3. Semi-Synchronous Replication in MySQL 5.5

The new licensing that was announced by Oracle earlier this month caused some FUD in the community that was addressed last week in an updated graphic comparing support and binary options and blog post from Oracle.  However, one of our customers sent me this earlier this week –

We are now re-evaluating whether we want to renew our MySQL Enterprise License.  As hard as I tried, I am still confused at what we get from the license we paid other than professional support.

In other words, I don’t know whether we are paying for the binary (for features not found in the Community version) or for the Service? I thought they are two different things. But it is just not clear on their Website.

Do you have some insight into MySQL Enterprise Licensing issue? I mean if it is a matter of buying support, can Blue Gecko provide similar type of Professional Service?

Blue Gecko most often manages MySQL Community Edition and so I spent some time talking to one of the MySQL sales staff members to understand if anything has changed in this edition under this new support structure.  I’m happy to say that the Community Edition is alive well, and just as we left it in late October.   It still has partitioning, InnoDB and all your favorite engines available in it.  There is a new MySQL Cluster Community Edition that has been separated (though still freely available) to parallel the MySQL Cluster Carrier Grade Edition.

What Oracle has changed is to offer MySQL Enterprise Monitor, Enterprise Backup (formerly InnoDB hotbackup), and Cluster Manager software packaged at different levels in addition to Oracle Premier Support.

So, to get to my favorite portion of the question above “Can Blue Gecko provide a similar type of Professional Support?” — The answer is yes and no.

Yes!

Blue Gecko provides operational support and monitoring 24/7 on your databases.  Our support encompasses proactive work, maintenance outages, unplanned outages, and performance tuning.  We work with existing database staff as either or both front line monitoring response and deep bench technical support.  We can also work with a development staff as completely outsourced operations staff.  I think by working more closely with a smaller group of clients, we are able to troubleshoot more effectively than an Oracle PS staff member who has never connected to your database.

The “no” portion of the answer is that Blue Gecko does not modify or develop patches to MySQL code.  We work with other firms if we find a customer needs a custom patch.  Though, as operational DBAs with decades of experience on small and large databases however they’re measured we have found that custom forks and custom patches are seldom the only solution and are most certainly not for the faint of heart.

Blue Gecko’s support is always month-to-month and includes a number of hours each month for the work I outlined above and our staff will be happy to work at odd and inconvenient hours on scheduled and unscheduled work.

You go enjoy your turkey, we’ll be watching your systems.

Related posts:

1. MySQL Enterprise on AWS
2. Oracle, MySQL, MariaDB, and Drizzle. oh my.
3. How I got access to My Oracle Support (MOS) for US$2.67