�ݺ�ߣ

Firebird DBMS

Daniele Bellavista, Luca Mella

Università di Bologna

December 5, 2011

Daniele Bellavista, Luca Mella (Unibo) Firebird DBMS December 5, 2011 1 / 49

Outline I
1 Introduction
2 Architettura Interna
Client-Server
Pagine e File
Tipi di Dato
Indici
Transazioni
3 Firebird Structured Query Language
Stored Procedure
Trigger
Cursori
Eccezioni
4 Security
Utenti
Ruoli
5 Concorrenza

Outline II
Firebird Support
MVCC
Locking

6 Fault Tollerance
Replicazione
Hot Backup

7 Ottimizzazione
Piani di accesso
Benchmark

8 References


Una breve introduzione a Firebird I

Un DBMS Open Source
Disponibile per Windows, Linux, Apple Macintosh OS/X, FreeBSD e
altre piattaforme UNIX-based.
Lo sviluppo di Firebird è supportato dalla Firebird Foundation.
Codice sorgente disponibile sotto licenza InterBase Public License (è
possibile costruire software a sua volta sotto licenza IPL utilizzando e
modiﬁcando liberamente il codice).
Sono disponibili vari tools (gratuiti e non) prodotti da terzi (es: GUI
manager, Replication support).
Sono disponibili vari connectors: ODBC, JDBC, Python, .NET e
Delphi driver.


Una breve introduzione a Firebird II

Firebird: le origini
Firebird nacque dal codice sorgente di InterBase 6.0 Open Edition
della Borland, rilasciato sotto licenza IPL nel Giugno 2000.
L’ultima release di Firebird è la 2.5.51, scritta in C++. Il codice
sorgente è disponibile su Sourceforge.
Firebird web-site link: http://www.ﬁrebirdsql.org/.
Sourceforge project link: http://sourceforge.net/projects/ﬁrebird/.


Architettura Server e Client

Server
SuperServer: multithreading (un thread per ogni connessione). Ogni thread
utilizza lo stesso database cache buffer (il page buffer).
Classic Server: ogni connessione è gestita da un processo con il proprio db
cache buffer.

Client
I client si connettono al server via TCP/IP o utilizzando Windows
Networking. Firebird mette a disposizione “isql” un client a linea di
comando.


Architettura del Database I

File
I database di Firebird sono memorizzati in uno o più file, creati
esplicitamente dall’utente.
CREATE DATABASE ’C:dbmyDB.fdb’
PAGE_SIZE 8192
LENGTH 1024
FILE ’C:dbmyDB.fd1’
LENGTH 100
FILE ’C:dbmyDB.fd2’
Nell’esempio riportato, è creato un un database formato da un file
primario e da due file secondari. L’ultimo file è riempito fino ai limiti o
del filesystem o di Firebird.
Ogni file è vincolato da Firebird ad una dimensione massima di 32 TiB.


Architettura del Database II
Pagine
I database di Firebird sono composti da sequenze di pagine a
dimensione fissa. Ogni pagina contiene un header che contiene un
identificatore del tipo di pagina, un checksum e altre informazioni
necessarie al DBMS per la corretta interpretazione.

Header Page pagina di header, la prima pagina del database. Nel caso di
multi-file database, l’header dei rimanenti file contiene
solamente la lunghezza e il nome del file successivo.
Transaction Inventory Page contiene le informazioni relative ad una
transizione, identificandone lo stato: committed, rolled back,
limbo (una transazione a due fasi, che lavora su due
database, ha committato solo la prima fase), active.
Data Page pagina data associata ad un’unica tabella. Contiene records e
BLOB di piccole dimensioni.


Architettura del Database III

Index Root Page pagina che descrive tutti gli indici di una sola tabella. Al
suo interno contiene i puntatori alle radici dei B-Tree,
memorizzate in pagine di tipo B-Tree Page.
Blob Page pagina che memorizza i BLOB di grandi dimensioni.
Contiene, se esiste, un riferimento alla pagina che ne contiene
il seguito.


Architettura del Database IV

Limiti
A causa della dimensione ﬁssa delle pagine, nascono delle limitazioni su vari
aspetti:
Numero massimo di tabelle: 32K
Dimensione massima di una tabella: 32 TiB
Numero massimo di record per tabella: 16G
Dimensione massima di un record: 64 KiB
In ogni caso, grazie alla possibilità di avere un multi-ﬁle database, la
dimensione massima di un DB è arbitrariamente espandibile.


Architettura del Database V

