Re: Ayuda con cadena de conexion ODBC windows XP SP 3 desde VFP a POSTGRESQL 8.4

Hola lista, una consulta, hay alguna forma de acelerar el proceso de VACUUM
ANALYZE? lo realizamos todas las noches sobre una base de datos de casi 120
GB y tarda aprox. 6 hs. Algún parámetro de conf que pueda tocarse?

Sergio Gabriel Rodríguez
http://www.3trex.com.ar
Corrientes - Argentina

Sergio Gabriel Rodriguez escribió:
> Hola lista, una consulta, hay alguna forma de acelerar el proceso de VACUUM
> ANALYZE? lo realizamos todas las noches sobre una base de datos de casi 120
> GB y tarda aprox. 6 hs. Algún parámetro de conf que pueda tocarse?

Version de Postgres? sistema operativo?

--
Alvaro Herrera Vendo parcela en Valdivia: http://rie.cl/?a=255568
"Cómo ponemos nuestros dedos en la arcilla del otro. Eso es la amistad; jugar
al alfarero y ver qué formas se pueden sacar del otro" (C. Halloway en
La Feria de las Tinieblas, R. Bradbury)

El 3 de diciembre de 2009 12:20, Alvaro Herrera
<alvherre(at)alvh(dot)no-ip(dot)org>escribió:

> Sergio Gabriel Rodriguez escribió:
> > Hola lista, una consulta, hay alguna forma de acelerar el proceso de
> VACUUM
> > ANALYZE? lo realizamos todas las noches sobre una base de datos de casi
> 120
> > GB y tarda aprox. 6 hs. Algún parámetro de conf que pueda tocarse?
>
> Version de Postgres? sistema operativo?
>
>
> Perdón 16 GB ram

Sergio Gabriel Rodríguez
http://www.3trex.com.ar
Corrientes - Argentina

Sergio Gabriel Rodriguez escribió:
> El 3 de diciembre de 2009 12:20, Alvaro Herrera
> <alvherre(at)alvh(dot)no-ip(dot)org>escribió:
>
> > Sergio Gabriel Rodriguez escribió:
> > > Hola lista, una consulta, hay alguna forma de acelerar el proceso de
> > VACUUM
> > > ANALYZE? lo realizamos todas las noches sobre una base de datos de casi
> > 120
> > > GB y tarda aprox. 6 hs. Algún parámetro de conf que pueda tocarse?
> >
> > Version de Postgres? sistema operativo?
> >
> >
> > Perdón 16 GB ram

Ya, pero eso no es lo que pregunté ...

--
Alvaro Herrera Vendo parcela en Valdivia: http://alvherre.cl/caboblanco
"Cuando no hay humildad las personas se degradan" (A. Christie)

El 3 de diciembre de 2009 12:20, Alvaro Herrera
<alvherre(at)alvh(dot)no-ip(dot)org>escribió:

Sergio Gabriel Rodriguez escribió:
> > Hola lista, una consulta, hay alguna forma de acelerar el proceso de
> VACUUM
> > ANALYZE? lo realizamos todas las noches sobre una base de datos de casi
> 120
> > GB y tarda aprox. 6 hs. Algún parámetro de conf que pueda tocarse?
>
> Version de Postgres? sistema operativo?
>
>
Había enviado mal: Pg 8.0.22 y Linux SLES 9, el server es en HP G5 2x Quad,
16B ram

Sergio Gabriel Rodríguez
http://www.3trex.com.ar
Corrientes - Argentina

Sergio Gabriel Rodriguez escribió:
> El 3 de diciembre de 2009 12:20, Alvaro Herrera
> <alvherre(at)alvh(dot)no-ip(dot)org>escribió:
>
> Sergio Gabriel Rodriguez escribió:
> > > Hola lista, una consulta, hay alguna forma de acelerar el proceso de
> > VACUUM
> > > ANALYZE? lo realizamos todas las noches sobre una base de datos de casi
> > 120
> > > GB y tarda aprox. 6 hs. Algún parámetro de conf que pueda tocarse?
> >
> > Version de Postgres? sistema operativo?
> >
> >
> Había enviado mal: Pg 8.0.22 y Linux SLES 9, el server es en HP G5 2x Quad,
> 16B ram

