Oracle Worst Practices

It seems that database design problems are very common and do not depend on used database platform - every new generation of developers each 4-5 years repeats the same mistakes...
The presentation below is recommended for every database developer, regardless of the database being used.
My favourite slide is about "How many tables do you really need? - Four at most!" :-))

Oracle Database Worst Practices


The need for backups

I've read the post at http://successfulsoftware.net about 10 things which non-technical users do not understand.  During our work with Firebird database recoveries we interact mostly with people considered as IT professionals - developers and system administrators, but we can confirm the absolute truth of the following words regarding backups:

8. The need for backups

Every few days I get an email from someone who has lost all their data because they had a major hardware problem and no backups on a separate device. Sometimes this is because they don’t even realize the data is stored on their computer. You can mention the need for back-ups in your documentation and/or in the software, but it is unlikely to make much difference. History shows that this is a lesson most people have to learn the hard way (techies included). Mentioning it doesn’t hurt though and it might help to defuse an angry users if you point it out to them after the event.

Consider this post as a small reminder that your Firebird database should have backups, and they should be done in the right way.


How to increase Firebird backup and restore speed (up to 30%)

It seems that many Firebird developers and administrators are not aware about switch -se[rvice] for gbak.exe
The origin of this switch is in the fact that code for backup and restore can be invoked in Firebird twice - first as explicit external application (i.e., through gbak.exe) and, second, as a Services API call.

Backup/restore through Services is faster than usual approach  - due to the bypassing of interprocess communication and, probably, due to some IO optimizations.

To use Services instead of regular gbak.exe you need to add switch -se to the gbak command:

gbak -se service_mgr -b -g ...

Try to run backup with your database with and without switch -se[rvice] and compare results. In our experience switch -se can increase backup and restore speed up to 30%.
Btw, our FBdataGuard uses Services API to run backup and restore, and many users find it faster than general gbak.exe. Now you know that it's not the magic  - just good knowledge of Firebird and its internals.