Alter Support
Firebird permette di effettuare l’alter a vari livelli; ad esempio è
possibile alterare il database introducendo nuovi file.
ALTER DATABASE ADD FILE filepath
[STARTING [AT [PAGE]] pagenum] [LENGTH [=] num [PAGE[S]]
È possibile alterare una tabella aggiungendo o rimuovendo una
colonna, modificandone il tipo, aggiungendo constraints come chiave
pimaria e indici, ma non è possibile imporre il NOT NULL ad un
campo già creato.


Architettura del Database - Data Type I

Data Types
Standard data types Char, Smallint, Integer, BigInt, Float, Double.
Date and Time Timestamp (64 bit), Date (32 bit), Time (32 bit a 4
decimali - picosecondi - )
Binary Large OBject BLOB memorizzati in pagine separate, con una
dimensione massima di 32 GiB.


Architettura del Database - Data Type II
Custom Data Types
È possibile deﬁnire dei domini, ovvero un tipo di dato che è un tipo di dato
primitivo con l’aggiunta di un valore di default e delle check condition.
CREATE DOMAIN domain_name
AS datatype [CHARACTER SET <charset>]
DEFAULT {literal | NULL | USER}
[NOT NULL]
[CHECK (<dom_check_condition>)]
[COLLATE <collation>];

Custom Data Types: Esempio - String Enum Type
CREATE DOMAIN db_enum
AS varchar(20) CHECK (value IS NULL OR value IN
(’Firebird’,’MySQL’,’MSSQL’));


Architettura del Database - Indici I

Indici
Firebird utilizza indici rappresentati come B-Tree. Supporta indici
primary e secondary, indici multi-attributo, ascending o descending.
In ﬁrebird il costo di accesso ad un indice clustered o unclustered è
identico: durante l’accesso agli indici, è raccolta una bitmap di record
locaters, riferimenti ai record. Una volta terminata la ricerca, si accede
alle Data Page in un certo ordine evitando caricamenti ripetuti della
stessa pagina.
Sempre utilizzando la bitmap, Firebird è in grado di utilizzare campi
presenti in indici diversi per ottimizzare la ricerca.


Architettura del Database - Indici II

Indici - Esempio Combinazione di Indici
Data una tabella FILM(ID, Titolo, Regista, Anno, Distribuzione) e tre
indici su Regista, Anno e Distribuzione e la query
SELECT titolo FROM FILM
WHERE Regista=’Neill Blomkamp’ AND Anno=2009 AND
Distribuzione=’Sony Pictures’
L’ottimizzatore potrebbe avvalersi dei tre indici separati per eﬀettuare
la ricerca.


Architettura del Database - Indici III

Indici - Side-Eﬀect del versioning
In particolari query come count(*), o di lettura del dato indicizzato, un
ottimizzatore potrebbe decidere di utilizzare le informazioni ricavate
dalla struttura dati dell’indice piuttosto che accedere alle pagine dati.
Come spiegato più avanti, Firebird gestisce transazioni concorrenti
“versionando” i dati. Una transazione può utilizzare dati che sono
caratterizzati da una data versione, ma questa informazione non è
replicata nelle pagine del B-Tree.
Di conseguenza Firebird deve accedere in ogni caso alle pagine dati
per ottenere la versione del dato.


Architettura del Database - Transazioni

Transazioni
ACID
No-autocommit mode
Ogni query inizia implicitamente una transazione, da terminare con un
COMMIT o un ROLLBACK
Per iniziare una transazione si utilizza lo statement START
TRANSACTION
È possibile creare dei savepoints con lo statement SAVEPOINT e
eﬀettuare dei RELEASE o dei ROLLBACK sul savepoint.


Firebird SQL

Dialetti SQL
Firebird è conforme allo standard SQL-92, inoltre implementa alcune
feature come stored procedure, triggers, role ed eccezioni.
Firebird utilizza tre dialetti di SQL:
Extended-SQL e Dynamic-SQL Linguaggi utilizzati in tutte le query
che non siano stored procedure.
Procedural-SQL Linguaggio utilizzato nelle stored procedure


Firebird SQL - Stored Procedures I

Stored Procedure
Una stored procedure è un modulo richiamabile da client, altre stored
procedure o trigger.
Le stored procedure eseguono codice PSQL e la loro creazione avviene
tramite ESQL e DSQL, quindi non è possibile per una stored
procedure creare una stored procedure.
All’interno del codice PSQL è possibile utilizzare lo statement
SUSPEND che ritorna una row composta dai valori di ritorno al
chiamante.


Firebird SQL - Stored Procedures II

Stored Procedure - Esempio
SET TERM #;
CREATE PROCEDURE mul (N INTEGER)
RETURNS (Res INTEGER)
AS

DECLARE C int;
DECLARE Tmp INTEGER;
BEGIN
Res = 0;
C = 1;
WHILE (C <= N) DO
begin
SELECT n.Numb FROM Numbers n WHERE n.ID = :C INTO :Tmp;
Res = Tmp + Res;
C = C + 1;
end;
SUSPEND;
END#


Firebird SQL - Stored Procedures III

Esecuzione di una Stored Procedure
Per eseguire una stored procedure si utilizza lo Statement
EXECUTE PROCEDURE procname [in_item {, in_item }]
[RETURNING_VALUES out_item , out_item]
Oppure, se si è incluso lo statement suspend, si può utilizzare:
SELECT * FROM procname
L’utilizzo della SELECT comporta la possibilità di creare viste da una
stored procedure.


Firebird SQL - Stored Procedures IV

Limitazioni di PSQL
Essenzialmente PSQL non permette di eﬀettuare le seguenti
operazioni:
1 CREATE / ALTER / DROP (database, tabelle, eccezioni, stored
procedure, . . . ).
2 Transaction Control
A diﬀerenza di SQL Server, non è disponibile una funzione di print su
standard output.


Firebird SQL - Altri Statements PSQL I

Trigger
CREATE TRIGGER Log_Price_Upd FOR Articles
AFTER INSERT OR UPDATE
AS BEGIN

IF INSERTING THEN
INSERT INTO PRICE_LOGS (ART_ID, ACTION, DATETIME, NEW_PRICE) VALUES
(NEW.ART_ID, ’I’, current_timestamp, NEW.PRICE);
ELSE
INSERT INTO PRICE_LOGS (ART_ID, ACTION, DATETIME, NEW_PRICE) VALUES
(NEW.ART_ID, ’U’, current_timestamp, NEW.PRICE);

END;

CREATE TRIGGER tr_connect ON CONNECT
AS BEGIN
INSERT INTO dblog (who, when, what) VALUES (current_user, current_timestamp, ’connected’);

END


Firebird SQL - Altri Statements PSQL II

Cursori
//* PSQL block *//
DECLARE cur CURSOR FOR SELECT p.num1, p.num2 FROM Prova p FOR UPDATE
BEGIN

OPEN cur;
WHILE (1 = 1) DO
BEGIN
FETCH cur INTO n1, n2;
IF (row_count = 0) THEN LEAVE;
IF(n1 > n2) THEN UPDATE Prova SET n2 = n1 WHERE CURRENT OF cur;
SUSPEND;
END;


Firebird SQL - Altri Statements PSQL III

Eccezioni
//*ESQL code*//
CREATE EXCEPTION My_Exception ’My Exception message’

//*PSQL code*//
WHEN EXCEPTION My_Exception DO
BEGIN
//*do things*//
END
WHEN ANY DO
BEGIN
//*do things*//
EXCEPTION; //* retrhow catched exception *//
END


Firebird Security I

Sicurezza in Firebird
Disponibile solo un supporto basilare di gestione utenti.
Desiderata: hide del codice di Stored Procedure e Triggers da parte di
altri utenti.
Soluzione: non esiste una soluzione eﬃcace.
Desiderata: connessione sicura al server database remoto.
Soluzione: costruzione a mano di un tunnel ssh.
Desiderata: cifratura del contenuto del database.
Soluzione: cifratura del ﬁlesystem con tool esterni o cifratura a mano
dei contenuti delle tabelle.


Firebird Security II

Livelli di protezione
Due livelli di protezione:
1 Validazione utente in fase di CONNECT al database.
2 Controlli a livello di database utilizzando utenti e privilegi deﬁniti in
SQL.

Gestione degli utenti
Utente root: SYSDBA.
Creazione di un utente tramite utility gsec.
Possibilità di utilizzare utenti di sistema, con pattern hostname
[username]. Tuttavia non è possibile utilizzare Server e Client con
gestione utenti incompatibili (Unix e Windows).


Firebird Security III

Privilegi di utenti
Operatori GRANT e REVOKE su:
INSERT, UPDATE, DELETE, SELECT (viste e tabelle).
EXECUTE ON PROCEDURE procname.
REFERENCE (permesso del server di eseguire un lookup sulle righe in
una relazione con primary/foreign key)


Firebird Security IV

SQL Roles
Utilizzo di SQL Roles, template per utenti, insiemi di privilegi.
CREATE ROLE rolename
È possibile fare GRANT e REVOKE su un roles.
Dopo aver creato un utente gli si può fare il GRANT di un ruolo:
GRANT rolename ON username;
Se un utente ha più ruoli, può connettersi ad un database speciﬁcando
un ruolo: CONNECT database USER user PASSWORD password
ROLE role;
Ruolo predeﬁnito di amministratore: ADMIN.


Concorrenza - Firebird Support I

Firebird Support
Consistency
ANSI/ISO SERIALIZABLE equivalente
Concurrency
Read Committed
rilascia r-lock appena possibile
non-repetable read possibile
Wait/No wait
in caso di conﬂitto di scrittura
attenti altra transazione o no
(fail immediately)
Snapshot/No Snapshot
ANSI/ISO REPEATABLE READS equivalente


Concorrenza - Firebird Support II

Firebird default. . .
Concurrency, Wait, Snapshot
Dirty writes: No
solo l’ultima versione può essere modiﬁcata
Dirty reads: No
le transazioni non vedono altre versioni del db
Repeatable read: Yes
cambiamenti eﬀettuati da transazioni concorrenti
sono ignorati


Concorrenza - MVCC I
Multi Version Concurrency Control

Concetti chiave
Record version, ogni transazione vede una certa versione.
Transaction signature (aka Transaction-id).
Write solo su ultima versione

Proprietà
+ Read mai bloccate.
- Generazione di più versioni.


Concorrenza - MVCC II

Quando una transazione accede ad un record. . .
Il sistema controlla se la ﬁrma appartiene ad una transazione
COMMITTED o ACTIVE.

In caso di COMMITTED T. In caso di ACTIVE T. ritorna (e
ritorna la versione più recente genera) una versione precedente.
del record.

Ok, ma. . . come??
Ricordate che il Transaction Manager mantiene un log delle transazioni son
segnate tutte le operazioni che sono state fatte?
Attraverso questo log il CM (Cuncurrency Manager) è capace di ricostruire
le versioni precedenti dei record.


Concorrenza - MVCC III

Table: Example scenario
Time Transaction T1 Transaction T2
1 begin x is signed with 120
2 begin
3 R(x), W(x) T1 sign x with 125
4 R(x) T2 reads previous version (120)
5 Commit
6 W(x) T2 has not the most recent version! FAIL
7 Rollback

NOTA
Se si scambia 5 con 6, il comportamento di T2 sara quello di attendere T1, perchè in caso di
fallimento (e rollback) di T1 il suo update sarà consistente.


Concorrenza - Locking
Locking Support
2 Phase Locking
R/W locking
Lock Promotion and Demotion
Prima richiedi lock su record, in caso di grande numero di record
scambia i lock ottenuti con un lock su tabella.
Prima richiedi lock su tabella, in caso di accesso concorrente alla stessa
tabella richiedi lock su record.

Granularity
DataBase lock, in caso di restore da backup (usa locking fornito
dall’OS)
Table lock
Record lock
Predicate lock, niente phandom records (costoso)

Fault Tollerance - Replicazione I

Tipi di replicazione supportati
Synchronous aggiornamenti propagati a real-time
- performance (computazione online).
+ consistenza.
Asynchronous aggiornamenti propagati a tempo arbitrario
+ performance-saving.
- meno consistenza tra le repliche.


Fault Tollerance - Replicazione II

Realizzazione di replicazione asincrona
Relativamente semplice, di base solo pochi elementi sono necessari:
CHANGELOG table,
eg.(<U|A|D>, <KEYFIELDNAME> ,
<SOURCEKEY>,<SOURCETABLE>,<USERNAME> , <Olds> , <News> )

Triggers su tabella sorgente, per riempire il CHANGELOG
Servizio di replicazione, che legge CHANGELOG periodicamente ed
effettua i cambiamenti sulla replica.

Altre soluzioni
Soluzioni e configurazioni più sofisticate possono essere realizzate usando
suite software ad-hoc come IBRreplicator, che gestisce più sorgenti e più
destinazioni in entrambe le maniere (SYNC, ASYNC).


Fault Tollerance - Hot Backup I

nbackup, un tool per hot-backup
Features:
Backup Incrementale ( -B <n>, with n>0 )
Disabilitazione trigger ( -T )
Locking del database ﬁle (backup manuale) ( -L,-N )

Example
nbackup -B 0 db.fdb db1-Oct-2011.nbk /*full backup*/
nbackup -B 1 db.fdb db2-Oct-2011.nbk /*incremental*/
/*restoring incremental*/
nbackup -R <db> [<backup0> [<backup1> [...] ] ]


Fault Tollerance - Hot Backup II

Altri tool: gbak, gstat e gfix
gbak stesse feature di nbackup, ma con controllo più fine (splitting,
remote backups,create/overwrite. . . )
gstat toole per report statistici (analizza indici, pagine, cache. . . )
gfix admin tool (start e stop del db, risolve transazioni in ’limbo’. . . )

Nota
Per completare un restore con successo (specialmente in overwrite mode) è
una buona pratica spegnere il database prima di cominciare.
Eg.
/*Shut down database, wait 60 seconds until all connections are closed*/
gfix -user SYSDBA -password "masterkey" dbserver:/db/mydb.fdb -shut
-attach 60


Ottimizzazione I

Query Optimizer
Ottimizzatore cost-based
Deﬁnizione di statistiche (eg. SET STATISTICS INDEX index-name)
Tiene traccia del fattore di carico delle pagine
Lunghezza media dei record e cardinalità
Profondità B+tree
Fattore di clustering (sparsità dati)
numero di NULLs
Il ricalcolo delle statistiche non è pienamente automatizzato. . .
E’triggerato per default quando le statistiche sono a 0.
Il DBA dovrebbe scriversi qualche procedura/trigger per farlo.


Ottimizzazione II

Table scan algorithms
Cardinalità, selettività, contatori di NULL sono considerati
SEQUENTIAL SCAN
INDEX SCAN (vedi prima parte:))
You should know them :D

