I have an FB 2.1.2 classic installation running a 70GB database with
the sweep interval set to 0 that runs gbak every night. I just
discovered last week that gbak was being run without garbage
collection (-g), probably to speed up the backup process. This led to
a gap between OAT and OIT that was
Anne -
-Original Message-
From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of Ann Harrison
Sent: Thursday, August 18, 2011 4:50 PM
To: firebird-support@yahoogroups.com
Subject: Re: [firebird-support] Oldest transaction stuck
>>
>> Database heade
Set,
> -Original Message-
> From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of Svein Erling
Tysvær
> Sent: Friday, August 19, 2011 2:18 AM
> To: firebird-support@yahoogroups.com
> Subject: RE: [firebird-support] Oldest transaction stuck
>
> >
Thomas,
> -Original Message-
> From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of Thomas
Steinmaurer
> Sent: Thursday, August 18, 2011 2:35 PM
> To: firebird-support@yahoogroups.com
> Subject: Re: [firebird-support] Oldest transaction stuck
>
> I
Michael -
-Original Message-
From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of Michael Ludwig
Sent: Thursday, June 07, 2012 1:12 PM
To: firebird-support@yahoogroups.com
Subject: Re: [firebird-support] Dealing with inserts from multiple
transacti
Doug -
On June 07, 2012 6:08 PM Doug Chamberlin wrote:
> Yes. On further thought I think I would make the whole ETL process a
> two-pass affair. First pass check for existence of all needed
entities
> and creates ones that are missing. Second pass should do the
inserting
> proper without errors.
I have an FB 2.1.5 Classic server running on a Windows 2003 server,
with a single hard drive for the operating system, and a 3 disk raid 5
array for the database. We have one database on this machine, which
is a dialect 1 database that was started on IB6.0 many years ago,
currently at 90GB. We ha
Alexey -
>> Alexey Kovyazin [mailto:a...@ib-aid.com]
>> Seems like you do correct things, but do you check that sweep is
really successful?
>>
>> Look at the transactions' markers log in IBTM (IBSurgeon
Transaction Monitor), gathered from Profitmed
>> database (120Gb, 400 clients, 2mln trans
Thomas -
-Original Message-
From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of Thomas
Steinmaurer
>> 1): The most obvious thing according to the header page is a very
large
>> gap between the oldest active transaction and the next transaction.
Alexey
>>
>> From: Alexey Kovyazin [mailto:a...@ib-aid.com]
>>
>> >> Is there any way to tell if the sweep was successful other than
all of the markers
matching? Is there any way to tell why a sweep would have failed?
>>
>> No. You should manually check transactions' markers
Here's a related question for you - as I looked at our script for
doing nightly backups, I see a note that says:
"do not use garbage collection (gbak -g) since we run a manual sweep
every night"
Do you know if that's true - we don't need to do garbage collection
via gbak if we are running gfix -
>>From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of Thomas
Steinmaurer
>>> Here's a related question for you - as I looked at our script for
v> doing nightly backups, I see a note that says:
>>>
>>> "do not use garbage collection (gbak -g) since we run
-Original Message-
From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of Bob Murdoch
Sent: Monday, September 17, 2012 10:27 AM
> I have an FB 2.1.5 Classic server running on a Windows 2003 server,
> with a single hard drive for the operating
I am using FB version 2.5.2 (64bit) on a Windows 2008 server.
When trying to restore a database, I am receiving the following error
message in the restore log:
gbak:activating and creating deferred index
FK_USER_DASHBOARD_ELEMENT_TO_US
gbak:cannot commit index FK_USER_DASHBOARD_ELEMENT
ot sure this is the issue, as some of the tables
from the 30 successful indexes have many times more records than the table
indicated in the error message.
Does anyone have any thoughts?
Thank you,
Bob Murdoch
Thomas -
-Original Message-
From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of Thomas Steinmaurer
Sent: Friday, October 11, 2013 5:06 PM
To: firebird-support@yahoogroups.com
Subject: Re: [firebird-support] Restore error during unique index creati
-Original Message-
> From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of Dmitry Kuzmenko
> Sent: Saturday, October 12, 2013 12:36 AM
> To: firebird-support@yahoogroups.com
> Subject: Re[2]: [firebird-support] Restore error during unique index
creati
I received an error during a restore process today, where multiple FKs could
not be restored. The restore log messages look like this:
gbak:cannot commit index FK_ZIP_CODE_ACCT_TO_ACCOUNT
gbak: ERROR:violation of FOREIGN KEY constraint "FK_ZIP_CODE_ACCT_TO_ACCOUNT"
on table "ZIP_CODE_ACCOUN
account a where
a.account_id + 0 = z.account_id)
This will be slow because it not use index but give you the answer
Regards,
Karol Bieniaszewski
- Reply message -
Od: "'Bob Murdoch' mailgro...@murdochfl.com [firebird-support]"
Do:
Temat: [firebird-support] Restore erro
Sean -
-Original Message-
> Very odd situation.
>
> Are the data types of the "account_id" columns the same for all tables?
>
> No one asked if you:
>
> - which FB version you are running?
>
> - are you performing backup/restore using the same FB version (ie. not trying
> to perform an
-Original Message-
> That is weird.
>
> The SQL which Karol provided should have found the problem/missing values
> from the Account table.
>
> I can only think of 2 options of the top of my head:
>
> 1- Try a slightly different SQL query, though it should be the same as
> Karol's (Select
21 matches
Mail list logo