8.0 es muy lento en cuanto a VACUUM. El primer paso es actualizar a una
versión más reciente -- 8.4 es muy superior por varios motivos, aunque
incluso migrar a 8.2 te dará una mejora significativa.

--
Alvaro Herrera Vendo parcela en Valdivia: http://rie.cl/?a=255568
"How strange it is to find the words "Perl" and "saner" in such close
proximity, with no apparent sense of irony. I doubt that Larry himself
could have managed it." (ncm, http://lwn.net/Articles/174769/)

El 3 de diciembre de 2009 12:37, Alvaro Herrera
<alvherre(at)alvh(dot)no-ip(dot)org>escribió:

> Sergio Gabriel Rodriguez escribió:
> > El 3 de diciembre de 2009 12:20, Alvaro Herrera
> > <alvherre(at)alvh(dot)no-ip(dot)org>escribió:
> >
> > Sergio Gabriel Rodriguez escribió:
> > > > Hola lista, una consulta, hay alguna forma de acelerar el proceso de
> > > VACUUM
> > > > ANALYZE? lo realizamos todas las noches sobre una base de datos de
> casi
> > > 120
> > > > GB y tarda aprox. 6 hs. Algún parámetro de conf que pueda tocarse?
> > >
> > > Version de Postgres? sistema operativo?
> > >
> > >
> > Había enviado mal: Pg 8.0.22 y Linux SLES 9, el server es en HP G5 2x
> Quad,
> > 16B ram
>
> 8.0 es muy lento en cuanto a VACUUM. El primer paso es actualizar a una
> versión más reciente -- 8.4 es muy superior por varios motivos, aunque
> incluso migrar a 8.2 te dará una mejora significativa.
>
>
lo imaginaba, gracias Alvaro, cuando hagamos la actualización de versión voy
a postear los resultados :)

Sergio Gabriel Rodríguez
http://www.3trex.com.ar
Corrientes - Argentina

Sergio Gabriel Rodriguez escribió:
> El 3 de diciembre de 2009 12:37, Alvaro Herrera
> <alvherre(at)alvh(dot)no-ip(dot)org>escribió:
>
> > Sergio Gabriel Rodriguez escribió:
> > > El 3 de diciembre de 2009 12:20, Alvaro Herrera
> > > <alvherre(at)alvh(dot)no-ip(dot)org>escribió:
> > >
> > > Sergio Gabriel Rodriguez escribió:
> > > > > Hola lista, una consulta, hay alguna forma de acelerar el proceso de
> > > > VACUUM
> > > > > ANALYZE? lo realizamos todas las noches sobre una base de datos de
> > casi
> > > > 120
> > > > > GB y tarda aprox. 6 hs. Algún parámetro de conf que pueda tocarse?
> > > >
> > > > Version de Postgres? sistema operativo?
> > > >
> > > >
> > > Había enviado mal: Pg 8.0.22 y Linux SLES 9, el server es en HP G5 2x
> > Quad,
> > > 16B ram
> >
> > 8.0 es muy lento en cuanto a VACUUM. El primer paso es actualizar a una
> > versión más reciente -- 8.4 es muy superior por varios motivos, aunque
> > incluso migrar a 8.2 te dará una mejora significativa.
> >
> >
> lo imaginaba, gracias Alvaro, cuando hagamos la actualización de versión voy
> a postear los resultados :)

Hmm, una cosa que quizas pueda ayudar sea aumentar maintenance_work_mem
a un numero bastante alto (digamos unos 2 GB, o mas dependiendo de si el
entorno es de 64 bits). Eso permite que la limpieza de indices se haga
en menos pasadas.

Otra cosa es que quizas tengas algunas tablas con mucho espacio muerto
que necesites recuperar, sobre todo si no has ajustado los parametros
del FSM. Para esto podrias usar VACUUM FULL o quizas el ALTER TABLE /
SET TYPE, pero no estoy seguro si ya existia en 8.0 (me parece que si)
Asumo que NO estas usando VACUUM FULL.

Y el ultimo punto es que quizas necesites hacer VACUUM mas frecuente
sobre algunas tablas, v.g. aquellas que tengan mucho update.

