Sinática Monitor is here!

If you are curious to know the Product I was cooking for the last months, your wait is over.

It’s called Sinática Monitor for Firebird. And it was specially created to monitor your database and discover those hard-to-find problems.

Here’s an example:
Remember that transaction that got stuck and caused a major confusion because your server became extremely slow?
Sinática Monitor detects exactly which transaction is stuck and spares you the hard work of looking for it.
Here’s another one:
Remember that customer that complains about your system becoming unbearably slow every third Saturday?
Sinática Monitor is the ideal tool to help you find out what is going on. Whether it is a slow statement or one that is not using indexes, Sinática monitor points you to the problem in a simple and easy way.

And that’s just the beginning.

Visit out new site and see screenshots of Sinática Monitor in action.

Sinática Monitor is entirely free during the Beta period.

Download now and find out what it can do for your database.

And please don’t be shy! I want to hear from you. Send me your ideas and suggestions!

Comments (5)

Know your server

A post by Jeff Atwood got my attention last week. He reports how he had difficulties to find a problem in StackOverflow beta. They kept getting deadlock logs during the day and in the end the problem was related to MS SQL Server blocking readers:

You can attach the profiler to catch the deadlock event and see the actual commands that are deadlocking. I did that, and found there was always one particular SQL command involved:

UPDATE [Posts]
SET [AnswerCount] = @p1, [LastActivityDate] = @p2, [LastActivityUserId] = @p3
WHERE [Id] = @p0

If it detects a deadlock, SQL Server forces one of the deadlocking commands to lose — specifically the one that uses the least resources. The statement on the losing side varied, but in our case the losing deadlock statement was always a really innocuous database read, like so:

FROM [Posts]
WHERE [ParentId] = @p0

To fix the problem they had to instruct MS SQL Server to use dirty reads on each those selects. What kept hammering my head all these days was not how can modern databases still block readers. But the lesson we can take from the episode. Independently of server and its architectural limitations, the important thing is to understand it and also to know your application’s environment very well.

In the case of StackOverflow Jeff found that a possible solution was dirty reads. If the transactions performed by the website took a long time, dirty reads would not be an option. But knowing his application very well he knew that was not the case. Choosing dirty reads would have no consequences. Independently of what ACID purists would say. And I confess I turned my nose when I first read "dirty read".

Thanks to its multi-generational architecture Firebird does not block readers. So it’s natural that this problem may seem strange to us. But each architecture has its pros and cons. This same multi-generational architecture, if not correctly used, can be a problem. It’s the case of long running transactions or "stuck transactions".

Such transactions cause record versions to accumulate in the database. (These versions can also be called generations. It’s multi-generational architecture, remember?) The more versions accumulate more work Firebird has to do to find the correct version of each record. If stuck for long enough Firebird server can get slow to the point of looking like it’s dead. How much time depends of the database load and the server’s hardware. Could be a month, could be an hour.

I’ve seen it happen many times. In some of those occasions I saw managers argue for hours that MS SQL Server or Oracle don’t have such problem. The fact is that they have other architectural details that you must take into account in your application. For example, some databases block readers. Simply switching databases, as some of those managers suggested, is not a solution.

Although having StackOverflow powered by Firebird would not be a bad idea. ;)

Comments (0)

Forced-Writes and Firebird database corruption

If there were statistics on corrupted Firebird databases, I believe more than 80% of them would have something in common: they were running with forced-writes off.

Since Firebird 2.1 forced-writes also work in linux. With that in mind I put together a comparison between the two modes.

What are forced-writes and when to use them?

I hope DBAs who like to live dangerously find this useful.

Comments (0)

5th Firebird Developers Day – What the future holds

Two fantastic days talking about Firebird with great people. That’s how my first Firebird Developers Day was.

Unimep Theater Piracicaba Firebird Developers Day

Arriving at the Unimep Theater

I learned a few new tricks and left with a very good perspective about the project’s future. This perspective I now share with you.

Firebird 3.0

We can wait a hybrid based on ClassicServer but with good doses of code from both SuperServer and Vulcan. And that’s good. No huge changes that would take decades to stabilize. The Firebird team’s proposal, according to Dmitry Yemanov, is evolutionary and not revolutionary.

Unimep Theater Piracicaba Firebird Developers Day

Very early in the morning there was a lot of people already.

Dmitry Yemanov also showed strong opinions about having shared data and metadata caches. It seems ClassicServer’s dedicated cache is going to be deprecated very soon. Amen.

Installation and configuration will be easier with only one executable for all architectures.

In the MasterClass I had the opportunity to express how much I like the monitoring tables and how easier they make the life of a Firebird DBA. The good news is that it seems the Firebird team is also interested in extending them.

Unimep Theater Piracicaba Firebird Developers Day

I was the last one to leave! :)

Firebird 4?

When I asked about a native SQL parser, Dmitry Yemanov said it is very interesting for Firebird and it’s in the plans. But there is no schedule and he can’t make promises.

Internally Firebird translates SQL into a recursive language called BLR. Statements are then executed in BLR. In theory a native SQL parser would bring a slight performance increase. Most importantly, it would make extending Firebird’s SQL syntax a much simpler task.

The same goes to having value distribution histograms in indices. No schedule.


Another fantastic part of FDD was meeting and getting to know our Russian colleagues Dmitry Kuzmenko (IBSurgeon), Dmitry Yemanov (Firebird SQL) e Michael Phlippenko (Fast Report). And also some of the Speakers as Alexandre Benson Smith (Thor Software), o Professor Beto (Unimep) e o Luis Paulo (

None of that would be possible, of couse, without the folks at A Big Thanks to them and in special to Carlos Cantu for organizing this event.

See you next year!

good night screen

This unimep terminal speaks for me.

Good Night. Waiting automatic energy shutdown in a few moments.

Comments (1)

Recommended update – Firebird 2.1.1

The recent release of Firebird version 2.1.1 is very welcome.

Here are a few of the fixes I consider important for 2.1 production servers and so recommend the update:

  • Stability fixes for the monitoring tables
  • Fixed possible corruption of the users database, security2.fdb.
  • Fixed nBackup, which did not work in version 2.1.
  • Fixed a memory leak on DDL statements.

The complete list of bugs fixed and the downloads are at the Firebird SQL website.

Comments (0)

Firebird SuperClassic – Another option

Firebird 2.5 just entered Alpha state. Among the new features is a new server architecture.

Called SuperClassic, it will be the basis for the multi-processor support that we’ll see in Firebird 3.0.

Don’t lose count. Starting from Firebird 2.5 you will be able to choose among SuperServer, ClassicServer and SuperClassic.

Basically SuperClassic is like ClassicServer. Only instead of a process for each attachment it uses a single process with a thread for each attachment. The benefit being that it uses fewer kernel resources and is a bit faster.

Read a deeper comparison between the three architectures.

Comments (0)
« Previous page