| Subject | Re: [firebird-support] Ghost dependencies |
|---|---|
| Author | Helen Borrie |
| Post date | 2008-11-27T22:00:26Z |
At 03:07 AM 28/11/2008, you wrote:
Running a backup from an exclusive clean connection would have been a prerequisite to a job like this... If backup and restore really *is* the only way, it suggests that you might have started the operation on a database that had dependent garbage.
If you are running your scripts from some friendly tool that puts the metadata of your database at your fingertips, then don't overlook the fact that your tool's queries over the system tables will poke a fresh lot of dependent pages into the cache each time you use it to connect to the database.
Another thing to bear in mind is that working in exclusive mode won't guarantee interference from other users if you have applications or users able to log in as SYSDBA or Owner. If that is your situation then rename the database before you start trying to do this restructuring.
Renaming the database is also a way to discover whether anyone else is actually logged in - if anything is connected to the database, you won't be able to rename it.
./heLen
>FB 2.0.1 on XP/Win2003.That should work, but are you sure it is the "only way"? The "ghost" dependencies exist because pages from affected tables are still in the page cache: the dropping of the dependencies will be deferred until the page cache has been cleared. As long as you are doing this job in exclusive mode (as you must) it should be sufficient to keep the database offline and log out, which will clear the page cache.
>
>Hi all, I'm getting a strange problem with dependencies that won't go
>away until a db has been backed-up and restored.
>
>When I run a bunch of scripts (run as part of an upgrade process) I
>need to drop a table. One script drops all its dependencies and then
>commits. The next just drops the table, but this invariably errors
>with between 2 and 5 objects reported as being dependent on the table.
>
>The only way to procede is to back-up, restore, and carry on from the
>table-dropping script. Then all is well.
Running a backup from an exclusive clean connection would have been a prerequisite to a job like this... If backup and restore really *is* the only way, it suggests that you might have started the operation on a database that had dependent garbage.
If you are running your scripts from some friendly tool that puts the metadata of your database at your fingertips, then don't overlook the fact that your tool's queries over the system tables will poke a fresh lot of dependent pages into the cache each time you use it to connect to the database.
>I'm could start deletingDestroying metadata in order to work around the built-in consistency protection is NOT a recommended way to restructure databases. The only operation you should *ever* do on system tables is SELECT.
>rows from RDB$Dependencies
Another thing to bear in mind is that working in exclusive mode won't guarantee interference from other users if you have applications or users able to log in as SYSDBA or Owner. If that is your situation then rename the database before you start trying to do this restructuring.
Renaming the database is also a way to discover whether anyone else is actually logged in - if anything is connected to the database, you won't be able to rename it.
./heLen