Markus,

Thanks for the comments.

But along with improving the performance of the existing restore
process, I, quite honestly, want to see if the whole backup/restore
approach can be re-thought.

What I'm thinking of is something like a DB "image" so that a "snapshot"
can be taken and then restored without the "need" to rebuild the
indexes.

Disk space is now cheap so that storing the indexes in the backup should
not be an "expensive". This approach could significantly increase the
speed of a restore.

But the, hopefull, goal of the "image" backup and restore (which would
NOT replace GBAK for ODS changes or transportable backups) would be
stream the database pages to disk on a block/page by block/page basis
rather than the current row by row. Each page would be "cleaned" by the
engine to only contain data in the 'context' of the backup
transaction/snap shot.

This approach would require adding a completely new set of functions to
the engine.

It's an idea, not completely baked right now but hopefully something
worth further discussion / brainstorming.


Sean

> -----Original Message-----
> From: Markus Kemper [mailto:mkemper@...]
> Sent: Wednesday, June 21, 2000 11:44 AM
> To: IB-Architect@egroups.com
> Subject: Re: [IB-Architect] Faster DB Backups, WAS Super-transactions
> and Incremental Backup
>
>
>
> Sean,
>
> I am sure that others know more about the internals of
> GBAK than I do but, one of the things that I believe
> could greatly increase the performance of a restore
> would be the ability to create indexes in parallel.
>
> Today, index creation on a restore takes a long time
> if you have many and the database is large. Part of
> the reason why is that if you have multiple indexes
> on a table gbak does multiple full table scans ( one
> per index per table ) to create the index. If gbak
> restore could be taught to scan the table once and
> build all indexes for ( a table ) in parallel the time
> to restore would come down.
>
> Also, there are likely performance improvements possible
> in the remote or loopback protocol layer. As seen by
> Greg Deatz's post recently, his large database took
> ~6 hrs to restore on a big Sun machine running 6.0
> SuperServer and ~3 hrs to restore on a smaller Linux
> system running 6.0 Classic. Classic has 'true' local
> access where as SuperServer ( non-Windows ) goes though
> local loopback to simulate a local connection.
>
> My hope is that some day ( and I don't think we're all
> that far away from it ) an InterBase database will be
> self maintaining and stable enough to be able to for-go
> the restore process entirely. Of course a backup will
> _always_ be a necessary recovery strategy in a production
> environment.
>
> Markus
>
> --------------------------------------------------------------
> ----------
> SALESFORCE.COM MAKES SOFTWARE OBSOLETE
> Secure, online sales force automation with 5 users FREE for 1 year!
> http://click.egroups.com/1/2658/6/_/830676/_/961602784/
> --------------------------------------------------------------
> ----------
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com
>
>
>