--
Alvaro Herrera Vendo parcela en Valdivia: http://alvherre.cl/caboblanco
<inflex> really, I see PHP as like a strange amalgamation of C, Perl, Shell
<crab> inflex: you know that "amalgam" means "mixture with mercury",
more or less, right?
<crab> i.e., "deadly poison"

2009/12/3 Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>

> Sergio Gabriel Rodriguez escribió:
> > El 3 de diciembre de 2009 12:37, Alvaro Herrera
> > <alvherre(at)alvh(dot)no-ip(dot)org>escribió:
> >
> > > Sergio Gabriel Rodriguez escribió:
> > > > El 3 de diciembre de 2009 12:20, Alvaro Herrera
> > > > <alvherre(at)alvh(dot)no-ip(dot)org>escribió:
> > > >
> > > > Sergio Gabriel Rodriguez escribió:
> > > > > > Hola lista, una consulta, hay alguna forma de acelerar el proceso
> de
> > > > > VACUUM
> > > > > > ANALYZE? lo realizamos todas las noches sobre una base de datos
> de
> > > casi
> > > > > 120
> > > > > > GB y tarda aprox. 6 hs. Algún parámetro de conf que pueda
> tocarse?
> > > > >
> > > > > Version de Postgres? sistema operativo?
> > > > >
> > > > >
> > > > Había enviado mal: Pg 8.0.22 y Linux SLES 9, el server es en HP G5
> 2x
> > > Quad,
> > > > 16B ram
> > >
> > > 8.0 es muy lento en cuanto a VACUUM. El primer paso es actualizar a
> una
> > > versión más reciente -- 8.4 es muy superior por varios motivos, aunque
> > > incluso migrar a 8.2 te dará una mejora significativa.
> > >
> > >
> > lo imaginaba, gracias Alvaro, cuando hagamos la actualización de versión
> voy
> > a postear los resultados :)
>
> Hmm, una cosa que quizas pueda ayudar sea aumentar maintenance_work_mem
> a un numero bastante alto (digamos unos 2 GB, o mas dependiendo de si el
> entorno es de 64 bits). Eso permite que la limpieza de indices se haga
> en menos pasadas.
>
> Otra cosa es que quizas tengas algunas tablas con mucho espacio muerto
> que necesites recuperar, sobre todo si no has ajustado los parametros
> del FSM. Para esto podrias usar VACUUM FULL o quizas el ALTER TABLE /
> SET TYPE, pero no estoy seguro si ya existia en 8.0 (me parece que si)
> Asumo que NO estas usando VACUUM FULL.
>
> Y el ultimo punto es que quizas necesites hacer VACUUM mas frecuente
> sobre algunas tablas, v.g. aquellas que tengan mucho update.
>

el vacuum analyze lo hago todas las noches, es necesario igualmente un full?
cuál es la desventaja de hacerlo?

Sergio Gabriel Rodriguez
http://www.3trex.com.ar
Corrientes - Argentina

Hola foro buenos días, estoy iniciándome en postgresql y quiero hacer una
conexión vía ODBC pero mediante una cadena de conexión y me arroja el
siguiente mensaje cada vez que intento la conexión:

[Microsoft][Administrador de controladores ODBC] no se encuentra el nombre
del origen de datos y no se especificó ningún controlador predeterminado.

Debo aclarar que ya tengo instalado el ODBC para postgresql en mi pc.

Tengo el siguiente escenario:

Windows XP SP3

Visual FoxPro 9.0

PostgreSQL 8.4

Este es el código que utilice:

lcRutaServer="192.168.1.3"

lcBaseDatos="miBD"

lcUser="postgres"

lcPasword="miclave"

lcConC ="Driver={PostgreSQL};Server="+lcRutaServer+";Port=5432;Database="+
ALLTRIM(lcBaseDatos) +";Uid=lcUser;Pwd=lcPasword"

miErrorTry=.f.

TRY

STORE SQLSTRINGCONNECT(lcConC,.t.) TO CONPOSTGRESQL

CATCH

miErrorTry = .t.

ENDTRY

IF miErrorTry

=MESSAGEBOX('Ocurrio un error en la conexion a POSTGRESQL')

