Your SlideShare is downloading. ×
Administracion basica pgsql(administracion de bdd)
Administracion basica pgsql(administracion de bdd)
Administracion basica pgsql(administracion de bdd)
Administracion basica pgsql(administracion de bdd)
Administracion basica pgsql(administracion de bdd)
Administracion basica pgsql(administracion de bdd)
Administracion basica pgsql(administracion de bdd)
Administracion basica pgsql(administracion de bdd)
Administracion basica pgsql(administracion de bdd)
Administracion basica pgsql(administracion de bdd)
Administracion basica pgsql(administracion de bdd)
Administracion basica pgsql(administracion de bdd)
Administracion basica pgsql(administracion de bdd)
Administracion basica pgsql(administracion de bdd)
Administracion basica pgsql(administracion de bdd)
Administracion basica pgsql(administracion de bdd)
Administracion basica pgsql(administracion de bdd)
Administracion basica pgsql(administracion de bdd)
Administracion basica pgsql(administracion de bdd)
Administracion basica pgsql(administracion de bdd)
Administracion basica pgsql(administracion de bdd)
Administracion basica pgsql(administracion de bdd)
Administracion basica pgsql(administracion de bdd)
Administracion basica pgsql(administracion de bdd)
Administracion basica pgsql(administracion de bdd)
Administracion basica pgsql(administracion de bdd)
Administracion basica pgsql(administracion de bdd)
Administracion basica pgsql(administracion de bdd)
Administracion basica pgsql(administracion de bdd)
Administracion basica pgsql(administracion de bdd)
Administracion basica pgsql(administracion de bdd)
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Administracion basica pgsql(administracion de bdd)

2,800

Published on

