Re: [firebird-support] Numeration without hole, Is right Before Insert Trigger?

[Svein Erling Tysvær setys...@gmail.com [firebird-support]]

Also, take a look at this ancient document that used to be the standard
answer to people asking the same question as yours:
http://ibobjects.com/docs/ti_AuditableSeries.ZIP

HTH,
Set

2015-12-22 20:26 GMT+01:00 Ann Harrison aharri...@ibphoenix.com
[firebird-support] :

>
>
> On Tue, Dec 22, 2015 at 9:40 AM, Luigi Siciliano luigi...@tiscalinet.it
> [firebird-support]  wrote:
>
>>
>>I must assign a serial number, without hole, in a column of a fiscal
>> document.  I must assign the number only when I know if the document is
>> complete
>> and I think the right moment is on a Before Insert Trigger for the table.
>>
>
> Yes that's a good place, but you've got to be very careful.
> Generators/Sequences won't
> work because they're deliberately non-transactional.  Once you take one
> its gone and if
> your operation fails, you'll have a hole.
>
>>
>> Is right or the insertion can fail? If not right, when I must assign the
>> number to be sure of not have a hole in numeration?
>>
>
> One way to get numbers without holes is to create a table with one field
> that contains
> the seed for  your numbers.  In your before insert trigger update that
> field adding one to it,
> then read to get the new value.  Unfortunately, if someone else has
> inserted a record
> concurrently, your transaction will wait then get an error and you'll need
> to re-run the
> whole thing.
>
>  Check the FAQ's at FirebirdSQL.org for other ways of handling this
> problem.
>
>
> Good luck,
>
> Ann
>
>
>>
>>
>
> 
>

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

[Eduardo guse...@gmail.com [firebird-support]]

Hi guys:

I have an application developped in Delphi that uses Firebird 
Superserver 2.1.4.18393.


It is installed in a Windows network. During many years, the server had 
Windows Server 2003 and everything worked fine. Some time ago they 
changed it temporarily to another PC with Windows 8.1. Everything worked 
fine.


A few days ago they installed a new server with Windows Server 2012. My 
application is working, but it works very slow. It has a log file and I 
verified that the bad performance occurs in every data base access, when 
it opens a database, when it executes any SQL, etc.


I did a little research and found that, apparently, the problem is 
related with the disk cache. In the old servers, disk cache was enabled 
but in the new one with Windows Server 2012 it is disabled and, as the 
server is configured as a domain controller, as far as I know, it can´t 
be enabled.


I read some articles about problems similar to this one and apparently 
this is a problem related with Firebird. In some articles they said that 
since version 2.1.5 this is solved. ¿Is this true?


¿Updating to 2.1.5 will solve the problem?

¿Is there something I can do to solve this without updating?

Any suggestions will be welcome!

Regards

Eduardo


---
El software de antivirus Avast ha analizado este correo electrónico en busca de 
virus.
https://www.avast.com/antivirus

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

['Carlos H. Cantu' lis...@warmboot.com.br [firebird-support]]

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

[Eduardo guse...@gmail.com [firebird-support]]

Carlos:

Thank you for your answer.

I suggested to not configure the server as a domain controller but the 
person who decide this didn´t want!


I already read the article you mention and there is where I found that 
apparently upgrading to 2.1.5 will solve the problem but I was not sure. 
So if I upgrade, the performance would be similar as if disk cache was 
enabled?


I don´t understand what do you mean saying "The cache problem you are 
referring to is another thing". Are there TWO cache problems? Which is 
THE OTHER? Please, can you explain me?


Regards

Eduardo

 Mensaje original 
*Asunto: *Re: [firebird-support] Bad performance of Firebird in Windows 
Server 2012
*De: *'Carlos H. Cantu' lis...@warmboot.com.br [firebird-support] 

*Para: *Eduardo guse...@gmail.com [firebird-support] 


*Fecha: *24/12/2015 12:47


Never use Firebird (or any RDBMS) in a PDC machine! Windows will 
always disable write disk cache in PDC, and it will be very bad for 
any write sensitive application, like databases (not only Firebird).


The cache problem you are referring to is another thing, and to solve 
this one, you need to upgrade to 2.1.5 (at last): 
http://dyemanov.blogspot.com.br/2012/03/firebird-vs-windows-file-system-caching.html 



Carlos
www.firebirdnews.org - 
www.FireBase.com.br 






