-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In my case, what appears to happen is that dbcheck runs for awhile, but
sometime during the Path check, MySQL hangs. From that point on, MySQL
is always consuming 33% of CPU but does not seem capable of responding
to Bacula for any other reason. I haven't tried a straight MySQL
connection. I am running 4.1.22 -- I guess I'll have to see if MySQL's
debug information can be made to tell me anything, because it is quite
clear that dbcheck's cannot.
Andreas Helmcke wrote:
> running bacula 2.0.3 with mysql 4.1.13 on SuSE 10.0
>
> Hello,
>
> just a few days ago i had similar problems with dbcheck.
> I had to run it because bacula was complaining about duplicate filenames.
> It took just a few minutes to find about 800 duplicate filenames but 12
> hours to erase them.
>
> Checks for orphaned Path or Filename records did not complete within 6
> hours so i stopped them.
>
> On 19.04.2007 23:41, Ryan Novosielski wrote:
>> Arno Lehmann wrote:
>>
>>> On 4/19/2007 8:23 PM, Ryan Novosielski wrote:
>>>> Hello, this is the database check/correct program.
>>>> [...]
>>>> Checking for orphaned File entries. This may take some time!
>>>> Found 103804 orphaned File records.
>>>> Checking for orphaned Path entries. This may take some time!
>>>>
>>>> ...before this begins to take an inordinate amount of time? My total DB
>>>> size is only 110MB or so -- doesn't seem like this should be a big deal
>>>> to my machine.
>>>>
>>>> That run right there, incidentally, included -d999 and -v -- neither
>>>> seemed to make any difference right there, only in the beginning before
>>>> the prompt appeared.
>
> Thats right. If you want see a little more output you have to give more "v":
> dbcheck -vvv
>
> At least, you will see the sql-statements which are executed.
>
>>>> Appreciate any pointers you could give. I suppose I could add that last
>>>> index, but it just doesn't sound like one that matters given the problem
>>>> I'm having.
>>> There was recently a report that dbcheck loops infinitely when checking.
>>> To me, it sounded like the change to have checks done in batches, not
>>> for the whole database at once, doesn't quite work... if you set dbcheck
>>> to fix problems it encounters, does it finish? (Make a dump before...)
>
> I don't think that this is the same problem, because allowing dbcheck to
> modify the database made no difference.
>
>> I ran a catalog backup and just kicked this thing off, so we'll find
>> out. Now that you mention it, I read that one too. I didn't ever use it
>> at the time so I didn't put two and two together. Interestingly enough,
>> though, is that there's a -b switch that controls batch mode. I don't
>> use it -- I wonder if it works with it on? I'm not willing to try it,
>> since I don't really know what it does. :-P
>
> -b does the very same you did with the interactive version. It just runs
> all the tests.
>
>> I guess this might be time for a bug report -- between the two postings
>> and the relatively idiot-proof nature of dbcheck, doesn't seem like
>> user-error.
>
> After some search in the mailinglist i found the solution:
>
>
> On 12.02.2007 11:29, Yann Cezard wrote:
>> Hi,
>>
>> Personnaly I resolved this problem by creating indexes before dbchecking.
>> This solution was given on this list some month ago.
>> Without them, dbchecking was taking hours (or days ? I don't know,
>> I stopped the dbcheck before its end :-) ).
>> With them, it just takes minutes, even with very huge databases (40 GB) !
>>
>> Here are they :
>> $ mysql -u bacula database_name
>>
>> mysql> create index File_PathId_idx on File(PathId);
>>
>> mysql> create index File_FilenameId_idx on File(FilenameId);
>>
>> And then just run dbcheck (in batch mode here) :
>> /usr/sbin/dbcheck -f -b -C CatalogName -c /etc/bacula/bacula-dir.conf
>>
>> Than don't forget to remove the indexes, cause it will slow down
>> insertions when
>> backing up :
>> mysql> drop index File_FilenameId_idx on File;
>>
>> mysql> drop index File_PathId_idx on File;
>>
>> Personnaly, I then run an OPTIMIZE :
>> mysql> OPTIMIZE TABLE File, Path, Filename;
>>
>> Hope this will help you to clean your bases faster !
>>
>> Cheers,
>>
>
> I think, this should be included in the documentation to spare others
> the headache.
>
>
> Andreas
- --
---- _ _ _ _ ___ _ _ _
|Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Systems Programmer III
|$&| |__| | | |__/ | \| _| |[EMAIL PROTECTED] - 973/972.0922 (2-0922)
\__/ Univ. of Med. and Dent.|IST/AST - NJMS Medical Science Bldg - C630
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGKNEQmb+gadEcsb4RAnvoAJ45ehFX82f+xeK/HE/DjaGzGLFKcgCfQVAS
Weznhf77WsqxbH5fs09GTo8=
=ps2C
-----END PGP SIGNATURE-----
begin:vcard
fn:Ryan Novosielski
n:Novosielski;Ryan
org:UMDNJ;IST/AST
adr;dom:MSB C630;;185 South Orange Avenue;Newark;NJ;07103
email;internet:[EMAIL PROTECTED]
title:Systems Programmer III
tel;work:(973) 972-0922
tel;fax:(973) 972-7412
tel;pager:(866) 20-UMDNJ
x-mozilla-html:FALSE
version:2.1
end:vcard
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