RETURN

ENDIF

IF CONPOSTGRESQL <= 0

lError=AERROR(Mi_Error)

=messagebox(Mi_error(1,3),0+64)

RETURN .f.

ENDIF

=MESSAGEBOX('conexion a POSTGRESQL OK')

Gracias de antemano.

Hola José Luis, prueba así a ver, es totalemnete configurable:
cadena_conex = "DRIVER={PostgreSQL ANSI};DATABASE=" & base_dat &
";SERVER=" & dir_servidor & ";PORT=" & PUERTO & ";UID=" & perso_a &
";PWD=" & perso_p & ";SSLMODE=prefer;"
Fíjate que la asignación de user y pass no lo tienes bien(como cadena)
si no me equivoco.
Esta a mí me va perfecto
Espero te ayude
Un saludo
Suso
>
> Hola foro buenos días, estoy iniciándome en postgresql y quiero hacer
> una conexión vía ODBC pero mediante una cadena de conexión y me arroja
> el siguiente mensaje cada vez que intento la conexión:
>
>
>
> *[Microsoft][Administrador de controladores ODBC] no se encuentra el
> nombre del origen de datos y no se especificó ningún controlador
> predeterminado.*
>
> * *
>
> Debo aclarar que ya tengo instalado el ODBC para postgresql en mi pc.
>
>
>
>
>
> Tengo el siguiente escenario:
>
>
>
> Windows XP SP3
>
> Visual FoxPro 9.0
>
> PostgreSQL 8.4
>
>
>
>
>
> Este es el código que utilice:
>
>
>
>
>
> lcRutaServer="192.168.1.3"
>
> lcBaseDatos="miBD"
>
> lcUser="postgres"
>
> lcPasword="miclave"
>
> lcConC
> ="Driver={PostgreSQL};Server="+lcRutaServer+";Port=5432;Database="+
> ALLTRIM(lcBaseDatos) +";Uid=lcUser;Pwd=lcPasword"
>
> miErrorTry=.f.
>
> TRY
>
> STORE SQLSTRINGCONNECT(lcConC,.t.) TO CONPOSTGRESQL
>
> CATCH
>
> miErrorTry = .t.
>
> ENDTRY
>
> IF miErrorTry
>
> =MESSAGEBOX('Ocurrio un error en la conexion a POSTGRESQL')
>
> RETURN
>
> ENDIF
>
>
>
> IF CONPOSTGRESQL <= 0
>
> lError=AERROR(Mi_Error)
>
> =messagebox(Mi_error(1,3),0+64)
>
> RETURN .f.
>
> ENDIF
>
> =MESSAGEBOX('conexion a POSTGRESQL OK')
>
>
>
>
>
>
>
>
>
>
>
> Gracias de antemano.
>
>
>
>
>
> __________ Información de ESET Smart Security, versión de la base de
> firmas de virus 4660 (20091204) __________
>
> ESET Smart Security ha comprobado este mensaje.
>
> http://www.eset.com
>
>
> __________ Información de ESET Smart Security, versión de la base de
> firmas de virus 4661 (20091204) __________
>
> ESET Smart Security ha comprobado este mensaje.
>
> http://www.eset.com

1) Debiste ponerlo como OT porque esto no es un foro de VFP, y el
error que tienes es de VFP
2) Aparentemente el problema que tienes es que no estan instalados los
drivers ODBC para conectarte con PostgreSQL
3) Revisa ese string de conexion porque no creo que este correcto.
Busca tus ODBC Aqui:

http://www.postgresql.org/ftp/odbc/versions/msi/

4) Suerte!

:: HDS Consultores TI
Servidores | Redes | Programacion | GNU/Linux | PostgreSQL
Web: http://hdsconsultores.net

