[firebird-support] Issue with Database Cache Size on FB 3.0

2016-05-31 Thread Fabian Ernesto Chocron fabia...@itbizolutions.com.au [firebird-support]
Hi All

We are having trouble setting up the database cache size on FB 3.0 
running on Windows 2008 R2 64 bits with 32 GB ram.

The problem we have is we cannot get the server to allocate the ram for 
the cache as we intend. With FB 2.54 we had the DB cache set very high, 
close to 1 GB per database, all running in RAM memory. With FB 3.0 we 
read it can allocate much more RAM to the cache, but it appears the 
server is allocating very small amount of Ram when the first user 
connects to the DB, and as we connect more users to the DB the ram 
consumption increases slowly. The setting we are playing with are:

On firebird.conf

FileSystemCacheThreshold = 0
FileSystemCacheSize = 17179869184 (this is 16 GB - the server has 32 GB 
ram.)


On databases.conf

MyTestDB = c:\Temp\MyDb.fdb
{
DefaultDbCachePages = 458752
}

Any ideas what could be wrong? Or what settings would give us maximum 
RAM usage for the DB cache (we dont want file system cache meaning HDD 
cache, we want to have the DB in RAM for the purpose of reading the DB)

Cheers,
Fabian

 










[firebird-support] Risks - Experience and doubts regarding upgrading to FB 3.0 from 2.54?

2016-05-31 Thread Fabian Ernesto Chocron fabia...@itbizolutions.com.au [firebird-support]
Hi Again

We are about to upgrade from Windows 2008 FB 2.54 64 bits into Windows 
2012 R2 FB 3.0 64 bits, and would appreciate comments from experienced 
DB administrators. We use FB as the main DB, and we access it via 32 bit 
native ODBC (the latest version of Firebird ODBC). 

I would appreciate if someone can give us a list of risks associated 
with the upgrade upfront, I have read other posts where some issues were 
experienced such as having to convert Stored Procedures and triggers and 
views, but I am not sure why would that be, in our case we did a test 
conversion to 3.0 and all SPs and Triggers and Views recompiled with no 
issues, so I am not really sure if we are missing something or in our 
case the problem does not apply because we have always used standard SQL 
92 when writting SPs and Triggers.

Also any upfront advise would be highly appreciated.

>From our point of view what we are after with the upgrade is:

1) Get parallel requests to be assigned to different CPUs, improving 
performance when a big process is being executed by another user. 

2) Be able to execute backups excluding some tables ( we read this is a 
new feature)

3) Be able to use Nbackup very often, like every 20 minutes, without 
killing the performance of the database, as it would run on an isolated 
processor, we understand the HDD would still be under the pump, but we 
estimate other system users will not be as affected as on FB 2.54 
because of the SMP feature.

4) DB encryption, we are planning to use this feature

5) Communications encryption, we are also planning to use this feature.

6) More DB pages into ram cache under 64 bit server, we would like to 
dedicate 96 GB ram to the DB cache, under FB 2.54 the limit was 131071 
DB pages at 16KB each page, meaning 2GB ram per database.


Any comments are highly appreciated!

Cheers
Fabian




 




[firebird-support] Is Firebird 3 ready for Production?

2016-05-24 Thread Fabian Ernesto Chocron fabia...@itbizolutions.com.au [firebird-support]
Hi All

We have a multi-user, multi-company, cloud based system running with 
Firebird 2.54 as the main database, with about 100 concurrent connections.  
We are considering migrating to FB 3.0 to take advantaje of the SMP 
architecture, we have a 32 core / processors server, so we are hopping to 
see an increased performance. We also have the need to set up online 
replication. 
Would anyone be able to advise if it it too soon to jump into FB 3.0 for 
production? And if the performance increase would be enough to make the 
upgrade worth considering 3.0 has not been around for long yet, and may be 
"taking too much risk" to move into it so soon? And regarding the 
replication, any advise on what product may be the right choice?

Cheers
Fabian




[firebird-support] Re: ODP: FB 3 issues with String from FB 2.54

2016-05-24 Thread Fabian Ernesto Chocron fabia...@itbizolutions.com.au [firebird-support]
liviuslivius liviuslivius  poczta.onet.pl [firebird-support] 
 yahoogroups.com> writes:

> 
> 
> 
> 
> 
> 
> hi,
> 
> will be good to know which charsets did you tried. utf8, none, 
octets...
> 
> but remember to connet to db also with this charset settings
> 
> regards,
> Karol Bieniaszewski
>  Oryginalna wiadomość Od: "fabianch  
itbizolutions.com.au [firebird-support]"  
yahoogroups.com> Data: 23.05.2016  03:45  (GMT+01:00) Do: firebird-
support  yahoogroups.com Temat: [firebird-support] FB 3 issues with 
String from FB 2.54  
> 
> 
> 
> 
>   
>   
>   
> Hi All
> 
> I have been trying to migrate from FB2.54 into FB 3 for a few weeks, 
and after hitting a string related error for some time i have got to the 
point where I do understand the issue, but I don't know how to solve it. 
The issue is pretty simple, the FB 2.54 DB contains a few characters 
that are not allowed into the FB 3 database, one example of a character 
causing an error during the restore was "Mcgarrity’s" (note the ’) as it 
appears to be outside the scope of the FB3 string domain, I have trying 
creating a new FB3 DB with many different charsets but none works. The 
other string causing issues is for example "΢ÈíÑźÚ", I have many 
records with this type of strings because the DB contains raw emails 
received by the system, stored into Varchars, and apparently some emails 
contain very weird characters, all were handled by FB2.54 but FB3 
rejects the records. I have been able to isolate all recrods with issues 
using IBExpert's table data comparer function, as it created a script 
with all recrods from all tables from FB2.54 and when running the script 
against FB3.0 it singles out all the offending records. 
> 
> Can anyone advise what options I have available to force FB3.0 to 
accept any stuff into string fields?
> 
> 
> Thanks in advanced
> 
> 
> 
> 
>  
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 


Hi Karol

After playing with the problem for a while I noticed the definition of 
the field was Varchar (8192) charset ASCII collate ASCII, so that was 
probably causing the problem. I changed the domain settings to be 
Charset NONE, Collate NONE, and that fixed the issue!  

Cheers,
Fabian