Re: [firebird-support] Bad performance of Firebird in Windows Server 2012

2015-12-30 Thread fabianoas...@gmail.com [firebird-support]
Eduardo. You problem only will be solved by turning on write cache if
possible or switching to a new cache write enabled server. Dot.
Do not change anything in your software.
Em 30/12/2015 12:15, "Eduardo guse...@gmail.com [firebird-support]" <
firebird-support@yahoogroups.com> escreveu:


>
>
> I read that disabling forced writes is not safe.
>
> But there is something that I really don´t understand.
>
> If I disable forced writes, then when I make commits, data goes to the RAM
> of the server and afterwards, in some moment, the data will be physically
> written to the database.
>
> If I enable disk write cache, then things happen the same way. So, what is
> the difference?
>
> From what I read, I think the difference is that with disk write cache,
> Windows manages when to physically write the data but, when disabling
> forced writes it is not guaranteed that Windows will physically write the
> data. Is this true?
>
> Another question. Why is so different the performance with disk write
> cache enabled or disabled? Is this something that happens in every RDBMS or
> is just a Firebird problem?
>
> Regards
>
> Eduardo
>
>  Mensaje original 
> *Asunto: *Re: [firebird-support] Bad performance of Firebird in Windows
> Server 2012
> *De: *Ann Harrison aharri...@ibphoenix.com [firebird-support]
>  
> *Para: *firebird-support@yahoogroups.com
>  
> *Fecha: *29/12/2015 17:26
>
>
> On Tue, Dec 29, 2015 at 2:44 PM, Macma mac...@wp.pl [firebird-support] <
> firebird-support@yahoogroups.com> wrote:
>
>>
>>
>> Do I have to change any configuration or the matter is that if I can´t
>> enable disk cache, there is nothing I can do to improve the performance?
>>
>> Try to disable force write on that database.
>>
>
> After you have a UPS installed and an aggressive backup schedule.
>
> Good luck,
>
> Ann
>
>
>
> 
>  Este
> correo electrónico se ha enviado desde un equipo libre de virus y protegido
> por Avast.
> www.avast.com
> 
>
>


[firebird-support] Fabiano Kureck invited you to check out Dropbox

2015-11-27 Thread Dropbox fabianoas...@gmail.com [firebird-support]
Hi there,

Fabiano Kureck wants you to try Dropbox! Dropbox lets you bring all your 
photos, docs, and videos with you anywhere and share them easily.

Accept invite[1]

Thanks!
- The Dropbox Team


If you prefer not to receive invites from Dropbox, please go here[2].
Dropbox, Inc., PO Box 77767, San Francisco, CA 94107

[1]: https://www.dropbox.com/l/8bn89oiP8duPXjL3lKsNLr?text=1
[2]: https://www.dropbox.com/l/IYeiID8ymyZ3iQFH4xqJYj?text=1

[firebird-support] Fabiano Kureck invited you to check out Dropbox

2015-11-27 Thread Dropbox fabianoas...@gmail.com [firebird-support]
Hi there,

Fabiano Kureck wants you to try Dropbox! Dropbox lets you bring all your 
photos, docs, and videos with you anywhere and share them easily.

Accept invite[1]

Thanks!
- The Dropbox Team


If you prefer not to receive invites from Dropbox, please go here[2].
Dropbox, Inc., PO Box 77767, San Francisco, CA 94107

[1]: https://www.dropbox.com/l/npJIj4InJUCLKNPxO8KCet?text=1
[2]: https://www.dropbox.com/l/bWUBtPqz15MZ4kKbyVHyrl?text=1

Re: [firebird-support] MAX() and index

2015-09-07 Thread fabianoas...@gmail.com [firebird-support]
You need to use a descending index for it (pk can be descending also).

Also change your sql to:
Select first 1 mycol from mytab order by mycol desc
This will have the spected result.
Em 07/09/2015 10:00, "Tim Ward t...@telensa.com [firebird-support]" <
firebird-support@yahoogroups.com> escreveu:

