Hi!Well, I guess that depends mostly on your resources usage and availability. But for 200 MB I would not move a finger. :)
Anyway, check Frontbase docs for more info about vacuuming, I don't even know if they have that concept. If they do, check if it's possible to automate it. PostgreSQL supports autovacuum since 8.something, IIRC.
Yours Miguel Arroz On 2009/03/17, at 16:29, Jeff Schmitz wrote:
Thanks Miguel,Very informative. I'm using Frontbase. I cleaned out a lot of unneeded rows in several tables in hopes that it would speed by pre- fetching. Sounds like most of the extra info produced by this will remain on the disc. Is there a size of the database where you may want to "vacuum"? I'm setting at about 200 Meg saved for a uncompressed backup using the Frontbase "live" backup method.JeffOn Tuesday, March 17, 2009, at 08:04AM, "Miguel Arroz" <[email protected] > wrote:Hi! Jeff, this depends on the DB engine you are using. On Postgresql, you have two sets of files. The base files, which contains the "stable" data, and the write-ahead logs (WALs). Every time you do an operation, whatever that is (including delete), the operation is written to the WALs. Data in WALs is never overwritten, only appended. From time to time (namely, when a WAL file is full - usually 16 MB,and when no active transaction is using that file) the data on the WALfiles is copied back to the base files, and the WALs are discarded. Even so, this might not release unused space. To do that, you have to run VACUUM queries. Note that running VACUUM on a table (or the entire DB) is a very heavy process, specially for the disks, so itwill kill your DB performance while it's being done. Anyway, you don'treally need to, because PostgreSQL will be able to use the unused space in a smart way, and it automatically vacuums some tables from time to time. Note also that each DB has it's own procedure for making a correct backup (ie, a backup you are 100% sure it's consistent and will work if recovery is needed). Here's what you should do for PostgreSQL: http://www.postgresql.org/docs/8.1/interactive/backup.html . Note that, on most DBs (if not all), simply copying the DB files for another drive is NOT a safe way to backup, your backup will most probably be corrupt. You have to make the backups in accordance with the DB engine itself. Yours Miguel Arroz On 2009/03/17, at 09:02, Jeff Schmitz wrote:This may be a dumb question, but why after deleting a bunch of EOs is my database backup larger than before? Looking at the data in the database, the data corresponding to the EOs does seem to be gone now. Jeff _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/arroz%40guiamac.com This email sent to [email protected]........................... http://www.survs.com_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/arroz%40guiamac.com This email sent to [email protected]
........................... http://www.survs.com
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
