Hi, I talk about delete + shutdown
In your case the best is Delete + shutdown + once again delete Regards, Karol Bieniaszewski ----- Reply message ----- Od: "Markov Dmitri [email protected] [firebird-support]" <[email protected]> Do: <[email protected]> Temat: Odp: [firebird-support] Re: database became broken for any reasons Data: wt., maj 20, 2014 22:18 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] [firebird-support] <[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