>
>
> Please can someone explain to me, again, why
>
> select Max(MYCOL) from MYTAB
>
> doesn't use the primary key
>
> PLAN (MYTAB NATURAL)
>
> Current memory = 3074072
> Delta memory = -20
> Max memory = 3217516
> Elapsed time= 0.27 sec
> Buffers = 150
> Reads = 1811
> Writes 0
> Fetches = 894779
>
> of which it is the first field
>
> CONSTRAINT PK_MYTABPRIMARY KEY (MYCOL, OTHERCOL)
>
> and instead reads thousands of pages from disk and takes over a quarter
> of a second?
>
> (I'm just curious and wanting to understand, really. I'm going to fix
> the actual problem with a change of approach, that's needed for other
> reasons anyway, which eliminates the problem query.)
>
> --
> Tim Ward
>
> 
>


Re: [firebird-support] Changing process priority

2015-06-12 Thread fabianoas...@gmail.com [firebird-support]
Realtime is only for SO process, it will mess the things, hang the system
and so on.
Em 11/06/2015 16:37, Rudi Feijó rudi.fe...@multidadosti.com.br
[firebird-support] firebird-support@yahoogroups.com escreveu:



 Is it safe to change firebird’s process priority to “above normal” ,
 “high” or “realtime” ?
 We have been having problems with it set to “normal”.

 Sometimes admins will copy files or do other process that are as
 prioritized and that ruins the servers.


  



Re: AW: AW: AW: AW: [firebird-support] Re: Memory usage excess / leak in FBServer 2.5.4

2015-06-09 Thread fabianoas...@gmail.com [firebird-support]
See above
Em 09/06/2015 06:41, Jesus Garcia jeg...@gmail.com [firebird-support] 
firebird-support@yahoogroups.com escreveu:




   Thank you !

 Vlad


 Vlad, does this issue affect classic and superclassic?
  



Re: [firebird-support] nbackup and lost indexes

2014-12-04 Thread fabianoas...@gmail.com [firebird-support]
What is you firebird version?
AFAIK the only working version, whit no bugs, is 2.5.3
So, try updating customer's Firebird and try again.
Em 04/12/2014 13:10, wobble...@yahoo.co.uk [firebird-support] 
firebird-support@yahoogroups.com escreveu:



 Hi All,


 We use nbackup to pull live copies of customer's production databases back
 to our office to play with and help with support. We run a level0 backup
 every weekend, and a level1 every day which are both copied back to the
 office over night. That just leaves us to run a level2 when we want a live
 copy. Generally it does exactly what it says on the tin and we are all
 happy at the speed we can grab a customer's 5GB database without the server
 really noticing - as opposed to a full gbak stealing all the disk IO.


 However, occasionally we end up tearing our hair out chasing down bizarre
 bugs not directly related to the issue we are really interested in, and it
 always ends up being a problem with the indexes that nbackup has restored. 
 There
 doesn't seem to be any pattern to the customers this affects, the size of
 the level2, the time of day, or anything. Sometimes a random index seems to
 just get corrupted. Queries still use it, but get no results. If we
 deactivate/activate an offending index then everything is great again.

 Has anyone else come across something similar?


 Thanks


 Ian



  



Re: R: [firebird-support] How to improve Firebird 2.5.3 Disk I/O on Windows server 2012 R2

2014-09-28 Thread fabianoas...@gmail.com [firebird-support]
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 lo...@nucleo.co.za
[firebird-support] firebird-support@yahoogroups.com escreveu:



 Why will corruption occur?

 Sent from my iPad

 On 27 Sep 2014, at 19:03, fabianoas...@gmail.com [firebird-support] 
 firebird-support@yahoogroups.com wrote:



 Do not change to a SSD! Corruption will occur.
 Em 27/09/2014 11:16, Doychin Bondzhev doyc...@dsoft-bg.com
 [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]

  



Re: R: [firebird-support] How to improve Firebird 2.5.3 Disk I/O on Windows server 2012 R2

