If the machines are identical distributions, libs, and layout you can copy
over the entire pgsql tree for your data rollover. You won't have any time
to test on your very loaded server before you know if something is wrong but
you might just want to keep a copy around so that two mv's will restore your
working server. Your only down time is what's needed to cp the directory.
There are some huge advantages to having a DB that actually uses
your file-system,
DEJ
> -----Original Message-----
> From: Bradford L. Barrett [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, August 10, 1999 1:13 PM
> To: Vadim Mikheev
> Cc: [EMAIL PROTECTED]
> Subject: Re: [ADMIN] Elapsed time in vacuum?
>
>
> > getrusage() is used. xxx - sec in system mode, yyy - in user.
> >
> > BTW, upgrade to 6.5.X - vacuum is now (much) faster in some cases.
>
> Ahhh, ok, makes sense :)
>
> And we are looking into a way to upgrade from 6.4.2. Problem is that
> it is a production system that is very busy 24x7, as we have customers
> all over the globe, and it can't afford to be down for any appreciable
> length of time :(
>
> We currently can't even do the table updates on the live system because
> of the length of time it takes.. usually somewhere between 4-6 hours
> per update cycle. We have found that during the update, the DB
> effectivly cannot be used by anyone else. This involves deleting
> anywhere between 200,000 to 400,000 rows, a vacuum, then an insert.
> Our solution was to break the table into 10 chunks, (originally one
> big ~3,000,000 row table which began taking over 36 hours for the
> vacuum alone!) which now makes each table much more manageable
> in terms of updating. All updates are done on a second system that
> is a duplicate of the production one, then moving the entire
> /data/... tree over to the production system when done. This gives
> us roughly a 10 minute downtime as opposed to several hours if done
> on the live system. BTW, both systems are 450Mhz machines w/256Meg
> memory and ultra-wide fast scsi drives...
>
> Brad
>
> --
> Bradford L. Barrett [EMAIL PROTECTED]
> A free electron in a sea of neutrons DoD#1750 KD4NAW
>
> Those that can, do... Those that can't... Run Windows!!
>
>
