Newsgroup: it.comp.software.database
Titolo: Firebird e stabilità

Salve a tutti,
qualcuno di voi ha esperienza con Firebird, mi interesserebbe capire 
quanto è stabile e veloce, magari facendo un paragone con altri dbms.
Le installazioni che dovrei fare sarebbero sia su sistemi Windows che 
Linux, non avrei bisogno di SP o trigger e le applicazioni client 
userebbero solo ANSI SQL.
grazie a tutti



Quanto a stabilità, io direi 100% .assolutamente indistruttibile.
Comunque per me va bene e non ho mai avuto problemi.
Lo uso come database aziendale , per cui è molto importante.
Quanto alla velocità ..... a me pare ottima . ma non so confrontarlo
con altri DB .
C'è da dire che io faccio accessi avendo cura di scrivere le clausole
Where rispettando le chiavi esistenti al più possibile.
La mia impressione è che l'eventuale collo di bottiglia è comunque la
rete, non il DB in sè.

 quanto è stabile e veloce, magari facendo un paragone con altri dbms.
Qui trovi un raffronto che dovrebbe esserti utile:
http://www.geocities.com/mailsoftware42/db/?200723
(nel caso desse problemi togli l'ultima parte dell'url, quella con punto 
interrogativo)
Qualche anno fa l'ho usato per un'applicazione, che viene ancora 
utilizzata anche se non fa un uso pesante del db, comunque in quattro 
anni non ha mai dato problemi di stabilità.
Come prestazioni mi sembra "nella norma" (leggi: non ho mai fatto test 
né raffronti, ma non ho mai notato rallentamenti o picchi).
Ciao,
Paolo


Sotto win e' stabilissimo, eccetto una o due volte che si e' 
corrotto il db(fortunatamente leggeva fino alle ultime righe 
delle tabelle quindi alla fine ho recupertato) per colpa di 
server non collegati a ups.
Se fai i db normalizzati e indicizzati a modo le prestazioni 
non dovrebbero manco deteriorarsi anche con quantita' di 
dati pesanti...
Ciao

innanzitutto vi ringrazio tutti delle risposte, tutte molto interessanti.
Se a qualcuno può interessare vi spiego meglio le mie esigenze.
Ho bisogno di interrogare il db con delle query nidificate, chiaramente 
è un aspetto molto particolare, quindi ho installato tre tipi di dbms 
(msde, PostgreSQL e Firebird) in locale ed ho fatto alcuni test.
Ho creato una tabella (T0001) con un unico campo (C0001) di tipo 
alfanumerico variabile max 4000 caratteri non indicizzato ed ho inserito 
3000 casuali.
Poi ho eseguito la query nidificata:
SELECT C0001 FROM T0001 WHERE C0001 IN (SELECT C0001 FROM T0001 WHERE 
C0001 IN (SELECT C0001 FROM T0001));
I risultati hanno dato come migliore PostgreSQL, seguito da MSDE e 
Firebird (PostgreSQL è addirittura il 40% più veloce di MSDE).
Spero che questo test possa essere utile anche a altri !
ciao

 quanto è stabile e veloce, magari facendo un paragone con altri dbms.
Le caratteristiche per cui di solito si sceglie Firebird rispetto ad un
altro RDBMS sono quattro:
1) versatilita` (da quello che so, Firebird e` l'unico che ti permette
di passare un database pensato per un uso embedded ad un database
client/server senza troppi problemi);
2) basso livello di manutenzione;
3) basse richieste hardware;
4) stabilita`.
Per quanto riguarda la velocita`, secondo un test che ho trovato in
rete, Firebird e` meno veloce e scalabile rispetto a MySQL e
PostgreSQL[1] , ma in compenso e` piu` stabile e costante
Enrico
[1] e.g. in un test misurato in migliaia di select al secondo, Firebird
con 100 thread aperti riesce a servire quasi 5000 select, mentre
PostreSQL ne serve circa 12000. Se pero` si continua a leggere il
grafico, PostgreSQL ha un andamento discontinuo, mentre Firebird ha un
andamento costante[2]
[2] 
http://devloop.org.uk/documentation/database-performance/

[2] 
http://devloop.org.uk/documentation/database-performance/
leggendo in quel link che hai dato, mi sono reso conto che nessuno
configura questo :
# This sets the number of pages from any one database that can be held
# in cache at once. If you increase this value, the engine will
# allocate more pages to the cache for every database. By default, the
# SuperServer allocates 2048 pages for each database and the classic
# allocates 75 pages per client connection per database.
#
# Type: integer
#
#DefaultDbCachePages = 2048
La dimensione della cache usata dipende pure dalla dimensione di ogni
pagina (quando il DB è stato creato), comunque semplicemente guardando
il taskmanager di Windows , si vede che il default è tale per cui usa
pochissima Ram
Io ho messo il numero 32768 . Così usa un pò più di Ram , e quindi usa
un pò meno il disco e quindi va un po più veloce.

 configura questo :