2014-09-27 Thread fabianoas...@gmail.com [firebird-support]
Do not change to a SSD! Corruption will occur.
Em 27/09/2014 11:16, Doychin Bondzhev doyc...@dsoft-bg.com
[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]

  



Re: SV: [firebird-support] Firebird Embedded corruptions

2014-09-15 Thread fabianoas...@gmail.com [firebird-support]
If you have VSS enabled in a drive where a live Firebird database is
working this is enought to corrupt the database as you described in the
examples.

Also, antivirus softwares do this but ussualy only when the database became
more than 1gb.

We had various problems like yours. We solved by performing an obrigatory
backup and restore cicly every day and check if all is correct. When we
have a problem the system stops, the client call us and we instruct (again)
to do not use vss or a external backup program or file copy or antivirus.
This reduced our problems and always found a problem related with user
configuration. We had only 2 corruptions related to a bad ram and a bad
disk.

The next step will be detect if an antivirus software is running and tell
the user to add an exception to our application. Also we will not run when
vss is enabled.
Em 15/09/2014 08:32, Jan Flyborg jan.pers...@gmail.com [firebird-support]
firebird-support@yahoogroups.com escreveu:



 Hi,

 Thanks for this.

 2014-09-14 1:21 GMT+02:00 fabianoas...@gmail.com [firebird-support] 
 firebird-support@yahoogroups.com:



 If Windows has volume shadow copy enabled this always corrupt databases
 in several ways.
 Em 13/09/2014 17:32, Svein Erling Tysvær
 svein.erling.tysv...@kreftregisteret.no [firebird-support] 
 firebird-support@yahoogroups.com escreveu:


 Do you mean it would be enough to have the Windows Backup service (or any
 other backup program that uses VSS) to corrupt a live database or do you
 mean that the backed up files would be corrupted and the error would be
 produced when such a backup was read back into production?

 Best Regards
 //Jan Flyborg
  



Re: SV: [firebird-support] Firebird Embedded corruptions

2014-09-15 Thread fabianoas...@gmail.com [firebird-support]
Morre info: a VSS corruption occurs when the vss is working or at this end.

A VSS corruption occurs with Oracle database also by the way. Changing the
database may not by an option, maybe...
 Em 15/09/2014 08:58, fabianoas...@gmail.com escreveu:

 If you have VSS enabled in a drive where a live Firebird database is
 working this is enought to corrupt the database as you described in the
 examples.

 Also, antivirus softwares do this but ussualy only when the database
 became more than 1gb.

 We had various problems like yours. We solved by performing an
 obrigatory backup and restore cicly every day and check if all is correct.
 When we have a problem the system stops, the client call us and we instruct
 (again) to do not use vss or a external backup program or file copy or
 antivirus.
 This reduced our problems and always found a problem related with user
 configuration. We had only 2 corruptions related to a bad ram and a bad
 disk.

 The next step will be detect if an antivirus software is running and tell
 the user to add an exception to our application. Also we will not run when
 vss is enabled.
 Em 15/09/2014 08:32, Jan Flyborg jan.pers...@gmail.com
 [firebird-support] firebird-support@yahoogroups.com escreveu:



 Hi,

 Thanks for this.

 2014-09-14 1:21 GMT+02:00 fabianoas...@gmail.com [firebird-support] 
 firebird-support@yahoogroups.com:



 If Windows has volume shadow copy enabled this always corrupt databases
 in several ways.
 Em 13/09/2014 17:32, Svein Erling Tysvær
 svein.erling.tysv...@kreftregisteret.no [firebird-support] 
 firebird-support@yahoogroups.com escreveu:


 Do you mean it would be enough to have the Windows Backup service (or any
 other backup program that uses VSS) to corrupt a live database or do you
 mean that the backed up files would be corrupted and the error would be
 produced when such a backup was read back into production?

 Best Regards
 //Jan Flyborg
  




Re: SV: [firebird-support] Firebird Embedded corruptions

