Ann, > > - 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.
Agreed. > 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. Agreed, but it is all about scale and the number of threads. On the backup side, although this depends on the size of the row, the *peak* speed of gbak is 40 MB/s, the average is much less (about 10MB/s). Most disk sub-systems that can support 4 times that much, some 12 times. So, if there were 2 or 3 reader threads, the backup could run much faster without any impact of overall performance. On the restore side, as with the backup, disk subsystems can support much higher level of activity than is currently generated. So, if the backup data were logically "blocked" to disk, separate threads could be writing data simultaneously from the separate blocks to the same table, or even across tables. As for rebuilding indexes, gbak currently restores them 1 at a time. The temporary disk IO is not that significant and most of the data should be in the OS cache. Why couldn't several indexes for the same table be built at the same time? > > - 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. Dimitry S was correct, I was thinking of a multi-threaded data pump utility which would pump the data to a new database. Sean ------------------------------------------------------------------------------ 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
