Subject | Symlink safety? |
---|---|
Author | Jason Dodson |
Post date | 2005-10-03T14:09:16Z |
Would there be ill effects if I were to create several symlinks to the same
file, and super server connect to each of them x times? I would imagine it would
be ok if locking was done completely within the fdb file, but fail if it was
done in memory/in a file.
For all of those BEGGING to ask, aside from having several "main" databases, I
want to write a nightly script that will create symlinks like 'yesterday.fdb',
'amonthago.fdb', etc.
Jason
Stephen Boyd wrote:
file, and super server connect to each of them x times? I would imagine it would
be ok if locking was done completely within the fdb file, but fail if it was
done in memory/in a file.
For all of those BEGGING to ask, aside from having several "main" databases, I
want to write a nightly script that will create symlinks like 'yesterday.fdb',
'amonthago.fdb', etc.
Jason
Stephen Boyd wrote:
> Thanks Ann.
>
> I am pretty sure it is garbage collection now. Looks like my app had
> a stuck transaction.
>
> A further question though. I fixed the app but the transaction number
> still seems stuck this morning but gbak is running. I would suppose
> that gbak would need to run as some sort of concurrency transaction.
> Would that cause the OAT to be stuck while the backup is running. If
> so, doesn't that get you into a catch-22. You need to run the backup,
> which is slow right now because of garbage collection but it in turn
> is causing more garbage to be generated because it causes the OAT to
> be stuck for several hours?
>
>
> --- In firebird-support@yahoogroups.com, "Ann W. Harrison"
> <aharrison@i...> wrote:
>
>>Stephen,
>>
>> A frequent culprit in that sort of performance is the garbage
>>collect thread, and the clues can be found in a gstat -a -r. Look for
>>tables with large numbers of back versions and indexes with > 32,000
>>instances of a single value. That combination puts the garbage collect
>>thread into a state where it doesn't get enough time in any one quantum
>>to do anything valuable. The resolution is to drop those indexes and
>>replace them with more selective indexes - adding the primary key at
>
> the
>
>>end of the list of fields to be indexed for example.
>>
>>Regards,
>>
>>
>>Ann
>
>
>
>
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Visit http://firebird.sourceforge.net and click the Resources item
> on the main (top) menu. Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoenix.com
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>