Hi,

>>I planned to investigate this at some point - but havent done so yet and

so

>>also am unaware of
>>exactly where it occurs - although it seems to be on first db access
>
>The first db access is the one that triggers off the SystemRestore because
>it's the one that opens the database file. The db file gets opened once
>and only once.
>
>> and gets longer as the database
>>grows - the hd light stays on continously - and it seems to fo for long
>>enough to have loaded all the
>>pages in the database.
>
>That because SystemRestore is a filesystem copy. So the bigger the file,
>the longer it takes.

If it is due to SystemRestore these would seem reasonable explanations.
Maybe .fdb files are also affected by SystemRestore - although what I've so
far read sugests that they are not - but this will be the first thing I'll
check when I get round too this problem.

>>Perhaps I am running a query which ends up needing to visit many pages in
>>the db and these end up getting cached by
>>OS
>
>Database pages aren't "cached by the OS" - they are cached in the DBCache
>by the server. The DBCache gets "emptied" when the server shuts down and
>releases its resources.

So it must open the file with 'FILE_FLAG_NO_BUFFERING' on win32 and an
equivilant on other platforms. I am aware the the database caches pages too.
I thought I remembered seeing some discussion the merits of opening the file
without OS caching but perhaps it was actually the reverse.

>>so removing the cost of loading these on susequent start up - I will need
>>to investigate this to really find out.
>
>You could save yourself a lot of effort by simply asking Ann Harrison about
>it on firebird-support or firebird-devel. You'll HAVE to believe Ann. She
>was the midwife at the birth of this DBMS.

sorry, I meant really to investigate(in my app) to the point where I could
rule out problems with it and would have some consise question(s) to ask and
be able to reliably reproduce the behaviour.

>And only one connection. The embedded server doesn't accommodate multiple
>connections.
>
>>So when the app closes all the connections to the DB
>
>there can only be one.
>
>>(which I guess
>>should occur on the server because the process owning the socket is

closed)

>>I guess it should cause the server to close the file - so in that respect

it

>>should be the same.
>
>It's not the same. The embedded server closes the ONLY connection. The
>normal server won't shut down unless there are no connections (which will
>eventually be the case if a forced shutdown is performed).
>
>>But when in client/server mode the server actually has a chance to close

the

>>file - whereas in embedded mode the server process just disappears - which
>>is what led to my previous hypothesis.
>
>Engage with Ann in a discussion of what the *server* does.

I'm refering to the FB1.5 embedded database which was supplied in a seperate
zip on win32 with RC1 and RC4. I thought this was based arround SS
archutecture and could accept multiple connections from within a single
process. All my usage of the embedded server would seem to confirm this.

>And at least explore the possibility that the disk-thrashing at startup has

nothing to

>do with the server and everything to do with the OS environment.

Of course. Until I do know what it is I am more then happy to explore any
reasonable possibility.

I do find it a bit baffeling - 1 - 2 mins on a modern machine(for 200 -
600MB DB) - there is room for a hell of a lot of somthing to be happening.

Thanks
Ryan

-----Original Message-----
From: Helen Borrie [mailto:helebor@...]
Sent: 16 July 2003 17:56
To: Firebird-Java@yahoogroups.com
Subject: RE: [Firebird-Java] Strange initial startup behavior


At 05:31 PM 16/07/2003 +0100, you wrote:

>Hi,
>
>I've used .fdb extension since I began using XP and I see this behaviour
>with .fdb extension.

That's not encouraging.

>I planned to investigate this at some point - but havent done so yet and so
>also am unaware of
>exactly where it occurs - although it seems to be on first db access

The first db access is the one that triggers off the SystemRestore because
it's the one that opens the database file. The db file gets opened once
and only once.

> and gets longer as the database
>grows - the hd light stays on continously - and it seems to fo for long
>enough to have loaded all the
>pages in the database.

That because SystemRestore is a filesystem copy. So the bigger the file,
the longer it takes.

>But this does not happen every time it starts - but I have not seen a
>corelation between this and restarting
>windows but I havent been looking.

:-)

>Perhaps I am running a query which ends up needing to visit many pages in
>the db and these end up getting cached by
>OS

Database pages aren't "cached by the OS" - they are cached in the DBCache
by the server. The DBCache gets "emptied" when the server shuts down and
releases its resources.

>so removing the cost of loading these on susequent start up - I will need
>to investigate this to really find out.

You could save yourself a lot of effort by simply asking Ann Harrison about
it on firebird-support or firebird-devel. You'll HAVE to believe Ann. She
was the midwife at the birth of this DBMS.

> >In normal client/server mode, it's the server that opens the file and

gets

> >the exclusive lock, so it will be the first user to log on who

experiences

> >the delay.
>
>The database is only accessed by the app and there is only one instance of
>the app.

And only one connection. The embedded server doesn't accommodate multiple
connections.

>So when the app closes all the connections to the DB

there can only be one.

>(which I guess
>should occur on the server because the process owning the socket is closed)
>I guess it should cause the server to close the file - so in that respect

it

>should be the same.

It's not the same. The embedded server closes the ONLY connection. The
normal server won't shut down unless there are no connections (which will
eventually be the case if a forced shutdown is performed).

>But when in client/server mode the server actually has a chance to close

the

>file - whereas in embedded mode the server process just disappears - which
>is what led to my previous hypothesis.

Engage with Ann in a discussion of what the *server* does. And at least
explore the possibility that the disk-thrashing at startup has nothing to
do with the server and everything to do with the OS environment.

>I cant be 100% sure that it only occurs with embedded server though.

Basicly

>I need to investigate this - I had just realised I had similar thing
>happening and that was what I though might be the cause.

Anyway, time for me to go to bed.

Helen




To unsubscribe from this group, send an email to:
Firebird-Java-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/