Re: Odp: [firebird-support] Firebird 2.5.3 SS Tuning
Thank you for answer. For 16Gb or 64Gb RAM I don't if it is possible with current server (physical server limits I mean), I'll ask to customer (I hope in 8Gb RAM). Anyhow, with dbbuffers you mean Page Buffers, right? And dbpagesize*dbbuffers=bytes used for cache, you mean total bytes for all connection or bytes for each connection? Another doubt (I found it in some forums but I don't remember the link), a 16k page includes a 16k hard disk cluster (format options I mean)? It's correct? Tiziano. Il Venerdì 19 Settembre 2014 7:25, 'liviusliv...@poczta.onet.pl' liviusliv...@poczta.onet.pl [firebird-support] firebird-support@yahoogroups.com ha scritto: Hi, Your big problem is low RAM with 32bit os an FB. Esspecially your sweep can take very very long time if some of your index is bigger than avaiable RAM. And yes upgrade to new server with minimum 16 GB RAM. Your DB is 50GB then the best will be 64. Then backup your db an restore with 16k page and increase your dbbuffers (value in pages) You can calc this as dbpagesize*dbbuffers=bytes used for cache I think that your stat query will run in few minutes instead of houers I made the same for my db server and it work like rocket ;-) Regards, Karol Bieniaszewski Sorry for lang errors - Reply message - Od: Tiziano tmdevelo...@yahoo.com [firebird-support] firebird-support@yahoogroups.com Do: firebird-support@yahoogroups.com Temat: [firebird-support] Firebird 2.5.3 SS Tuning Data: czw., wrz 18, 2014 18:06 [CUT]
Re: Odp: [firebird-support] Firebird 2.5.3 SS Tuning
On Fri, 19 Sep 2014 01:22:31 -0700, Tiziano tmdevelo...@yahoo.com [firebird-support] firebird-support@yahoogroups.com wrote: Thank you for answer. For 16Gb or 64Gb RAM I don't if it is possible with current server (physical server limits I mean), I'll ask to customer (I hope in 8Gb RAM). Adding more RAM is not very useful if you are not going use it. Especially with SuperServer with a small page buffer and a small page size, the only effect of more memory is that more of the database might be in the filesystem cache. If the server is 32 bit as you seem to imply, then there is not a lot of use in increasing memory beyond 4 GB. Anyhow, with dbbuffers you mean Page Buffers, right? And dbpagesize*dbbuffers=bytes used for cache, you mean total bytes for all connection or bytes for each connection? Another doubt (I found it in some forums but I don't remember the link), a 16k page includes a 16k hard disk cluster (format options I mean)? It's correct? No, the page size is the size of data pages in the database. It has nothing to do with cluster size of your hard disk (although potentially it might influence performance if they are the same, I wouldn't count on that as most disk are already read in multiple clusters at once). In general I'd use 16K pages, but your mileage may vary. Mark
[firebird-support] MON$STATEMENTS question
Hi, I'm not sure if this is a problem or not, but I have quite a few entries like this with NULL transaction ID's in the MON$STATEMENTS table: MON$STATEMENT_ID 460577 MON$ATTACHMENT_ID 128 MON$TRANSACTION_ID NULL MON$STATE 0 MON$TIMESTAMP NULL MON$SQL_TEXT Select abc from xyz where this = that MON$STAT_ID 421 Is this a sign that my code isn't cleaning something up properly, or is it perfectly normal? Any idea under what circumstances this will happen? Thanks Maya
[firebird-support] firebird.log in Windows directory
Hi everyone, We are using FB 2.5.2 and 2.5.3 x64 SuperClassic under Windows 2008R2 with default installation options and noticed recently that beside the expected location (%programfiles%\firebird\firebird_2_5\) a firebird.log instance containing fairly recent entries. Anyone else noticed, any way to avoid or should it be registered in the tracker? It bugs the operators as the latter is'nt checked regularly and some failure conditions might be missed. Best Regards Zsolt
[firebird-support] Re: Can't connect to CentOS 7 service port 3050 from network
Thank you both for helping. Effectively I missed some steps your posts remind me. Hernando.
Re: [firebird-support] firebird.log in Windows directory
On Fri, 19 Sep 2014 15:14:22 +0200, Zsazsi m-zs...@freemail.hu [firebird-support] firebird-support@yahoogroups.com wrote: Hi everyone, We are using FB 2.5.2 and 2.5.3 x64 SuperClassic under Windows 2008R2 with default installation options and noticed recently that beside the expected location (%programfiles%\firebird\firebird_2_5\) a firebird.log instance containing fairly recent entries. Anyone else noticed, any way to avoid or should it be registered in the tracker? It bugs the operators as the latter is'nt checked regularly and some failure conditions might be missed. That might be from client, not from the server. If fbclient.dll is loaded from the Windows folder, then chances are the log is also written there. Mark
[firebird-support] Re: MON$STATEMENTS question
19.09.2014 13:16, Maya Opperman wrote: I’m not sure if this is a problem or not, but I have quite a few entries like this with NULL transaction ID’s in the MON$STATEMENTS table: Is this a sign that my code isn’t cleaning something up properly, or is it perfectly normal? Any idea under what circumstances this will happen? This is perfectly normal. From /doc/README.monitoring_tables: 3) For table MON$STATEMENTS: - column MON$SQL_TEXT contains NULL for GDML statements - columns MON$TRANSACTION_ID and MON$TIMESTAMP contain valid values for active statements only i.e. if the statement is prepared but not currently executed, then its transaction id will be NULL in MON$STATEMENTS. Dmitry ++ Visit http://www.firebirdsql.org and click the Documentation item on the main (top) menu. Try FAQ and other links from the left-side menu there. Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/ ++ Yahoo Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/firebird-support/ * Your email settings: Individual Email | Traditional * To change settings online go to: http://groups.yahoo.com/group/firebird-support/join (Yahoo! ID required) * To change settings via email: firebird-support-dig...@yahoogroups.com firebird-support-fullfeatu...@yahoogroups.com * To unsubscribe from this group, send an email to: firebird-support-unsubscr...@yahoogroups.com * Your use of Yahoo Groups is subject to: https://info.yahoo.com/legal/us/yahoo/utos/terms/
Re: [firebird-support] firebird.log in Windows directory
2014-09-19 15:55 GMT+02:00 Mark Rotteveel m...@lawinegevaar.nl [firebird-support] firebird-support@yahoogroups.com: On Fri, 19 Sep 2014 15:14:22 +0200, Zsazsi m-zs...@freemail.hu [firebird-support] firebird-support@yahoogroups.com wrote: Hi everyone, We are using FB 2.5.2 and 2.5.3 x64 SuperClassic under Windows 2008R2 with default installation options and noticed recently that beside the expected location (%programfiles%\firebird\firebird_2_5\) a firebird.log instance containing fairly recent entries. Anyone else noticed, any way to avoid or should it be registered in the tracker? It bugs the operators as the latter is'nt checked regularly and some failure conditions might be missed. That might be from client, not from the server. If fbclient.dll is loaded from the Windows folder, then chances are the log is also written there. Mark Good bet Mark, it seems that only client entries exist in Windows\firebird.log. Our application uses IBX that binds to gds32.dll (a copy of fbclient.dll), which is placed into the WINDOWS\SysWOW64 during installation with fbclient.dll, not into WINDOWS. Also this behaviour seems to exists only in SuperClassic and perhaps Classic, SuperServer writes the client log messages correctly to the FB install base folder. Thanks Zsolt
Re: [firebird-support] Firebird Embedded corruptions
On Mon, Sep 15, 2014 at 7:41 AM, Jan Flyborg jan.pers...@gmail.com [firebird-support] firebird-support@yahoogroups.com wrote: I just made another posting where I tried to describe three different examples of things we have seen. The first was a wrong page type, which sounds like a bug that was fixed in a newer version in code that's common to all Firebird architectures. In your case, the bad page was in an index (7). If you can find the index with the bad page and recreate it, all will be well. Just as an FYI, the page types are: 0 - undefined, normally an uninitialized page and indicates a bad page pointer elsewhere; 1 - Database header page 2 - Page inventory page 3 - Transaction inventory page 4 - Pointer page 5 - Data page 6 - Index root page - contains information about each index on the table, one per table 7 - Index (B-tree) page 8 - Blob data page 9 - Generator pages The second problem (CCH_precedence: block marked. file: cch.cpp line: 4390) is more concerning - I don't remember having read a bug about it. CCH is the cache handler. A mark is the sign that a page is about to be changed. When Firebird is forced to write a page either as part of a commit or to free space in the cache, it must write out any pages that the page depends on first. That's a little obscure. Suppose that the page you're about to write has a record with a back version, and the back version is on a different page. To keep the database consistent, the page with the back version must be on disk before the page that includes a record that points to the back version. Firebird keeps a list of precedence relationships and CCH goes through them before writing a page. I think the error means that someone is currently writing to a page that's on the precedence list. That should never happen. It's interesting that the problem occurred during an alter index operation. However, the database should be fine on disk and usable after you restart Firebird. Page marks are entirely in memory. It's quite possible that I missed a bug report and this problem was fixed in a later version. The third problem is two records in a referencing table lack mates in the referenced table, despite a referential constraint. I have no idea how that happened, but it should be reasonably easy to fix in your database. The first problem is what I would call a physical corruption - the internal structure of the database is corrupt. The second is an in-memory corruption - the disk database is OK, but the in-memory version is damaged. The third is logical corruption - the database is physically intact, but does not conform to the data rules.. Typically we fix our problems with a gfix -mend and then doing a backup restore cycle. Usually some tables then still have problems (typically foreign keys that refers to non existing primary keys), so if possible we then remove the faulty records and then it works again. Gfix is pretty old and somewhat crude. IBFirstAid might give you better help on physical corruptions. Checking that there is no non-conforming data before creating constraints may help with logical corruption. Good luck (and my apologies for the late response) Ann
Re: [firebird-support] read-only select generates 'lock conflict on no wait transaction'?
On Thu, Sep 18, 2014 at 1:00 PM, 'Carlos H. Cantu' lis...@warmboot.com.br [firebird-support] firebird-support@yahoogroups.com wrote: If you are sure that there will be no data editing, I recommend you to use ReadCommited+ReadOnly transaction, since it will not block garbage collection. Assuming you can live with a little inconsistency in your results. And that the problem is not that someone has introduced a No Rec Version condition into the transaction definition. Cheers, Ann
RES: [firebird-support] Firebird Embedded corruptions
Ann, about the third problem: “The third problem is two records in a referencing table lack mates in the referenced table, despite a referential constraint. I have no idea how that happened, but it should be reasonably easy to fix in your database. ” I saw this happen two times, it is related to bad RAM. I thought that when Firebird writes to the memory the memory changes this contents and when the transaction commits you get a different value. We struggle with one case this week. The solution is change RAM from the server where Firebird is running. De: firebird-support@yahoogroups.com [mailto:firebird-support@yahoogroups.com] Enviada em: sexta-feira, 19 de setembro de 2014 16:14 Para: firebird-support@yahoogroups.com Assunto: Re: [firebird-support] Firebird Embedded corruptions On Mon, Sep 15, 2014 at 7:41 AM, Jan Flyborg jan.pers...@gmail.com [firebird-support] firebird-support@yahoogroups.com wrote: I just made another posting where I tried to describe three different examples of things we have seen. The first was a wrong page type, which sounds like a bug that was fixed in a newer version in code that's common to all Firebird architectures. In your case, the bad page was in an index (7). If you can find the index with the bad page and recreate it, all will be well. Just as an FYI, the page types are: 0 - undefined, normally an uninitialized page and indicates a bad page pointer elsewhere; 1 - Database header page 2 - Page inventory page 3 - Transaction inventory page 4 - Pointer page 5 - Data page 6 - Index root page - contains information about each index on the table, one per table 7 - Index (B-tree) page 8 - Blob data page 9 - Generator pages The second problem (CCH_precedence: block marked. file: cch.cpp line: 4390) is more concerning - I don't remember having read a bug about it. CCH is the cache handler. A mark is the sign that a page is about to be changed. When Firebird is forced to write a page either as part of a commit or to free space in the cache, it must write out any pages that the page depends on first. That's a little obscure. Suppose that the page you're about to write has a record with a back version, and the back version is on a different page. To keep the database consistent, the page with the back version must be on disk before the page that includes a record that points to the back version. Firebird keeps a list of precedence relationships and CCH goes through them before writing a page. I think the error means that someone is currently writing to a page that's on the precedence list. That should never happen. It's interesting that the problem occurred during an alter index operation. However, the database should be fine on disk and usable after you restart Firebird. Page marks are entirely in memory. It's quite possible that I missed a bug report and this problem was fixed in a later version. The third problem is two records in a referencing table lack mates in the referenced table, despite a referential constraint. I have no idea how that happened, but it should be reasonably easy to fix in your database. The first problem is what I would call a physical corruption - the internal structure of the database is corrupt. The second is an in-memory corruption - the disk database is OK, but the in-memory version is damaged. The third is logical corruption - the database is physically intact, but does not conform to the data rules.. Typically we fix our problems with a gfix -mend and then doing a backup restore cycle. Usually some tables then still have problems (typically foreign keys that refers to non existing primary keys), so if possible we then remove the faulty records and then it works again. Gfix is pretty old and somewhat crude. IBFirstAid might give you better help on physical corruptions. Checking that there is no non-conforming data before creating constraints may help with logical corruption. Good luck (and my apologies for the late response) Ann
[firebird-support] Rescheduled: Maintenance/outage for tracker.firebirdsql.org and web.firebirdsql.org from Sept 20 08:00 to Sept 21 18:00 (EDT)
All, The previously mentioned ISP problems have been resolved, so the server room equipment move is happening tomorrow. Although the move should be largely completed on the 13th, there may be issues which could drag into the 14th. This will affect the project tracker.firebirdsql.org and web.firebirdsql.org systems. Sean
