Instalacion de Posgresql Manual

7/24/2019 Instalacion de Posgresql Manual

1/17

REPBLICA BOLIVARIANA DE VENEZUELA

MINISTERIO DEL PODER POPULAR PARA LA DEFENSA

UNIVERSIDAD NACIONAL EXPERIMENTAL POLITCNICA DE LA

FUERZA ARMADA NACIONAL

NCLEO LARA

Autores:Br.Douglas GodoyBr.Enrique TorrealbaBr.Ramn SalasBr.Orlando CorroSeccin:14N1- IS.

Diciembre, 2010


2/17

Instalacin de Postgresql

Paso 1

La primera pantalla que se nos muestra es la bienvenida al instalador de

Postgresql. A partir de ahora tendremos que pulsar "Next" cada vez que queramos

avanzar al siguiente paso.

Paso 2

En el siguiente paso tendremos que definir el directorio donde vamos a instalar

todos los programas que vienen con esta versin de PostgreSQL. En nuestro caso,

utilizaremos el valor por defecto que el programa nos sugiere. C:\Archivos de

programa\PostgreSQL\9.0


3/17

Paso 3

En este paso tenemos que definir el directorio de datos en donde se crearn

nuestras bases de datos. De nuevo, en nuestro caso utilizaremos el valor por defecto que

el programa nos sugiere. C:\Archivos de programa\PostgreSQL\9.0\data

Paso 4

En este paso tenemos que definir una clave de acceso para el usuario

administrador de nuestra base de datos Postgresql. No olvidar esta clave, para no tener

problemas ms adelante.

Ms adelante podremos cambiar, si queremos, la clave del usuario administrador

(postgres) de la base de datos. Esta clave es totalmente independiente de la clave de la

cuenta de servicio 'postgres' en el sistema operativo.


4/17

Paso 5

En este paso tendremos que especificar el puerto que Postgresql utilizar para

escuchar por conexiones. En nuestro caso dejamos el valor por defecto, 5432.

Paso 6

En este paso se selecciona la configuracin regional por el clster, en nuestro caso

seleccionamos el espaol.

Luego de esto el programa esta listo para ser instalado presionando siguiente

Una vez terminada la instalacin, podremos salir del instalador pulsando

"Finish". En este ltimo paso el instalador nos da la opcin de arrancar automticamente

un programa llamado "Stack Builder". Este programa puede ser usado para instalar

diversos programas adicionales, tanto programas libres como algunos distribuidos por

EnterpriseDB.


5/17

Revisin de la configuracin.

Los tipos de configuracin

Existen diferentes tipos de variables de configuracin, divididas en base a los

posibles valores de entrada

Boolean true, false, on, off

Integer Nmeros (2112)

Float Valores decimales (21.12)

Memory / Disk Enteros (2112) o "Unidades computacionales" (512MB,

2112GB). Evite usar nmeros enteros sin unidad; necesitar saber la unidad

subyacente para entender lo que significa.

Time "Unidades de tiempo" aka d,m,s (30s). A veces se omite la unidad; no

haga esto.

Strings Texto simple con comilla simple('pg_log')

ENUMs Cadenas de caracteres, pero de una lista especfica ('WARNING',

'ERROR')

