This is a follow-up to part I from last week. You've considered what you want to do, you've looked at your soft skills, and you still want to be a DBA. How then do you get started?

The first thing to do is decide which platform you're going to focus on. Each "flavor" has its own proprietary tools and commands. While all share a basic SQL language foundation, DBCC CHECKDB() doesn't run on MySQL and DESCRIBE doesn't get you anything SQL Server. Likewise, SQL Server Management Objects (SMO) don't help you with Oracle and if you're looking for " …

I do realize that for most of you, there may be nothing new about the dbms_sys_sql package ? knowledge of it has been floating around for quite a while. I myself discovered this package a couple of years ago while playing around with HTMLDB’s (now APEX’s) internals. I’m posting this as a response to a [...]

Is it fair to compare Innodb to MyISAM with innodb_flush_log_at_trx_commit=1 and flush=OFF?

Granted different applications have different requirements. But, when you're trying to show a graph comparing the two Engines, isn't it reasonable to try to keep the same settings as close to equal as possible?

I suppose that begs the question of how similar innodb_flush_log_at_trx_commit is to flush, and if it's even possible to get a valid comparison.

Innodb tends to be slower (I'm on 4.1 currently, ancient history), but it seems to me that it's doing a whole lot more for the money. What do you think?

[UPDATE] Additionally, I'm running sequential benchmarks back to back, for example loading the table, then turning around and running a read test on the table. For innodb, this often means that a good chunk of the buffer pool is dirty and the read test has to slog through while the dirty buffers are …

Keith: Tomorrow is Tuesday ;)

While we're on the subject, the Montreal MySQL User Group *is* tomorrow. You can RSVP on the Meetup site, or via Facebook. This month's talk is on Performance Tuning.

I've been running a series of sysbench tests on Innodb with MySQL 4.1 My tests include doing both reads and writes on the table.

I've noticed that after the test is complete, and while there are no processes in show processlist, I see a fairly large amount of buffer pool reads and writes, as well as a large number of Modified db pages. Now, I know that it could take a while for innodb to flush out the dirty buffers after a large amount of writes, but I'm seeing the Modified db pages actually getting larger for a while, and then gradually getting to the point where it finally settles down and returns to 0.

The only thing I can think of is Innodb is doing some sort of table optimization, which begs the question of whether I should rerun my tests with the optimized table or not.

Has anyone else seen this?

UPDATE: I believe I have figured out what's happening. My sysbench test is working on a …

Si Chen wrote recently about the growth limits of open-source projects. He points out that as a project becomes larger, it gets harder to maintain. I can only agree. As the MySQL Toolkit project has grown, it's become significantly more work to maintain, document, and enhance.

We have fixed the issue with the PHP dtrace extension not working in Cool Stack 1.2. As I mentioned in my announcement post, we had already identified the issue but didn't have time to fix it before the release. The issue was that /usr/ccs/bin/ld was being used to do the linking but this doesn't work for dtrace as some initialization code needs to be called from the .init section and this is not setup correctly if we don't use 'cc' to do the linking (rather than 'ld'). 

So a simple addition to the configure line:
LD="cc"

did the trick.

We now have two files : dtrace_1.2_sparc.so and dtrace_1.2_x86.so posted. Download the one for …

We have fixed the issue with the PHP dtrace extension not working in Cool Stack 1.2. As I mentioned in my announcement post, we had already identified the issue but didn't have time to fix it before the release. The issue was that /usr/ccs/bin/ld was being used to do the linking but this doesn't work for dtrace as some initialization code needs to be called from the .init section and this is not setup correctly if we don't use 'cc' to do the linking (rather than 'ld'). 

So a simple addition to the configure line:
LD="cc"

did the trick.

We now have two files : dtrace_1.2_sparc.so and dtrace_1.2_x86.so posted. Download the one for …

(Please watch this youtube video to fully appreciate the "the future is today" joke)

What are federated tables?

The FEDERATED storage engine is available beginning with MySQL 5.0.3. It is a storage engine that accesses data in tables of remote databases rather than in local tables.
(the link to the mysql site)So federated tables are tables that lookup data from regular tables that are on remote server, meaning somewhere else over your network or internet. This is very interesting to me, because it technically saves you a lot of coding to update your tables manually from another server.
Here is an article from O'Reilly - …

One of the enhancements I added to MySQL Archiver in the recent release was listed innocently in the changelog as "Destination plugins can now rewrite the INSERT statement." Not very exciting or informative, huh? Keep reading.