E` il problema di Firebird: funziona talmente bene che nessuno si
preoccupa di configurarlo :)
Enrico

 Spero che questo test possa essere utile anche a altri !
Hai indicizzato i campi?
Firebird supporta una sintassi WHERE EXISTS che forse è più veloce.
Comunque la IN è uno dei peggior modi per quanto riguarda le prestazioni.
Ti posso dire che Firebird non supporta select nidificate:
SELECT * FROM (SELECT * FROM TABELLA)

 preoccupa di configurarlo :)
A me si sono corrotti 3 volte degli archivi.
Ma almeno 2 volte erano problemi di Disco rigido.
In ogni caso con una procedura particolare di backup e restore è stato
recuperato tutto.

 SELECT * FROM (SELECT * FROM TABELLA)
dalla 2.0 direi di si'.

 dalla 2.0 direi di si'.
Ecco sono rimasto alla 1.5x :)
Putroppo mi pare che non abbiamo fatto una gestione per Tabelle Temporanee,
e per UPDATE a catena (un po' come invece supporta INSERT INTO (campi)
SELECT).

 recuperato tutto.
"...procedura particolare di backup..."   ????
E che sarebbe ?
Ciao
RobertoA

 SELECT).
le temporary table dovrebbero arrivare a breve se rispettano la roadmap:
http://www.firebirdsql.org/index.php?op=devel&sub=engine&id=roadmap_2007&nosb=1

 SELECT * FROM (SELECT * FROM TABELLA)
Mi sembra strano, la query l'ha eseguita senza errori.


anche con gback a volte li mette a posto anche perche' 
reindicizza i dati(sempre se ci sono gli indici :) )
Ciao
-- 
#Wizard Developer#
http://www.wizardtale.org
Ci sono troppi Aragorn su usenet!!!

 dati(sempre se ci sono gli indici :) )
son dislessico logicamente non volevo dire che li mette a 
posto perche' reindicizza!! lol
cmq quando facevamo il backup and restore le query 
rispondevano piu' velocemente.
ciao

4r4g0rn ha scritto:

...questo mi sembra veramente strano... bah...

 ...questo mi sembra veramente strano... bah...
pero' mi sa che era interbase 6.0 sto facendo casino... 
praticamente eravamo andati da un cliente che diceva che era 
lentissimo e avevamo fatto ql lavoro li' e praticamente dopo 
andava piu' veloce e io e il mio collega avevam pensato che 
avesse reindicizzato... -_- ma puo' essere che c'erano degli 
errori che ha messo a posto... boh

 ...questo mi sembra veramente strano... bah...
no non lo e'... per firebird. backup/restore e' la procedura di
manutenzione standard. chiedi in qualsiasi forum perche' il tuo database
"e' lento"... ti chiedono quando hai fatto l'ultimo backup/restore.
tra l'altro backup/restore e' anche l'unico modo di fare un backup
veramente affidabile perche' mi e' gia' capitato di fare un backup di un
db corrotto che poi non era piu' "restorabile" perche' violava una foreign
key (un campo di un record a seguito della corruzione aveva un valore non
valido). quindi bisogna testare ogni backup per essere sicuri.
comunque fondamentalmente esegue diverse operazioni di riorganizzazione
tra le quali la reindicizzazione (che si puo' fare ovviamente
indipendentemente) e il garbage collect (che e' il recupero dello spazio
dei record cancellati.
il backup dovrebbe essersi evoluto a partire dalla 2.0- Prima era
fondamentalmente quello di interbase 6.

 fondamentalmente quello di interbase 6.
Evoluto nel senso che questo metodo del piffero e` stato soppiantato?
Enrico
P.S. su PostgreSQL succede una cosa simile, solo che viene risolta con
un comando sql o con un comando shell

 Evoluto nel senso che questo metodo del piffero e` stato soppiantato?
se non erro, come ho gia' detto mi sono fermato alla 1.5 per ora, hanno
aggiunto i backup incrementali... di piu' non so.

 E che sarebbe ?
Quattro Batch presi da una guida:
gfix -v -full -user SYSDBA -password masterkey 030.gdb
pause
gfix -mend -user SYSDBA -password masterkey 030.gdb
pause
gbak -b -v -ig -user SYSDBA -password masterkey 030.gdb 030.gbk
pause
gbak -c -user SYSDBA -password masterkey 030.gbk 031.gdb
pause

 avrei delle query da rigirare un po' e non ne vedo il motivo.
Il 2.0 si incavola se specifici alias e non gli usi
	select 
T.ID
, TABELLA.CODICE from TABELLA T
Io ne ho alcune in giro :)

 Come detto, non ho creato indici.
Probabilmente gli altri DB gestiscono meglio tabelle non indicizzate.
Prova ad indicizzare e vedi...