El día 4 de diciembre de 2009 11:05, José Luis Carranza
<joseluis(at)adesynet(dot)com> escribió:
> Hola foro buenos días, estoy iniciándome en postgresql y quiero hacer una
> conexión vía ODBC pero mediante una cadena de conexión y me arroja el
> siguiente mensaje cada vez que intento la conexión:
>
>
>
> [Microsoft][Administrador de controladores ODBC] no se encuentra el nombre
> del origen de datos y no se especificó ningún controlador predeterminado.
>
>
>
> Debo aclarar que ya tengo instalado el ODBC para postgresql en mi pc.
>
>
>
>
>
> Tengo el siguiente escenario:
>
>
>
> Windows XP SP3
>
> Visual FoxPro 9.0
>
> PostgreSQL 8.4
>
>
>
>
>
> Este es el código que utilice:
>
>
>
>
>
> lcRutaServer="192.168.1.3"
>
> lcBaseDatos="miBD"
>
> lcUser="postgres"
>
> lcPasword="miclave"
>
> lcConC ="Driver={PostgreSQL};Server="+lcRutaServer+";Port=5432;Database="+
> ALLTRIM(lcBaseDatos) +";Uid=lcUser;Pwd=lcPasword"
>
> miErrorTry=.f.
>
> TRY
>
>       STORE SQLSTRINGCONNECT(lcConC,.t.) TO CONPOSTGRESQL
>
> CATCH
>
>       miErrorTry  =     .t.
>
> ENDTRY
>
> IF miErrorTry
>
>       =MESSAGEBOX('Ocurrio un error en la conexion a POSTGRESQL')
>
>       RETURN
>
> ENDIF
>
>
>
> IF CONPOSTGRESQL <= 0
>
>       lError=AERROR(Mi_Error)
>
>       =messagebox(Mi_error(1,3),0+64)
>
>       RETURN .f.
>
> ENDIF
>
> =MESSAGEBOX('conexion a POSTGRESQL OK')
>
>
>
>
>
>
>
>
>
>
>
> Gracias de antemano.
>
>
>
> __________ Información de ESET Smart Security, versión de la base de firmas
> de virus 4660 (20091204) __________
>
> ESET Smart Security ha comprobado este mensaje.
>
> http://www.eset.com
>

Hola Héctor gracias por tu respuesta.

1. No me pareció un problema de VFP ya que he conectado vía ODBC otras
BD(SQL) por ello no puse el OT
2. Si tengo instalado el ODBC de postgresql por eso no me explicaba por qué
no lo reconocía como conexión, pensé que quizás me faltaba copiar algunos
.dll a otras carpetas para que lo reconozca, por eso recurrí al foro de
postgresql ;)
3. Ahí estaba el problema, en el string de conexión y lo comento en el post
anterior:
Esto es lo que me aconsejo un amigo de otro foro:

Lo más probable es que tengas malo esta
parte:

Driver={PostgreSQL};

Te aconsejo que crees un ODBC de archivo,
luego lo busques y lo habrás con el notepad y fíjate como genera el Windows
la cadena de conexión,
esta forma nunca falla.

Siguiendo estas pautas la cadena de conexión que funciono es
la siguiente:
lcConC ="DRIVER=PostgreSQL ODBC
Driver(ANSI);Server=127.0.0.1;Port=5432;Database=mi_db;Uid=postgres;Pwd=micl
ave;"

4) Gracias!

Un fuerte abrazo.

-----Mensaje original-----
De: Hector R. De los Santos (Consultor TI) [mailto:zahory(at)gmail(dot)com]
Enviado el: Sábado, 05 de Diciembre de 2009 01:32 p.m.
Para: José Luis Carranza
CC: pgsql-es-ayuda(at)postgresql(dot)org
Asunto: Re: [pgsql-es-ayuda] Ayuda con cadena de conexion ODBC windows XP SP
3 desde VFP a POSTGRESQL 8.4

1) Debiste ponerlo como OT porque esto no es un foro de VFP, y el
error que tienes es de VFP
2) Aparentemente el problema que tienes es que no estan instalados los
drivers ODBC para conectarte con PostgreSQL
3) Revisa ese string de conexion porque no creo que este correcto.
Busca tus ODBC Aqui:

http://www.postgresql.org/ftp/odbc/versions/msi/

4) Suerte!

:: HDS Consultores TI
Servidores | Redes | Programacion | GNU/Linux | PostgreSQL
Web: http://hdsconsultores.net

