Sean, > >> The problem is not downtime is how much downtime. Backup and restore is >> so much downtime. > > There are a couple of possible solutions which would reduce the downtime; > - a new backup/restore tool which would use multiple readers/writers to > minimize execution time,
Here we're talking about a logical backup that can be used to restart transaction numbers. Record numbers are based loosely on record storage location. Since a logical backup/restore changes storage location and thus record numbers and indexes link values to record numbers, indexes must be recreated. The problem with a multi-threaded logical backup is that all the threads contend for the same I/O bandwidth and possibly the same CPU time. Much of the restore time is spent sorting keys to recreate indexes and multiple threads would contend for the same temporary disk I/O. > - a "data port" utility which would allow for data to be ported from a live > database to a new database while live is active but would need a finalization > step where the live database is shutdown to apply the final data changes and > add FK constraints. It's not immediately obvious to me how that sort of backup/restore could reset transaction numbers. > There are, however, certain "realities" which cannot be overcome; disk > throughput/IO performance. > > ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
