Subject | Re: [firebird-support] Database files on a remote mapped drive development |
---|---|
Author | Ann W. Harrison |
Post date | 2009-09-03T21:46:44Z |
Clarke, Thomas (UK) wrote:
a gfix command that sets a flag on the first page of the database
(header page). Normally even read-only applications change the
content of the database in three ways:
1) Read-only transactions participate in garbage collection or
cause the garbage collect thread to run. That's likely to cause
serious corruption if done by two connections independently.
2) Even if the database is completely clean, read-only connections
get new connection ids. The next connection id is on the header
page and might cause a bit of havoc if two connections got the same
id.
3) Read-only transactions get unique transaction ids. Transaction
ids are stored on transaction inventory pages (TIPs). Sooner or later,
you run out of space on one TIP and need to allocate another. Having
two uncoordinated connections allocate new pages will certainly cause
corruption.
So, be sure the database is set to read only.
I'll let someone who is more familiar with the current code than I
tell you how to keep the server from objecting to the network mount.
And I'll let lots of other people suggest that you just install a
server on the machine that owns the disk and avoid all these problems.
Good luck,
Ann
>Be sure you set the database to be read-only, explicitly. There's
> I have been charged by my company to modify if necessary Firebird 2 so
> that we ma be able to access database files on the network.
> The safety issues listed wherever the issue is discussed (ie. the
> database gettting corrupted under such circumstances) would not seem to
> apply as there will be no writing to the database. It's purely read
> only.
a gfix command that sets a flag on the first page of the database
(header page). Normally even read-only applications change the
content of the database in three ways:
1) Read-only transactions participate in garbage collection or
cause the garbage collect thread to run. That's likely to cause
serious corruption if done by two connections independently.
2) Even if the database is completely clean, read-only connections
get new connection ids. The next connection id is on the header
page and might cause a bit of havoc if two connections got the same
id.
3) Read-only transactions get unique transaction ids. Transaction
ids are stored on transaction inventory pages (TIPs). Sooner or later,
you run out of space on one TIP and need to allocate another. Having
two uncoordinated connections allocate new pages will certainly cause
corruption.
So, be sure the database is set to read only.
I'll let someone who is more familiar with the current code than I
tell you how to keep the server from objecting to the network mount.
And I'll let lots of other people suggest that you just install a
server on the machine that owns the disk and avoid all these problems.
Good luck,
Ann