El día 4 de diciembre de 2009 11:05, José Luis Carranza
<joseluis(at)adesynet(dot)com> escribió:
> Hola foro buenos días, estoy iniciándome en postgresql y quiero hacer una
> conexión vía ODBC pero mediante una cadena de conexión y me arroja el
> siguiente mensaje cada vez que intento la conexión:
>
>
>
> [Microsoft][Administrador de controladores ODBC] no se encuentra el nombre
> del origen de datos y no se especificó ningún controlador predeterminado.
>
>
>
> Debo aclarar que ya tengo instalado el ODBC para postgresql en mi pc.
>
>
>
>
>
> Tengo el siguiente escenario:
>
>
>
> Windows XP SP3
>
> Visual FoxPro 9.0
>
> PostgreSQL 8.4
>
>
>
>
>
> Este es el código que utilice:
>
>
>
>
>
> lcRutaServer="192.168.1.3"
>
> lcBaseDatos="miBD"
>
> lcUser="postgres"
>
> lcPasword="miclave"
>
> lcConC ="Driver={PostgreSQL};Server="+lcRutaServer+";Port=5432;Database="+
> ALLTRIM(lcBaseDatos) +";Uid=lcUser;Pwd=lcPasword"
>
> miErrorTry=.f.
>
> TRY
>
>       STORE SQLSTRINGCONNECT(lcConC,.t.) TO CONPOSTGRESQL
>
> CATCH
>
>       miErrorTry  =     .t.
>
> ENDTRY
>
> IF miErrorTry
>
>       =MESSAGEBOX('Ocurrio un error en la conexion a POSTGRESQL')
>
>       RETURN
>
> ENDIF
>
>
>
> IF CONPOSTGRESQL <= 0
>
>       lError=AERROR(Mi_Error)
>
>       =messagebox(Mi_error(1,3),0+64)
>
>       RETURN .f.
>
> ENDIF
>
> =MESSAGEBOX('conexion a POSTGRESQL OK')
>
>
>
>
>
>
>
>
>
>
>
> Gracias de antemano.
>
>
>
> __________ Información de ESET Smart Security, versión de la base de
firmas
> de virus 4660 (20091204) __________
>
> ESET Smart Security ha comprobado este mensaje.
>
> http://www.eset.com
>

__________ Información de ESET Smart Security, versión de la base de firmas
de virus 4662 (20091205) __________

ESET Smart Security ha comprobado este mensaje.

http://www.eset.com

__________ Información de ESET Smart Security, versión de la base de firmas
de virus 4662 (20091205) __________

ESET Smart Security ha comprobado este mensaje.

http://www.eset.com

El 5 de diciembre de 2009 12:31, Hector R. De los Santos (Consultor TI) <
zahory(at)gmail(dot)com> escribió:

> 1) Debiste ponerlo como OT porque esto no es un foro de VFP, y el
> error que tienes es de VFP
> 2) Aparentemente el problema que tienes es que no estan instalados los
> drivers ODBC para conectarte con PostgreSQL

Concuerdo con que le falta instalar el driver de PostgreSql

> Hola Héctor gracias por tu respuesta.
>
> 1. No me pareció un problema de VFP ya que he conectado vía ODBC otras
> BD(SQL) por ello no puse el OT
> 2. Si tengo instalado el ODBC de postgresql por eso no me explicaba por
> qué
> no lo reconocía como conexión, pensé que quizás me faltaba copiar algunos
> .dll a otras carpetas para que lo reconozca, por eso recurrí al foro de
> postgresql ;)
> 3. Ahí estaba el problema, en el string de conexión y lo comento en el
> post
> anterior:
> Esto es lo que me aconsejo un amigo de otro foro:
>
> Lo más probable es que tengas malo esta
> parte:
>
> Driver={PostgreSQL};
>
> Te aconsejo que crees un ODBC de archivo,
> luego lo busques y lo habrás con el notepad y fíjate como genera el
> Windows
> la cadena de conexión,
> esta forma nunca falla.
>
> Siguiendo estas pautas la cadena de conexión que funciono es
> la siguiente:
> lcConC ="DRIVER=PostgreSQL ODBC
> Driver(ANSI);Server=127.0.0.1;Port=5432;Database=mi_db;Uid=postgres;Pwd=micl
> ave;"
>

