I`ve been using SSDs for quite some time - had major issues with a Kingston model a while back, so I`ve kept away from them. Most my servers are with Corsair Force 3 drives and doing fine (they are UPS protected, so power outages don`t happen all that often) - haven`t had a corruption during normal operation (meaning no firebird errors at runtime and no improper shutdowns during heavy I/O). I also have a couple of Samsung 830 drives and Intel 330 - yes, they aren`t really the freshest of models but they are proof you can be reasonably safe with SSDs. Even when I do get a corrupted page or two, I haven`t had data loss - a b/r cycle and everything goes back to normal.

PS Of course, regular backups on a classic HDD are something you should never ever consider skipping :)

2014-09-28 13:49 GMT+03:00 fabianoaspro@... [firebird-support] <firebird-support@yahoogroups.com>:

 

Number of guaranteed writes is much lower on SSD. when FB tries to write some write operations will fail and database will be corrupted.
Flash disks as pen drives and memory cards also.

Em 28/09/2014 04:53, "Louis van Alphen louis@... [firebird-support]" <firebird-support@yahoogroups.com> escreveu:

 

Why will corruption occur?

Sent from my iPad

On 27 Sep 2014, at 19:03, "fabianoaspro@... [firebird-support]" <firebird-support@yahoogroups.com> wrote:

 

Do not change to a SSD! Corruption will occur.

Em 27/09/2014 11:16, "Doychin Bondzhev doychin@... [firebird-support]" <firebird-support@yahoogroups.com> escreveu:

 

Hi Costantino,

I did some experimenting before one year and I found that Firebird is
much faster when you use page size = cluster size on the file system.

So if your file system is with 4K cluster I suggest to use page size of 4K.

This is very helpful when you have Forced Write = ON.

Performance gain with insert only scenario is more then 10-15% from 16K
page on Windows 7 with RAID 10.

another thing to look for is to try to minimize the number of
transactions you create.

Try to put as many as possible statements into single transaction. So
for this check do you use autocommit on every statement or you wrap all
statements executed while processing single file in one transaction.

Also when you process your lines in the input file try to group as many
as possible selects into single select.

for example:

select field1, filed2, filed3, field4 from table1 where field1 = ? and
field2 = ?

into :

select field1, filed2, filed3, field4 from table1 where (field1 = ? and
field2 = ?) or (field1 = ? and field2 = ?) or (field1 = ? and field2 =
?) ..........

this way you will check for multiple values at once and that means less
selects to execute on the database.

If you do your query on single field then you can use IN instead of =

Check also you have proper index setup on the tables.

Usually execution that is IO heavy does not get much better performance
by just changing the hardware. If you move from HDD to SSD this can
speed up much more but HDD performance is not very different in the last
10 years.

Also another thing to note is that for DB scenarios I prefer to use Read
Caching and no Write caching. This gives me better guarantee that I will
not end with broken database in case of power failure.

Have a nice day.

--
Doychin Bondzhev
dSoft-Bulgaria Ltd.
PowerPro - billing & provisioning solution for Service providers
PowerStor - Warehouse & POS
http://www.dsoft-bg.com/
Mobile: +359888243116

[Non-text portions of this message have been removed]