Published in: Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,800
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
149
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Curso de administracion de PostgreSQL INCOP - Marzo 2010 Jaime Alberto Casanova Merchán Email: jcasanov@systemguards.com.ec
  • 2. Índice de contenidoConceptos básicos y estructura interna.................................................................................................4 El proceso Postmaster .....................................................................................................................4 La memoria compartida ..................................................................................................................4 WAL: Write-Ahead Log ..................................................................................................................4 ¿Qué es? .....................................................................................................................................4 WAL: Principios de diseño ........................................................................................................5 ¿Qué es un registro de WAL?......................................................................................................5 Consideraciones sobre el WAL ..................................................................................................5 Checkpoints ................................................................................................................................5 Estructura del WAL ....................................................................................................................6 Nombres de los archivos del WAL .............................................................................................6 Detectando el final del WAL ......................................................................................................6 MVCC: Multi Version Concurrency Control ..................................................................................7 ¿Qué es? .....................................................................................................................................7 Beneficios de MVCC .................................................................................................................7 Implementación ..........................................................................................................................7 Consideraciones sobre MVCC....................................................................................................9 Tareas de mantenimiento ..............................................................................................................10 VACUUM.................................................................................................................................10 VACUUM FULL ......................................................................................................................10 Alternativas a VACUUM FULL ..............................................................................................10 CLUSTER ...........................................................................................................................11 ALTER TABLE / SET TYPE ..............................................................................................11 ANALYZE................................................................................................................................11 REINDEX ................................................................................................................................11 Autovacuum .............................................................................................................................11 Concepto de “Cluster de bases de datos” en PostgreSQL.............................................................12 Jerarquía de Objetos a nivel lógico...........................................................................................12Instalando PostgreSQL ......................................................................................................................14 Instalando desde los fuentes..........................................................................................................14 Requisitos .................................................................................................................................14 Procedimiento de instalación....................................................................................................14 Crear el usuario postgres......................................................................................................15 ./configure.............................................................................................................................15 make ....................................................................................................................................15 make install...........................................................................................................................15 initdb.....................................................................................................................................16 Instalación desde repositorios........................................................................................................16 Procedimiento instalación.........................................................................................................16 Instalación desde el instalador.......................................................................................................17 Procedimiento instalación.........................................................................................................17 Actualización.................................................................................................................................17 Versiones menores.....................................................................................................................17 Versiones mayores.....................................................................................................................17 Estructura física.............................................................................................................................17 Archivos ...................................................................................................................................18 Directorios.................................................................................................................................18 -2-
  • 3. Aplicaciones instaladas..................................................................................................................19 Aplicaciones cliente..................................................................................................................19 Aplicaciones servidor................................................................................................................19 Módulos adicionales.................................................................................................................19 Si instalamos desde los fuentes............................................................................................20 Si instalamos desde los repositorios ....................................................................................20 Si instalamos desde el instalador .........................................................................................20Configuración del Servidor................................................................................................................21 Párametros del Kernel....................................................................................................................21 Consideraciones sobre el Sistema de Discos.................................................................................21 Archivos de configuración de PostgreSQL...................................................................................21 postgresql.conf..........................................................................................................................21 Ubicación de ficheros ..........................................................................................................21 Conexión .............................................................................................................................21 Seguridad y autenticado ......................................................................................................22 TCP Keepalives....................................................................................................................22 Uso de recursos : Memoria ..................................................................................................22 Uso de recursos del kernel ...................................................................................................23 Retraso del vacuum basado en costo....................................................................................23 Configuración del proceso bgwriter.....................................................................................23 Comportamiento asincrónico...............................................................................................23 Write Ahead Log..................................................................................................................23 Checkpoints .........................................................................................................................24 Archivado del WAL..............................................................................................................24 Método de planificación y optimización .............................................................................25 Constantes de costeo para la planeación..............................................................................25 GEQO (Genetic Query Optimizer) ......................................................................................25 Otras opciones para la planeación........................................................................................26 Configuración del log...........................................................................................................26 Estadísticas ..........................................................................................................................28 Autovacuum ........................................................................................................................28 Predeterminados para las conexiones cliente ......................................................................29 Localización y formato ........................................................................................................29 Gestión de Bloqueos ............................................................................................................29 Compatibilidad con versiones anteriores de PostgreSQL....................................................30 Compatibilidad con otras plataformas y clientes.................................................................30 Opciones especiales..............................................................................................................30 pg_hba.conf...............................................................................................................................30 -3-
  • 4. Conceptos básicos y estructura internaEl proceso Postmaster • es el proceso inicial • gestiona los accesos multiusuario y multiconexión • levanta la memoria compartida • está al tanto de solicitudes de nuevas conexiones • lanza procesos de atención de demanda, realizando las operaciones sobre la base de datos a solicitud de los clientes • realiza el enlazado con los archivos de datos, gestionando estos ficheros, donde los ficheros pueden pertenecer a varias bases de datosLa comunicación entre BackEnd/FrontEnd se realiza mediante TCP/IP, normalmente por el puerto5432, creando un socket (/tmp/.s.PGSQL.5432).La memoria compartida • gestiona los recursos entre procesos backend • gestiona la caché del disco • maneja otras estructuras internasDe esta manera podemos definir el concepto de CLUSTER DE BASE DE DATOS, como unainstancia de PostgreSQL, donde se lanza un proceso postmaster, que puede gestionar varias basesde datos. En un servidor, pueden haber varios cluster, cada uno tendrá su postmaster, y cadapostmaster escuchará por un puerto diferente.No confundir este concepto de “cluster” con los típicos que se manejan en bases de datos de“base de datos en cluster” o “tablas en cluster”.WAL: Write-Ahead Log¿Qué es?Siglas: Write Ahead LogEs un log de escritura adelantada, también conocido como log transaccional o REDO log por otrosgestores de bases de datos; en el que se graban todos los cambios efectuados a las páginas de datosantes de efectuar tales cambios. Puesto que solo este log es necesario para garantizar que loscambios permaneceran aun en el caso de caída del servidor también se reduce la cantidad deescrituras a disco aumentando así el rendimiento.El WAL es la base para lograr respaldos incrementales, recuperación hasta un punto en el tiempo(PITR) y una técnica de alta disponibilidad conocida como Warm Standby. -4-
  • 5. WAL: Principios de diseñoEl log de transacciones consiste en una serie de registros de log los cuales describen los cambiosque se están realizando a la base de datos y por lo tanto debe existir un registro de log por cadacambio realizado.El registro en el WAL de una operación siempre se escribe primero que las páginas de los datosafectados, esto asegurá que los cambios permanecerán aun cuando el servidor por algún motivodejará de funcionar abruptamente.En caso de que el servidor tenga una caída, se reconstruyen las transacciones comprometidas(aquellas en las que se ha hecho COMMIT), y que aún no se hayan escrito en las páginas de losdatos, leyendo desde el WAL¿Qué es un registro de WAL?Lleva los detalles de la operación a realizar (ej: que tipo de operación es, en que base de datos, enque tabla o índice en que página de disco, información de estado del snapshot de la transacción, laposición del registro de WAL anterior, etc...).Ejemplo:INSERT INTO foo VALUES (1234, ’foobar’);insert: ts 1663 db 11564 rel 16389 block 0 off 2header: t_infomask2 2 t_infomask 2050 t_hoff 240/004F8E14: prv 0/004F8DD0; xid 655; BTREE info 00 len 30 tot_len 58insert_leaf: index 1663/11564/16395 tid 1/10/004F8E50: prv 0/004F8E14; xid 655; XACT info 00 len 24 tot_len 52commit: 655 at 1979-10-31 18:02:49 EETConsideraciones sobre el WALSi está en el WAL está seguro, es decir que podrá recuperarse de una caída del servidor sin perdidade datos... • a menos que se dañe el disco • o que no vaya al disco en el orden correcto, en este caso habrá corrupción de datos. ◦ Esto último puede ocurrir si hemos desactivado el parámetro fsync en el postgresql.conf ◦ O si tenemos activo el cache de escritura en el disco (entonces el disco decidirá cuando grabar cada cosa y puede no ser el orden que esperabamos).Cosas que no van al WAL • tablas temporales • índices hash, para recuperar un índice hash despues de una caída de servidor es necesario usar el comando REINDEX.Se escribe en disco dos veces: primero al WAL y luego a las páginas de datos, aunque no al mismotiempo; por eso es recomendable poner el directorio del WAL en otro disco.El WAL no se puede apagar, y aunque se pudiera no sería deseable hacer tal cosa pues se perderíala habilidad de recuperarse de caídas del servidor.CheckpointsEl WAL crea tantos archivos como necesite, por eso a menos que se reutilicen los archivos viejospodría crecer indefinidamente . -5-
  • 6. Para evitar que lleguen a ocupar demasiado espacio en disco están los checkpoints que se encargande sincronizar los cambios registrados en el WAL a las páginas de disco de las tablas e índices.Un checkpoint realiza las siguientes operaciones: 1. Sincroniza todos los cambios en las páginas de datos al disco 2. Escribe en WAL un registro de checkpoint 3. Borra los WAL viejosUn checkpoint en modo de recuperación, es decir el que se ejecuta al inciar el servidor, realiza losiguiente: 1. Determina el punto de inicio de recuperación en el WAL es decir, qué transacciones que están comprometidas aún no se han sincronizado a las páginas de los datos ◦ pg_control 2. Sincroniza todos los cambios en las páginas de datos al disco 3. Escribe en WAL un registro de checkpoint 4. Borra los WAL viejosEstructura del WALEl WAL esta dividido en segmentos. Cada segmento es un archivo en el directorio$PGDATA/pg_xlog, generalmente de 16MB cada uno (configurable en tiempo de compilación).$ ls -ltotal 131236-rw------- 1 postgres postgres 16777216 nov 18 21:09 000000010000000000000041-rw------- 1 postgres postgres 16777216 nov 9 17:12 000000010000000000000042-rw------- 1 postgres postgres 16777216 nov 9 17:12 000000010000000000000043-rw------- 1 postgres postgres 16777216 nov 9 17:12 000000010000000000000044-rw------- 1 postgres postgres 16777216 nov 9 17:13 000000010000000000000045-rw------- 1 postgres postgres 16777216 nov 9 17:13 000000010000000000000046-rw------- 1 postgres postgres 16777216 nov 9 17:13 000000010000000000000047-rw------- 1 postgres postgres 16777216 nov 9 17:13 000000010000000000000048drwx--S--- 2 postgres postgres 4096 nov 9 17:08 archive_statusNombres de los archivos del WALEl nombre de los segmentos del WAL consta de 3 partes :Usemos el siguiente nombre de un segmento de WAL para nuestro ejemplo:000000010000000000000048 1. Los primeros 8 dígitos (contando de izquierda a derecha), indican el id de la línea de tiempo del registro. ◦ El id de la linea de tiempo se usa para distinguir segmentos de WAL generados antes y despues de una recuperacion PITR. 2. Los siguientes 8 dígitos (contando de izquierda a derecha), indican el id del log 3. Los ultimos 8 dígitos (contando de izquierda a derecha), indican el id (secuencial) del segmentoLos últimos 16 dígitos en conjunto conforman la primera parte del LSN .Detectando el final del WAL¿Como se determina donde termina el WAL, de forma que no se intente sincronizar basura? Cadaregistro tiene un puntero que apunta al registro anterior en la cadena si no coinciden, hemos llegadoal final del WAL -6-
  • 7. MVCC: Multi Version Concurrency Control¿Qué es?Siglas: Multi Version Concurrency ControlEs una técnica para el control de acceso simultáneo (concurrencia) a traves de la gestión demúltiples versiones de un mismo registro (tuplas).Mediante el uso de MVCC, PostgreSQL evita el problema de que procesos lectores estén esperandoa que se termine de escribir. En su lugar, PostgreSQL mantiene una ruta a todas las transaccionesrealizadas por los usuarios de la base de datos. PostgreSQL es capaz entonces de manejar losregistros sin necesidad de que los usuarios tengan que esperar a que los registros estén disponibles.La idea básica es evitar al máximo los bloqueos, así usando MVCC logramos que: • Una lectura no bloquee a otra lectura • Una escritura no bloquee a una lectura • Una escritura no bloquee a otra escritura ◦ a menos que deban escribir el mismo registroBeneficios de MVCC • Flexibilizar el acceso a los datos gracias a los candados ligeros , postgres siempre toma algún tipo de bloqueo pero siempre es el mínimo necesario. • Facilita la vida de los desarrolladores puesto que se reduce la necesidad de gestionar manualmente los bloqueos. • Permite tener niveles de “aislamiento” en la transacción, esto es que cada transacción ve datos de manera independiente y por lo tanto no es posible ver datos inconsistentes debido a cambios realizados por una transacción no finalizada.Implementación • Cada transacción que escribe datos en una tabla, tiene un identificador de transacción (xid) • Cada registro de las tabla contiene dos informaciones esenciales: ◦ Identificador de transacción (xid) que creó el registro (XMIN) ◦ Identificador de transacción (xid) que destruyó el registro (XMAX) • Cada proceso “ve” una imagen (snapshot) específica de la base de datos, esa imagen es guiada por los siguientes principios: ◦ ve las tuplas (una versión de un registro) cuyo identificador de creación sea inferior al identificador de la transacción del proceso ◦ y cuyo identificador de destrucción sea mayor al identificador de la transacción del proceso ◦ y evidentemente, a condición de que la transacción de creación y destrucción de la tupla sean válidas ◦ además debe comparar los identificadores de creación y destrucción con el conjunto de identificadores de transacción de otros procesos que estaban en curso al momento de iniciar la transacción -7-
  • 8. Veamos un ejemplo:-- creamos una tablaCREATE TABLE t1 ( i integer, t text);-- Insertamos algunos registros, 3 para empezarINSERT INTO t1 VALUES (1, ’uno’), (2, ’dos’), (3, ’tres’);-- Verificamos su existencia con un SELECTSELECT * FROM t1; i t1 uno2 dos 3 tres(3 filas)De forma automática se insertan además unos campos especiales en todos los registros, estoscampos no son visibles normalmente a menos que pidamos que nos los muestre; por ejemplo: • xmin: Identificador de la transacción que creó el registro • xmax: Identificador de la transacción que destruyó el registro • ctid: Posición física del registro en la tablaSELECT xmin, xmax, ctid, * FROM t1xmin xmax ctid i t1078 0 (0,1) 1 uno1078 0 (0,2) 2 dos 1078 0 (0,3) 3 tres(3 filas)Actualicemos un registro :UPDATE t1 SET t = upper(t) WHERE i = 2;SELECT xmin, xmax, ctid, * FROM t1xmin xmax ctid i t1078 0 (0,1) 1 uno1078 0 (0,3) 3 tres 1079 0 (0,4) 2 DOS(3 filas)¿Qué ha pasado? • La línea de ctid (0,2) está “muerta” y por lo tanto no es visible cuando ejecutamos el SELECT • La nueva versión está en ctid (0,4)Volvamos a actualizarUPDATE t1 SET t = upper(t) WHERE i = 2;SELECT xmin, xmax, ctid, * FROM t1 -8-
  • 9. xmin xmax ctid i t1078 0 (0,1) 1 uno1078 0 (0,3) 3 tres 1080 0 (0,5) 2 DOS(3 filas) • PostgreSQL crea una nueva copia del registro aun cuando la actualización no causo ningún cambio visible ◦ Tenemos una tupla viva distinta ◦ Tenemos una nueva tupla muerta¿Y si insertamos un nuevo registro?INSERT INTO t1 VALUES (4, ’cuatro’); ¿En qué posición lo guardará? En la posición 2? En la posición 4? En la posición 6?xmin xmax ctid i t1078 0 (0,1) 1 uno1078 0 (0,3) 3 tres1080 0 (0,5) 2 DOS 1081 0 (0,6) 4 cuatro(4 filas)Consideraciones sobre MVCCLas actualizaciones en una tabla dejan registros muertos que abultan la tabla y causanfragmentación • el problema es cuando esa fragmentación obliga a crear nuevas páginas en disco, si la fragmentación ocurre dentro de una misma páginas es manejable ◦ para lograr que la fragmentación ocurra dentro de la misma página podemos usar la cláusula FILLFACTOR (por omisión: 100% para tablas y 90% para índices) • porque causa que las lecturas secuenciales se vuelvan más lentas ◦ De ahí la pérdida de rendimientoEl espacio muerto no se reutiliza de forma automática. • Para recuperar el espacio muerto de una tabla es necesario ejecutar la orden VACUUM ◦ VACUUM lee secuencialmente toda la tabla ▪ a partir de la versión 8.4 sólo lee aquellas páginas que fueron modificadas desde la última vez que se ejecutó VACUUM ▪ VACUUM completo es obligatorio si la tabla excede de vacuum_freeze_table_age ◦ Verifica para cada registro, si aún está vivo para alguna transacción en curso ▪ Si no lo está, compacta el espacio y registra el espacio libre de la página en una estructura llamada FSM (Free Space Map o “Mapa de espacio libre”)Para versiones anteriores a 8.4:El FSM era una estructura en memoria compartida de tamaño fijo y controlada por los parámetros: • max_fsm_relations -9-
  • 10. • max_fsm_pagesDe 8.4 en adelante:El FSM es una estructura en disco que puede crecer automáticamente para ajustarse a la tabla y yano necesita administración manual a través de los parámetros max_fsm_*Al ejecutar VACUUM el tamaño de la tabla no cambia o lo hace muy poco; para realmente reducirel tamaño al mínimo debe usarse VACUUM FULL .Aún así no se recomienda el uso de VACUUM FULL por que bloquea cualquier operación sobre latabla (incluso lecturas) y degrada el rendimiento de los índices .Sin embargo, es útil en algunos casos ; por ejemplo cuando hay muchos registros borrados de golpeo cuando uno ha estado usando la BD mucho tiempo con el FSM mal configurado .MVCC tiene muchas ventajas al permitir la mejor concurrencia posible sin causar conflictos, perotambien tiene inconvenientes que pueden ser disminuidos mediante el correcto uso de: • VACUUM • FILLFACTOR para controlar la fragmentación • y algunos algoritmos internos de reutilización de espacio como: HOT (Heap Only Tuples)Tareas de mantenimientoEs posible mejorar el rendimiento de las tareas de mantenimiento aumentando el valor demaintenance_work_memVACUUM • Se encarga de: ◦ Eliminar registros obsoletos ◦ Compactar el espacio disponible ◦ Registrar cuánto espacio libre hay en esa página en el FSM ◦ Lleva en memoria las direcciones de las tuplas que se eliminaron ◦ Recorrer todos y cada uno de los índices de la tabla para eliminar entradas que hubieran estado apuntando a registros muertos • No requiere bloquear la tabla por lo que operaciones de escritura podrían ocurrir concurrentementeVACUUM FULL • Forma más antigua de VACUUM • No deja ningún espacio libre en las páginas • Operación posterior necesita extender la tabla • Desventajas ◦ Requiere bloquear totalmente la tabla ◦ los índices quedan en mal estado ◦ es muy lentoAlternativas a VACUUM FULLVeamos dos alternativas viables a VACUUM FULL, ambos requieren candados exclusivos igual -10-
  • 11. que VACUUM FULL pero son más rápidos .CLUSTER • Reordena una tabla según un índice especificado • Reescribe toda la tabla y todos sus índices • Elimina todo el espacio muerto • Desventaja: es muy lento si los datos no están ordenados por el índiceALTER TABLE / SET TYPE • Esta sentencia cambia el tipo de dato de una columna, pero si específicamos que cambie al mismo tipo de dato que ya tenía la columna en ese caso funcionará igual que CLUSTER pero no reordena rá la tablaANALYZE • PostgreSQL tiene un optimizador de consultas basado en costo; de modo que para cada consulta se busca el mecanismo de ejecución más eficiente, es decir el que “cueste” menos. ◦ El costo total de cada posible plan de ejecución se estima usando ecuaciones de costo y estadísticas recolectadas de los datos presentes en las tablas ◦ Las estadísticas se obtienen usando el comando ANALYZE ◦ A veces usado como opción en VACUUM . Ej: VACUUM ANALYZE • Si las estadísticas no están ajustadas a la realidad, pueden pasar cosas raras • Sobre todo, que los planes de ejecución sean subóptimos (consultas lentas)REINDEX • Reescribe los índices de una tabla • Útil cuando los índices se salen de manos • No debería usarse con periodicidad ◦ sólo para casos patológicosAutovacuumCon el objetivo de lograr un sistema libre de administración es posible automatizar VACUUM yANALIZE (que son las tareas mas importantes y deberían ejecutarse periodicamente), para estoexiste un proceso llamado: Autovacuum (desde la versión 8.1 este proceso esta integrado en la basede datos, antes de eso se lo podía encontrar como un modulo adicional). • Desde la versión 8.1 es un daemon manejado internamente por el postmaster y configurable desde el archivo postgresql.conf • Es importante configurarlo adecuadamente para que entre en acción a tiempo ◦ a partir de la versión 8.3 hay múltiples trabajos autovacuum concurrentes • Nunca ejecuta tareas bloqueantes ◦ y si lo hiciera desde la versión 8.3: se suicida para prevenir bloqueosTambién es posible configurar el autovacuum por tablas, esto es útil cuando tenemos tablas muygrandes o con mucho tráfico:en las versiones 8.1 hasta 8.3, se lo logra usando el catalogo de sistema pg_autovacuum. Ej: -11-
  • 12. INSERT INTO pg_autovacuum VALUES (’nombre_tabla’::regclass, ’f’, -1, -1, -1, ...); • los -1 indican que se usará el valor por omisión. • ¡no usar 0!Desde la versión 8.4, se usa una sentencia ALTER TABLE. Ej:ALTER TABLE ...SET (autovacuum_enable = false, autovacuum_vacuum_scale_factor = 0.05);Concepto de “Cluster de bases de datos” en PostgreSQLRepositorio que engloba un conjunto de bases de datos, que contienen objetos que se puedenguardar en distintos tablespaces y un conjunto de usuarios que se conectan al cluster. • Una base de datos engloba un conjunto de esquemas, los cuales tienen un usuario propietario. ◦ En los esquemas es donde se crean los objetos (tablas, índices, procedimientos, vistas, etc.)Con lo que tenemos aquí los elementos principales a nivel lógico en un cluster: • Bases de datos: agrupaciones de esquemas. Por defecto, siempre hay tres bases de datos creadas, template0, template1 y postgres. • Esquemas: Es una agrupación lógica dentro de una base de datos. Para separar objetos organizandolos por usuario, o aplicativo o cualquier otra organización que consideremos oportuna. • Tablespaces: ubicaciones alternativas a la que por defecto tiene el cluster. Por defecto no se crea ninguno. • Roles: engloba el concepto de usuarios (roles de login) y grupos de permisos (roles de grupo). Hasta la versión 8 de Postgres no se podían anidar roles, ahora si. Por defecto, si al crear el cluster no se ha indicado otro usuario, se crea el usuario postgres como superusuario.Hay que tener en cuenta: • Todos los usuarios son comunes a las bases de datos del cluster, se pueden conectar con cualquiera de las bases de datos. • Las bases de datos son independientes entre ellas, no se pueden ver objetos de una base de datos desde otra base de datos, excepto si se usan módulos externos como dblink o dbi-link. Entonces una organización recomendable pudiera ser: ◦ si es un servidor que acoge proyectos separados y no se han de interrelacionar: ▪ separación en bases de datos distintas. ◦ si es un servidor de proyectos con recursos comunes: una única base de datos y distintos ▪ esquemas para cada proyecto.Jerarquía de Objetos a nivel lógicoVeamos aquí una breve descripción de los objetos tal como salen en el pgAdmin3: • Servidores ◦ Bases de datos (template0, template1 y postgres) ▪ Cast: conversiones entre tipos de datos ▪ Lenguajes : Lenguajes procedurales para la creación de funciones ▪ Esquemas • Agregados: definir funciones de agregación -12-
  • 13. • Conversiones: definir nuevas conversiones de codificación de caracteres • Dominios: crear dominios que se pueden usar en la definición de tablas • Funciones • Funciones disparadoras • Operadores • Operador de clases • Secuencias • Tablas • Tipos de datos • Vistas ▪ Replicación : En el pgAdmin3 esto hace referencia a un esquema especial en el que se crean los objetos para la replicación a través de Slony I◦ Tablespaces◦ Roles de grupo (roles)◦ Roles de login (usuarios) -13-
  • 14. Instalando PostgreSQLPostgreSQL se puede instalar en muchas plataformas, las más conocidas Windows y Linux, en estemanual vamos a ver cómo instalarlo en Linux.Podemos instalar desde: • Desde los fuentes • Usando un instalador (Cortesía de la empresa EnterpriseDB) • Desde los repositorios de nuestra distribución • Desde los repositorios oficiales de PostgreSQL (Cortesía de la empresa CommandPropmt)Los fuentes, el instalador y los repositorios oficiales los podemos encontrar enhttp://www.postgresql.orgInstalando desde los fuentesRequisitos • Compilador gcc • readline-devel • zlib-devel • openssl (solo si queremos que las conexiones usen SSL) • libxml2-devel (solo si queremos instalar con soporte para XML) • gettext (solo si se quiere NLS)Procedimiento de instalación • Crear el usuario postgres (como root) • ./configure • make • make install (como root) • chown -R postgres.postgres /ruta/instalacion (como root) • cd /ruta/instalacion • bin/initdb -D /ruta/carpeta/data • cp contrib/start-scripts/linux /etc/init.d/postgresql • Crear los enlaces en las carpetas de arranque apropiadas ◦ ln -s /etc/init.d/postgresql S98pgsql ◦ o usar: chkconfig --add postgresqlEste método tiene como inconveniente la dificultad de implantación, ya que requiere que elinstalador se plantee una serie de requerimientos, así como se deben realizar operaciones querequieren estar famililiarizados con el sistema operativo, aunque en la documentación explican pasoa paso todo lo que hay que hacer.Las ventajas, en cambio, son muchas: • instalación controlada totalmente • fijamos la ubicación de todos los directorios y ficheros, tanto los del programa como los de los datos. -14-
  • 15. • podemos instalar características opcionales: soporte extendido para tipos de datos, soporte nativo de idiomas, etc. • podemos instalar paquetes opcionales: tcl/tk, python, java, perl, PAM, OpenSSL, etc. • total flexibilidad para configurar a gusto del administrador.Crear el usuario postgresPara crear el usuario dueño de la instalación de la base de datos (usualmente postgres), ejecutamosla siguiente orden como root:adduser --home /home/postgres postgres./configureLuego debemos configurar los fuentes para que se ajusten a la arquiterctura de nuestro servidor asícomo para que se adapte a, o para que nos diga que no podemos instalar debido a, las versiones delas herramientas que estemos usando. También aprovechamos esta opción para forzar ciertasopciones (para ver todas las opciones disponibles usamos ./configure --help)../configure [opciones]Algunas opciones son:--prefix=/ruta/donde/se/instalará/postgres--with-pgport=5432--enable-nls[=lenguaje] (ejemplo: es)--with-perl--with-python--with-krb5--with-ldap--with-openssl--with-libxml--with-blocksize=Tamaño de una pagina de disco en kb--with-segsize=Tamaño máximo de un archivo en GB (cuando postgres alcanza este tamaño de archivo crea uno nuevo para seguir almacenando los datos de la tabla)--with-wal-blocksize=Tamaño de una página de disco para el WAL en kb--with-wal-segsize=Tamaño cada archivo (segmento) del WAL en MbmakeCompila los binarios de PostgreSQL, usando la información de configuración que le hemos dado.Una vez terminada la compilación podemos verificar que todo esté bien usando la orden makecheck, comando con el cual se realizará una serie de pruebas para verificar que todas lascaracterísticas de postgres esten funcionando apropiadamente.make installCon esta orden se creará la carpeta en la que se va a instalar postgres (la que indicamos en la opción./configure --prefix o /usr/local/pgsql sino indicamos nada).Esta orden debe ejecutarse con permisos de root si la carpeta en la que se instalará postgres no estadisponible para este usuario debido a permisos de escritura. Luego deberemos darle tales permisosal usuario postgres sobre la carpeta que se cree.Eso lo hacemos mediante la orden: chown -R postgres.postgres /ruta/instalacion -15-
  • 16. initdbDespués de instalar PostgreSQL, lo primero que hay que realizar en la creación de un cluster,teniendo en cuenta que en un servidor, se pueden crear todos los cluster que se quiera siempre queescuchen por puertos distintos.initdb [opciones]Algunas opciones son:-D directorio | --pgdata=directorio: directorio donde se crea el cluster, si no se indica, usa loque establezca la variable de entorno PGDATA-E juego_caracteres | --encoding=juego_caracteres: si no se indica, usa el del SO--locale=ubicación: ubicación geográfica, se puede concretar más:--lc-collate = ubicación: ordenamiento--lc_ctype = ubicación: clasificación de caracteres--lc_messages = ubicación: mensajes (se puede cambiar luego)--lc-monetary = locale (se puede cambiar luego)--lc-numeric = locale (se puede cambiar luego)--lc-time = locale (se puede cambiar luego)-U usuario | --username=usuario: superusuario del cluster-W | --pwprompt: pide una contraseña que se establecerá para el nuevo superusuarioInstalación desde repositoriosLa instalación a partir de los repositorios de una distribución determinada tiene sus ventajas einconvenientes:Ventajas: • Facilidad de implantación, los archivos van a directorios predeterminados. Es un buen método para tener instalado PostgreSQL con poco esfuerzo y ponerse a practicar. • Se crea automáticamente toda la infraestructura de funcionamiento, el usuario del sistema operativo, los programas de arranque y parada en el init.d, etc. • Crea una instancia de base de datos, cluster. • Incluso en algunas distribuciones , viene como una opción más que se puede instalar.Inconvenientes: • Poca flexibilidad, no podemos elegir en qué directorios instalar, aunque suele ser suficiente • No suelen venir las últimas versiones en el caso de que vengan suministrados por la distribución, aunque probablemente en la web de PostgreSQL o en la de la distribución ya tengan el paquete preparado para la última versión.Procedimiento instalación • yum install postgresql-* ◦ Donde postgresql-* representa a uno o varios paquetes que podemos instalar ▪ Podemos ver que paquetes hay disponibles para instalar con: yum search postgresqlTambién podemos usar los repositorios propios de postgres (con paquetes para centos, fedora y -16-
  • 17. redhat) • Descargar el archivo apropiado desde: http://yum.pgsqlrpms.org • rpm -ivh archivo_descargado • Instalar postgres usando yum ◦ yum install postgresql-* ◦ Donde postgresql-* representa a uno o varios paquetes que podemos instalar ▪ Podemos ver que paquetes hay disponibles para instalar con: yum search postgresqlInstalación desde el instaladorTiene las misma ventajas que instalar desde el repositorio pero sin los inconvenientes (aunque no estan flexible como instalar desde los fuentes suele ser suficiente). Además el instalador incluye unaherramienta llamada Stack Builder que nos permite descargar e instalar algunos módulos yherramientas adicionales.Procedimiento instalación • Descargar el instalador apropiado para nuestro SO desde http://www.postgresql.org • ejcutar en una ventana de terminal como root: ./nombre_instalador ◦ A partir de ahí seguiremos las indicaciones del instalador, generalmente será cuestion de solo presionar siguiente hasta el final.ActualizaciónVersiones menoresSon aquellas en las que solo cambio el último número de la versión, por ejemplo 8.4.1 y 8.4.2 sonversiones menores de la versión 8.4.En este caso solo es necesario re-compilar e instalar los binarios en el mismo directorio donde seinstalarón originalmente y reiniciar el servicio de PostgreSQL. Debemos tener cuidado de usar lasmismas opciones en ./configure, podemos saber que opciones usamos originalmente con elcomando pg_config.Versiones mayoresSon aquellas en las que cambia el primer y/o segundo dígito de la versión, por ejemplo: 8.3 y 8.4son versiones mayores diferentes.Para actualizar a versiones mayores es necesario sacar un respaldo de los datos, reinstalarreinicializar el directorio de instalacion usando el initdb de la nueva versión y restaurar los datos.Estructura físicaLuego de inicializar el cluster (esto lo hacen automaticamente los paquetes y el instalador y lohacemos manualmente mediante la orden “initdb”), se crean una serie de directorios y archivosdentro de la carpeta data (que usualmente la llamaremos: $PGDATA). -17-
  • 18. Archivos • postgresql.conf: fichero de configuración principal, contiene la asignación a los parámetros que configuran el funcionamiento global del servidor. • pg_hba.conf: fichero de configuración de la autenticación de los clientes y usuarios y del acceso a las bases de datos del cluster. • pg_ident.conf: fichero accesorio al anterior, determina como se realiza la autenticación ident que contiene la correspondencia entre usuarios del Sistema Operativo y de PostgreSQL. • PG_VERSION: fichero de texto con la versión de software Postgres que crea el cluster . • Otros archivos: ◦ postmaster.pid: se crea cuando el postmaster arranca, contiene el PID del proceso postmaster. ◦ postmaster.opts. contiene las opciones con las que se ha iniciado el postmaster. ◦ recovery.conf, recovery.done: si se quiere o se ha hecho una recuperación.Directorios • base: las plantillas y las bases de datos. contiene un directorio por cada base de datos, dentro hay un fichero por cada tabla o índice de una base de datos, los números corresponden a los OIDs de las tablas o índices. ◦ template0: contiene las definiciones de las tablas del sistema, vistas, funciones y tipos estándar. Nunca se debe modificar ni intentar conectarse a ella, ya que está por si template1 se corrompe. ◦ template1: base de datos plantilla para crear nuevas bases de datos, se puede modificar su estructura, añadiendo tablas, índices, funciones, etc. Es la que se usará como plantilla para crear otras bases de datos. ◦ postgres: una base de datos administrativa. • global: tablas e indices del catálogo comunes a todas las bases de datos. ◦ catálogo compartido: pg_auth (autorizaciones), pg_database, etc. ◦ pgstat.stat: fichero usado por el monitor de estadísticas. ◦ pg_control: fichero con parámetros del cluster, algunos inmutables (establecidos en la creación del cluster) y otros variables (establecidos en la puesta en marcha). • pg_log: archivos de log entendible por humanos. • pg_xlog: archivos de log transaccional (WAL). • pg_clog: archivo de estado para las transacciones (estado de cada transacción). ◦ El estado de una transacción puede ser: confirmada, en progreso o abortada. • pg_multixact: contiene datos sobre el estado multi-transaccional, usado para los bloqueos compartidos de filas. • pg_twophase: ficheros de estado para las transacciones preparadas. Se usa en COMMIT en dos fases. • pg_subtrans: para realizar los “savepoints” en medio de transacciones. • pg_tblspc: información sobre los tablespaces. Enlaces a los directorios donde esta montado el tablespace. • pg_stat_tmp: Contiene temporalmente las estadísticas que se recojen en tiempo de ejecución que luego se escriben a los catálogos del sistema. -18-
  • 19. Aplicaciones instaladasAplicaciones cliente • clusterdb: equivalente al comando CLUSTER de SQL, reorganiza cluster de tablas. • createdb: crea una base de datos. • createlang: define un nuevo lenguaje procedural en una base de datos. • createuser: creación de usuarios. • dropdb: borrar una base de datos. • droplang: borrar un lenguaje procedural. • dropuser: borrar un usuario. • ecpg: SQL C preprocesador embebido. • pg_config: recupera información sobre la versión instalada de PostgreSQL. • pg_dump: extrae una base de datos en un fichero script o en otros formatos. • pg_dumpall: extrae un cluster de base de datos en un fichero script. • pg_restore: restaura una base de datos desde un fichero creado con pg_dump (siempre que no sea texto plano). • psql: terminal interactivo de PostgreSQL. Es la herramienta canónica para la ejecución de sentencias SQL a través del shell del SO Es una herramienta de tipo frontend que permite describir sentencias SQL, ejecutarlas y visualizar sus resultados El método de ingreso puede ser mediante la inserción directa del código en la consola, o la ejecución de sentencias dentro de un archivo de texto Provee diversos meta-comandos para la ejecución de las sentencias, así como diversas opciones tipo shell propias de la herramienta • reindexdb: reindexa una base de datos. • vacuumdb: reorganiza y analiza una base de datos.Aplicaciones servidor • initdb: crea un cluster de base de datos. • pg_controldata: muestra información de control de un cluster de base de datos. • pg_ctl: inicia, para o reinicia un servidor PostgreSQL. • pg_resetxlog: reinicia el “write-ahead log” y otras informaciones de control de un cluster de base de datos. • postgres: Proceso postmaster principal • postmaster: enlace simbólico a la aplicación postgres, está solo para mantener compatibilidad con versiones anteriores.Módulos adicionalesLa distribución oficial de postgres viene con ciertos módulos adicionales que pueden ser útiles.Algunos módulos interesantes son:auto_explain Permite ejecutar EXPLAIN sobre las consultas que se están ejecutando en la base de datos de forma automáticacitext Tipo de dato text que no distingue entre mayúsculas y minúsculasdblink Permite conectarse con otras bases de datos postgresqlpgbench Se usa para pruebas de rendimiento simples -19-
  • 20. pg_standby Permite tener un servidor en modo de recuperación permanentestart-scripts Scripts de inicio para usar en varios SOPara instalarlos podemos seguir el siguiente procedimiento:Si instalamos desde los fuentes • Nos ubicamos en el directorio contrib de la distribución de postgres • pasamos a la carpeta del módulo que deseamos instalar • make • make install • Vea el archivo README de cada modulo para saber si requiere algún paso adicional para ese módulo en particular.Si instalamos desde los repositorios • Los módulos contrib se instalan ejecutando: yum install postgresql-contrib • Vea el archivo README de cada modulo para saber si requiere algún paso adicional para ese módulo en particular.Si instalamos desde el instalador • Vea el archivo README de cada modulo para saber si requiere algún paso adicional para ese módulo en particular. -20-
  • 21. Configuración del ServidorPárametros del KernelLa instalación de PostgreSQL requiere la comprobación de que el servidor será capaz de soportarlo.Normalmente, los valores por defecto en la mayoría de los párametros son suficientes, no asiSHMMAX que es demasiado bajo. Es tarea del administrador de sistemas cambiar los valores delos parámetros que sea necesario. Si el sistema no puede proporcionar los recursos que requiere elservidor, éste no se puede poner en marcha y devuelve un error.El únicos párametros que normalmente requieren cambios son: SHMMAX y OVERCOMMIT.Para cambiar los valores de estos párametros agregaremos las siguientes líneas en el archivo/etc/sysctl.conf y luego reiniciaremos el sistema:kernel.shmmax=<valor proporcionado por el mensaje de error cuando no quizo levantar>vm.overcommit_memory=2Consideraciones sobre el Sistema de DiscosPuesto que el sistema de discos es la parte mas lenta de todo sistema, se recomienda los siguientespuntos al configurar el servidor. • Configuración RAID ◦ En la comunidad se ha recomendado el nivel 10 • Apagar cache de escritura o usar battery backed array controllers • Distribución de los discos ◦ Poner el WAL ($PGDATADIR/pg_xlog) en un disco aparte ◦ Si es posible; disponer de discos separados para poner los datos, índices y archivos temporales.Archivos de configuración de PostgreSQLPostgreSQL tiene tres archivos de configuración, los cuales mencionamos cuando vimos losarchivos que crea postgresql en el cluster.postgresql.confUbicación de ficherosdata_directory = ‘ConfigDir’ ConfigDir representa $PGDATAhba_file = ConfigDir/pg_hba.conf fichero de configuración de autenticaciónident_file = ConfigDir/pg_ident.conf fichero de configuración de la autenticaciónexternal_pid_file = ‘(none)’ nombre del fichero pidConexiónlisten_adresses= localhost especifica las direcciones IP que el servidor debe escuchar desde aplicaciones cliente. Lista separada por comas, si está vacía no acepta conexiones por red, si es -21-
  • 22. ‘*’ acepta cualquier dirección.port = 5432 puerto TCP/IP donde escucha postmastermax_connections = 100 máximo de sesiones concurrentes (100)superuser_reserved_connections = 3 conexiones reservadas para superusuariosunix_socket_directory = indica donde se encuentran los socket del dominio local para las conexiones locales (/tmp)unix_socket_group = unix_socket_permissions = 0777 si ponemos 0700 solo dejamos conectar al usuario postgresbonjour_name = ‘’Seguridad y autenticadoauthentication_timeout = 1min tiempo máximo en segundos para completar el autenticado del clientessl = off si el postmaster negocia con clientes que usen conexiones sslssl_ciphers = ALL:!ADH:!LOW:!EXP:! Cifrados SSL permitidosMD5:@STRENGTHpassword_encryption = on cómo se almacena por defecto una palabra de paso (on, encriptada)db_user_namespace = off Vincula a los usuarios a una base de datos específicakrb_server_keyfile = configura el modo de usar el autenticado con Kerberoskrb_svrname = postgreskrb_caseins_users = offTCP Keepalivestcp_keepalives_idle = 0 controla si las conexiones siguen vivas,tcp_keepalives_interval = 0 para matarlas si no respondentcp_keepalives_count = 0Uso de recursos : Memoriashared_buffers = 32MB Tamaño de la memoria compartidatemp_buffers = 8MB Máximo de memoria a utilizar para buffers temporales que una sesión puede usar, se usan para acceder a las tablas temporalesmax_prepared_transactions = 0 número máximo de transacciones preparadas permitidas simultáneamente. Se recomienda que sean al menos igual a max_connections si se desean usarwork_mem = 1MB cantidad de memoria total que se usará para operaciones de ordenación y hash antes de usar -22-
  • 23. archivos temporales en discomaintenance_work_mem = 16MB cantidad máxima de memoria que se usará para operaciones de mantenimientomax_stack_depth = 2MB profundidad máxima de seguridad de la pila de ejecución del servidor (ver ulimit –s)Uso de recursos del kernelmax_files_per_process = 1000 no máximo de ficheros abiertos por cada proceso servidor. Si aparece el error en el SO de “too many files” reducir este valor o cambiar el kernelshared_preload_libraries = especifica las librerias compartidas que deben cargarse en la puesta en marcha del servidorRetraso del vacuum basado en costovacuum_cost_delay = 0ms tiempo en ms que se duerme el proceso vacuum cuando se ha excedido el vacuum_cost_limitvacuum_cost_page_hit = 1 coste estimado de limpiar un buffer del cache de BD, bloquear la pila del buffer, actualizar la tabla compartida hash, y escanear el contenido de la páginavacuum_cost_page_miss = 10 coste estimado en limpiar un buffer que tiene que ser leido del disco, bloquear la pila del buffer, actualizar la tabla compartida hash, leer el bloque desde disco y escanear el contenido de la páginavacuum_cost_page_dirty = 20 coste estimado cuando la limpieza modifica un buffer limpio dejándolo sucio. Trabajo extra de llevar el buffer a discovacuum_cost_limit = 200 coste acumulado que hace que el vacuum se pare momentáneamenteConfiguración del proceso bgwriterbgwriter_delay = 200ms tiempo en ms entre cada puesta en marcha del procesobgwriter_lru_maxpages = 100 no de buferes que serán escritos por el método de estar próximo su recicladobgwriter_lru_multiplier = 2.0 porcentaje de bufferes que están próximos su reciclado y escribe los que están suciosComportamiento asincrónicoeffective_io_concurrency = 1Write Ahead Logfsync = on determina si PostgreSQL debe forzar al SO a escribir en disco, jamas se debe apagar -23-
  • 24. synchronous_commit = onwal_sync_method = fsync método que usa el gestor WAL para forzar la escritura de los buffers en disco. Posibles valores: fsync, fdatasunc, open_sync, open_datasync, fsync_writethrough (de forma predeterminada usa el primero soportado por el SO)full_pages_writes = on establece si se copia el bloque entero al diario después de la primera modificación que sufra o no, después de un punto de verificación (por defecto está a on, para evitar problemas de corrupción de bloques).wal_buffers = 64kB cantidad de buffers para los diarios que forman la cache de la WALwal_writer_delay = 200mscommit_delay = 0 tiempo en microsegundos que espera el servidor para llevar las entradas del buffer de diario a los diarios después de que una transacción se confirme. Permite que otros procesos puedan aprovechar esta operación, es decir, que se haga un solo commit para varias transacciones.commit_siblings = 5 no mínimo de transacciones activas que debe de haber para que el gestor WAL se espere el tiempo indicado en commit_delayCheckpointscheckpoint_segments = 3 distancia máxima entre puntos de verificación automáticos, medida en no de ficheros. Los diarios están divididos en segmentos de 16Mb, cuando se han llenado el no de segmentos de este parámetro, se realiza un punto de verificación y así el sistema puede reutilizar los segmentoscheckpoint_timeout = 5min tiempo máximo entre la realización de un punto de verificación y el siguientecheckpoint_warning = 30s escribe un mensaje en el fichero de seguimiento si un punto de verificación se lanza antes del intervalo dado en este parámetro, si es 0 se deshabilita el warningcheckpoint_completion_target = 0.5 Factor para determinar la duración del checkpointArchivado del WALarchive_mode = offarchive_command = instrucción del SO que se debe ejecutar para archivar un segmento completado del WAL. Por ejemplo: ‘cp %p /mnt/archivedir/%f’ donde %p es el camino completo al fichero y %f el nombre -24-
  • 25. archive_timeout = 0 Fuerza el archivado pasado este tiempoMétodo de planificación y optimizaciónenable_bitmapscan = on habilita o deshabilita el uso de tipos de planes de escaneo en bitmapsenable_hashagg = on habilita o deshabilita el uso de tipos de planes de agregación por dispersiónenable_hashjoin = on habilita o deshabilita el uso de tipos de planes concatenaciónenable_indexscan = on habilita o deshabilita el uso de planes de recorrido en índiceenable_mergejoin = on habilita o deshabilita el uso de tipos de planes de concatenación por fusiónenable_nestloop = on habilita o deshabilita el uso de tipos de planes de concatenación de bucles anidadosenable_seqscan = on habilita o deshabilita el uso de tipos de planes de recorrido secuencial (full scan)enable_sort = on habilita o deshabilita el uso de pasos de ordenación explícitosenable_tidscan = on habilita o deshabilita el uso de planes del rastreo TID en el planificador. Se usa un rastreo TID cuando la pseudo- columna CTID aparece en un WHERE CTID es la localización física de una filaConstantes de costeo para la planeaciónseq_page_cost = 1.0random_page_cost = 4 indica el coste de cargar una página al azar en cache (4). Se supone que el coste de carga de una página secuencial es 1cpu_tuple_cost = 0.01 indica el coste de procesar una tupla en una página de datos (0.01)cpu_index_tuple_cost = 0.005 indica el coste de procesar una entrada en una página de índice (0.001)cpu_operator_cost = 0.0025 indica el coste de procesar un operador (0.0025)effective_cache_size = 128MB tamaño efectivo de la cache de disco disponible para realizar un rastreo con índice. Valor alto aumenta la probabilidad de rastreo con índice, en caso contrario, será secuencialGEQO (Genetic Query Optimizer)geqo = on PostgreSQL usa el optimizador genético cuando considera que es muy costoso hacer una planeación -25-
  • 26. exhaustiva.geqo_threshold = 12 indica el no de items en el FROM a partir del cual se debe usar GEQOgeqo_effort = 5 controla el compromiso entre el tiempo de planificación y la eficiencia del plan de ejecución (entero entre 1 y 10)geqo_pool_size = 0 indica el no de individuos de una población (al menos 2, valor típico entre 100 y 1000). Si es 0, el valor por defecto adecuado se elige en función de geqo_effortgeqo_generations = 0 indica el valor para las generaciones (iteraciones del algoritmo). Es un valor entero, si es 0 se calcula con la fórmula: geqo_effort*Log2(geqo_pool_size)geqo_selection_bias = 2.0 indica la presión selectiva dentro de la población (entre 1.5 y 2.0)Otras opciones para la planeacióndefault_statistics_target = 100 establece el objetivo estadístico por defecto para los columnas de las tablas que no lo tienen definido explícitamente con ALTER TABLE SET STATISTICS).constraint_exclusion = partition establece si el optmizador debe utilizar las restricciones para realizar la optimizacióncursor_tuple_fraction = 0.1from_collapse_limit = 8 establece si el optimizador debe fusionar subconsultas en las consultas si los items en el FROM está por debajo del valor dadojoin_collapse_limit = 8Configuración del loglog_destination = stderr existen varios métodos para emitir los mensajes del servidor (stderr, csvlog, syslog y eventlog)logging_collector = on permite enviar los errores enviados a stderr a los ficheros de seguimientolog_directory = pg_log si el parámetro anterior está habilitado determina el directorio donde se crean los ficheros de seguimientolog_filename = postgresql-%Y-%m-%d_ nombre de los ficheros de seguimiento%H%M%S.loglog_truncate_on_rotation = off establece la rotación de ficheros, aunque se pueden usar alternativaslog_rotation_age = 1d si redirect_stderr = on establece la duración máxima de cada fichero de seguimiento, con 0 deshabilita esta opción -26-
  • 27. log_rotation_size = 10MB tamaño de los ficheros rotadossyslog_facility = LOCAL0 si el seguimiento lo hace syslog, aquí se determina qué utilidad se usasyslog_ident = postgres si se usa syslog este es el nombre del programa utilizado para identificar los mensajes de PostgreSQL.silent_mode = off la salida estándar y los errores se envían a /dev/nullclient_min_messages = notice establece el nivel de los mensajes que serán enviados a los clienteslog_min_messages = warning controla el nivel de los mensajes que son escritos en el fichero de seguimientolog_error_verbosity = default controla el detalle de la información que se escribe en el fichero de seguimiento (terse, default, verbose), cada nivel añade más camposlog_min_error_statement = error controla si la instrucción SQL que ha provocado el error debe ser recordada o no el el fichero de seguimiento.log_min_duration_statement = -1 registra las instrucciones y su duración si su ejecución tarda más que el indicado aquí. Con 0 registra todas y con -1 ningunadebug_print_parse = off configuran el servidor para que registre de cada consulta información de su ejecucióndebug_print_rewritten = offdebug_print_plan = offdebug_pretty_print = offlog_checkpoints = offlog_connections = off información detallada de cada conexiónlog_disconnections = off información detallada de cada desconexiónlog_duration = off registra la duración de cada instrucción que va a ser registradalog_hostname = off con esta opción, aparte de la IP, se registra también el nombre del host desde donde se establece la conexiónlog_line_prefix = escribe una cadena antes de cada línea de informe.log_lock_waits = off Muestra las esperas de bloqueos mayores o igual a deadlock_timeoutlog_statement = none controla qué instrucciones son registradas (none, ddl, mod y all)log_temp_files = -1 Se indica el tamaño en kB. -1 es desactivado y 0 muestra todos.log_timezone = unknown -27-
  • 28. Estadísticastrack_activities = ontrack_counts = ontrack_functions = none none, pl, alltrack_activity_query_size = 1024update_process_title = onstats_temp_directory = pg_stat_tmplog_parser_stats = offlog_planner_stats = offlog_executor_stats = offlog_statement_stats = offAutovacuumautovacuum = on si el servidor debe lanzar el proceso autovacuumlog_autovacuum_min_duration = -1autovacuum_max_workers = 3autovacuum_naptime = 1min periodo de parada en segundos entre dos puestas en marcha del autovacuumautovacuum_vacuum_threshold =50 no mínimo de filas modificadas o borradas para lanzar el autovacuum. Este valor se puede sobreescribir para tablas individuales incluyendo información en pg_autovacuum.autovacuum_analyze_threshold = 50 especifica el no mínimo de filas modificadas o borradas para lanzar un analyze sobre una tabla. Este valor se puede sobreescribir para tablas individuales incluyendo información en pg_autovacuum.autovacuum_vacuum_scale_factor = 0.2 especifica la fracción del tanmaño de la tabla que se debe añadir a autovacuum_vacuum_thershold para decidir si se lanza la purga.autovacuum_analyze_scale_factor = 0.1 especifica la fracción del tanmaño de la tabla que se debe añadir a autovacuum_analyze_thershold para decidir si se lanza el analyze.autovacuum_freeze_max_age = Máximo valor de XID antes de forzar un vacuum200000000autovacuum_vacuum_cost_delay = 20 especifica el coste de retraso que se debe utilizar en las operaciones autovacuum. Si es -1 se usa vacuum_cost_delay. Este valor se puede sobreescribir para tablas individuales incluyendo información en pg_autovacuum.autovacuum_vacuum_cost_limit = -1 -28-
  • 29. Predeterminados para las conexiones clientesearch_path = $user,public órden de búsqueda de esquemas de la base de datosdefault_tablespace = tablespace donde se crearan los objetos si no se indica otrotemp_tablespaces = una lista de tablespaces para crear objetos temporalescheck_function_bodies = on habilita la validación de los cuerpos de las funciones que se creandefault_transaction_isolation = read establece el nivel de aislamiento por defectocommitteddefault_transaction_read_only = off establece cómo son las nuevas transacciones, ‘read_only’ o ‘read/write’. Las transacciones read_only solo pueden modificar tablas temporales.session_replication_role = originstatement_timeout = 0 se abortará cualquier instrucción cuya ejecución supere este límite. 0 deshabilita esta opción.vacuum_freeze_min_age = 50000000vacuum_freeze_table_age = 150000000xmlbinary = base64xmloption = contentLocalización y formatodatestyle = iso, mdy comportamiento del servidor asociado aintervalstyle = postgrestimezone = unknown valores geográficos y de tiempo. Si no setimezone_abbreviations = Default configuran , se usan los valores del entorno.extra_float_digits = 0client_encoding = sql_ascii cambiarlc_messages = es_EC.UTF-8lc_monetary = es_EC.UTF-8lc_numeric = es_EC.UTF-8’lc_time = es_EC.UTF-8default_text_search_config =pg_catalog.spanishdynamic_library_path = $libdirlocal_preload_libraries = Gestión de Bloqueosdeadlock_timeout = 1s tiempo que el servidor espera cuando se genera un bloqueo para comprobar la condición de bloqueo -29-
  • 30. mortal.max_locks_per_transaction = 64 la tabla de bloqueos compartida se crea para alojar un no de bloqueos: max_locks_per_transactions *(max_conections + max_prepared_transaction)Compatibilidad con versiones anteriores de PostgreSQLadd_missing_from = offarray_nulls = onbackslash_quote = safe_encoding on, off, or safe_encodingdefault_with_oids = offescape_string_warning = onregex_flavor = advanced advanced, extended, or basicsql_inheritance = onstandard_conforming_strings = offsynchronize_seqscans = onCompatibilidad con otras plataformas y clientestransform_null_equals = offOpciones especialescustom_variable_classes = pg_hba.confEs importante poder definir desde qué equipos se pueden conectar a nuestra base de datos, así comopoder definir qué usuarios y a qué bases de datos se pueden conectar.La configuración de este nivel de seguridad se realiza en el archivo pg_hba.conf (hba = host basedauthentication).Se trata de editar una serie de reglas que se irán procesando de arriba abajo, cuando se encuentreuna regla que cumpla la conexión, se ejecutará lo que ponga en el método.Hay cuatro formas generales de definir un acceso autorizado:TIPO BASE DATOS USUARIOS DIRECCIÓN MÉTODOLOCAL base_datos usuario método-autenticación [opción]HOST base_datos usuario direcciónCIDR método autenticación [opción]HOSTSSL base_datos usuario direcciónCIDR método autenticación [opción]HOSTNOSSL base_datos usuario direcciónCIDR método autenticación [opción]base_datos: • ALL: se permite la conexión a cualquier base de datos • SAMEUSER: solo a bases de datos que su nombre sea el mismo que el usuario que se conecta • SAMEROLE: solo a bases de datos que su nombre sea el mismo que el role que se conecta • nombd1, nombd2,...: se permite la conexión a cualquiera de las bases de datos de la lista • @fichero: se permite la conexión a las bases de datos incluidas en el fichero, que debe estar -30-
  • 31. en el mismo directorio que pg_hba.confusuario: • ALL: se permite la conexión de cualquier role • role1, [+]role2,...: se permite la conexión de los roles de la lista y además se permite la conexión de cualquier role que sea miembre de role2 • @fichero: se permite la conexión de los roles incluidos en el fichero, que debe estar en el mismo directorio que pg_hba.confmétodo-autenticación • TRUST: conexión aceptada sin condiciones • REJECT: conexión rechazada sin condiciones • PASSWORD: se solicita palabra de paso sin encriptar, las palabras de paso se almacenan en la tabla pg_authid y pueden estar cifradas o no según como se creara el role. • MD5: palabra de paso con el método de encriptación md5, y se almacena también con este método. Es el método recomendado por PostgreSQL. Se obtiene un cifrado a partir de la ID de usuario y la palabra de paso, el cliente solicita una semilla al servidor y así se obtiene un segundo cifrado que es envíado al servidor, en el servidor se utiliza la palabra de paso almacenada, la ID del usuario (la obtiene de la conexión) y la semilla para obtener un cifrado similar y los compara. • KRB5: se usa Kerberos v5 para autenticar el cliente, se ha de habilitar en la instalación del servidor. • IDENT correspondencia: a partir del usuario de la conexión cliente (se fía de la autenticación del cliente) y de la correspondencia indicada en la opción, se obtiene un role de PostgreSQL para realizar la conexión. Las correspondencias se obtienen del fichero pg_ident.conf. La correspondencia puede ser: ◦ SAMEUSER: el usuario del sistema operativo es el mismo que se conecta a la BD. ◦ cambio-usuario: el sistema mira el fichero pg_ident.conf, y busca una fila donde esté la correspondencia llamada ‘cambio-usuario’ y se corresponda con el usuario conectado al SO, haciendo la conexión a la BD con el usuario con el usuario de la columna usuario- pg. -31-

×