Subject | Re: cannot connect to a restored database |
---|---|
Author | flpratt |
Post date | 2004-01-06T21:15:34Z |
--- In firebird-support@yahoogroups.com, "Brian L. Juergensmeyer"
<brianj@c...> wrote:
This is interesting. I re-directed the gbak output to a file and
the last entry was:
gbak: restoring index SEQ_ECM_REPOSTS
There is no "Finished", "Success", or "Done" in the file to confirm
completion of the task. I ran the gbak -c command from a shell
script file because it was several lines long. I remember that
there were no messages at all when I ran the shell script, but that
the return code was 1. There are almost 22,000 lines in the file,
but none of them contain "ERR" or "FAIL". I did a quick scan of the
file and the output pattern is:
1. lines detailing file path names
2. a bunch of "restoring domain" lines
3. "restoring table table-name" and "restoring column column-name"
lines for each table
4. "committing metadata"
5. some "restoring index" lines
6. "restoring data for table table-name" followed by
some "restoring index" lines for each table
7. "restoring privelege for user.." lines
8. "creating indexes" line
9. some more "restoring index index-name lines" ending with the
line above
It is interesting that "restoring index" lines appear at different
places in the file. I would expect the indexes to be created right
after each file is loaded, but I am just learning firebird.
Should there be some sort of "finished" message in the file?
I w/b very happy to send the entire file to anyone who is
interested. At this point, I am losing confidence in the integrity
of the restored database. We have been back in production for
almost 3 hours now with no reported problems, but this gbak output
file has caused me to replace the cork in the champagne bottle.
Thanks,
Fred
<brianj@c...> wrote:
> Hello, Fred,restore? I
>
> Did you by chance happen to look at the log from the original
> can't swear that this is the case in the more recent Firebirdofferings, but
> Interbase will leave the database shutdown if an index cannot bereactivated
> or some other data problem exists with the database.check to see
>
> It might be worthwhile to do a restore to a temporary area and
> if there are any problems with reactivating unique indexes orthings of that
> nature.Brian,
>
> Brian
This is interesting. I re-directed the gbak output to a file and
the last entry was:
gbak: restoring index SEQ_ECM_REPOSTS
There is no "Finished", "Success", or "Done" in the file to confirm
completion of the task. I ran the gbak -c command from a shell
script file because it was several lines long. I remember that
there were no messages at all when I ran the shell script, but that
the return code was 1. There are almost 22,000 lines in the file,
but none of them contain "ERR" or "FAIL". I did a quick scan of the
file and the output pattern is:
1. lines detailing file path names
2. a bunch of "restoring domain" lines
3. "restoring table table-name" and "restoring column column-name"
lines for each table
4. "committing metadata"
5. some "restoring index" lines
6. "restoring data for table table-name" followed by
some "restoring index" lines for each table
7. "restoring privelege for user.." lines
8. "creating indexes" line
9. some more "restoring index index-name lines" ending with the
line above
It is interesting that "restoring index" lines appear at different
places in the file. I would expect the indexes to be created right
after each file is loaded, but I am just learning firebird.
Should there be some sort of "finished" message in the file?
I w/b very happy to send the entire file to anyone who is
interested. At this point, I am losing confidence in the integrity
of the restored database. We have been back in production for
almost 3 hours now with no reported problems, but this gbak output
file has caused me to replace the cork in the champagne bottle.
Thanks,
Fred