Lists Una lista de cadenas separada por comas ('"$user",public,tsearch2)


6/17

Parmetros de manejo de memoria.

SHARED_BUFFERS

El nmero de shared_bufferses el parmetro que ms afecta al rendimiento de

PostgreSQL. Este valor, de tipo entero, indica el nmero de bloques de memoria o

buffers de 8KB (8192 bytes) que postgres reservar, como zona de trabajo, en el

momento del arranque para procesar las consultas. De forma predeterminada (en

postgresql.conf), su valor es de 1000. Un nmero claramente insuficiente para conseguir

un rendimiento mnimamente aceptable.

Estos buffers se ubican dentro de los denominados segmentos de memoria

compartida. Es importante saber que el espacio ocupado por el nmero de buffers que

pretendamos asignar, nunca podr exceder al tamao mximo que tengan los segmentos

de memoria. En caso contrario, postgres se negar a arrancar avisando con un error que

no puede reservar el espacio solicitado.

El proceso consiste en los siguientes pasos:

1. Considerar un nmero superior al actual de shared buffers (comenzaremos por

un 10% del total de la memoria)

2. Modificar el tamao del segmento si no cabe el nmero de buffers

3. Comprobar el rendimiento y paginacin

4. En funcin del resultado obtenido, aumentar o disminuir el porcentaje de

memoria y empezar de nuevo

Una buena recomendacin (lee el artculo de B. Momjian) es la de empezar

asignando un 10% del total de la memoria RAM parashared_buffersy a partir de ah, iraumentando o disminuyendo dicho porcentaje en funcin del rendimiento y la

paginacin.

Para comprobar el rendimiento, aplica EXPLAIN a tus consultas. Para ver la

paginacin del servidor, puedes usar herramientas como vmstat o ipcs (consulta sus

pginas man).


7/17

Comenzamos:

El 10% de 1 GB: (1048576 KB/10) = 104857 KB

shared_buffers: (104857 KB/8 KB) = 13107

Asignamos este valor a la variable shared_buffers (postgresql.conf) y

reiniciamos el servidor. De ser el valor del parmetro superior o inferior este genera un

mensaje donde se indica que una peticin de PostgreSQL para obtener un segmento de

memoria compartida excedi el parmetro SHMMAX del kernel.

WORK_MEM

Este parmetro configura el espacio de memoria que postgres utiliza para realizar

ordenaciones de tablas o de resultados parciales de consultas, sobre todo en clusulas ORDER

BY, CREATE INDEX o MERGE JOIN.

Este valor es ms dificil de configurar porque depende, por un lado, de lo grande que

sean las tablas o resultados que hay que ordenar, y por otro, del nmero de peticiones

simultneas para esa misma consulta (para cada una se emplear la misma cantidad de

memoria).

Una buen comienzo es asignar entre un 2% y un 4% del total de la memoria si prevemos

pocos accesos simultneos a grandes sesiones de ordenacin y mucho menor, si esperamos

muchos accesos simultneos a sesiones de ordenacin pequeas. Como antes, lo mejor es ir

probando distintos valores y ver en qu pueden afectar a la paginacin adversa (swap pagein).

El valor hay que expresarlo en KB.

En nuestro ejemplo, hemos optado por usar un 4% de la memoria:

El 4% de 1 GB: 41943 KB (1048576 KB*4)/100work_men = 41943

Effective_cache_size

Este debe ser establecido en un monto estimado de cuanta memoria est disponible para

memorai intermedia en el disco para el sistema operativo, luego de entrar a una cuenta usada

por el Sistema operativo , dedicado a la memoria de postgresql y otras aplicaciones. Esta es una

gua para como se espera que est disponible la memoria en el bfer de cach de sistema


8/17

operativo, no una asignacin! Este valor es solo utilizado por el planeador de consultas para

tener en cuenta los planes que puedan o no caber en memoria. si es establecido demasiado bajo,

los indices no se utilizaran del modo que ud. esperara.

Estableciendo effective_cache_size a la mitad del total de la memoria, debera ser laopcin ms conservadora y 3/4 para una opcin ms agresiva pero que sigue siendo razonable.

Sera conveniente que elija este valor de acuerdo a las estadsitcas del sistema operativo. En

sistemas Unix/linux, sume free + cached arrojados por los comandos freeo toppara tener una

estimacin. En Windows vea el tamao del "System Cache" de la pestaa del Administrador de

Tareas. Cambiar este valor no requiere reiniciar el servidor (un HUP sera suficiente o un

RELOAD).

checkpoint_segments(entero)

Nmero mximo de segmentos de archivo de registro entre checkpoints automticos

(cada segmento es normalmente de 16 megabytes). El valor por defecto es de tres segmentos. El

aumento de este parmetro puede aumentar la cantidad de tiempo necesario para la recuperacin

de una cada. Este parmetro slo se puede establecer en el archivo postgresql.conf o en la lnea

de comandos del servidor.

checkpoint_timeout(entero)

Tiempo mximo entre checkpoints automticos, en cuestin de segundos. El valor

predeterminado es de cinco minutos (5 minutos). El aumento de este parmetro puede aumentar

la cantidad de tiempo necesario para la recuperacin de una cada. Este parmetro slo se puede

establecer en el archivo postgresql.conf o en la lnea de comandos del servidor.

checkpoint_completion_target (coma flotante)

Especifica el objetivo de completar puesto de control, como una fraccin del tiempo

total entre los puntos de control. El valor por defecto es de 0,5. Este parmetro slo se puede


checkpoint_warning (entero)

Escribir un mensaje en el registro de servidor si los puestos de control causado por el

llenado de los archivos del segmento puesto de control de suceder ms juntos que esta cantidad

de segundos (lo que sugiere que checkpoint_segments debe ser levantada). El valor por defecto


9/17

es de 30 segundos (30 aos). Cero deshabilita la advertencia. Este parmetro slo se puede


Estos pueden ser un recurso intensivo, y en un sistema moderno hacer uno cada 48 MB

puede ocacionar cuellos de botella. Estableciendo este valor un poco ms alto mejorara esteinconveniente. Si esta corriendo en una configuracin pequea, debera establecer esta al menos

en 10, permitiendo alcanzar los objetivos.

Para sistemas de escritura masiva, valores desde 32 (punto de chequeo cada 512MB) a

256 (cada 128GB) son vias populares. Sistemas muy grandes utilizan muchsimo ms disco lo

que la recuperacin llevara ms tiempo, por lo que debera elegir en que rango se encuentra

comfortable. Normalmente los valores altos (>64/1GB) son utilizadas para cargas de gran

aumento de volumen.

vacuum_mem(integer)

Especifica la cantidad mxima de la memoria para ser usada por el vacuum. El valor seda en Kb y por default se establece a 8192 kb.

Conexiones simultaneas,

pg_hba.conf

Este fichero se utiliza para definir como, donde y desde que sitio un usuario puede

utilizar nuestro cluster PostgreSQL. Todas las lineas que empiezen con el caracter # se

interpretan como comentarios. El resto debe de tener el siguiente formato:

[Tipo de conexion][database][usuario][IP][Netmask][Tipo de autentificacion][opciones]

Dependiendo del tipo de conexion y del tipo de autentificacion, [IP],[Netmask] y

[opciones] pueden ser opcionales. Vamos a explicar un poco como definir las reglas de acceso.

El tipo de conexion puede tener los siguientes valores, local, host, hostssl y hostnossl. El tipo de

metodo puede tener los siguientes valores, trust, reject, md5, crypt, password, krb5, ident, pam o

ldap

Una serie de ejemplos nos ayudaran a comprender mejor como podemos configurar

diferentes accesos al cluster PostgreSQL.


10/17

Ejemplo 1 .- Acceso por tcp/ip (red) a la base de datos test001, como usuario test desde el

ordenador con IP 10.0.0.100, y metodo de autentificacion md5:

host test001 test 10.0.0.100 255.255.255.255 md5

Esta misma entrada se podria escribir tambien con la mascara de red en notacion CIDR:

host test001 test 10.0.0.100/32 md5

Ejemplo 2 .- Acceso por tcp/ip (red) a la base de datos test001, como usuario test desde todos

los ordenadores de la red 10.0.0.0, con mascara de red 255.255.255.0 (254 ordenadores en total)

y metodo de autentificacion md5:

host test001 test 10.0.0.0 255.255.255.0 md5

Esta misma entrada se podria escribir tambien con la mascara de red en notacion CIDR:

host test001 test 10.0.0.0/24 md5

Ejemplo 3 .- Acceso por tcp/ip (red), encriptado, a todas las bases de datos de nuestro cluster,

como usuario test desde el ordenador con IP 10.0.0.100, y el ordenador 10.1.1.100 y metodo de

autentificacion md5 (necesitamos dos entradas en nuestro fichero pg_hba.conf:

hostssl all test 10.0.0.100 255.255.255.255 md5

hostssl all test 10.1.1.100 255.255.255.255 md5

Ejemplo 4.- Denegar el acceso a todos las bases de datos de nuestro cluster al usuario test, desde

todos los ordenadores de la red 10.0.0.0/24 y dar accesso al resto del mundo con el metodo

md5:

host all test 10.0.0.0/24 reject

host all all 0.0.0.0/0 md5

Asi podriamos seguir jugando con todas las posibilidades que nos brinda este fichero de

configuracion. Por supuesto que las bases de datos y usuarios usados en este fichero tienen que

existir en nuestro cluster para que todo funcione y algunos de los parametros solo se pueden

usar si hemos compilado con las opciones pertinentes en el proceso de instalacion (por ejemplo,

hostssl, pam, krb5)


11/17

Para poder en produccion los cambios en este fichero tendremos que decirle a

PostgreSQL que vuelva a leerlo. Basta con un simple 'reload' (/usr/local/bin/pg_ctl -D

/var/pgsql/data reload) desde la linea de comandos o con la funcion pg_reload_conf() como

usuario postgres desde psql, el cliente PostgreSQL.

[postgres@servidor]# /usr/local/bin/psql

Welcome to psql 8.2.4, the PostgreSQL interactive terminal.

Type: \copyright for distribution terms

\h for help with SQL commands

\? for help with psql commands

\g or terminate with semicolon to execute query

\q to quit postgres=# SELECT pg_reload_conf();

pg_reload_conf

t

(1 row)

postgres=#

Para una documentacion detallada sobre el fichero pg_hba.con, pasaros por la seccion Chapter

20. Client Authentication de la documentacion oficial de PostgreSQL.

Ejemplo:

A continuacion vamos a ver los parametros mas importantes que deberiamos cambiar si

empezamos a usar PostgreSQL para un uso serio y si queremos sacarle el maximo partido a

nuestra maquina. Existen muchos mas parametros que se pueden y con el tiempo se deberan de

ajustar, aqui nos vamos a centrar en los mas importantes y los cuales deberiamos cambiar antes

de empezar a utilizar PostgreSQL de una manera seria.

max_connections: Numero maximo de clientes conectados a la vez a nuestras bases de datos.

Deberiamos de incrementar este valor en proporcion al numero de clientes concurrentes en

nuestro cluster PostgreSQL. Un buen valor para empezar es el 100:

max_connections = 100


12/17

shared_buffers: Este parametro es importantisimo y define el tamao del buffer de memoria

utilizado por PostgreSQL. No por aumentar este valor mucho tendremos mejor respuesta. En un

servidor dedicado podemos empezar con un 25% del total de nuestra memoria. Nunca mas de

1/3 (33%) del total. Por ejemplo, en un servidor con 4Gbytes de memoria, podemos usar

1024MB como valor inicial.

shared_buffers = 1024MB

work_mem:Usada en operaciones que contengan ORDER BY, DISTINCT, joins, .... En un

servidor dedicado podemos usar un 2-4% del total de nuestra memoria si tenemos solamente

unas pocas sesiones (clientes) grandes. Como valor inicial podemos usar 8 Mbytes.

work_mem= 8MB

maintenance_work_mem: Usada en operaciones del tipo VACUUM, ANALYZE, CREATE

INDEX, ALTER TABLE, ADD FOREIGN KEY. Su valor dependera mucho del tamao de

nuestras bases de datos. Por ejemplo, en un servidor con 4Gbytes de memoria, podemos usar

256MB como valor inicial.

maintenance_work_mem = 256MB

effective_cache_size: Parametro usado por el 'query planner' de nuestro motor de bases de datospara optimizar la lectura de datos. En un servidor dedicado podemos empezar con un 50% del

total de nuestra memoria. Como maximo unos 2/3 (66%) del total. Por ejemplo, en un servidor

con 4Gbytes de memoria, podemos usar 2048MB como valor inicial.

effective_cache_size= 2048MB

checkpoint_segments: Este parametro es muy importante en bases de datos con numerosas

operaciones de escritura (insert,update,delete). Para empezar podemos empezar con un valor de

64. En grandes databases con muchos Gbytes de datos escritos podemos aumentar este valor

hasta 128-256.

checkpoint_segments= 64

Es muy importante tener en cuenta que al aumentar los valores por defecto de muchos de estos

parametros, tendremos que aumentar los valores por defecto de algunos parametros del kernel

de nuestro sistema.


13/17

Inicio, reinicio y parada del servidor de Base de Datos

La puesta en marcha del servidor se puede hacer de forma manual con dos comandos:

pg_ctl: facilidad para la puesta en marcha, parada y reconfiguracin del servidor. Hace uso dela instruccin que acta sobre el servidor postgres.

postmaster:proceso servidor de base de datos.

El comando pg_ctl es el que se usa normalmente, porque permite controlar ms aspectos que el

comando postmaster.

Operaciones:

start: puesta en marcha del servidor. stop: parada del servidor.

restart: parada del servidor seguida de puesta en marcha.

reload: envia al postmaster una senal SIGHUP, que provoca que recargue toda la informacion

de configuracion. Algunas opciones de configuracion requieren parar el servidor.

status: comprueba si hay un postmaster en marcha y muestra el PID y su opciones de puesta en

marcha.

kill, register, unregister: opciones para la version de Windows para matar, registrar como

servicio o eliminar el servicio.

CREATE DATABASE crea una nueva base de datos PostgreSQL. El creador pasa a ser el

propietario de la nueva base de datos.

Puede especificarse una localizacin alternativa para, por ejemplo, almacenar la base de

datos en un disco diferente. La ruta debe haber sido preparada con la orden initlocation.

Si la ruta contiene una barra, la parte delantera se interpreta como una variable de

entorno, que debe ser conocida por el proceso servidor. De esta forma el administrador de la

base de datos puede ejercer control sobre las localizaciones que pueden ser creadas. (Una

eleccin de usuario puede ser, por ejemplo, 'PGDATA2'.) Si el servidor est compilado con

ALLOW_ABSOLUTE_DBPATHS (cosa que no se hace por defecto), se permiten tambin los

nombres de ruta absolutos, identificados por una barra al principio (p. ej. '/usr/local/pgsql/data').

CREATE DATABASE name[ WITH LOCATION = 'dbpath' ]


14/17

Eliminacin de Base de Datos

DROP DATABASEelimina las entradas de catlogo de una base de datos existente y borra el

directorio que contiene los datos. Solamente puede ser ejecutado por el propietario de la base de

datos (normalmente quien la cre).

DROP DATABASE name

Creacin de Tablas,

CREATE [ TEMPORARY | TEMP ] TABLE table(columntype[ NULL | NOT NULL ] [ UNIQUE ] [ DEFAULT value][column_constraint_clause| PRIMARY KEY } [ ... ] ][, ... ][, PRIMARY KEY ( column[, ...] ) ][, CHECK ( condition) ][, table_constraint_clause]) [ INHERITS ( inherited_table[, ...] ) ]

Modificacin de Tablas

MODIFICAR TABLA tabla[ * ]AADIR [ COLUMNA ] columnatipo

MODIFICAR TABLA tabla[ * ]MODIFICAR [ COLUMNA ] columna{ SET DEFAULT valor| DROP DEFAULT }

MODIFICAR TABLA tabla[ * ]RENOMBRAR [ COLUMNA ] columnaA nueva columna

MODIFICAR TABLA tabla

RENOMBRAR A nueva tabla

Eliminacin de Tablas

DROP TABLEelimina tablas y vistas de una base de datos. Solo su propietario (owner) puededestruir una tabla o vista. Una tabla puede ser vaciada de sus filas, pero no destruida, usandoDELETE.

Si una tabla a ser destruida tiene un ndice secundario, este debe ser removido primero. Laremocin de solo un ndice secundario no afecta el contenido de la tabla subyacente.

DROP TABLE nombre[, ...]

Creacin de Usuario

CREAR USUARIO nombre de usuario[ CON[ SYSID uid][ PASSWORD 'palabra clave' ] ]

[ CREARDB | NOCREARDB ] [ CREARUSUARIO | NOCREARUSUARIO ][ EN EL GRUPO nombre de grupo[, ...] ]

[ VALIDO HASTA 'abstime' ]


15/17

Modificacin de usuario

MODIFICAR USUARIO nombre de usuario[ WITH PASSWORD 'palabra clave' ][ CREATEDB | NOCREATEDB ] [ CREATEUSER | NOCREATEUSER ][ VALID UNTIL 'abstime' ]

Eliminacin de usuarios

DROP USER

Retira de la base de datos el usuario dado. No retira tablas, vistas u otros objetos que

pertenezcan al usuario. Si el usuario es dueo de una base de datos, se producir un error.

Use CREAR USUARIOpara adicionar nuevos usuarios, yMODIFICAR USUARIOpara

modificar las propiedades de un usuario. PostgreSQL viene con un guin dropuserque tiene la

misma funcin de este comando (de hecho, invoca este comando) pero que puede ser ejecutado

desde la shell.

DROP USER nombre

Privilegios

Cuando se crea un objeto en la base de datos, se le asigna un dueo. El dueo es el

usuario que ejecut la declaracin de la creacin. Para cambiar al dueo de una tabla, ndice,

secuencia, vista, se utiliza el comando ALTER TABLE. Por default, solo el dueo (o

superusuario) puede hacer cualquier cosa con el objeto. Para permitir que otros usuarios lo

utilicen, los privilegios deben ser concedidos (grant).

Hay varios privilegios : SELECT, INSERT, UPDATE, DELETE, RULE,

REFERENCES, TRIGGER, CREATE, TEMPORARY, EXECUTE, USAGE, y ALL

PRIVILEGES. El hecho de modificar o destruir un objeto es siempre el privilegio del dueo

solamente, para ello se utiliza el comando GRANT.


16/17

GRANTotorga privilegios de acceso a un usuario, un grupo o a todos los usuarios.

GRANTprivilege[, ...] ON object[, ...]

TO { PUBLIC | GROUPgroup| username}

Entradas

privilege

Los posibles privilegios son:

SELECTAcceso a todas las columnas de una tabla/vista especfica.

INSERTInserta datos en todas las columnas de una tabla especfica.

UPDATEActualiza todas las columnas de una tabal especfica.

DELETEElimina filas de una tabla especfica.

RULEDefine las reglas de la tabla(vista (cer sentencia CREATE RULE).

ALLOtorga todos los privilegios-

object

El nombre de un objeto al que se quiere conceder el acceso. Los posibles objetos son:

tabla vista secuencia indice

PUBLIC

Una abreviacin para representar a todos los usuarios.

GROUP group

Ungrupoal que se otorgan privilegios. En la actual versin, el grupo debe haber sidocreado explcitamente como se menciona ms adelante.

username

El nombre de un usuario al que se quiere conceder privilegios. PUBLIC es unaabreviatura para representar a todos los usuarios.


17/17

Documents

Instalacion de Posgresql Manual