Join algorithms
Firebird considera cardinalità e selettività per decidere quale algoritmo
usare
NESTED LOOP JOIN
SORT MERGE JOIN
HASH JOIN not yet implemented!
You should know them too :D


Ottimizzazione III
Group by algorithms
Firebird d considera cardinalità e selettività per decidere
SORT Aggregation
Legge un record in input che è stato ordinato per il campo di
raggruppamento
Appena letto il record, viene comparato con il precedente
Se i campi di raggruppamento matchano, allora aggiorna il
gruppo.
Altrimenti il gruppo è ﬁnito.
HASH Aggregation
Crea una hash table (in-memory) dei campi di raggruppamento.
Come leggi un record, aggiorna il corrispondente gruppo.
Computa tutti i record prima di ritornare i gruppi.
Computazione dei gruppi avviene in parallelo


Optimization - Piani di accesso I

Visualizzare un piano d’accesso
SET PLANONLY ON;
SELECT a.emp, b.currency FROM a INNER JOIN b ON a.field = b.field;
PLAN JOIN (A NATURAL,B INDEX (RDBPRIMARY1))
/*This is the execution plan,wich means that firebird optimizator will access
to A naturally (sequentially) and to B through his primary key’s index */

Specificare un piano di accesso a piacere
SELECT . . .
. . . ORDER BY column1
/* Here you can specify wich kind of join to use and how access to
relations*/
PLAN [JOIN] | [SORT] [MERGE] ] (<table1> NATURAL,
<table2> INDEX (<indexname>));


