Subject | Re: [firebird-support] Re: script for nbackup |
---|---|
Author | Kjell Rilbe |
Post date | 2011-06-02T08:50:03Z |
Den 2011-06-02 09:04 skrev davidwilder_13 såhär:
time to time, going from 2-3 seconds for a page refresh to 15-20
seconds. For us it helps to simply stop the application pool in MS IIS,
stop the FB service, start the service again, start the IIS app pool.
As another thought, if you really do need a gbak backup restore cycle to
remedy your slowdown, start a replicator or logger at the same time you
start gbak. Then after the restore is complete, replicate back.
I'm sure there will be details that mess things up, like how to handle
transactions that commit during the post-restore backwards replication
process - the new transactions should commit AFTER the replicated ones,
so... how to solve that?
Perhaps keep two copies of the DB with replication from master to slave.
When slowdown happens, stop the replicator, run a gbak backup/restore on
the slave, sync the databses (how?), then switch master/slave so the
newly restored DB is now the master.
I'm sure others can come up with more detailed and tested solutions...
Kjell
--
--------------------------------------
Kjell Rilbe
DataDIA AB
E-post: kjell@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64
> The reason for this requirement is that our customers have requested aNot sure it's relevant, but our online system seems to slow down from
> 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?
time to time, going from 2-3 seconds for a page refresh to 15-20
seconds. For us it helps to simply stop the application pool in MS IIS,
stop the FB service, start the service again, start the IIS app pool.
As another thought, if you really do need a gbak backup restore cycle to
remedy your slowdown, start a replicator or logger at the same time you
start gbak. Then after the restore is complete, replicate back.
I'm sure there will be details that mess things up, like how to handle
transactions that commit during the post-restore backwards replication
process - the new transactions should commit AFTER the replicated ones,
so... how to solve that?
Perhaps keep two copies of the DB with replication from master to slave.
When slowdown happens, stop the replicator, run a gbak backup/restore on
the slave, sync the databses (how?), then switch master/slave so the
newly restored DB is now the master.
I'm sure others can come up with more detailed and tested solutions...
Kjell
--
--------------------------------------
Kjell Rilbe
DataDIA AB
E-post: kjell@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64