Re: [firebird-support] gbak error

['Woody' woody-...@gt.rr.com [firebird-support]]

Not sure it helps, but I once had my FB backup schedule service stop working 
after a server software update. It was a Windows server, though, so not sure it 
applies here. Just something else to think about.

Woody (TMW)


From: mailto:firebird-support@yahoogroups.com 
Sent: Tuesday, August 30, 2016 3:36 PM
To: firebird support 
Subject: Re: [firebird-support] gbak error




no, not a file name collision and plenty of disk space

this just started happening, no change to installed s/w 

Nick Upson,
Principal Operations Engineer, Telensa Ltd.
Direct +44 (0) 1799 533252, Support Hotline +44 (0) 1799 399200


On 30 August 2016 at 21:14, Helen Borrie hele...@iinet.net.au 
[firebird-support]  wrote:


  Hello Nick,

  > I'm running fb2.1 on centos5, recently a system has started
  > throwing this error when asked to do a backup, the gbak parameters
  > are unchanged, permissions all seem ok, any suggestions what I might check

  > gbak: ERROR:Unexpected I/O error while writing to backup file
  > gbak:Exiting before completion due to errors

  "gbak parameters are unchanged." Could be you already have a file in
  that location with the same name.

  HB

Re: [firebird-support] gbak error

[Nick Upson n...@telensa.com [firebird-support]]

no, not a file name collision and plenty of disk space

this just started happening, no change to installed s/w

Nick Upson,
Principal Operations Engineer, Telensa Ltd.
Direct +44 (0) 1799 533252, Support Hotline +44 (0) 1799 399200

On 30 August 2016 at 21:14, Helen Borrie hele...@iinet.net.au
[firebird-support]  wrote:

>
>
> Hello Nick,
>
> > I'm running fb2.1 on centos5, recently a system has started
> > throwing this error when asked to do a backup, the gbak parameters
> > are unchanged, permissions all seem ok, any suggestions what I might
> check
>
> > gbak: ERROR:Unexpected I/O error while writing to backup file
> > gbak:Exiting before completion due to errors
>
> "gbak parameters are unchanged." Could be you already have a file in
> that location with the same name.
>
> HB
>
> 
>

Re: [firebird-support] Slow Firebird performance in Azure with durable data disks (e.g., Premium Storage)

[Alexey Kovyazin (ak) a...@ib-aid.com [firebird-support]]

Hi Antti,
Try to lock database with nbackup and check the peformance with locked database 
- in this case all writes will go to delta file sequentially.
If your assumption is true and Premium Storage does not work good with random 
writes, you will see less decrease of performance.
Also, there are other options to deal with such performance problem - please 
contact me directly.
--
Regards,
Alexey Kovyazin
IBSurgeon вторник, 30 августа 2016г., 19:18 +03:00 от Antti Nivala 
antti.niv...@m-files.com [firebird-support]  firebird-support@yahoogroups.com :

> 
>Hi,
> 
>We've experimented with the performance of Firebird in virtual machines in 
>Microsoft's Azure cloud. With Azure VMs, any durable data needs to be placed 
>in "data disks", and essentially that means network-connected storage that is 
>inherently
 slower than e.g. local SSD disks.
> 
>When testing our application's operations with a Firebird database that's on 
>such a "data disk", the performance is roughly 6x slower than when the 
>database is on the VM's local, temporary-only disk. The temporary disks 
>obviously are not
 good for real use so this is for performance comparison only.
> 
>When we do the same test with SQL Server (e.g., SQL Server Express Edition), 
>the performance difference between the temporary local disks and the durable 
>data disks is significantly smaller. SQL Server seems to perform pretty much 
>as fast
 with the data disk with our application's operations.
> 
>The way I'm explaining this difference to myself is that Firebird's way of 
>making the transactions durable is not well suited for this kind of 
>environment where the disk has latency. As far as I understand, Firebird needs 
>to make a lot
 of page writes to the disk to different locations (as the transaction is 
touching multiple tables), and this is probably poison in a situation where the 
disk has latency. On the other hand, SQL Server, as far as I understand, only 
needs to write to its transaction
 log file to make the transaction durable, which is probably an advantage in 
