"Tim Young [Elevate Software]" wrote:

Arthur,

<<
How big of a database are you backing up ?   Most databases back up pretty
quickly, and any transactions will simply wait.

The other alternative, which Roy mentioned, is to use replication to log
updates and then do a SAVE UPDATES as a form of incremental backup.  So,
full backup on weekends or sometime that there is the possibility of a few
minutes of "no writes", and incremental backups the rest of the time.
>>

The current database is not all that large, perhaps 250,000 records. The current load isn't much, only averaging 250 updates/second. The expanded version might be a couple of million records, maybe 1500-2000 updates/second. Maybe SAVE UPDATES would work, I don't know, but it seems best to just avoid the situation altogether. Personally I find delays of more than a second or two to be intolerable in real-time applications.

Anyway, it was just a suggestion. If it can't be done, it can't be done.

Arthur,

<< Anyway, it was just a suggestion. If it can't be done, it can't be done.
>>

Can't is a strong word.  It's certainly something that is on the radar
for EDB 3, which will have the ability to choose when it commits database
updates to disk due to the single-file/single-process architecture.
Therefore, it will be easy to accomplish then because it can just delay any
commits until after the raw backup of the consistent, on-disk database file
is complete.

Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" wrote:

>>
Therefore, it will be easy to accomplish then because it can just delay any
commits until after the raw backup of the consistent, on-disk database file
is complete.
>>

That doesn't sound any better. The application is still going to be made to wait until the backup is complete. The aim ought to be to allow the backup to proceed without making the application(s) wait. The backup needn't be up to the second to date, merely consistent.

Arthur


The only way I can see to accomplish what you're looking for is some form of journalling. Depending what your application is that will either be difficult or easy. Care to post a few more details about the system as a whole rather than just backup?

Roy Lambert

Arthur,

<< That doesn't sound any better. The application is still going to be made
to wait until the backup is complete. The aim ought to be to allow the
backup to proceed without making the application(s) wait. The backup needn't
be up to the second to date, merely consistent. >>

We're talking about two completely different types of "commit".  The
handling of the commit interval is a database engine level fail safety/disk
concern and does not affect how applications commit their transactions.  The
commit interval in the database engine is a mechanism whereby you can
control at what interval transactions are made permanent on disk and will,
by default, be a fairly short interval.  However, in some cases/applications
it may be desirable to increase the commit interval in order improve
performance.

If you have any other questions, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" wrote:

>>>  The
commit interval in the database engine is a mechanism whereby you can
control at what interval transactions are made permanent on disk and will,
by default, be a fairly short interval.
>>

Perhaps I have misunderstood, but the meaning of your statement seems to be that when the application is given control back from a commit the data has not actually been committed to the disk. What happens if the system crashes between the application commit and the server engine commit ? Presumably the server has mechanism to recover these pending commits.

Arthur,

<< Perhaps I have misunderstood, but the meaning of your statement seems to
be that when the application is given control back from a commit the data
has not actually been committed to the disk. What happens if the system
crashes between the application commit and the server engine commit ?
Presumably the server has mechanism to recover these pending commits. >>

Initially, no, it will not.  At some point there will probably be a
write-ahead log or something similar. The key in the initial design is
database consistency and fast restart, and you'll need to set the commit
interval based upon your tolerance for data loss.

Tim Young
Elevate Software
www.elevatesoft.com