http://www.connectionstrings.com/postgre-sql

Atentamente,

RAUL DUQUE
Bogotá, Colombia

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4663 (20091205) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

2009/12/3 Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>

> Sergio Gabriel Rodriguez escribió:
> > El 3 de diciembre de 2009 12:37, Alvaro Herrera
> > <alvherre(at)alvh(dot)no-ip(dot)org>escribió:
> >
> > > Sergio Gabriel Rodriguez escribió:
> > > > El 3 de diciembre de 2009 12:20, Alvaro Herrera
> > > > <alvherre(at)alvh(dot)no-ip(dot)org>escribió:
> > > >
> > > > Sergio Gabriel Rodriguez escribió:
> > > > > > Hola lista, una consulta, hay alguna forma de acelerar el proceso
> de
> > > > > VACUUM
> > > > > > ANALYZE? lo realizamos todas las noches sobre una base de datos
> de
> > > casi
> > > > > 120
> > > > > > GB y tarda aprox. 6 hs. Algún parámetro de conf que pueda
> tocarse?
> > > > >
> > > > > Version de Postgres? sistema operativo?
> > > > >
> > > > >
> > > > Había enviado mal: Pg 8.0.22 y Linux SLES 9, el server es en HP G5
> 2x
> > > Quad,
> > > > 16B ram
> > >
> > > 8.0 es muy lento en cuanto a VACUUM. El primer paso es actualizar a
> una
> > > versión más reciente -- 8.4 es muy superior por varios motivos, aunque
> > > incluso migrar a 8.2 te dará una mejora significativa.
> > >
> > >
> > lo imaginaba, gracias Alvaro, cuando hagamos la actualización de versión
> voy
> > a postear los resultados :)
>
> Hmm, una cosa que quizas pueda ayudar sea aumentar maintenance_work_mem
> a un numero bastante alto (digamos unos 2 GB, o mas dependiendo de si el
> entorno es de 64 bits). Eso permite que la limpieza de indices se haga
> en menos pasadas.
>

maintenance_work_mem estaba en 65536 (64 mb) y la lleve a 1048576 (1GB) y
tardó exctamente lo mismo 5:30 hs , primero al querer establecerla en 2GB y
darle restart a postgres me dió failed, por lo que la dejé en 1 GB. Ningún
otro proceso corre en este servidor a esa hora.

>
> Y el ultimo punto es que quizas necesites hacer VACUUM mas frecuente
> sobre algunas tablas, v.g. aquellas que tengan mucho update.
>
>
Sobre esta base se realiza todas las noches vacuum analyze, lo extraño es
que en otro server, mucho mas chico en prestaciones un vacuum sobre un
restore actualizado de esta misma base, tardó 1 hora..

Alguna sugerencia?

Sergio.

>
> maintenance_work_mem estaba en 65536 (64 mb) y la lleve a 1048576 (1GB)
> y tardó exctamente lo mismo 5:30 hs , primero al querer establecerla en 2GB
> y darle restart a postgres me dió failed, por lo que la dejé en 1 GB. Ningún
> otro proceso corre en este servidor a esa hora.
>
>
>>
>> Y el ultimo punto es que quizas necesites hacer VACUUM mas frecuente
>> sobre algunas tablas, v.g. aquellas que tengan mucho update.
>>
>>
> Sobre esta base se realiza todas las noches vacuum analyze, lo extraño es
> que en otro server, mucho mas chico en prestaciones un vacuum sobre un
> restore actualizado de esta misma base, tardó 1 hora..
>
> Alguna sugerencia?
>
>
el final del log de vacuum muestra lo sgte:

INFO: mapa de espacio libre: 424 relaciones, 38436 paginas almacenadas;
690384 paginas requeridas en total
DETAIL: tamaño del FSM: 2000 relaciones + 40000 paginas = 442 kB memoria
compartida

necesito aumentar el FSM?

Sergio Gabriel Rodriguez escribió:

> el final del log de vacuum muestra lo sgte:
>
> INFO: mapa de espacio libre: 424 relaciones, 38436 paginas almacenadas;
> 690384 paginas requeridas en total
> DETAIL: tamaño del FSM: 2000 relaciones + 40000 paginas = 442 kB memoria
> compartida
>
> necesito aumentar el FSM?