this kind of hardware setup.
> 
>Do you think these general observations/reasons for the slow performance with 
>Firebird with Azure data disks are correct?
> 
>Is there anything obvious that we could do to make Firebird work fast in Azure 
>VMs (requiring durability of the transactions, of course, so turning forced 
>writes off doesn't sound like an option)?
> 
>I can't think of anything myself, but I wanted to ask before completely 
>disregarding the option of running Firebird in Azure VMs.
> 
>More info on Azure Premium Storage data disks here:
>https://azure.microsoft.com/en-us/documentation/articles/storage-premium-storage/
> 
>Antti
> 
>

Re: [firebird-support] gbak error

[Helen Borrie hele...@iinet.net.au [firebird-support]]

Hello Nick,

> I'm running fb2.1 on centos5, recently a system has started
> throwing this error when asked to do a backup, the gbak parameters
> are unchanged, permissions all seem ok, any suggestions what I might check

> gbak: ERROR:Unexpected I/O error while writing to backup file
> gbak:Exiting before completion due to errors

"gbak parameters are unchanged." Could be you already have a file in
that location with the same name.

HB

[firebird-support] Slow Firebird performance in Azure with durable data disks (e.g., Premium Storage)

[Antti Nivala antti.niv...@m-files.com [firebird-support]]

Hi,


We've experimented with the performance of Firebird in virtual machines in 
Microsoft's Azure cloud. With Azure VMs, any durable data needs to be placed in 
"data disks", and essentially that means network-connected storage that is 
inherently slower than e.g. local SSD disks.


When testing our application's operations with a Firebird database that's on 
such a "data disk", the performance is roughly 6x slower than when the database 
is on the VM's local, temporary-only disk. The temporary disks obviously are 
not good for real use so this is for performance comparison only.


When we do the same test with SQL Server (e.g., SQL Server Express Edition), 
the performance difference between the temporary local disks and the durable 
data disks is significantly smaller. SQL Server seems to perform pretty much as 
fast with the data disk with our application's operations.


The way I'm explaining this difference to myself is that Firebird's way of 
making the transactions durable is not well suited for this kind of environment 
where the disk has latency. As far as I understand, Firebird needs to make a 
lot of page writes to the disk to different locations (as the transaction is 
touching multiple tables), and this is probably poison in a situation where the 
disk has latency. On the other hand, SQL Server, as far as I understand, only 
needs to write to its transaction log file to make the transaction durable, 
which is probably an advantage in this kind of hardware setup.


Do you think these general observations/reasons for the slow performance with 
Firebird with Azure data disks are correct?


Is there anything obvious that we could do to make Firebird work fast in Azure 
VMs (requiring durability of the transactions, of course, so turning forced 
writes off doesn't sound like an option)?


I can't think of anything myself, but I wanted to ask before completely 
disregarding the option of running Firebird in Azure VMs.


More info on Azure Premium Storage data disks here:
https://azure.microsoft.com/en-us/documentation/articles/storage-premium-storage/


Antti

Re: [firebird-support] gbak error

[Nick Upson n...@telensa.com [firebird-support]]

it all seems ok, files have been created in other ways

Nick Upson,
Principal Operations Engineer, Telensa Ltd.
Direct +44 (0) 1799 533252, Support Hotline +44 (0) 1799 399200

On 30 August 2016 at 19:26, 'Leyne, Sean' s...@broadviewsoftware.com
[firebird-support]  wrote:

>
>
>
>
> > I'm running fb2.1 on centos5, recently a system has started throwing
> this
> > error when asked to do a backup, the gbak parameters are unchanged,
> > permissions all seem ok, any suggestions what I might check
> >
> > gbak: ERROR:Unexpected I/O error while writing to backup file
> > gbak:Exiting before completion due to errors
>
> Check integrity of storage subsystem.
>
>
> Sean
>
> 
>

RE: [firebird-support] gbak error

['Leyne, Sean' s...@broadviewsoftware.com [firebird-support]]

> I'm running fb2.1 on centos5, recently a system has started throwing this
> error when asked to do a backup, the gbak parameters are unchanged,
> permissions all seem ok, any suggestions what I might check
> 
> gbak: ERROR:Unexpected I/O error while writing to backup file
> gbak:Exiting before completion due to errors

Check integrity of storage subsystem.


Sean

[firebird-support] Firebird Crash - version 2.5.6

[Jardar Maatje jardar.maa...@nds.nortek.no [firebird-support]]

Hi

We are running firebird 2.5.6 and at uneven intervals the service is
crashing with the following log
"C:\Program Files\Firebird\Firebird_2_5\bin\fbserver.exe": terminated
abnormally (4294967295)

It typically happens at night, but not directly related to any scheduled
task. It does run on a virtual server in the cloud, so there could be other
maintenenance services running that we do not see.

The load on the CPU for firbird is fairly high, but I would still not
expect a crash like this.

Typically this happens at least once a week.

Any suggestions on how to progress to find and fix this issue?

-- 
Jardar Maatje
Nortek Data Services AS
Brugata 1
0168 Oslo
tlf: +47 95184034

Re: [firebird-support] Character sets and collations of columns

[Stefan Heymann li...@stefanheymann.de [firebird-support]]

Tomasz,

> One of the legacy databases I happen to maintain has character sets and
> collations messed up. [...]

For a database that is messed up like this, I'd go the clean way and
use a pump. That would also give you the opportunity to change it to
Unicode (UTF-8) at the same time, which is a transition that you will
have to do anyway.

Regards

Stefan

Re: [firebird-support] deploy Windows Application to access Firebird database

[Stefan Heymann li...@stefanheymann.de [firebird-support]]

> Does it apply to remote servers also such as
> www.myserver.com:/opt/database/fbdata.fdb
> The release note README file in the embbeded zip says:
> [...]

You are mixing up access to a remote database (only fbclient.dll
needed) and the Embedded Firebird server (fbembed.dll, renamed to
fbclient.dll).

Regards

Stefan