On 5/9/24 13:08, Marcin Haba wrote:
OK. I was thinking about step after, where files are selected and
restore is starting. For 263 files this slowness can not be too visible.
For restoring a larger set of files, it is.
For the building file list, there is used .bvfs_update command that
builds Bvfs cache in the following way:
.bvfs_update jobid=XXX,YYY,ZZZ
where XXX, YYY and ZZZ are jobids that are needed for list files for
restore. This building Bvfs cache can be done independently on BAT. One
from practice is to run it after a backup job in Runscript. This way the
Bvfs cache is already built before the restore process is started.
Hmmmmmmm. That sounds as though it has potential. Where does that end
up stored? The difficulty that seems to present itself in running that
.bvfs_update as a RunAfterJob is knowing what the jbods should be.
I'm starting to make sense of the actual tree-building query, and I can
certainly clean it up and make it a lot more *readable* and eliminate
some redundant JOINs, but so far I've not found a modification that
significantly increases its performance because basically almost all of
the time is in the inner loop.
I have noticed, or stumbled across, a lot of issues with column
definitions. One such is FileIndex, which is not consistently defined:
MySQL epsilon3> SELECT TABLE_NAME, COLUMN_TYPE, IS_NULLABLE,
COLUMN_DEFAULT FROM information_schema.columns WHERE TABLE_SCHEMA =
'bacula' AND column_name = 'FileIndex';
+----------------+------------------+-------------+----------------+
| TABLE_NAME | COLUMN_TYPE | IS_NULLABLE | COLUMN_DEFAULT |
+----------------+------------------+-------------+----------------+
| BaseFiles | int(11) | YES | 0 |
| File | int(11) | YES | 0 |
| FileEvents | int(11) | YES | NULL |
| FileMedia | int(10) unsigned | NO | NULL |
| MetaAttachment | int(11) | YES | NULL |
| MetaEmail | int(11) | YES | NULL |
| Object | int(11) | NO | 0 |
| RestoreObject | int(11) | YES | 0 |
+----------------+------------------+-------------+----------------+
8 rows in set (0.005 sec)
It is an INT UNSIGNED NOT NULL (with no DEFAULT specified) in FileMedia,
but it is a signed INT(11) in every other table where it exists. It is
inconsistently allowed to be NULL, has a DEFAULT specified in BaseFiles
but is allowed to be NULL there, is NOT NULL DEFAULT 0 in Object but
NULL DEFAULT 0 in RestoreObject, ...
Is this column *SUPPOSED* to be INT UNSIGNED NOT NULL DEFAULT 0 wherever
it exists?
I'm seeing a LOT of columns either defined with a DEFAULT but allowed to
be NULL (in which case the DEFAULT will not be used because NULL is
allowed), or NOT NULL but no DEFAULT (which is a SQL99 violation unless
the column is AUTO_INCREMENT). For my own peace of mind if nothing
else, I'm strongly inclined to go through and fix all of these
consistently to what it appears they should be.
--
Phil Stracchino
Fenian House Publishing
ph...@caerllewys.net
p...@co.ordinate.org
Landline: +1.603.293.8485
Mobile: +1.603.998.6958
_______________________________________________
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel
