Archive for March, 2007

The MySQL Vision - What do you see?

Thursday, March 22nd, 2007

I used to wear glasses (was nearsighted), but through some natural processes that I won’t go into here, I actually reversed my nearsightedness and now see clearly without the need for glasses. Having clear vision is a great thing, both for individuals and for companies.

One of the terrific aspects about MySQL is that the vision for the database is established with the help of the very active and innovative community of MySQL users who are daily pushing and extending the MySQL database server to do new and exciting things. We are in the process now of crafting the future vision of the server, and that process would be incomplete without your input.

Where would you like to see MySQL go in the coming years? What new areas would you like to see MySQL address? What does your business need MySQL to do that it currently doesn’t? We’re not talking about detailed feature requests here, but more of a “big picture” type of thing.

Please think about these things and shoot me a mail at rschumacher@mysql.com so we can include your feedback and input into what we come up with. I’ll make sure and let you know what the end result is.

Thanks for your support and see you at the upcoming Users Conference!

DBA guide to the MySQL Users Conference

Tuesday, March 13th, 2007

With all the great sessions that Jay and crew have lined up at the upcoming MySQL Users Conference, you might have a hard time creating a personal schedule from all that’s available. So I just wrote a new dev zone article that is a DBA’s guide to the MySQL User’s Conference to help. In the article, I try and highlight the things DBA’s care about - performance management and key database administration duties - and then link each area to the sessions you’ll want to make sure and attend.

Anyone interested in writing a Developer’s Guide to the UC…?

Another daylight savings time reminder

Friday, March 9th, 2007

Although a few posts have already been made about this, I thought I’d post a nice quick article by Peter Gulutzan and Dmitri Lenev on what to do with the upcoming daylight savings time changes and MySQL. This is in case you aren’t using the OS for your time zone info. You can find this out by issuing the following query:


SELECT @@global.time_zone;

If you get back “SYSTEM”, then the MySQL server is looking to the OS for timezone data, which is the default setting.

DAYLIGHT SAVING TIME CHANGES
By Peter Gulutzan and Dmitri Lenev

This year many American states and Canadian provinces will switch to daylight saving time on March 11 (the second Sunday of March) instead of switching on the first Sunday of April as happened during previous years.

If you populated the mysql.time_zone_transition according to the instructions in the MySQL Reference Manual, “5.11.8. MySQL Server Time Zone Support” now’s the time to make sure the time is up to date.

Here is an example, taken from an older system with the “wrong” dates. The region setting, that is, the value of @@time_zone, was ‘America/Edmonton’.

(The example is for a Canadian time zone because the risk is greatest there, but you should check for all the locations you work in.)

Find out the time zone id for the region:


mysql> select * from mysql.time_zone_name
-> where Name = 'America/Edmonton';
+------------------------+--------------+
| Name | Time_zone_id |
+------------------------+--------------+
| America/Edmonton | 100 |
+------------------------+--------------+
1 row in set (0.97 sec)

Find out the transition dates for that zone in this year:

mysql> select * from time_zone_transition
-> where Time_zone_id =
-> and Transition_time between 1167634800 and 1199170799
-> order by Time_zone_id,Transition_time;
+--------------+-----------------+--------------------+
| Time_zone_id | Transition_time | Transition_type_id |
+--------------+-----------------+--------------------+
| 100 | 1175418000 | 1 |
| 100 | 1193558400 | 2 |
+--------------+-----------------+--------------------+
2 rows in set (0.00 sec)

Find out what ‘1175418000′ and ‘1193558400′ mean:

mysql> select from_unixtime(1175418000);
+---------------------------+
| from_unixtime(1175418000) |
+---------------------------+
| 2007-04-01 03:00:00 |
+---------------------------+
1 row in set (0.00 sec)

mysql> select from_unixtime(1193558400);
+---------------------------+
| from_unixtime(1193558400) |
+---------------------------+
| 2007-10-28 01:00:00 |
+---------------------------+
1 row in set (0.00 sec)

Diagnosis: this database thinks the switch is on April 1, which is wrong. Cure: update your operating system files, check the “MySQL Server Time Zone Support” section of the manual, and update the table.

Who’s following who?

Wednesday, March 7th, 2007

In the most recent edition of Database Trends and Applications (hardcopy), there’s an interview with Tom Kyte from Oracle with the focus being the new enhancements coming in Oracle11g. I’m a big fan of Mr. Kyte as he really knows his stuff and is not shy in admitting what Oracle doesn’t do well. Even though I’m no longer an in-the-trenches Oracle DBA, I still follow his columns because his advice can oftentimes apply to other DBMS’s in addition to Oracle.

I was intrigued to see the very first 11g enhancement he noted in his interview - Oracle will now sport a new memory cache that will cache the results (not just the raw data blocks) of SQL queries. Sound familiar? When I first came to MySQL, one thing that quickly caught my eye was the query cache. Now I know the query cache isn’t for everybody, but in the right situations, it can really be a godsend. Seems Oracle has now gotten the same message. And no wonder: for repetitively issued queries that don’t see lots of data changes, it’s far more efficient to cache the result set for coming identical queries than recompute that same result set over and over again (especially if you have to plow through millions of rows to do it). Of course, this is something MySQL has been doing for years.

Hey, imitation is the best form of flattery!

Getting excited about PBXT

Thursday, March 1st, 2007

I’ve been following the development of the PBXT storage engine for some time, but only recently got the chance to get my hands dirty with the engine. I have to say - I like what I see! Paul McCullagh (PBXT’s creator) has done a great job creating a stellar transactional engine for MySQL, and the new beta sports foreign keys that work like a champ.

Check out the article I just wrote on PBXT - I think you’ll be excited too once you see all that PBXT offers and the performance it delivers. Paul has also started making binaries of the plugin-engine available, which makes it even easier to pop PBXT into a version of MySQL and run.

Check PBXT out when you can - like me, I think you’ll quickly be turned into a fan.