Marc Schiffbauer wrote: > * Bill Moran schrieb am 09.09.08 um 19:41 Uhr: >> In response to Dan Langille <[EMAIL PROTECTED]>: >> >>> Bill Moran wrote: >>> >>>> So, my question would be, is dbcheck's performance important enough to >>>> do that with? As a utility program that doesn't really get run that >>>> often, it's quite likely a misdirection of resources. Granted, don't >>>> turn down the patch ... if it helps MySQL without hurting anything else, >>>> go for it. >>> Point: If everything Bacula does is within a transaction, why is dbcheck >>> required? >> Correct me if I'm wrong, but I don't believe that the orphaned filename/ >> path issue is the result of crashes or other non-transactional issues. I >> know for a fact that our primary Bacula server has run for many months >> without failure and it has still accumulated many orphaned paths and >> filenames. >> >> My understanding of what happens is this: >> 1) Job runs and creates a filename entry for a filename not used before >> (let's say something really unique, such as would be created by >> mktemp) >> 2) Time goes by and that file is deleted, never to be seen again. >> Eventually, Bacula gets to a point where all the jobs that backed >> up that filename have been pruned, thus there are no longer any >> file entries referencing that row. >> 3) Now we have an orphaned filname row in that table. >> >> The same thing can happen with path. > > In a clean database design the database would care for this itself. > Why not let the database delete any rows that are not referenced > anymore? > >> The canonical way to solve this would be to keep a reference counter in >> the filename/path tables that keeps track of how many file entries >> reference that row. When it's hits 0, it can be deleted. But this >> creates other issues: >> 1) What is the overhead of maintaining the reference counter? >> 2) In the case of a crash, we _must_ fix all reference counters immediately, >> otherwise records could be deleted that still need to be used. >> >> Referential integrity doesn't even gain us much here, as that only >> guarantees that records can't be created that don't have proper >> references, it doesn't automatically clean up after deletes. > > AFAIK it does work if the database is properly created, not? > (with foreign keys)
What are you talking about? :) Please elaborate. -- Dan Langille BSDCan - The Technical BSD Conference : http://www.bsdcan.org/ PGCon - The PostgreSQL Conference: http://www.pgcon.org/ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
