[firebird-support] Re: Firebird 1.5.3 on Windows 2012 R2 Server
Mike wrote: Can anyone tell me if Firebird 1.5.3 will run on Windows 2012 R2 Server? The silence might mean that you are the first (on this list) wanting to run the ancient 1.5.3 on a Windows2012R2 server. Try it, and report back. -- Aage J.
[firebird-support] Re: Memory usage excess / leak in FBServer 2.
Jojakim Stahl wrote: still no solution. Running since last Friday, fbserver.exe grew up to +3GB memory so far. Few minutes ago, I stopped all our services, it remained only one attachment from isql to select mon$memory_usage: memory did not went down. IMHO, this memory leak is not caused by a client leaving open something, otherwise the memory should go down when the connection is closed, shouldn't it? Could it be that the only one attachment remained is a cause of your problems? If the transaction is not R/O+committed it could prevent moving the transaction counters. -- Aage J.
[firebird-support] Re: losing connection with server on a local PC
shg sistemas wrote Hello! This is a bit of firebird.log (just the lines with errors) of the last few days. Thanks!!! BARO (Client) Tue May 12 12:20:20 2015 C:\Program Files\Firebird Firebird_2_5\bin#92;fbserver.exe: terminated abnormally (4294967295) BARO (Server) Tue May 12 12:30:24 2015 *** DUMP *** BARO (Server) Tue May 12 12:30:24 2015 Fatal exception during clumplet dump: Invalid clumplet buffer structure: spb in service attach should begin with isc_spb_version1 or isc_spb_version BARO (Server) Tue May 12 12:30:24 2015 Plain dump starting with offset 893: araSlZfMaehCCOyPmJJrIwcTxhqacRmZTqcNgJYlugrSrAlLLYdbXcYfgnmke ... I see much of the same happening. It started with the occasional message in December 2014, but in May it got much more frequent (with abnormal termination and restarts). This is a Win2008R2 server with 64bit Firebird 2.5.1. The server was rebooted, but that did not fix the problem. This server has been running since 2012 (with the same set of databases) with hardly a problem. The fbclient on remote clients could be anything from version 1.5 to 2.5. Last night we upgraded to latest Fb 2.5.4 (reboot after installing a number of Windows updates). The databases (sizes: 2GB and 16GB) were backuped with Fb/2.5.1 and restored with Fb/2.5.4. No hickups. The databases are accessed with internet connections (in addition to the local network). It looked fine for a short time... The log contains this (after the upgrade to 2.5.4): === FILMINFOSERVER (Client) Wed May 13 20:37:15 2015 Guardian starting: C:\Program Files\Firebird\Firebird_2_5\bin\fbserver.exe FILMINFOSERVER (Server) Thu May 14 02:04:08 2015 *** DUMP *** FILMINFOSERVER (Server) Thu May 14 02:04:08 2015 Tag=-1 Offset=34 Length=36 Eof=0 FILMINFOSERVER (Server) Thu May 14 02:04:08 2015 Clump 5 at offset 0: D1383Jf4e1Z00a41e^00ebffY00151f]001ffeY0015loc FILMINFOSERVER (Server) Thu May 14 02:04:08 2015 Fatal exception during clumplet dump: Invalid clumplet buffer structure: buffer end before end of clumplet - clumplet too long FILMINFOSERVER (Server) Thu May 14 02:04:08 2015 Plain dump starting with offset 34: al FILMINFOSERVER (Server) Thu May 14 02:05:12 2015 *** DUMP *** FILMINFOSERVER (Server) Thu May 14 02:05:12 2015 Tag=-1 Offset=34 Length=36 Eof=0 FILMINFOSERVER (Server) Thu May 14 02:05:12 2015 Clump 5 at offset 0: d5cW00Edfd5JDb8U00wee86Jc001ceeZ00d382J15loc FILMINFOSERVER (Server) Thu May 14 02:05:12 2015 Fatal exception during clumplet dump: Invalid clumplet buffer structure: buffer end before end of clumplet - clumplet too long FILMINFOSERVER (Server) Thu May 14 02:05:12 2015 Plain dump starting with offset 34: al FILMINFOSERVER (Server) Thu May 14 02:07:46 2015 *** DUMP *** FILMINFOSERVER (Server) Thu May 14 02:07:46 2015 Tag=-1 Offset=34 Length=36 Eof=0 FILMINFOSERVER (Server) Thu May 14 02:07:46 2015 Clump 5 at offset 0: rde00faddJb81a^000beY0015fff6\00dba3Y0015loc FILMINFOSERVER (Server) Thu May 14 02:07:46 2015 Fatal exception during clumplet dump: Invalid clumplet buffer structure: buffer end before end of clumplet - clumplet too long FILMINFOSERVER (Server) Thu May 14 02:07:46 2015 Plain dump starting with offset 34: al FILMINFOSERVER (Server) Thu May 14 02:13:24 2015 *** DUMP *** FILMINFOSERVER (Server) Thu May 14 02:13:24 2015 Tag=-1 Offset=34 Length=36 Eof=0 FILMINFOSERVER (Server) Thu May 14 02:13:24 2015 Clump 5 at offset 0: )484JcdNdfJLB00e180Jc00199TL00dv84J15loc FILMINFOSERVER (Server) Thu May 14 02:13:24 2015 Fatal exception during clumplet dump: Invalid clumplet buffer structure: buffer end before end of clumplet - clumplet too long FILMINFOSERVER (Server) Thu May 14 02:13:24 2015 Plain dump starting with offset 34: al FILMINFOSERVER (Server) Thu May 14 02:24:24 2015 *** DUMP *** FILMINFOSERVER (Server) Thu May 14 02:24:24 2015 Fatal exception during clumplet dump: Invalid clumplet buffer structure: spb in service attach should begin with isc_spb_version1 or isc_spb_version FILMINFOSERVER (Server) Thu May 14 02:24:24 2015 Plain dump starting with offset 927: zrPRZJCkLgJbqbqHa FILMINFOSERVER (Server) Thu May 14 02:24:27 2015 INET/inet_error: read errno = 10054 FILMINFOSERVER (Server) Thu May 14 03:16:50 2015 INET/inet_error: read errno = 10054 === This is an unfortunate situation - I hope someone can offer guidance. TiA Aage J.
[firebird-support] Re: Moving from FB 1.5x to 2.5x
Ed Dresse3l wrote: We are considering moving from 1.5x to 2.5x. You may need to consider the -fix_fss_data and _fix_fss_metadata switches of gbak. I no longer recall what kind of problems I saw (if any), but anyhow I ended up writing two small programs that converted Norwegian letters in procedures, trigger, exceptions, table and field descriptions. One program converted the letters to strings like e.g. $aa$ before backup with 1.5, and the other program converted back after restore with 2.x. -- Aage J.
[firebird-support] Re: Unable to create unique constraint
André wrote ... The table is a completely new creation, and nobody else could have been using it besides me, although the database itself is the original production database used by some 50 concurrent users. I disconnected and reconnected, even did a backup (to visit each record) and explicit sweep and made sure noone else was connected to the database late in the evening. No success. ... A couple of times I've seen problems vanish just by stopping/starting the Firebird service. Maybe just closing all connection or, at worst, restarting the service. Those problems occured after some metadata change (with connected users). The latest one was desctibed in a message to this list on January 14. (Subject: Firebird error: partner index description not found). Maybe you did some tinkering with the metadata? -- Aage J.
[firebird-support] Firebird error: partner index description not found
Suddenly (I don't know what caused it!), it was no longer possible to connect to one of our databases. Other databases worked ok. This was found in firebird.log (along with quite a few 10054 errors): Database: ...\prod.fdb25 (full path, but it was accessed via an alias) Internal Firebird consistency check (partner index description not found (175), file: idx.cpp line: 1346) The Firebird version is 2.5.1.26351, SuperServer. I don't recall the Windows version, but it probably is something like 2008server (R2) - running in a VM. There are only Firebird databases running on this server. And some AV s/w (Nod32, I think). The Firebird service was stopped, and the Windows server was rebooted (we did an update of some VMware software which included the reboot). After this we could sucessfully connect. We ran a gfix v n which terminated (after 10 minutes or so) without any messages. Q's: Should we do something/anything (to check the health of the database)? What could cause such a problem? We hardly ever experience problems with our Firebird databases, even so, maybe there are precautions to be taken? TiA Aage J.
[firebird-support] Re: Forced write
rddymanohar wrote: We are on Firebird 1.56 and recently encountered database corruption problem with a customer. Found that forced write was turned off on the database and after the database was restored turned it on. However on checking the next day forced write was again turned off. We do daily sweep, reindex and backup on the database as maintenance at the the eod. Will any of this cause forced write to be turned off. None of those operations, on their own, will change the forced write flag setting. The setting can be changed thru gfix command or API call. Sean P.S. A restore would not change the setting on its own -- it would restore using the setting that was present from the backup. Could it be that for Fb/1.5 any user can change this setting? If so, an impatient user might be tempted to increase performance... -- Aage J.
[firebird-support] Re: Help, tunning database
Anto wrote: I have Superserver Firebird 2.5.1 installed on Win7 pro 64 bit on I7 2600K. When data grows, Firebird Server starting to slow down. I shutdown Firebird Server, starting again without changing anything and Firebird Server became smooth again. Any ideas, what is the problem with this? Firebird.conf mostly on its default values except for cpuaffinity set to 15 and DefaultDbCachePages set to 4096. And later: I did a small test, here are the settings : - FB Super Classic 2.5.1 64 bit - Win7 pro 64 bit Not related to your main problem, but if you are using SuperServer then cpuaffinity set to 15 may not be an optimal setting. -- Aage J.
[firebird-support] employee.fdb
Is there a good reason for the employee.fdb database to use character set NONE (apart from this being described in Helen's Firebird book (and it has always been like this))? DBAs using NONE seem to be met with raised eyebrows (on this NG, at least), so why not use e.g. UTF8 in the example database. -- Aage J.
[firebird-support] Re: Rename database command
There are no long running transactions. Good. At first I thought it could be a long lasting transaction that someone used just to monitor activities in the database. -- Aage J.
[firebird-support] Re: unavailable database
André wrote: In case somebody's just reading by and has a clue, don't hold back :-) I'm reading, but have no clue! Anyway, did you consider this: http://www.ib-aid.com/downloads/ Best of luck Aage J.
[firebird-support] Re: Redirection
gu1tarrr wrote: ... If you want, you can make a simple test, connect like 127.0.0.1:127.0.0.1:database.fdb and try to run some SQL on it. In my case it connects successfully, the problem comes when I try to execute some SQL. ... Using IB_SQL and a connection string like 127.0.0.1:127.0.0.1:SomeAlias or localhost:localhost:SomeAlias I just got: Invalid connection path when trying to connect. I did set Redirection = 1, and restarted Firebird/2.5.2 afterwards. -- Aage J.
[firebird-support] Re: UNION prevents all records from being pulled to the results
SoftTech wrote: The SQL that follows pulls these results: (These results are missing 5 records from the second select of the union) FEE_CODE AMT_EARNED_AGENCY SHOW_IN_PMT_DIST_PLAN FEE_CATEGORY CCO2 76 1 0 SVC 1.17 1 0 SVC 30 1 0 ... ... From Helen's Firebird book: If duplicate rows are formed during the creating of the union set, the default behavior is to exclude the duplicate rows from the set. To include the duplicates, use UNION ALL instead of UNION on its own . -- Aage J. [Non-text portions of this message have been removed]
[firebird-support] Re: Desktop Application For Centralized Firebird Database...
Vishal wrote: ... Here, my doubt is Using Delphi 5 and Firebird database, is it possible for all the instances of this application which are installed at different cities could access one centralized database ? If yes then HOW ? ... You need a fixed IP address for the machine which is hosting the database (the db server). Your program - wherever it runs - just need to use a connection string with IP address or machine name:database path and filename, or alias, e.g. 123.234.123.234:D:\DB\ourdb.fdb (or possibly VISHAL_SERVER:LIBRARY_DB, with necessary definitions in place). You may have to persuade administrators to open port 3050 in firewalls (in- and outbound). -- Aage J.
[firebird-support] Re: Restore problem
Dmitry Kuzmenko wrote: if you run same command line for the same DB, i.e. backup/restore, backup/restore, etc, than you killed metadata in it. I think we are facing a major misunderstanding. Note, there are 2 sites involved. 1. Site A is running Fb/1.5. A backup is made nightly from a database. 2. At irregular intervals last night's backup is transferred (ftp) to site B - my pc. 3. My pc is running Fb/2.5. I restore the backup here (site B) using the parameters shown. The restore always overwrites the current database (otherwise I rename it before restore). 4. This backup is _never_ returned to site A. It is just used (on site B) for test/development. 5. The original database (at site A) is updated by some other users. I do sometimes update the metadata of the database at site A. -- Aage J.
[firebird-support] Re: Restore problem
Friday, April 13, 2012, 1:44:34 AM, Dmitry Kuzmenko wrote: AJ Fb/2.5 restoring Fb/1.5 database with (one single command line): AJ == AJ gbak -se service_mgr AJ -fix_fss_metadata ISO8859_1 AJ -fix_fss_data ISO8859_1 AJ -rep -v -z AJ -user SYSDBA -password masterkey AJ E:\...\...\sl1b3_20120412.fbk15 SL1 AJ == AJ Previous restores have never failed. DK mmm, you did this command SEVERAL TIMES??? Yes, I've do this quite often. I transfer the backup file for a specific database at irregular intervals to do testing and development. So, the file is a new one every time. Previous restores means backups from e.g. last month. Why wouldn't I use the same restore command each time I fetch a new backup? Any advice on improvements of the command is most welcome. Latest news should anyone be following this thread: 1. There were no interesting messages in the firebird.log 2. Today's backup was restored without any problems I'll blame the problem on some corruption during the transfer. -- Aage J.
[firebird-support] Restore problem
Fb/2.5 restoring Fb/1.5 database with (one single command line): == gbak -se service_mgr -fix_fss_metadata ISO8859_1 -fix_fss_data ISO8859_1 -rep -v -z -user SYSDBA -password masterkey E:\...\...\sl1b3_20120412.fbk15 SL1 == Previous restores have never failed. This restore ended with: == ... gbak:restoring data for table AKTIVITET gbak: 1 records restored ... gbak: 22 records restored gbak: 23 records restored gbak: 24 records restored gbak: ERROR:validation error for column IDNR, value *** null *** gbak: ERROR:warning -- record could not be restored gbak:Exiting before completion due to errors == No previous problems with the database (AFAIK). The table is filled by triggers. Table definition: == CREATE TABLE AKTIVITET ( IDNR INTEGER not NullPrimary Key, TIDSPUNKTTIMESTAMP, BRUKER VARCHAR(16), HENDELSE VARCHAR(16), TABELL VARCHAR( 8), SLNR INTEGER, ID INTEGER ) == About 2 million records. I did not find any records with == select * from AKTIVITET where IDNR is null == And none should be found, AKTIVITET.IDNR - the primary key - cannot be Null (right?). What happened to the database? I'll try a new backup tomorrow. Note: The backup file was transferred to my pc via ftp. Could it just be an act of internet, corrupting my file? -- Aage J. Running WinXP Pro SP3
[firebird-support] Re: Firebird/2.5 and Win/2008R2
Alexandre responded: My experience is with OLTP use, once you said that there is few insert/update/delete perhaps the shared cache of SS could be a good benefit, but I think that the OS cache could do the same job... A natural choice for SMP machine is CS or SC... I would choose SC or CS instead of SS even if the most use is select's Alexey responded: Use Classic or SuperClassic to benefit from multi-CPU environment (if one user will run bad query which consumes 100% CPU, others will work without any problem). Since RAM is database size, the database will be stored completely in file cache (after some time), it means better performance, but stability becomes an issue - ensure you make reliable backups and, of course, use UPS. Thank you for comments and advice. Are there any peculiarities with the setup of SuperClassic? Cache size for CS is very different than cache size for SS - what are the rules for SuperClassic? The main database (in SuperCerver mode) currently uses a page size of 8KB, and 8K page buffers - totalling 64MB. This (64MB) isn't much, but it is according to the old recommendations of don't use more than about 1 pages. Does a cache size of 1GB (with 64bit SuperClassic) seem reasonable? What are experiences with the configuration setting FileSystemCacheThreshold? The ReleaseNotes mentions its relationship to the value of MaxFileSystemCache, but it also says that MaxFileSystemCache is no longer a valid parameter (for 2.5)! Maybe this needs to be cleaned up in the ReleaseNotes? -- Aage J.
[firebird-support] Re: comments/advices on database design change please
Milan B. wrote: ehaerim wrote: 1) Can you tell me more how efficient by keeping blobs outside of the main table? It is not really any more efficient. The blob in main table would only keep blob ID there - actually blob data is stored on a separate database page. You would essentially be duplicating what Firebird is already doing. Milan, isn't it so that small blobs are stored on database pages with the rest of the record? I haven't seen any authoritative numbers on this, but as best as I can remember the advice given in a session at the Luxembourg conference was that keeping blobs in separate tables was (could be?) a good thing. As I wrote, (with Firebird) I never bothered to do the split. As for YMMV, it is often used when giving an estimate on how many miles a car can run on a gallon of petrol - Your Milage May Vary. -- Aage J.
[firebird-support] Re: comments/advices on database design change please
HR wrote ... The previous database design was - multiple yearly databases - three tables - single key having symb and date combined - no indexing The new database will be [1] One single database file : OneBigDB.fdb [2] One single table : DAILYBLOB [3] Five columns : SYMB, YMD, TB, MB, DB [4] Primary keys : SYMB, YMD [5] Index : YMD (descending) CREATE TABLE DAILYBLOB ( SYMB VARCHAR(20) NOT NULL, YMD DATE NOT NULL, TB BLOB SUBTYPE BINARY, MB BLOB SUBTYPE BINARY, DB BLOB SUBTYPE BINARY, PRIMARY KEY(SYMB, YMD) ); CREATE DESC INDEX YMD_IDX ON DAILYBLOB(YMD); ... Maybe two tables will be better? create table DAILYMAIN ( ID integer not null primary key, SYMB varchar(20) not null, YMDdate not null ); create table DAILYBLOB ( ID integer not null primary key, TB blob ..., MB blob ..., DB blob ... ); Individual indexes on SYMB and YMD (whatever proves beneficial). These tables are in a one-to-one relationship (on their IDs, use a single generator). Keeping blobs outside of the main table might make for more efficient search and retrieval (if you don't always need the blobs). YMMV. -- Aage J.
[firebird-support] Re: backup very slow and how often sweep a database ?
stéphane wrote: Everyday i sweep the database and i backup it gfix.exe -sweep and just after a backup like this : gbak.exe -B -t -v -z the probleme is that the sweep can take up to 5 hours to finish and the backup up to 12 hours to finish :( i know that in the backup i don't put the -g params (inhibit garbage collection) but someone say me that the -g do something else that the gfix.exe -sweep doesn't do ... I think it is the other way around: sweep can do something that gbak's GC doesn't do. Sweep does a more thorough cleaning when no other user is connected, I think. If the sweep is run before the gbak, then gbak's GC will not find anything to do and using -g (or not) should not have any affect. now i need to know, how often i need to launch the gfix.exe -sweep and the gbak.exe -B without the -g params ? everydays seam not anymore possible because of the time taken by these process... one time a month ? thanks by advance for you help If weekends are quiet periods you could schedule gbak -g to run every night and gfix sweep every weekend. Note: When I started to use the ServerManager switch (-se service_mgr) I noticed a significant speedup for gbak. -- Aage J.
[firebird-support] Re: DDL updates in 2.5
Martin Agren wrote: ... Data output from my stored proc isnt reflecting the changes I have made. I make changes in DDL, check the new dataset (Flamerobin or my client app) and am not getting the desired results as data is unchanged. I make another change, still no effect. Then, when disconnectiong and restarting my client side apps all the changes suddenly appear. Will your stored procedure need re-compiling before changes will show up in the results? I don't think the SP is recompiled until the database is closed and reopened - it could be difficult to recompile for you and keeping the old one for other users. OTOH - I could be mistaken. -- Aage J.
[firebird-support] Re: FB suitability for Consolidated Database of 15 GB.
Sam wrote: ... Take a look at the Synchronization Example at the bottom of this link: http://msdn.microsoft.com/en-us/sync/bb821992 It explains the basic concept of how Sync Framework syncs the data. The whole key to it is the Update Tick Count which is database wide. In the Microsoft world is the @@DBTS function. They refer to this function as either the timestamp or as the rowversion. ... When I read about maintaining tombstone information (for deleted items) I thought that replication - while not a simple solution - might eventually be a better choice. YMMV. A point to note is that InterBase and Firebird may be talking a lot on the wire (at least they used to) meaning that they might not be the very quickest performers over the internet. Again, YMMV. -- Aage J.
