 Dmitry Yemanov, Firebird lead architect |
Firebird release strategy and roadmap for 2015/2016 This session will be dedicated to post V3 development. It will outline the new release strategy to be established for the coming years, it will show what is being plabben will describes the primary goals for the future Firebird versions. An updated roadmap will be presented. Firebird performance counters in details The Firebird database engine internally maintains a number of performance counters that are exposed as runtime statistics via both monitoring tables and the trace facility. Firebird 3.0 improves on this by introducing lots of other performance counters. This session will provide an in-depth review of both existing and newly added counters with examples how to use them in both query profiling and bottleneck investigations. |
 Ann Harrison  Jim Starkey |
Threading through InterBase, Firebird, and beyond From its original conception as Rdb/ELN, the design that became Firebird targeted the use of multiple processors to improve database performance. Computer architectures have changed radically over time and the process architectures of Firebird changed with them. What remains constant, is that database applications need all the power available to them, and the best way to get it is to increase the parallelism. Early versions of InterBase and Firebird in its classic mode used process-based parallel execution. That design suited environments before most operating systems supported threads. On VAX clusters, processes could run on different computers in the cluster. On multi-processor systems, the operating systems schedule Firebird processes on different processors on the same machine. One anomaly in the parallelism story is the SuperServer architecture of InterBase and Firebird prior to V3. SuperServer is threaded, but has only a single control stream and cannot run on multiple processors. Having multiple threads in a single process has many advantages over a multi-process architecture on current multi-processor machines. Sharing the page cache means fewer copies of each page in memory, many fewer I/O operations, and of course, eliminates the need for interprocess communication. Multi-threading is not simple. Introducing multi-threading into existing software is particularly challenging. Firebird has made major progress in Version3. Other database management systems have implemented more complex mechanisms to provide parallelism. This talk and paper will consider threading and parallelism and the challenges they present starting in the early eighties and continuing to consider a new model, created by Jim Starkey, that provides elastic scalability and distributed query processing. Orphans, Corruption, Careful Write, and Logging A frequent question on the Firebird Support list is "Gfix thinks my database is corrupt. How can I fix it?" The best answer may be to fix gfix itself so it reports benign errors differently from actual corruption. The most common errors reported by gfix can simply be ignored. From the beginning of InterBase to now, gfix is the least interesting of the utilities, so it's had little attention. However it requires a great deal of knowledge of database internals, so it's not easily replaced by a separately developed tool. So, from 1984 until now, gfix has reported major corruption and benign errors as if they were all the same. What's a benign error? Usually, it's an artifact from the sudden death of a Firebird server that leaves obsolete record versions or even whole empty pages orphaned — neither released nor in use. Orphans represent lost space, but have no other damaging effect on the database. Orphaned record versions and pages occur because Firebird carefully orders its page writes to avoid the need for before or after logs. Database management systems that rely on logging for durability and recovery write each piece of data twice — once to a log and later to the database. Careful write requires discipline in programming. In 1984, careful write had performance advantages that more than made up for the need for careful programming. This talk and paper explore the cause of "orphan" pages and record versions, Firebird's careful write I/O architecture, and the trade-offs between careful write and logging today. |
 Pavel Cizar, IBPhoenix |
Using Firebird trace & audit as tool for system analysis Firebird trace and audit services were introduced in Firebird version 2.5. They provide extensive logging of various events that occur performed inside the database engine, such as statement execution, connections, disconnections, etc., that can be used to identify problematic spots in your system. However, these audit trails can be huge and very hard to analyse. This session will present some challenges and solutions based on experience and usage of the trace and audit services at IBPhoenix. Using Firebird monitoring tables as tool for system monitoring and analysis Firebird monitoring tables are a less intrusive tool for system monitoring and analysis than the trace and audit services, because they provide snapshots of internal states rather than a continuous trail of events. However, using them effectively has it's own set of challenges. This session will present some approaches and solutions based on experience with monitoring tables at IBPhoenix. |
 Alexey Kovyazin, IBSurgeon |
Firebird database recovery: tools and techniques Why do Firebird databases become corrupted? How to avoid corruptions? These are popular questions from Firebird administrators and developers of Firebird applications. This Session will be devoted to key corruptions and issues that can sometimes happen to Firebird databases, the session will detail the methods needed to fix them. |
 Dmitry Kuzmenko, IBSurgeon |
