| Subject | Re: [firebird-support] Re: Firebird 2.1.1 Gbak Issues |
|---|---|
| Author | Helen Borrie |
| Post date | 2009-03-13T21:06:21Z |
At 04:49 AM 14/03/2009, you wrote:
1. Something is creating a table or called UTMP that contains at least one computed field and one index (which might be a PK or FK index).
2. Something (that table, or another arbitrarily created one) has a computed field referring to a table whose RDB$RELATION_ID IS 171.
3. Arbitrarily, instances of the app are creating, altering and dropping UTMP and maybe others.
gbak -b comes in at noon and starts a transaction. Sometimes that table is visible in the system tables, sometimes not, and sometimes these arbitrarily created bits and pieces are part there and part not. gbak sees what's there at the split-second moment its transaction starts.
So if you have apps running that are arbitrarily doing stuff that has committed unfinished DDL work that makes another transaction able to see stuff in the system tables that doesn't live there permanently, then queries by that transaction will retrieve output from the system tables that is unstable in unpredictable ways (I think you've shown us 4 possible ways, so far).
Dig.
All I can recommend is that you either *don't* schedule backups while anyone is potentially running this destabilising user code; or you fix it. You can replace it using GTTs (whose data is never seen by gbak) or, if the temporary sets need to be visible to other transactions/users for a while, by a persistent table into which the application writes its working sets with a set-specific identifier.
./hb
>I'm now loging all my db backup results with the -Y switch from my scheduler. I just ran it on all my databases. One is a DOCUMENT SERVER DATABASE all it has is three tables. I ran the scheduled backup procedure on it and got this result.Do you have the sources to the user apps? Already from your various posts you've show several clues to help you find the offending code, viz.
>
>gbak: ERROR:invalid request BLR at offset 13
>gbak: ERROR: table id 171 is not defined
>gbak: ERROR:gds_$compile_request failed
>gbak:Exiting before completion due to errors
>
>I then ran a backup manually and it worked just fine no errors doing the backup. The manual backup was doing using IBConsole. The scheduled one was done using a windows service that shells out to windows to run the commands I sent earlier.
>
>What is going on??
1. Something is creating a table or called UTMP that contains at least one computed field and one index (which might be a PK or FK index).
2. Something (that table, or another arbitrarily created one) has a computed field referring to a table whose RDB$RELATION_ID IS 171.
3. Arbitrarily, instances of the app are creating, altering and dropping UTMP and maybe others.
gbak -b comes in at noon and starts a transaction. Sometimes that table is visible in the system tables, sometimes not, and sometimes these arbitrarily created bits and pieces are part there and part not. gbak sees what's there at the split-second moment its transaction starts.
So if you have apps running that are arbitrarily doing stuff that has committed unfinished DDL work that makes another transaction able to see stuff in the system tables that doesn't live there permanently, then queries by that transaction will retrieve output from the system tables that is unstable in unpredictable ways (I think you've shown us 4 possible ways, so far).
Dig.
All I can recommend is that you either *don't* schedule backups while anyone is potentially running this destabilising user code; or you fix it. You can replace it using GTTs (whose data is never seen by gbak) or, if the temporary sets need to be visible to other transactions/users for a while, by a persistent table into which the application writes its working sets with a set-specific identifier.
./hb