Re: parallel backup and restore w onbar
Ok Jacque, thanks very much. I understand better now.
I wasn't aware of the whole system parallel feature in 11. Another reason
to try and push 11 on my bosses.
----- Original Message -----
Subject: Re: parallel backup and restore w onbar
Date: Tue, February 19, 2008 13:47
From: jprenaut@yahoo.com
On Feb 19, 12:20 pm, "Floyd Wellershaus" <fl...@fwellers.com> wrote:
> > Thanks Gustavo,
> > The reason I want to do it is for speeding up the backups and restores.
> > So if I'm hearing you correctly , as long as I don't have referential
> > constraints, I should be good to go this way ?
> >
> > Thanks,
> > floyd
> >
> > ----- Original Message -----
> > Subject: Re: parallel backup and restore w onbar
> > Date: Tue, February 19, 2008 13:03
> > From: "Gustavo Castro" <gcast...@bellsouth.net>
> >
> > I think you mean :
> >
> > > "can I do parallel backup and restore on an instance that has ONLY
> > > databases WITHOUT transaction logging?"
> >
> > > As long as you backup the logical logs yes you can, but maybe you
> > shouldn't:
> >
> > > If your databases spawn more than 1 dbspace, and there are tables
> > > related among the dbspaces, then the data will be logically corrupted,
> > > take this example:
> >
> > > - Instance with a single non-logging database named "mydb", created in
> > > rootdbs.
> > > - "mydb" has 2 tables :
> > > + "parent"
> > > + "child"
> > > - You have a foreign key from child to parent.
> > > - Each table is a different dbspace
> >
> > > A parallel backup/restore will work, however the tables will
probably be
> > > out of syncs (You oculd get parents without children or children
without
> > > parent).
> >
> > > This is becasue a parallel backup is in reality a dbspace backup. YOu
> > > can only take snapshots of the dbspaces.
> >
> > > Without logs there is no way to "glue" this backups to see the "whole
> > > picture"
> >
> > > Gustavo
> >
> > > Floyd Wellershaus wrote:
> > > > hello,
> > > > In IDS10, using onbar, can I do parallel backup and restore on an
> > > > instance that has no database transaction logging ?
> > > > I think I should be able to, as long as I backup the logical logs and
> > > > logs will need to be restored during a parallel restore. Is that
> > correct ?
> >
> > > > ps. I realize I won't be getting schema changes that occurred since
> > > > the last archive, but that's ok for now.
> >
> > > > Thanks,
> > > > Floyd
> >
> > > > ------------------------------------------------------------------------
> >
> > > > _______________________________________________
> > > > Informix-list mailing list
> > > > Informix-l...@iiug.org
> > > >http://www.iiug.org/mailman/listinfo/informix-list
>
> I think I'd expand that to no fragmented tables, no detached indexes,
> no system catalogs in 1 dbspace while the tables reside in a different
> dbspace (so really 1 database and all it's tables contained in 1
> dbspace), oh yeah, and no blobspaces, and possibly other things I
> can't think of off the top of my head. The way parallel backups work
> is the dbspaces each perform their own checkpoint (like the one that
> is done at the start of a non-parallel) so the phsyical logging that
> is done and checked for when archiving pages that are getting modified
> is different for each dbspace as they are archived in parallel. So if
> you don't have logical logging and logs to make sure all these
> different start points can sync up, you are really asking for the
> possiblity of something to get out of what, like a row that got
> inserted into a table, but the modification to the index page didn't
> make it (in the case of detached index in a different dbspace). I've
> seen more then 1 issue when a customer used parallel backups on non-
> logged databases that caused them consistency problems after a
> restore.
>
> In 11 the feature for parallel whole system archives was added. I
> really would try to avoid trying it on systems with non-logged
> databases before then, in a very specific sort of configuration you
> might be able to get it to work for you, but there are probably a lot
> more ways to have it not work then work.
>
> Jacques
> _______________________________________________
> Informix-list mailing list
> Informix-list@iiug.org
> http://www.iiug.org/mailman/listinfo/informix-list
>
>