I like very much the way Ann explains, almost impossible to be more clear. Greetings.
Walter. On Tue, May 20, 2014 at 10:47 AM, Ann Harrison [email protected][firebird-support] <[email protected]> wrote: > > > 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 > > >
