From: Volker S. <vo...@vo...> - 2005-10-25 09:40:21
|
Hello all, this might be more a mysql issue than a bacula issue but I'l ask this list anyway: I'm running bacula 1.36.2-2sarge1 on Debian Sarge. I'm using mysql 4.0.24-10sarge1. I'm backing up about 20 machines and the database is grown quite large since I'm covering about half a year of backup history. The database is now 3.0G in size where the File Table is: -rw-rw---- 1 mysql mysql 2.3G Oct 25 11:32 File.MYD -rw-rw---- 1 mysql mysql 503M Oct 25 11:34 File.MYI -rw-rw---- 1 mysql mysql 8.6K Oct 21 20:04 File.frm The problem is easy to desribe: it takes about 5 to 10 hours (!) to run a prune or purge command. Since auto-prune is on, sometimes the bconsole locks up for a day since bacula runs a SQL DELETE on mysql. Like so: mysql> show processlist; +----+--------+-----------+--------+---------+------+----------+-----------= ------------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+--------+-----------+--------+---------+------+----------+-----------= ------------------------+ | 64 | bacula | localhost | bacula | Query | 31 | updating | DELETE FROM File WHERE JobId=3D3545 | | 65 | root | localhost | NULL | Query | 0 | NULL | show processlist | +----+--------+-----------+--------+---------+------+----------+-----------= ------------------------+ 2 rows in set (0.00 sec) Is this normal? Is my database missing an index or so?? Regards Volker --=20 Volker Sauer * Alexanderstrasse 39/217 * 64283 Darmstadt Telefon: 06151-154260 * Mobil: 0179-6901475 * ICQ#98164307 mailto:vo...@vo... * http://www.volker-sauer.de PGPKey-Fingerprint: DB2611C7B12E0B2739992E4F7E354E4D5DD5D0E0 |
From: Arno L. <al...@it...> - 2005-10-25 11:07:05
|
Hello, On 25.10.2005 11:39, Volker Sauer wrote: > Hello all, > > this might be more a mysql issue than a bacula issue but I'l ask this > list anyway: > > I'm running bacula 1.36.2-2sarge1 on Debian Sarge. I'm using mysql > 4.0.24-10sarge1. I'm backing up about 20 machines and the database is > grown quite large since I'm covering about half a year of backup > history. The database is now 3.0G in size where the File Table is: > > -rw-rw---- 1 mysql mysql 2.3G Oct 25 11:32 File.MYD > -rw-rw---- 1 mysql mysql 503M Oct 25 11:34 File.MYI > -rw-rw---- 1 mysql mysql 8.6K Oct 21 20:04 File.frm > > The problem is easy to desribe: it takes about 5 to 10 hours (!) to run > a prune or purge command. Since auto-prune is on, sometimes the bconsole > locks up for a day since bacula runs a SQL DELETE on mysql. Like so: Hmm. You didn't tell us what server you have behind your cataog database, and if that machine is usually loaded or not. Anyway, for reference: I've got an Athlon 500 MHz with 512 MB RAM working as my all-purpose server. That machines load is usually less than one, this weeks average was 0.6, for example. The Bacula catalog File table is a little smaller than yours: 1.3 GB data, >13500000 rows, and about 800 MB indexes. Pruning / recycling is also automatic here, but usually takes less than 15 minutes. I haven't any reports with pruning in them to give more exact times at the moment. Anyway, the DIR never was busier longer than I expected. > mysql> show processlist; > +----+--------+-----------+--------+---------+------+----------+-----------------------------------+ > | Id | User | Host | db | Command | Time | State | Info > | > +----+--------+-----------+--------+---------+------+----------+-----------------------------------+ > | 64 | bacula | localhost | bacula | Query | 31 | updating | DELETE > FROM File WHERE JobId=3545 | > | 65 | root | localhost | NULL | Query | 0 | NULL | show > processlist | > +----+--------+-----------+--------+---------+------+----------+-----------------------------------+ > 2 rows in set (0.00 sec) Well, 31 seconds is not exactly a long time. If it's busy for a really long time, you could analyze the query mysqladmin reports. That should give yo a clue if you understand the output of the explain SQL command, which I don't do very good :-) Perhaps an "analyze table File" also helps, if the indexes distribution MySQL knows about is not representing the actual table data. (Note that this command can take really long, and the table in question is locked read-only.) Apart from that, make sure that the server isn't overloaded and all the other stuff you probably know about already. > > Is this normal? Is my database missing an index or so?? Well, a "show index from File" gives me 7 result rows, representing 5 indexes. Arno > Regards > Volker -- IT-Service Lehmann al...@it... Arno Lehmann http://www.its-lehmann.de |
From: Volker S. <vo...@vo...> - 2005-10-25 12:03:03
|
On Di, 25 Okt 2005, Arno Lehmann <al...@it...> wrote: > Hmm. You didn't tell us what server you have behind your cataog=20 > database, and if that machine is usually loaded or not. Sorry, I was a little in a hurry when I wrote the mail! It's a dual 1.3GHz Pentium 3 with 1.5G of RAM and 2x120GB Disks. It run's some other little things, too. The load during the day is about 1, in the night it's less. I don't think that harware is the problem, because one week ago, bacula used to run on a 2x2GHz Athlon with 2GB RAM (dedicated to bacula) and the problem was the same. >=20 > Anyway, for reference: I've got an Athlon 500 MHz with 512 MB RAM=20 > working as my all-purpose server. That machines load is usually less=20 > than one, this weeks average was 0.6, for example. > The Bacula catalog File table is a little smaller than yours: 1.3 GB=20 > data, >13500000 rows, and about 800 MB indexes. > Pruning / recycling is also automatic here, but usually takes less than= =20 > 15 minutes. I haven't any reports with pruning in them to give more=20 > exact times at the moment. Anyway, the DIR never was busier longer than= =20 > I expected. That's great. That's what I expect! [.....] > Well, a "show index from File" gives me 7 result rows, representing 5=20 > indexes. Mine show this: mysql> show index from File; | File | 0 | PRIMARY | 1 | FileId | A | 22336637 | NULL | NULL | | BTREE | | | File | 1 | FilenameId | 1 | FilenameId | A | 7445545 | NULL | NULL | | BTREE | | | File | 1 | FilenameId | 2 | PathId | A | 22336637 | NULL | NULL | | BTREE | | It's only three indexes!! Probably that's the reason! There's indexes missing! I'll look in the bacula source an create all the missing indexes! I expect this to fix the problem! Thanks for your help! Regards Volker --=20 Volker Sauer * Alexanderstrasse 39/217 * 64283 Darmstadt Telefon: 06151-154260 * Mobil: 0179-6901475 * ICQ#98164307 mailto:vo...@vo... * http://www.volker-sauer.de PGPKey-Fingerprint: DB2611C7B12E0B2739992E4F7E354E4D5DD5D0E0 |
From: Florian S. <flo...@do...> - 2005-10-25 12:42:33
|
> > It's only three indexes!! Probably that's the reason! There's indexes > missing! I'll look in the bacula source an create all the missing > indexes! I expect this to fix the problem! > yes :-) for comparison: i'm using postgresql now ... total database size is 1.3 GB, about 500k files backed up every day, and index age of max a week. database cleanup usually takes 5-10 minutes, CPU less that 1, seems to be only limited by HD speed ... Florian |
From: Russell H. <rus...@wr...> - 2005-10-26 10:23:27
|
Florian Schnabel wrote: > i'm using postgresql now ... > > database cleanup usually takes 5-10 minutes, CPU less that 1, seems to > be only limited by HD speed ... Check to see if Postgres is issuing an fsync() after every operation or not, and then decide if you need it to. If you can disable that, things should get a *LOT* faster. I posted a link to some Postgresql performance tuning documents a while back - they're linked to from the postgres website too. -- Russell Howe rus...@wr... |
From: Peter de J. <pe...@pe...> - 2005-10-26 11:22:14
|
Hi all, Is it possible to do a restore while a full backup is running? My guess is that a restore should have a higher priority than a backup, Bacula resumes the backup right after the restore. Is this possible / is it implemented? Peter Scheduled Jobs: Level Type Pri Scheduled Name Volume ============================================================================ ======= Incremental Backup 10 27-Oct-05 01:05 Backup_pdjserv Tape_0010 Full Backup 11 27-Oct-05 01:10 BackupCatalog Tape_0010 ==== Running Jobs: JobId Level Name Status ====================================================================== 8 RestoreFiles.2005-10-26_12.09.21 has been canceled 7 Full BackupCatalog.2005-10-26_01.10.00 has been canceled 6 Increme Backup_pdjserv.2005-10-26_01.05.00 is waiting execution 5 RestoreFiles.2005-10-25_21.19.06 has been canceled 4 RestoreFiles.2005-10-25_21.13.42 is waiting execution 3 Full BackupCatalog.2005-10-25_01.10.00 is waiting for higher priority jobs to finish 2 Full Backup_pdjserv.2005-10-25_01.05.00 is running |
From: Arno L. <al...@it...> - 2005-10-26 11:37:32
|
Hello, On 26.10.2005 13:19, Peter de Jong wrote: > Hi all, > > Is it possible to do a restore while a full backup is running? > My guess is that a restore should have a higher priority than a backup, > Bacula resumes the backup right after the restore. > > Is this possible / is it implemented? Well, first that depends on the number of available storage devices you have, and the number of concurrent jobs allowed. Bacula can not hold a job, do something else, and later resume the job held. Priorites are one way to organize the order of job execution. You can set a high priority in the restore jobs template, and it will execute as soon as there are no longer any jobs running with a lower priority. In any case, jobs that are already running have to be canceled or finish. Arno > Peter > > > Scheduled Jobs: > Level Type Pri Scheduled Name Volume > ============================================================================ > ======= > Incremental Backup 10 27-Oct-05 01:05 Backup_pdjserv Tape_0010 > Full Backup 11 27-Oct-05 01:10 BackupCatalog Tape_0010 > ==== > > Running Jobs: > JobId Level Name Status > ====================================================================== > 8 RestoreFiles.2005-10-26_12.09.21 has been canceled > 7 Full BackupCatalog.2005-10-26_01.10.00 has been canceled > 6 Increme Backup_pdjserv.2005-10-26_01.05.00 is waiting execution > 5 RestoreFiles.2005-10-25_21.19.06 has been canceled > 4 RestoreFiles.2005-10-25_21.13.42 is waiting execution > 3 Full BackupCatalog.2005-10-25_01.10.00 is waiting for higher > priority jobs to finish > 2 Full Backup_pdjserv.2005-10-25_01.05.00 is running > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. > Get Certified Today * Register for a JBoss Training Course > Free Certification Exam for All Training Attendees Through End of 2005 > Visit http://www.jboss.com/services/certification for more information > _______________________________________________ > Bacula-users mailing list > Bac...@li... > https://lists.sourceforge.net/lists/listinfo/bacula-users > -- IT-Service Lehmann al...@it... Arno Lehmann http://www.its-lehmann.de |
From: Peter de J. <pe...@pe...> - 2005-10-26 12:44:50
|
Arno, Thanks for your response. I hoped a kind of job suspension was possible based on the priority of a new job like a restore. Maybe for a future release. Peter -----Oorspronkelijk bericht----- Van: Arno Lehmann [mailto:al...@it...] Verzonden: woensdag 26 oktober 2005 13:37 Aan: Peter de Jong CC: bac...@li... Onderwerp: Re: [Bacula-users] Restore while a full backup is running? Hello, On 26.10.2005 13:19, Peter de Jong wrote: > Hi all, > > Is it possible to do a restore while a full backup is running? > My guess is that a restore should have a higher priority than a backup, > Bacula resumes the backup right after the restore. > > Is this possible / is it implemented? Well, first that depends on the number of available storage devices you have, and the number of concurrent jobs allowed. Bacula can not hold a job, do something else, and later resume the job held. Priorites are one way to organize the order of job execution. You can set a high priority in the restore jobs template, and it will execute as soon as there are no longer any jobs running with a lower priority. In any case, jobs that are already running have to be canceled or finish. Arno > Peter > > > Scheduled Jobs: > Level Type Pri Scheduled Name Volume > ============================================================================ > ======= > Incremental Backup 10 27-Oct-05 01:05 Backup_pdjserv Tape_0010 > Full Backup 11 27-Oct-05 01:10 BackupCatalog Tape_0010 > ==== > > Running Jobs: > JobId Level Name Status > ====================================================================== > 8 RestoreFiles.2005-10-26_12.09.21 has been canceled > 7 Full BackupCatalog.2005-10-26_01.10.00 has been canceled > 6 Increme Backup_pdjserv.2005-10-26_01.05.00 is waiting execution > 5 RestoreFiles.2005-10-25_21.19.06 has been canceled > 4 RestoreFiles.2005-10-25_21.13.42 is waiting execution > 3 Full BackupCatalog.2005-10-25_01.10.00 is waiting for higher > priority jobs to finish > 2 Full Backup_pdjserv.2005-10-25_01.05.00 is running > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. > Get Certified Today * Register for a JBoss Training Course > Free Certification Exam for All Training Attendees Through End of 2005 > Visit http://www.jboss.com/services/certification for more information > _______________________________________________ > Bacula-users mailing list > Bac...@li... > https://lists.sourceforge.net/lists/listinfo/bacula-users > -- IT-Service Lehmann al...@it... Arno Lehmann http://www.its-lehmann.de |
From: Kern S. <ke...@si...> - 2005-10-25 13:00:29
|
On Tuesday 25 October 2005 14:02, Volker Sauer wrote: > On Di, 25 Okt 2005, Arno Lehmann <al...@it...> wrote: > > Hmm. You didn't tell us what server you have behind your cataog > > database, and if that machine is usually loaded or not. > > Sorry, I was a little in a hurry when I wrote the mail! > It's a dual 1.3GHz Pentium 3 with 1.5G of RAM and 2x120GB Disks. It > run's some other little things, too. The load during the day is about 1, > in the night it's less. I don't think that harware is the problem, > because one week ago, bacula used to run on a 2x2GHz Athlon with 2GB RAM > (dedicated to bacula) and the problem was the same. > > > Anyway, for reference: I've got an Athlon 500 MHz with 512 MB RAM > > working as my all-purpose server. That machines load is usually less > > than one, this weeks average was 0.6, for example. > > The Bacula catalog File table is a little smaller than yours: 1.3 GB > > data, >13500000 rows, and about 800 MB indexes. > > Pruning / recycling is also automatic here, but usually takes less than > > 15 minutes. I haven't any reports with pruning in them to give more > > exact times at the moment. Anyway, the DIR never was busier longer than > > I expected. > > That's great. That's what I expect! > > [.....] > > > Well, a "show index from File" gives me 7 result rows, representing 5 > > indexes. > > Mine show this: > > mysql> show index from File; > > | File | 0 | PRIMARY | 1 | FileId | A > | 22336637 | NULL | NULL | | BTREE | | > | File | 1 | FilenameId | 1 | FilenameId | A > | 7445545 | NULL | NULL | | BTREE | | > | File | 1 | FilenameId | 2 | PathId | A > | 22336637 | NULL | NULL | | BTREE | | > > It's only three indexes!! Probably that's the reason! There's indexes > missing! I'll look in the bacula source an create all the missing > indexes! I expect this to fix the problem! Well, something is wrong here, you should have an index on JobId as follows: +-------+------------+------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+ | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | +-------+------------+------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+ | File | 0 | PRIMARY | 1 | FileId | A | 1309549 | NULL | NULL | | BTREE | | | File | 1 | FilenameId | 1 | FilenameId | A | 218258 | NULL | NULL | | BTREE | | | File | 1 | FilenameId | 2 | PathId | A | 654774 | NULL | NULL | | BTREE | | | File | 1 | JobId | 1 | JobId | A | 119 | NULL | NULL | | BTREE | | +-------+------------+------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+ 4 rows in set (0.00 sec) > > Thanks for your help! > Regards > Volker -- Best regards, Kern ("> /\ V_V |
From: Volker S. <vo...@vo...> - 2005-10-25 13:08:49
|
On Di, 25 Okt 2005, Kern Sibbald <ke...@si...> wrote: > > > > Mine show this: > > > > mysql> show index from File; > > > > | File | 0 | PRIMARY | 1 | FileId | A > > | 22336637 | NULL | NULL | | BTREE | | > > | File | 1 | FilenameId | 1 | FilenameId | A > > | 7445545 | NULL | NULL | | BTREE | | > > | File | 1 | FilenameId | 2 | PathId | A > > | 22336637 | NULL | NULL | | BTREE | | > > > > It's only three indexes!! Probably that's the reason! There's indexes > > missing! I'll look in the bacula source an create all the missing > > indexes! I expect this to fix the problem! >=20 > Well, something is wrong here, you should have an index on JobId as follo= ws: >=20 > | File | 0 | PRIMARY | 1 | FileId | A = | 1309549 | NULL | NULL | | BTREE | | > | File | 1 | FilenameId | 1 | FilenameId | A = | 218258 | NULL | NULL | | BTREE | | > | File | 1 | FilenameId | 2 | PathId | A = | 654774 | NULL | NULL | | BTREE | | > | File | 1 | JobId | 1 | JobId | A = | 119 | NULL | NULL | | BTREE | | Yes, and that's the solution! The missing index on JobId make the SQL with "... where JobID=3D...." painfully slow! I checked the source and the debian package and this index is included by default. I have no idea why it's missing on my database. I'm creating it right now (takes some time)! Reagrds Volker --=20 Volker Sauer * Alexanderstrasse 39/217 * 64283 Darmstadt Telefon: 06151-154260 * Mobil: 0179-6901475 * ICQ#98164307 mailto:vo...@vo... * http://www.volker-sauer.de PGPKey-Fingerprint: DB2611C7B12E0B2739992E4F7E354E4D5DD5D0E0 |
From: Sebastian S. <st...@tu...> - 2005-10-25 13:38:38
|
On Tuesday 25 October 2005 15:08, Volker Sauer wrote: > > Well, something is wrong here, you should have an index on JobId as follows: > Yes, and that's the solution! The missing index on JobId make the SQL > with "... where JobID=...." painfully slow! > I checked the source and the debian package and this index is included > by default. I have no idea why it's missing on my database. I'm creating > it right now (takes some time)! Hi Volker, We're suffering from exactly the same problem. Could you describe how to add the missing index? Can it be done while the server is running? -Sebastian -- Sebastian Stark -- http://www.kyb.tuebingen.mpg.de/~stark Max Planck Institute for Biological Cybernetics |
From: Sebastian S. <st...@tu...> - 2005-10-26 09:21:39
|
On Tuesday 25 October 2005 15:38, Sebastian Stark wrote: > On Tuesday 25 October 2005 15:08, Volker Sauer wrote: > > > Well, something is wrong here, you should have an index on JobId as > > follows: > > Yes, and that's the solution! The missing index on JobId make the SQL > > with "... where JobID=...." painfully slow! > > I checked the source and the debian package and this index is included > > by default. I have no idea why it's missing on my database. I'm creating > > it right now (takes some time)! > > Hi Volker, > > We're suffering from exactly the same problem. Could you describe how to > add the missing index? Can it be done while the server is running? Okay, I figured that out: CREATE INDEX JobId ON File (JobId);. Now some figures :) Building the directory tree for a client with ~1.5 millions of files used to take hours, if not days (!) for our installation. After adding an index on the JobId to the File table it takes a couple of minutes! That's what I call speeding up things. -Sebastian -- Sebastian Stark -- http://www.kyb.tuebingen.mpg.de/~stark Max Planck Institute for Biological Cybernetics |
From: Christoph H. <em...@ch...> - 2005-10-25 19:53:57
|
On Tuesday 25 October 2005 15:08, Volker Sauer wrote: > Yes, and that's the solution! The missing index on JobId make the SQL > with "... where JobID=...." painfully slow! > I checked the source and the debian package and this index is included > by default. I have no idea why it's missing on my database. I'm creating > it right now (takes some time)! I'll try that, too. I was pretty annoyed by the low speed, too. Restoring files from a full backup and two incremental backups takes 10 minutes to show me the list of files (800,000 files in backup). But where in the Debian package (I assume you mean Sarge) did you see that an index over "JobId" is being created? I just found: /usr/share/bacula-director/make_mysql_tables And it just reads: # Possibly add one or more of the following indexes # to the above File table if your Verifies are # too slow. # # INDEX (JobId), # INDEX (PathId), # INDEX (FilenameId), # INDEX (JobId, PathId, FilenameId) So that's just a suggestion. If it were really a bug in the Debian package I'd like to report it. Admittedly at the time I installed Bacula there was still the annoying bug that broke the installation when using the MySQL backend (http://bugs.debian.org/312329). So I may have used a different installation routine than you. Christoph -- ~ ~ ".signature" [Modified] 1 line --100%-- 1,48 All |
From: Paul H. <hei...@ma...> - 2005-10-26 15:55:48
|
On Wed, 26 Oct 2005, Russell Howe wrote: > Check to see if Postgres is issuing an fsync() after every operation > or not, and then decide if you need it to. > > If you can disable that, things should get a *LOT* faster. I posted > a link to some Postgresql performance tuning documents a while back > - they're linked to from the postgres website too. At the risk of being somewhat off-topic, I'll add that the same is true of SQLite. In SQLite 2.8, setting the default_synchronous flag to OFF will speed things up markedly: echo 'PRAGMA default_synchronous=0;' | sqlite bacula.db The danger is that a system crash can easily result in a wholly corrupted database. In fact, the SQLite developers have removed this functionality from version 3, calling it "dangerous." Make sure you read the documentation to understand the dangers: http://www.sqlite.org/pragma.html The upside is that attribute spooling that used to take a couple days is now done in a few hours. My weekly full backups used to take from Friday night until Monday night; now they start Saturday evening and are finished about the time I get my Sunday-morning coffee. -- Paul Heinlein <> hei...@ma... <> www.madboa.com |
From: Russell H. <rus...@wr...> - 2005-10-26 16:13:05
|
Paul Heinlein wrote: > At the risk of being somewhat off-topic, I'll add that the same is true > of SQLite. In SQLite 2.8, setting the default_synchronous flag to OFF > will speed things up markedly: > > echo 'PRAGMA default_synchronous=0;' | sqlite bacula.db I posted about this previously: http://article.gmane.org/gmane.comp.bacula.user/16853/match=pragma Looks like they just removed the option to default all databases to non-synchronous operation in SQLite 3.0, requiring you to manually set your databases to be asynchronous. A good decision, I would say. I think the 'default_synchronous' setting will only apply to databases when they're created (or, to put it another way, changing it will not affect any existing databases). Since you're taking backups of the database, and you can restore the catalog by using bscan, I don't see the need for synchronous operation, unless you absolutely cannot have your database server down for the time it would take to restore the catalog in the event of a power failure or somesuch. I'll be turning it off tonight, to see what difference it makes to performance... -- Russell Howe rus...@wr... |
From: Kern S. <ke...@si...> - 2005-10-26 16:18:29
|
On Wednesday 26 October 2005 18:12, Russell Howe wrote: > Paul Heinlein wrote: > > At the risk of being somewhat off-topic, I'll add that the same is true > > of SQLite. In SQLite 2.8, setting the default_synchronous flag to OFF > > will speed things up markedly: > > > > echo 'PRAGMA default_synchronous=0;' | sqlite bacula.db > > I posted about this previously: > > http://article.gmane.org/gmane.comp.bacula.user/16853/match=pragma > > Looks like they just removed the option to default all databases to > non-synchronous operation in SQLite 3.0, requiring you to manually set > your databases to be asynchronous. A good decision, I would say. > > I think the 'default_synchronous' setting will only apply to databases > when they're created (or, to put it another way, changing it will not > affect any existing databases). > > Since you're taking backups of the database, and you can restore the > catalog by using bscan, I don't see the need for synchronous operation, > unless you absolutely cannot have your database server down for the time > it would take to restore the catalog in the event of a power failure or > somesuch. > > I'll be turning it off tonight, to see what difference it makes to > performance... The default for Bacula 1.37 SQLite is: PRAGMA default_synchronous = OFF; which I implemented shortly after Russell's original post. Thanks Russell. -- Best regards, Kern ("> /\ V_V |
From: Alan B. <aj...@ms...> - 2005-10-27 11:09:37
|
On Wed, 26 Oct 2005, Paul Heinlein wrote: > The danger is that a system crash can easily result in a wholly corrupted > database. In fact, the SQLite developers have removed this functionality from > version 3, calling it "dangerous." Make sure you read the documentation to > understand the dangers: Rather than using a stack of individual inserts, it'd be a big (and safer) gain to use transactions or batch inserts. Both MySQL and Postgres can do this in current versions. I don't know if SQlite has the functionality > The upside is that attribute spooling that used to take a couple days is now > done in a few hours. My weekly full backups used to take from Friday night > until Monday night; now they start Saturday evening and are finished about > the time I get my Sunday-morning coffee. My Full backups take 3-8 days but that's more a function of tape run time on 20Tb of disk. :-) AB |