On 04/13/2012 04:47 PM, Joe Nyland wrote:
> I seem to have settled on the suggestion that maybe I should't worry
> about these temporary tables too much. As I think Phil is trying to
> explain; if there were a way in which these temporary tables could be
> backed up and restored somehow, then the actual data they would bring
> to the database would be useless anyway - the job wouldn't suddenly
> start running again from where it left off. So for all intents and
> purposes, the information about files being backed up in the job
> running at the moment when the database is being backed up may as
> well not even be in the database. After all, the temporary batch
> tables would only be deleted later on the the binary logs when the
> file records are actually moved to the file table, so to me, it seems
> pointless to worry about the batch table references. (If I've
> misunderstood something here, please accept my apologies)
That's it exactly. Without the context of the then-running jobs and
then-open DB connections, the data is simply not useful any more.
--
Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355
ala...@caerllewys.net ala...@metrocast.net p...@co.ordinate.org
Renaissance Man, Unix ronin, Perl hacker, SQL wrangler, Free Stater
It's not the years, it's the mileage.
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
