>>> 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.
While the restore process is pretty much I/O bound, creating indices loves RAM, as I have seen in some tests I had made in the past. So restore might get a speed up when more RAM can be utilized. There is a -bu(ffers) option for the restore, but I think this really overrides the database page buffers than acting as a higher temporary page cache. Another option might be to restore to a RAM disk, if the database file fits onto it and then move the restored database to a persistent storage. >> - 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. True, but things are getting better if we can do more stuff in RAM which would go to disk otherwise, especially temporary data e.g. when creating indices. Regards, Thomas ------------------------------------------------------------------------------ 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
