Hi Ann,

I work with Robert. We assumed this worked after running a quick test;
1. Create test.fdb, create table and insert 2 records
2. Lock database
#./nbackup -U BASX -P **** -L ../data/test.fdb
3 Copy database to temp location
#cp ../data/test.fdb ../data/temp/test.fdb
4. inserted a few more records into the original database which created a merge file
5. Set state of backup database to normal with nbackup
#./nbackup -U BASX -P **** -F ../data/temp/test.fdb
6. Backup and restore
#./gbak -b -t -v -user BASX -pas **** "../data/temp/test.fdb" "../data/temp/test.gbk"
#./gbak -c -p 16384 -v -user BASX -pas **** ../data/temp/test.gbk ../data/temp/testnew.gdb
7. Then Shutdown service and swap the databases
#/etc/intit.d/firebird stop
#mv ../data/temp/testnew.gdb ../data/test.fdb
#/etc/intit.d/firebird start
8. Then merge changes back in with nbackup
#./nbackup -U BASX -P **** -N ../data/test.fdb
After this we found the merge file was deleted and we had all 6 records in the new database.

We were yet to run some more thorough tests but if nbackup is not intended for this purpose I guess we won't bother now.

The reason for this requirement is that our customers have requested a change to our service agreement and wish to switch to 24/7 availability.
This is fine for most databases with the exception of several 700GB+ systems. These databases process over 200,000 transactions a day and we have found that from time to time we get a performance decrease which we cannot fix with a sweep. This performance drop means our daily ETL process that usually imports records at 400-600 recs/sec drops to less than 100.
Our current solution is to bring the system off-line on weekends and backup/restore which takes 30-40+hours to complete and fixes the performance problem every time.

Do you know of any methods caching changes for the purpose of an online (or few minutes outage max) backup restore?

Or perhaps any ideas about how we find and fix the root cause of our performance decrease?

Thanks,
David

--- In firebird-support@yahoogroups.com, Ann Harrison <aharrison@...> wrote:
>
> Robert,
>
> >
> > So to reduce the transaction id's and keep the database live.
> > i need to use a combination of gbak and nbackup.
>
> Unfortunately, no. They don't combine at all well. Gbak
> creates a totally new file with different page contents Nbak
> requires that pages be stable. They work together like the
> ... well, ... leaving aside the middle east, Afganistan, and
> the euro nations, like oil and water. So no, if your goal
> is to lower the starting transaction ID, you need to take
> the database off-line from the time you start gbak, or find
> your own mechanism for caching changes.
>
>
> Good luck,
>
> Ann
>