Transactions: how they work inside Firebird This session is devoted to an explanation of how the internal transaction mechanism works in Firebird, in order to give developers practical recommendations on how to correctly handle transaction management. |
 Pavel Zotov, Firebird Project QA |
Firebird Performance tests: open-source framework to simulate real-world Firebird applications with heavy load This Session is all about Firebird performance testing, and about an open-source framework created to simulate the heavy load of real-world Firebird applications using complex business-logic. The framework supports both Firebird 2.5 and Firebird 3.0, and utilises many Firebird 3 features. Comparison test results and tuning recommendations for Firebird 2.5 and Firebird 3.0 will also be presented. |
 Jiri Cincura, Firebird Project, .NET driver developer |
A year in the life of .NET provider What's new and what's planned, an overview of changes made to the .NET provider, as well as new features and the expected direction of development for the coming year. Using Azure cloud and Firebird to develop applications easily A session to introduce developers in using Firebird on the Azure cloud and what it offers for a .NET developer. Focused on loosely coupled scenarios where part of the application can be run on-premise, or even written in different language, whilst other part(s) run on Azure and have the benefit of the .NET world and its scalability. |
 Marius Popa |
Firebird and Node.js An overview of Node.js and Firebird drivers with a examples (Express/Angular) and performance comparison : A native c++ driver vs a pure java script driver. |
 Carlos Cantu |
Creating logs for data auditing Sometimes you can have situations where users say that information has disappeared from the system or it has been modified without any intervention. In these cases, typically no user will take the responsibility for what has happened blaming the developer, the application or even the database. That's when audit logs become an extremely useful tool. Using logs, we can check everything that happens to our data (inserts,updates, deletes) as well as who and when it took place. This talk will cover a real example of how to implement logs for data auditing in Firebird databases, using only the native features of Firebird 2.1 and 2.5. The information will be stored in log tables and can be accessed by standard sql (select), allowing the user to know who inserted, modified or removed any data, when the operation took place, the IP address of the system involved and what information has been affected. It will also show an example of keeping the log data both in production database as well as in an external log database as well. Understanding numbers in Firebird Firebird offers several datatypes to store numbers: integer, numeric, decimal, double precision, etc. Developers sometime have doubts about what is the best type to use for a specific purpose, e.g. storing monetary values, etc. The behaviour of some of those datatypes also depends on the dialect being used, and can affect even the precision of the retrieved values. This talk will explore the different datatypes supported by Firebird to store numerical values, the differences among them, what care needs to be taken regarding limits and precision, and some "quirks" that can generate strange results like truncated values, retrieved values that are different from what was originally stored, etc. |
 Ivan Prenosil |
Tips for using system tables To ensure your database is in good shape, you do not always need to use specialised tools. A quick look into the Firebird system tables can reveal lot of interesting things or warn about problematic or suspicious places in your database structure. |
 Paul Reeves, IBPhoenix |
Benchmarking Firebird with TPC-C The tpc-c spec is designed to imitate an OLTP database application — which is very much the zone that many firebird databases occupy. This makes it an ideal candidate for benchmarking different firebird configurations. In this session we start with a brief look at the tpc-c specification and how it needs to be modified to work as a benchmark for Firebird. We then look at what else is required to set up the test harness. With the test harness in place we can then use it to examine the results of running the benchmark under various configurations. We will run tests that aim to provide answers to these sorts of questions:
|
 Mark Rotteveel, Firebird Project, Jaybird developer |
Jaybird Status Update Current state of Jaybird development, new features in Jaybird 2.2 and 3.0, JDBC 4.2 (Java 8). Using Firebird from Java (using Jaybird) with the help of jOOQ&Hibernate JDBC is a relatively low-level API that requires a lot of boilerplate code. This is usually hidden with higher level APIs that make developer life simpler. This session shows two different styles of querying database in Java: Hibernate is an Object Relational Mapper to map between Java objects and database tables, while jOOQ is a fluent API that gives you the flexibility and power of SQL in a typesafe manner |
 Roman Simakov, Red Soft Corporation |
Overview of Red Database 2.5 This session describes what Red Database is and how it's correlated with Firebird project. We'll talk about development process and main features which Red Database added to Firebird: a lot of security improvements, database file and network traffic encription, built-in engine record level replication, etc. Also roadmap and some interesting case studies will be presented. |
 Jonathan Neve, CopyCat |
Firebird replication with CopyCat This talk is devoted to the Firebird replication with CopyCat components and CopyCat LiveMirror. |