| Subject | RE: [IBO] Does TIBODatabase hold .FDB files open? |
|---|---|
| Author | Helen Borrie |
| Post date | 2014-05-21T04:16:42Z |
At 02:36 p.m. 21/05/2014, 'IBO Support List' supportlist@... [IBObjects] wrote:
I do query the wisdom of using file copying as the means of backup, though. Clients detaching from databases is a client-side thing - you're saying "This client has finished with the database for now." A database file is opened by the server, not by clients. (How this actually works depends on whether the server is SS or CS/SC.) The server does its own jobs on databases, such as GC and sweeping. Don't confuse the two. they are not the same thing. GC can be going on even after all the clients have detached. If a database is configured for auto-sweeping, that could be going on after all detachments, too. In both cases, it's not a great idea to stop them unfinished. It will leave orphans. Orphans don't cause a corrupt database, though, just a messy one.
Many, if not most, of these file-copying routines lock the sectors of disk where the files are located, even overriding the lock applied by the Firebird server. You can actually corrupt a database by running these utilities while the Firebird server is busy doing its background stuff. All Firebird ops happen in transactions. Utilities have no knowledge of transactions: they just march in and bust up the joint.
You can use the service component TIBOBackup to run a gbak backup from your application. As gbak runs in its own transaction, your backup will be a clean snapshot of the database state as it is when gbak's transaction starts. It's up to you whether you get the clients out before running the backup....depends on how up-to-date you want your backups to be. Running gbak backups does more than just back up the database: it's an important part of garbage and index cleanup.
Actually, you can write the gbak -backup output (and your backup log, too, if you keep one) to an UNC-coded network location, too, if you wish. These are just files, too.
hth
Helen
>Hmmm... I'm not sure the UNC route is the way you would want to go.Well, this is just a file-copying procedure, not a database backup. The UNC network path is quite valid for that.
>I suggest you run this past the Firebird experts on the support list there.
>
>No worries about wasting my time. I'm happy to help when I am able.
>
I do query the wisdom of using file copying as the means of backup, though. Clients detaching from databases is a client-side thing - you're saying "This client has finished with the database for now." A database file is opened by the server, not by clients. (How this actually works depends on whether the server is SS or CS/SC.) The server does its own jobs on databases, such as GC and sweeping. Don't confuse the two. they are not the same thing. GC can be going on even after all the clients have detached. If a database is configured for auto-sweeping, that could be going on after all detachments, too. In both cases, it's not a great idea to stop them unfinished. It will leave orphans. Orphans don't cause a corrupt database, though, just a messy one.
Many, if not most, of these file-copying routines lock the sectors of disk where the files are located, even overriding the lock applied by the Firebird server. You can actually corrupt a database by running these utilities while the Firebird server is busy doing its background stuff. All Firebird ops happen in transactions. Utilities have no knowledge of transactions: they just march in and bust up the joint.
You can use the service component TIBOBackup to run a gbak backup from your application. As gbak runs in its own transaction, your backup will be a clean snapshot of the database state as it is when gbak's transaction starts. It's up to you whether you get the clients out before running the backup....depends on how up-to-date you want your backups to be. Running gbak backups does more than just back up the database: it's an important part of garbage and index cleanup.
Actually, you can write the gbak -backup output (and your backup log, too, if you keep one) to an UNC-coded network location, too, if you wish. These are just files, too.
hth
Helen