Subject | Re: nbackup / gbak interoperation |
---|---|
Author | dkeith2 |
Post date | 2009-12-15T14:52:23Z |
--- In firebird-support@yahoogroups.com, "Steffen Heil" <lists@...> wrote:
I apologize for my lack of terminology that is relevant to the product; I've worked with so many databases over the years that I sometimes get my terms confused.
It sounds like some of you use Firebird in OLTP systems. If anyone has any pointers to articles/case studies/blog posts etc. I would appreciate seeing them and I'm sure the community would benefit.
I read an article in the Interbase/Firebird magazine (hope I said that right!) but it didn't go into much detail.
I have seen that Holger Klemt has some sort of scripting mechanism using IBExpert and scripts that he uses for clustering - which I think would be a good way to handle OLTP. That way one database in the cluster could be taken offline if necessary - I know it isn't always necessary(!!!!) - and restored if there were ever a problem.
Any examples or even ideas relating to OLTP or Clustering or other high-availability approaches that someone has implemented would be helpful.
Thanks again for the good info and discussion.
David Keith
>Thanks for all of the replies, even if they weren't necessarily directed at me/my issue, the info was helpful.
> No
>
> Completely forget that.
>
> The delta file works at block level. There is no semantic information that
> is merged later, there are simply blocks that will overwrite blocks in the
> real database.
> If you modify the database in any way this "merge" will destroy the file.
> The operating system should however prevent you to change it, because it is
> still locked exclusively for write access.
>
>
> And back to the comments you already got: Simply don't try to reclaim that
> "unused" space in a working environment. The server will reuse it later.
> Afaik there are only two good reasons to get rid of that space: Either for
> backups (but gbak handles this itself, nbackup does not) or if the database
> is later only opened readonly, but if you switch the very basic type of
> access to the database, you can do a backup/restore: You don't change such
> aspects on the fly.
>
>
> Visit http://www.firebirdsql.org and click the Resources item
> on the main (top) menu. Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoenix.com
I apologize for my lack of terminology that is relevant to the product; I've worked with so many databases over the years that I sometimes get my terms confused.
It sounds like some of you use Firebird in OLTP systems. If anyone has any pointers to articles/case studies/blog posts etc. I would appreciate seeing them and I'm sure the community would benefit.
I read an article in the Interbase/Firebird magazine (hope I said that right!) but it didn't go into much detail.
I have seen that Holger Klemt has some sort of scripting mechanism using IBExpert and scripts that he uses for clustering - which I think would be a good way to handle OLTP. That way one database in the cluster could be taken offline if necessary - I know it isn't always necessary(!!!!) - and restored if there were ever a problem.
Any examples or even ideas relating to OLTP or Clustering or other high-availability approaches that someone has implemented would be helpful.
Thanks again for the good info and discussion.
David Keith