It's not resolve problem, because any my application can reconnect to
database.
20.05.2014 23:45, '[email protected]'
[email protected] [firebird-support] пишет:
Hi,
Delete from mon$attachments excluding current connection
After that you are only logged user
Regards,
Karol Bieniaszewski
----- Reply message -----
Od: "Markov Dmitri [email protected] [firebird-support]"
<[email protected]>
Do: <[email protected]>
Temat: [firebird-support] Re: database became broken for any reasons
Data: wt., maj 20, 2014 20:22
I turn off automatic sweep - only manual sweep.
For today I try to change keepalive parameters - it's look like all
ok. All processes named fb_inet_server.exe closed, but it's work if
connection was lost. It's not work when the connection established and
not closed for any reasons(for example the application waiting for
some system process on client side and so don't close connection and
don't react on my commands from server side).
So how I can from server side close connection normally, so after that
I may shutdown database and it's not create orphan records or pages?
I use shutdown for absolute prohibition of connection to database
using user accounts for database update process(changing metadata or
changing only data).
20.05.2014 18:47, Ann Harrison [email protected]
[firebird-support] пишет:
On Mon, May 19, 2014 at 1:31 PM, [email protected]
<mailto:[email protected]> [firebird-support]
<[email protected]
<mailto:[email protected]>> wrote:
For preventing orphan pages or backversions I turn off autosweep.
So for the last month I don't see any orphan pages or orphan
backversions.
Probably you were shutting the database down hard while a sweep was
active.
I know that shutdown during sweep can broke database, so I turn
off autosweep and do only manual sweep.
I've got to take exception to your statement. Shutdown during sweep
doesn't "break" the database. It leaves some
space (record or page) inaccessible, but, assuming you're running
with forced writes turned on, the database is not
corrupt. All the data is accessible and correct.
My service of database looks like this:
1) try normally close all connections(all my applications get
commands for starting of autoclose procedure)
OK
2) kill all terminal instance of my applications
OK, though that will leave errors in the log - but you caused them,
so not a big deal.
3) shutdown database(my software use non root access, so it's
guarantee single user access)
OK.
4) killing all processes fb_inet_server.exe
Not OK. Once the connections are gone, the fb_inet_servers will
eventually stop, after they've written all their changes to disk. If
you kill them, there's a chance that, for example, an old record
version will have been removed and the page it was on will have been
written, but the older versions that are chained to that record will
not have been removed and their pages flushed to disk. Firebird uses
a technique called "careful write" to maintain on-disk consistency
without a separate log. Essentially that means that when new
"things" are created, the thing is created first, then pointer to it
follow. Conversely, when a "thing" is removed, all the pointers are
removed first, then the thing itself. When done correctly and
consistently, careful writes never leave broken pointers. However,
it can lead to lost space. For example, when a table needs a new
data page, Firebird looks for a free page - they're indicated on
pages called PageInformationPages or PIPs. When it finds a free page
on a PIP, Firebird marks the page as "in use", before it starts the
process of allocating that page to the table, If the operation is
interrupted, the PIP will say that the page is in use, but it's not
part of a table or any other part of the database - hence, orphaned.
Orphans are a normal and benign result of a hard database shutdown
with write pending.
Good luck,
Ann