2014-09-13 Thread fabianoas...@gmail.com [firebird-support]
If Windows has volume shadow copy enabled this always corrupt databases in
several ways.
Em 13/09/2014 17:32, Svein Erling Tysvær
svein.erling.tysv...@kreftregisteret.no [firebird-support] 
firebird-support@yahoogroups.com escreveu:



 Hi,
 
 We have shipped Firebird Embedded bundled together with our product for a
 few years now and the system is currently in production at several thousand
 of our customer's sites.
 Currently we are using Firebird Embedded 2.5.1 with the latest
 .NET-driver and a stack consisting of Castle Active Record on top on
 NHibernate and the system is running on the
 latest versions of Windows.
 
 All is well and Firebird has served us good so far with the exception of
 database corruptions that gets reported from a new set of customers every
 week. For some of them it is
 possible to instruct the customer on how to repair the databases
 themselves, but some of the databases are unfortunately so heavily
 corrupted that they need to be sent to us
 for repairing (which is a tedious work that steals time from other
 tasks). Most of them corruptions are normally found in the tables that gets
 the most writes, but I guess that is
 only natural.
 
 We are now at the planning stage for the next major release of our
 product and we are thus rethinking if Firebird really is a good choice,
 because of this.
 
 Lots of effort has gone into solving this problem on our side, so I think
 the normal prerequisites has already been put into place (e.g using forced
 writes and so forth), but our
 system needs to be up and running 24x7, which means that it is not
 possible to schedule periodic backup/restore cycles and my personal theory
 is that Firebird embedded gets
 corrupted over time if you are not doing this regularly.
 
 So I have have a few questions that I would appreciate if someone could
 answer:
 
 1. Is it feasible to run Firebird Embedded 24x7 in a setup where there
 are no scheduled backup/restore cycles. If not, how often should this be
 performed to ensure that the
 database does not get corrupted.
 
 2. Most of our customers are not using a UPS. From my experiments I have
 not managed to create a corrupted database by turning of the power while
 doing a large set of
 writes (in a session running in VirtualBox). Could someone please confirm
 that this is indeed safe when you are running with synchronized writes
 turned on?
 
 3. Are there any operations on a live database that should be avoided to
 minimize the risk of corruptions?
 
 4. Just read a discussion about whether it is needed or not to call
 fb_shutdown to stop Firebird Embedded. Could this be the reason why we are
 getting corruptions? Should
 we change our service to perform this call when it is stopped?
 
 5. I have also seen discussions of turning of automatic sweeps of the
 database (and doing them manually instead). Is this a likely source of
 corruptions for our setup?
 
 Thanks in advance. Maybe are there no certain answers to my questions,
 but any pointers in the right direction would be very appreciated. Firebird
 has been a real workhorse
 for us and we would rather like to keep it.

 Hei Jan!

 The one thing I try to avoid, is running DDL (CREATE, ALTER, DROP
 table|trigger|stored procedure) on a database in use. Maybe I'm overly
 careful, but not all too long ago, a colleague caused some problems when he
 did

 ALTER MyTable DROP MyField;

 while he simultaneously had another transaction having uncommitted changes
 to MyField in one record.

 I think (but have no experience), that possible reasons for corruption
 could include file system backups of the database while it is in use
 (exclude the database file(s) from such backups, rather use gbak for the
 backup, and include the resulting file in the system backup), and possibly
 anti-viruses preventing Firebird from doing it's work (though I would
 expect this to result in the database being unaccessible, not corrupted).

 Another thing that's only affecting Fb 2.5.1, is that this version has an
 error relating to compund indices (requiring backup/restore or rebuilding
 such indices if upgrading to 2.5.2). Though I doubt this error would cause
 data corruptions involving more than the index.

 Others will be able to give you a more thorough answer, despite having
 used Firebird since it's inception (0.9.4), I've very little experience
 with corruptions (undoubtedly related to only working on a handful of
 databases with about 20 simultaneous users).

 HTH,
 Set