Optimization - Benchmark I

TPC-B
Misura il throughput in termini di numero di transazioni gesite
nell’intervallo di tempo tramite l’emulazione di un tipico screnario bancario
(conti, ﬁliali, cassieri e storico).

EMP7
Benchmark non standard, si basa su una query CPU intensive che coinvolge
un unica relazione (tabella) contenente solo 14 record. Join multipli sulla
stessa relazione garantiscono un fardello computazionale notevole.


Optimization - Benchmark II


Optimization - Benchmark III

Nota
Piano d’accesso simile per entrambi i dbms. . .
Nested Loops Join
Sequential access
10 records, 100 iterations in EMP7
scale 10, 1000 iterations in TPCB


References I

Function and Design Documentation
http://www.ibphoenix.com/resources/documents/design
Language Reference
http://www.firebirdsql.org/file/documentation/reference_
manuals/reference_material/html/langrefupd25.html
Users and Security
http:
//www.ibphoenix.com/resources/documents/search/doc_59
Async Replication
www.ibphoenix.com/resources/documents/how_to/doc_316
Replication
www.ibphoenix.com/products/software/ibreplicator


References II
MVCC
http:
//www.ibphoenix.com/resources/documents/articles/doc_27
Locking
http:
//www.ibphoenix.com/resources/documents/search/doc_48
Optimization I
http://ibexpert.net/ibe/index.php?n=Doc.Optimization
Optimization II
http://www.slideshare.net/ibsurgeon/
firebird-costbased-optimization-and-statistics-by-dmitry-ye
Algorithms
http://dcx.sybase.com/1001/en/dbugen10/
ug-grouping-optimizer-queryopt.html


Questions

?


�ݺ�ߣ

Firebird DBMS

More Related Content

Firebird DBMS