> > > 2. As an option be able to do brick level backup or at least brick
> > > level restore.
> >
> > I am lead to believe that Backup Exec can do a brick level (or at
least
> > mailbox level) restore from a full backup, so maybe there are API's
to
> > do that, or maybe just under Exchange 2007.
>
* Dan Langille schrieb am 09.09.08 um 22:15 Uhr:
> Marc Schiffbauer wrote:
> > * Bill Moran schrieb am 09.09.08 um 19:41 Uhr:
> >> 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.
In response to "Yuri Timofeev" <[EMAIL PROTECTED]>:
> 2008/9/9 Bill Moran <[EMAIL PROTECTED]>:
> > In response to Bob Hetzel <[EMAIL PROTECTED]>:
> >. Additionally, doing that
> > rewrite so that it results in improvements to all SQL platforms is
> > probably going to require that the code be bro
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
* 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 q
2008/9/9 Bill Moran <[EMAIL PROTECTED]>:
> In response to Bob Hetzel <[EMAIL PROTECTED]>:
>. Additionally, doing that
> rewrite so that it results in improvements to all SQL platforms is
> probably going to require that the code be broken into SQL-dependent
> and SQL-independent sections.
It may
2008/9/9 Bill Moran <[EMAIL PROTECTED]>:
> In response to Bob Hetzel <[EMAIL PROTECTED]>:
>
> After spending about 5 minutes looking at the code, I can tell you that
> (from an SQL standpoint) dbcheck is enormously inefficient, and will
> not get much better without a huge rewrite.
I would not say
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
> >
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 anyt
In response to Martin Simmons <[EMAIL PROTECTED]>:
> > On Tue, 9 Sep 2008 11:40:02 -0400, Bill Moran said:
> >
> > In response to Bob Hetzel <[EMAIL PROTECTED]>:
> >
> > > Sorry to jump in late here... but if both of
> > > a) the dbceck takes a long time w/o the index
> > > b) the index adds
Hello James,
First thanks for agreeing to work on the Bacula Exchange Plugin.
For the list, I gave James a brief spec of what is needed and he has responded
to that.
On Tuesday 09 September 2008 08:04:14 James Harper wrote:
> > Basically, think we need several options starting from simple and t
> On Tue, 9 Sep 2008 11:40:02 -0400, Bill Moran said:
>
> In response to Bob Hetzel <[EMAIL PROTECTED]>:
>
> > Sorry to jump in late here... but if both of
> > a) the dbceck takes a long time w/o the index
> > b) the index adds quickly, then the dbcheck runs quickly
> >
> > I would have to a
Yuri Timofeev wrote:
> 2008/9/9 Dan Langille <[EMAIL PROTECTED]>:
>>> Algorithm:
>>> - when you specify "9) Check for orphaned Path records" or "10) Check
>>> for orphaned Filename records" :
>>> - verified the existence of the "one-column" index on the column
>>> PathId (or FilenameId)
>>> - if th
In response to Bob Hetzel <[EMAIL PROTECTED]>:
> Sorry to jump in late here... but if both of
> a) the dbceck takes a long time w/o the index
> b) the index adds quickly, then the dbcheck runs quickly
>
> I would have to agree with Kern's earlier suggestion that perhaps
> somebody should look at
2008/9/9 Dan Langille <[EMAIL PROTECTED]>:
>>
>> Algorithm:
>> - when you specify "9) Check for orphaned Path records" or "10) Check
>> for orphaned Filename records" :
>> - verified the existence of the "one-column" index on the column
>> PathId (or FilenameId)
>> - if the index does not exist, th
Sorry to jump in late here... but if both of
a) the dbceck takes a long time w/o the index
b) the index adds quickly, then the dbcheck runs quickly
I would have to agree with Kern's earlier suggestion that perhaps
somebody should look at the SQL code in dbcheck to optimize it. This
also has the
Kern Sibbald wrote:
> Hello,
>
> Why didn't you also add the indexes for other databases such as PostgreSQL
> and
> SQLite3?
For PostgreSQL, he said it did not have the performance issues that
MySQL had. I suspect PostgreSQL can use some other index that MySQL
cannot. See his NOTE below.
>
Yuri Timofeev wrote:
> Hi
>
> I once again explored speed dbcheck for MySQL and received steady results.
>
> Servers configurations :
> production server : Fedora Core 6, 2.6.22.9-61.fc6,
> bacula-mysql-2.2.8-2, mysql-5.0.27
>about 7M records in File table.
>
> test server : Fedora Core 8, 2
Hello,
Why didn't you also add the indexes for other databases such as PostgreSQL and
SQLite3?
Please go to: www.bacula.org -> FSFE License
Print out two copies of the license, fill in the fields as described in the
notes, sign it, send the two copies by mail to the Zurich address, then
not
Hi
I once again explored speed dbcheck for MySQL and received steady results.
Servers configurations :
production server : Fedora Core 6, 2.6.22.9-61.fc6,
bacula-mysql-2.2.8-2, mysql-5.0.27
about 7M records in File table.
test server : Fedora Core 8, 2.6.25.10-47.fc8, bacula-mysql-2.2.8-2,
my
20 matches
Mail list logo