Si, yo lo pondría al menos en 1000000.

--
Alvaro Herrera Vendo parcela en Valdivia: http://rie.cl/?a=255568
"Find a bug in a program, and fix it, and the program will work today.
Show the program how to find and fix a bug, and the program
will work forever" (Oliver Silfridge)

2009/12/7 Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>

> Sergio Gabriel Rodriguez escribió:
>
> > el final del log de vacuum muestra lo sgte:
> >
> > INFO: mapa de espacio libre: 424 relaciones, 38436 paginas almacenadas;
> > 690384 paginas requeridas en total
> > DETAIL: tamaño del FSM: 2000 relaciones + 40000 paginas = 442 kB memoria
> > compartida
> >
> > necesito aumentar el FSM?
>
> Si, yo lo pondría al menos en 1000000.
>
>
Gracias, Álvaro nuevamente, una última, afecta en algo más este parámetro?
es decir si lo subo a ese valor puede repercutir en otra cosa?, aclaro que
vacuum corre en un horario donde no existen usuarios conectados.

saludos

Hola yo programa también en VFP 9, analiza este ejemplo, sobre todo la
cadena de conexión y me cuentas por favor:

lcServidor = 'localhost'
lcPuerto = '5432'
lcBaseDatos = 'prueba'
usu = 'postgres'
pass = '1234'

lcStr = 'DRIVER={PostgreSQL Ansi};SERVER=' + lcServidor +;
';port=' + lcPuerto + ';DATABASE=' + ALLTRIM(lcBaseDatos) +;
';UID=' + usu +;
';PWD='+ pass +';'

gnConnHandle_temp= SQLSTRINGCONNECT(lcStr,.T.)

if gnConnHandle_temp = -1
AERROR(arrayerror)

if arrayerror(4)='28000' then
MESSAGEBOX('Usuario o contraseña incorrectos',16,':: Error en la
conexión ::')
endif
else
WAIT WINDOW "Conexion exitosa"
=SQLSETPROP(gnConnHandle_temp,'Transactions',1)

sqlexec(gnConnHandle_temp,"INSERT INTO ventas
(cli_rut,ven_moto)VALUES (' 18855997', 221379)")

IF SQLCOMMIT(gnConnHandle_temp)>0
MESSAGEBOX("Datos Actualizados",0+42,"Mensaje de Dialogo")
ELSE
IF AERROR(laError)>0
MESSAGEBOX("Se ha producido un error"+laError[2])
endif
endif
= SQLDISCONNECT(gnConnHandle_temp)
endif

Patricio Castro Benavides

Sergio Gabriel Rodriguez escribió:
> 2009/12/7 Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
>
> > Sergio Gabriel Rodriguez escribió:
> >
> > > el final del log de vacuum muestra lo sgte:
> > >
> > > INFO: mapa de espacio libre: 424 relaciones, 38436 paginas almacenadas;
> > > 690384 paginas requeridas en total
> > > DETAIL: tamaño del FSM: 2000 relaciones + 40000 paginas = 442 kB memoria
> > > compartida
> > >
> > > necesito aumentar el FSM?
> >
> > Si, yo lo pondría al menos en 1000000.
> >
> Gracias, Álvaro nuevamente, una última, afecta en algo más este parámetro?
> es decir si lo subo a ese valor puede repercutir en otra cosa?, aclaro que
> vacuum corre en un horario donde no existen usuarios conectados.

No, sólo que va a usar un poco más de memoria compartida y puede que sea
necesario aumentar kernel.shmmax en /etc/sysctl.conf.

Ahora, sólo aumentar el valor no te va a solucionar el problema, porque
no va a ser posible compactar la base de datos. Como ya te dije,
necesitas algo que compacte de emergencia, como VACUUM FULL o CLUSTER.

--
Alvaro Herrera Vendo parcela en Valdivia:
http://www.portalinmobiliario.com/propiedades/fichas.asp?PropID=749682
"Porque francamente, si para saber manejarse a uno mismo hubiera que
rendir examen... ¿Quién es el machito que tendría carnet?" (Mafalda)