Hi guys:

I have an application developped in Delphi that uses Firebird 
Superserver 2.1.4.18393.


It is installed in a Windows network. During many years, the server 
had Windows Server 2003 and everything worked fine. Some time ago they 
changed it temporarily to another PC with Windows 8.1. Everything 
worked fine.


A few days ago they installed a new server with Windows Server 2012. 
My application is working, but it works very slow. It has a log file 
and I verified that the bad performance occurs in every data base 
access, when it opens a database, when it executes any SQL, etc.


I did a little research and found that, apparently, the problem is 
related with the disk cache. In the old servers, disk cache was 
enabled but in the new one with Windows Server 2012 it is disabled 
and, as the server is configured as a domain controller, as far as I 
know, it can´t be enabled.


I read some articles about problems similar to this one and apparently 
this is a problem related with Firebird. In some articles they said 
that since version 2.1.5 this is solved. ¿Is this true?


¿Updating to 2.1.5 will solve the problem?

¿Is there something I can do to solve this without updating?

Any suggestions will be welcome!

Regards

Eduardo

	Este correo electrónico se ha enviado desde un equipo libre de virus 
y protegido por Avast.
www.avast.com 
 











---
El software de antivirus Avast ha analizado este correo electrónico en busca de 
virus.
https://www.avast.com/antivirus

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

['Carlos H. Cantu' lis...@warmboot.com.br [firebird-support]]

[firebird-support] Re: UPDATE to same record causing heavy disk I/O

[Dmitry Yemanov dim...@users.sourceforge.net [firebird-support]]

24.12.2015 05:31, 'Leyne, Sean' wrote:
>
> With today's unlimited availability of disk space and silly-low cost per GB 
> for storage, would an argument to dispense with the delta and simply store a 
> full copy of the record (not including BLOB) be worthy of discussion?

It's not about storage cost, but about IOPS. Bigger record = more I/O 
for the same data = slower performance. Situation is better for SSDs, 
but "silly-low cost" does not really apply there.

> I know that Jim has mentioned that in his later db engine he has adopted a 
> reverse approach which has the latest version stored in full and for 
> transactions required back versions responsible processing the deltas.  In 
> this way, the latest version of the row are always complete so that the back 
> versions can be dropped very efficiently.

Isn't it exactly how Firebird works?


Dmitry

Re: [firebird-support] Re: UPDATE to same record causing heavy disk I/O

[Ann Harrison aharri...@ibphoenix.com [firebird-support]]

On Thu, Dec 24, 2015 at 1:03 PM, Dmitry Yemanov dim...@users.sourceforge.net
[firebird-support]  wrote:

> 24.12.2015 05:31, 'Leyne, Sean' wrote:
> >
> > With today's unlimited availability of disk space and silly-low cost per
> GB for storage, would an argument to dispense with the delta and simply
> store a full copy of the record (not including BLOB) be worthy of
> discussion?
>
> It's not about storage cost, but about IOPS. Bigger record = more I/O
> for the same data = slower performance. Situation is better for SSDs,
> but "silly-low cost" does not really apply there.
>

Right.  The logic was never about saving space on disk, except to the
extent that it reduces the amount of I/O necessary to complete a query.

>
> > I know that Jim has mentioned that in his later db engine he has adopted
> a reverse approach which has the latest version stored in full and for
> transactions required back versions responsible processing the deltas.  In
> this way, the latest version of the row are always complete so that the
> back versions can be dropped very efficiently.
>
> Isn't it exactly how Firebird works?
>

Yes it is.  The primary record version - the most recently created one - is
always complete. The earlier record versions may be whole or deltas.

Jim did handle back versions differently in Netfrastructure and slightly
differently again in NuoDB.  InterBase was designed for systems where
having a whole megbyte of memory, so stuff had to go to disk as quickly as
possible.  When designing for more generous memory systems, he chose to
keep only the most current committed record on disk. That version, and
important back versions, and the newest uncommited version were all
maintained in memory.  If the system went down, any old transactions that
needed old versions went down with it.

NuoDB did approximately the same thing, except that it was distributed, so
old versions had to be maintained a bit more carefully so losing one node
would never lose all old versions.

His latest database, AmorphousDB handles versioning at the attribute level
rather than the record level, but follows the model that only the most
recently committed version of an attribute is worth the cost of a disk
write.

Cheers,

Ann