Re: [firebird-support] Is our FB 2.5 Db corrupted ?
is it FB 2.5 or fb 2.5.1 ? because in 2.5.0 i also have this kind of problem on the index (corrupt all the time) the 2.5.1 now work like a charm :) try gfix if you have the time to see if the index are corrupted also commitretaining not so good ... On 1/30/2012 2:51 PM, Colin wrote: We have a 5GB Database FB2.5 Win2008 Server 4 Core M/C, 143 tables, problem with table INV 48K Records When everyone logs off and then log on, access to INV is slow for the last 7K Records. If we fetch all, it takes forever, but eventually can log off and log on again and all is ok. Same is OK if we set all indexes ACTIVE (takes 4 hours for this table), or do a backup. Also if we sweep. this takes the same or more time. Questions: If we backup and restore the database is like new? data exported and then reloaded into a copied schema? This seems to work. Can sweep occur if the database has connections, but no activity? If it did, then we would not get all the sweep operations stacked up. Why does sweep (or the slow backup) take so long and if so, why is there no cpu load? I would have thought that the CPU would have been busy. In the app - one transaction and all datasets/queries/procedures are commitretaining. And, and why always this table - treated much the same as other tables. Are there special settings for the database connection? and how can we know that this might happen (so we could backup and restore before the last user logged out)? Lawrence [Non-text portions of this message have been removed]
[firebird-support] Is our FB 2.5 Db corrupted ?
We have a 5GB Database FB2.5 Win2008 Server 4 Core M/C, 143 tables, problem with table INV 48K Records When everyone logs off and then log on, access to INV is slow for the last 7K Records. If we fetch all, it takes forever, but eventually can log off and log on again and all is ok. Same is OK if we set all indexes ACTIVE (takes 4 hours for this table), or do a backup. Also if we sweep. this takes the same or more time. Questions: If we backup and restore the database is like new? data exported and then reloaded into a copied schema? This seems to work. Can sweep occur if the database has connections, but no activity? If it did, then we would not get all the sweep operations stacked up. Why does sweep (or the slow backup) take so long and if so, why is there no cpu load? I would have thought that the CPU would have been busy. In the app - one transaction and all datasets/queries/procedures are commitretaining. And, and why always this table - treated much the same as other tables. Are there special settings for the database connection? and how can we know that this might happen (so we could backup and restore before the last user logged out)? Lawrence
Re: [firebird-support] Is our FB 2.5 Db corrupted ?
Hello Colin, We have a 5GB Database FB2.5 Win2008 Server 4 Core M/C, 143 tables, problem with table INV 48K Records When everyone logs off and then log on, access to INV is slow for the last 7K Records. If we fetch all, it takes forever, but eventually can log off and log on again and all is ok. Same is OK if we set all indexes ACTIVE (takes 4 hours for this table), or do a backup. Also if we sweep. this takes the same or more time. It sounds more like performance problem. Though you can always ask for free corruption investigation to make sure there is no problem. Questions: If we backup and restore the database is like new? data exported and then reloaded into a copied schema? This seems to work. Almost - internal compiled representation of stored procedures and triggers is not recompiled with backup/restore. Can sweep occur if the database has connections, but no activity? If it did, then we would not get all the sweep operations stacked up. In general - yes, it depends on transaction's markers activity. Why does sweep (or the slow backup) take so long and if so, why is there no cpu load? I would have thought that the CPU would have been busy. Probably application produces a lot of version. In the app - one transaction and all datasets/queries/procedures are commitretaining. And, and why always this table - treated much the same as other tables. Are there special settings for the database connection? and how can we know that this might happen (so we could backup and restore before the last user logged out)? I would say there is no problem with corruption and not enough information to answer performance-related questions. Regards, Alexey Kovyazin IBSurgeon (www.ib-aid.com) Lawrence [Non-text portions of this message have been removed]