Proyecto Hacienda

Minuta de Reunin
Curso de PostgreSQL Avanzando
20 de Septiembre del 2013

Participantes:
Agustin Moyano

FOR004_MINUTA DE REUNION_V3.0 Acceso Norte Ruta Nacional N3

Caleta Olivia (9011) Santa Cruz

TEL. 0297 4854888 Int 114 e-mail: pas@uaco.unpa.edu.ar

P l a n d e A c c i n d e S i s t e m a s

Este documento cumple con las pautas establecidas por el Plan de Accin de Sistemas y fue creado utilizando el formulario FOR004_MINUTA DE REUNION_V3.0.ott. La informacin contenida en este documento esta sujeta a modificaciones.

Equipo de Trabajo
Chicahuala, Mirta Eva Molina Carrazana, Sonia Elizabeth Moyano, Agustin Vidal, Paola

Impreso en el PAS

2/21

181089661.odt

P l a n d e A c c i n d e S i s t e m a s

1. Temas tratados
En el curso convocada por el SIU de PostgreSQL Avanzado, dictado por Ignacio Bisso, los das 9 y 10 de Septiembre de 2013 en la UTN de Buenos Aires. Los temas dictados fueron: 1. Introduccin 2. Introduccin a PostgreSQL. 3. SQL en general. 4. Arquitectura. 5. Mantenimiento. 6. Monitoreo. // FIN DIA 1 7. Movimiento de datos y Backup continuo PITR. 8. ndices, Constraints y Vistas.// FIN DIA 2 Despus de cada tema abordado se realizaron practicas, aplicando lo visto en la teora.

1.1. Introduccin
El curso comenz con una introduccin abordando los temas de que son una base de datos, porque se utilizan y que problemas resuelven. Se presentaron los tipos de modelos de base de datos (lgicos, relacional y orientadas a objetos) y en que tipo de aplicaciones se utilizan (Aplicaciones WEB, Aplicaciones de Escritorio y Datawarehouse). Para finalizar la introduccin se presentaron los tipos de lenguajes de consultas (lgebra Relacional y SQL).

1.2. Introduccin a PostgreSQL

Se realizo una breve descripcin del motor de base de datos PostgreSQL, comentando que es opensource, posee casi 30 aos de desarrollo, soporte ACID, es objeto-relacional, arquitectura cliente/servidor, soporte a distintos lenguajes de programacion, posee WAL (Write Ahead LOG), Optimizadores de consultas, etc. Por el lado de caractersticas avanzadas se nos aclaro que PostgreSQL posee multiple tipos de datos, restricciones Referential Integrity Constraints (evita eliminaciones accidentales), anidacin de consultas, conexin SSL, TOAST (atributos comprimidos largos, transparentes al usuario). Por otro lado se vieron los limites: Mximo de la BD: ilimitado. De Tablas: 32 TB. De tupla: 1.6 TB. De campo: 1 GB Tuplas x tabla: ilimitado. ndices por tabla: ilimitado. Bloque: 8k

181089661.odt

3/21

P l a n d e A c c i n d e S i s t e m a s

1.3. SQL en general.

Se comenz definiendo el lgebra Relacional y sus operaciones: Operaciones de conjunto aplicadas a relaciones: unin(), interseccin() y diferencia(-). Operaciones que eliminan una parte de las relaciones: seleccin() y proyeccin(). Operaciones que combinan las tuplas de dos relaciones: producto cartesiano(x), junta natural (|X|) . Operacin que cambia el nombre de los atributos relacin: renombre(). En cuanto SQL, se estudiaron sus componentes y ejemplos (DDL, DML, Control de transacciones y Control de Permisos). DDL (CREATE, ALTER y DROP). DML (SELECT, INSERT, UPDATE, DELETE (Elimina tabla) TRUNCATE (Vacia tabla)). Se vieron los distintos tipos de JOINS (LEFT, RIGHT, INNER, FULL OUTER). ,

Figura 1. Tipos de Joins SQL Figura 1 Tipos de JOINS. Para finalizar se introdujo la herramienta psql y PgAdmin. La ventaja de utilizar PgAdmin es que tiene interfaz grfica y facilita la realizacin de consultas y operaciones sobre la base de datos, aunque tiene sus limites para el trabajo sobre configuracin del motor. Mientras que psql es por linea de comandos pero se pueden realizar operaciones que en PgAdmin no.

4/21

181089661.odt

P l a n d e A c c i n d e S i s t e m a s

1.4. Arquitectura
Al iniciar sobre este tema se defini que es un Cluster y como esta compuesto. Un cluster es un rea en disco (donde se almacenan los datos entre otras cosas). Esta rea se llama PGDATA, y existe una variable de entorno que apunta a esa carpeta. Adems posee un rea de memoria compartida de linux (shared memory) (que comparten todos los procesos postgres) donde entre otras cosas esta el pool de buffers. Tambien hay archivos de configuracin (postgresql.conf). Un cluster puede tener muchas bases de datos. Al crear un cluster se inicializa su espacio en disco (PGDATA) y crea una base llamada postgres, se utiliza el comando initdb para inicializar un cluster, es importante recalcar que es posible tener ms de un cluster activo en un mismo servidor fsico y que cada Cluster tiene un puerto donde escucha los requerimientos de los clientes. A continuacin se visualizara una pantalla donde se muestra el directorio de postgres y sus archivos:

Figura 2 Directorio PGDATA. Asi se compone los archivos de postgres: 1. Archivos de configuracin: postgresql.conf (no siempre en PGDATA) PG_VERSION (contiene el nro de versin de la instalacin)

2. Otros Ficheros: 3. Base Bases de datos y plantillas (Template0 y 1). Dentro se encuentran las tablas e ndices con sus correspondientes OIDs. postmaster.pid: contiene el numero del PID del servidor principal del cluster. postmaster.opts: opciones con las cuales arranca el servidor.

4. Global Tablas e ndices comunes a todas las bases.

181089661.odt

5/21

P l a n d e A c c i n d e S i s t e m a s

5. pg_log

Catlogo compartido: pg_shadow (usuarios), pg_database. pgstat.stat (usado por el monitor de estadsticas) pg_control: arch. Con param del Cluster.

Generalmente es esta carpeta la que contiene los logs del servidor. 6. pg_xlog (WAL): Diarios de escritura adelantada. Utilizada para recuperaciones. Conjunto de segmentos de un tamao de 16 MB y divididos en pginas de 8KB. Se van creando de acuerdo a las necesidades.

7. pg_clog Ficheros de confirmacin Guarda los estados de las transacciones.

8. pg_multixact Utilizado para estados multitransaccionales, bloqueos compartidos de filas.

9. pg_twophase Ficheros para el control de transacciones preparadas.

10. pg_subtrans Para realizar savepoints dentro de transacciones.

11. pg_tblspc Informacin de los tablespaces. *nix contienen los links a los directorios.

Es importante recalcar que el Cluster luego de inicializarse tiene 3 bases de datos: 1. postgres: Se crea al inicializar, se puede usar. 2. template1: Se crea al inicializar el cluster. Actua como un modelo, cada vez que ejecuta un CREATE DATABASE. Todo lo que agreguemos a template1, aparecer en cada base que se cree posteriormente. No se la debe usar, pero si agregarle todo lo que queremos que aparezca por default en una base nueva (pgplsql). 3. template0: Es como un backup de template1, NO se debe modificar. Los Tablespaces en PostgreSQL permite al DBA definir un lugar dentro del file system donde crear los objetos de la base de datos (tablas, indices). Por defecto Postgres se inicializa con 2 tablespaces: pg_global: Aqu van algunas tablas compartidas de postgres. pg_default: Aqu van todas las tablas, indices de las bases de datos, inclusive el catlogo. Como creamos otro tablespace: CREATE TABLESPACE fastspace LOCATION '/mnt/sda1/postgresql/data';

6/21

181089661.odt

P l a n d e A c c i n d e S i s t e m a s

Al crear una tabla o ndice podemos especificar en forma explicita el tablespace donde residir CREATE TABLE foo(i int) TABLESPACE fastspace; Sino especificamos, usa el default_tablespace. SET default_tablespace = space1; CREATE TABLE foo(i int);

1.5. Mantenimiento
Existen varias herramientas para el mantenimiento de un motor de base de datos, pero las siguientes son indispensables: Subir y Bajar Postgres. VACUUM ANALYZE REINDEX CLUSTERDB Mantenimiento de Logs

Subir postgres: /etc/init.d/postgresql start // service postgresql start // pg_ctl start Bajar postgres: /etc/init.d/postgresql stop // service postgresql stop // pg_ctl stop Reniciar postgres: /etc/init.d/postgresql restart // service postgresql restart // pg_ctl restart Recargar configuracin: /etc/init.d/postgresql reload // service postgresql reload Algo muy importante que posee el motor PostgreSQL es el MVCC (Multi Version Concurrent Control), el nombre lo dice es para el control de concurrencia. Cada consulta ve nicamente las transacciones completadas antes de comenzar. Si una transaccin mediante un update cambia una columna, entonces se genera una nueva fila, y se mantiene la anterior fila visible para las transacciones simultaneas a la que modifico. Se toma por defecto el nivel de read committed isolation level.

EL MVCC consume mucho espacio y es importante recuperarlo cuando es liberado, la tarea de recobrar espacio de disco ocupado por la actualizacin, borrado de datos y Actualizar las

181089661.odt

7/21

P l a n d e A c c i n d e S i s t e m a s

estadsticas usadas por el planeador es del VACUUM. Los tipos de este son FREEZE, ANALYZE, FULL y S/P. S/P(Sin Parmetros): Recuperacin en lnea, no bloquea las tablas. Solo libera espacio para ser utilizado por el motor. (O sea devuelve el espacio recuperado a Postgres. Agrega espacio a FSM Free Space Map). Compacta por Pgina. FULL: En lnea, realiza bloqueo a nivel de tabla, compacta y devuelve el espacio al SO. til despus de grandes cambios. Import grandes. Update que afecten mas del 20% de los registros de la tabla. No acomoda ndices. Es necesario hacer REINDEX! FREEZE: Eliminacin de todas las versiones de las tuplas. No puede haber otras conexiones abiertas. Es usado para armar templates o bases fuera de lnea (de solo lectura).

VACUUM FULL puede liberar mayor cantidad de disco pero es ms lento.

VACUUM Puede correr de forma paralela con otras operaciones excepto modificaciones en los objetos (ALTER)

requiere bloqueo exclusivo en la tabla que esta Generalmente se recomienda utilizar este tipo trabajando. de vacuum.

Desventaja es que no reduce el tamao proporsional del ndice. Puede hacer a los ndices ms grandes.

Tabla 1 Caractersticas VACUUM FULL y VACUUM

Para ejecutar el VACUUM desde linea de comandos se realiza de la siguiente manera:

Vacuumdb -a, --all -d, --dbname=DBNAM -t, --table='TABLE[(COLUMNS)]' -f, --full -z, --analyze
Desde un cliente: VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] [ table ]

vacuum todas las b.d. vacuum a una base. vacuum a una tabla. vacuum full. actualizar base del optimizador.

8/21

181089661.odt

P l a n d e A c c i n d e S i s t e m a s

VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] ANALYZE [ table [ (column [, ...] ) ] ] Como se comento anteriormente, el analyze actualiza los datos del Optimizador (o Planner). El Optimizador es uno de los mdulos ms importantes de todo RDBMS. Su funcin es encontrar el plan de acceso ptimo para cada consulta. El Optimizador tiene 2 inputs: 1. El query o Consulta a optimizar 2. La informacin del Catlogo (Tablas / Columnas / Incides / Cantidad de filas / Distribuciones de los datos / valores mximos y mnimos de las columnas). El Optimizador tiene 1 output: El Plan de Acceso ptimo.

Figura 3 Optimizador El ANALYZE recolecta estadsticas de acuerdo a la configuracin de las relaciones. Su modo de uso es: ANALYZE [ VERBOSE ] [ table [ ( column [, ...] ) ] ] El REINDEX se utiliza cuando un ndice se ha corrompido, y ya no contiene datos vlidos. Aunque en teora esto NO debera ocurrir nunca, en la prctica, los ndices pueden daarse debido a errores de software o fallos de hardware. Un ndice luego de muchos inserts/deletes puede tener muchos espacios vacos por pginas. Esto puede ocurrir con ndices B-tree en determinadas modalidades de acceso poco frecuente. Se reconstruye el ndice sin paginas muertas. Otro punto puede ser cuando se ha modificado un parmetro de almacenamiento (fillfactor) para un ndice, y desean que el cambio tengo efecto sobre la totalidad del ndice. Tambin cuando se construye un ndice CONCURRENTLY y el

181089661.odt

9/21

P l a n d e A c c i n d e S i s t e m a s

mismo falla. Modo de uso: REINDEX { INDEX | TABLE | DATABASE |SYSTEM } name [ FORCE ] Desde linea de comando: reindexdb

Una buena practica es tener habilitado el AUTO VACUUM. Este es un daemon que constantemente vigila las tablas con muchas inserciones y actualizaciones. Es altamente recomendado y si esta activo el DBA no debe correr el vacuum Se configura desde el postgresql.conf.

Por ultimo y no menos importante el mantenimiento de los Logs: Es importar evitar el crecimiento exponencial de los logs, mediante la especificar rotacin (Desde el postgresql.conf: log_rotation_size). Mostrar datos realmente relevantes. Borrar histricos seguido, a menos que sean de valor. Setear niveles de log de acuerdo a la situacin, evitar dejar uno esttico. Logs logs de Postgres se encuentra en /var/log/postgres/.

1.5. Monitoreo
Lo que refiere a monitoreo se comenzo explicando como se verifica si el postgres esta levantado: /etc/init.d/postgresql status // service postgresql status Solo nos indica el PID del servidor que est levantado contra el cluster.

Figura 4 Status PostgreSQL

Con un simple ps de linux podemos ver los procesos de postgres corriendo Cada conexin a postgres tiene un proceso asociado. Inclusive podemos ver la bd y que tipo de sql esta corriendo (delete; select) Comando: ps -ef | grep postgres // ps -ef | grep PID Ejemplo: postgres@nefertiti:/home/ibisso$ ps -ef | grep 2338 postgres 2338 1 0 Feb25 ? 00:00:00 /usr/lib/postgresql/8.1compilado/bin/postmaster -D /var/lib/postgresql/8.1compilado/main

10/21

181089661.odt

P l a n d e A c c i n d e S i s t e m a s

postgres 2546 2338 0 Feb25 ? postgres 2547 2338 0 Feb25 ? postgres 2851 2338 0 10:47 ? 192.168.123.182(53206) idle postgres 3205 2338 99 13:02 ? [local] DELETE postgres 3214 2338 0 13:20 ? 192.168.123.182(53752) idle postgres 3287 2338 0 14:59 ? 192.168.123.182(54797) idle

00:02:14 postgres: writer process 00:00:00 postgres: stats buffer process 00:00:00 postgres: postgres spu_pedidos_14022013 02:20:13 postgres: postgres spu_pedidos_14022013 00:00:15 postgres: postgres spu_pedidos_14022013 00:00:00 postgres: postgres spu_pedidos_14022013

Los logs de Postgres (errores y/o mensajes del motor) por defecto van al standard error del master process. Es posible enviar estos mensajes al archivo syslog mediante el parmetro de configuracin log_destination=syslog. El contenido del archivo del syslog se puede monitorear con tail f /var/log/syslog. (Al menos en la imagen con Ubuntu) Tambin se puede arrancar el postgres con distintos niveles de debug (0:nada al 5:super verboso). Al arrancarlo poner el flag d n en el comando postgres donde n es el nivel de debug. Por medio de la herramienta top (Linux) se puede observar de manera dinamica el uso de los recursos de nuestro sistema. Por lo general se utiliza para ver que proceso es el que mas memoria/CPU esta consumiendo.

Figura 5 top Linux.

Esto tambin se puede realizar con el PgAdmin, mediante la operacin Tools Server Status.

181089661.odt

11/21

P l a n d e A c c i n d e S i s t e m a s

Figura 6 Control Status PgAdmin.

El Statistics Collector de PostgreSQL es un mdulo para la colectar y reportar informacin acerca de la actividad en el cluster. El colector puede contar accesos a las tablas e ndices, tanto en trminos de bloques de disco y de filas. Tambin realiza un seguimiento del nmero total de filas en cada tabla, la informacin del vacuum y analyze para cada tabla. El Satistics Collector se configura desde el postgresql.conf y tiene los siguientes parametros: track_activities: Habilita el monitoreo del comando actual ejecutado por cualquier proceso del servidor. track_counts: Controla si se recopilan estadsticas sobre la tabla y accesos de ndices. track_functions: Permite el seguimiento del uso de las funciones definidas por el usuario. track_io_timing: Permite la monitorizacin de los tiempos de leer y escribir.

12/21

181089661.odt

P l a n d e A c c i n d e S i s t e m a s

Figura 7 Tabla de Statistics Collector

Por ejemplo si ejecutamos: SELECT * FROM pg_stat_activity Obtendremos:

Figura 8 Consulta a pg_stat_activity. Este nos muestra las consultas que se estan realizando, id, base, usuario, los tiempos de la consulta, la consulta, direccin y puerto.

1.7. Movimiento de Datos y Backup continuo PITR.

Existen diversas maneras de realizar backups, estas son: PG_DUMP.

181089661.odt

13/21

P l a n d e A c c i n d e S i s t e m a s

A nivel cluster: pg_dumpall A nivel base, tabla, estructura: pg_dump Tipo texto / -Fc (comprimido) se restaura con pg_restore FILE SYSTEM LEVEL BACKUP: Es un backup a nivel del file system, es importante que Postgres este bajo. Es una foto, no es posible recuperar nada ms BACKUP CONTINUO.

USO PG_DUMPALL pg_dumpall archivo sql con toda la inf. del cluster. pg_dumpall > todo.sql pg_dumpall -f todo.sql pg_dumpall | gzip > todo.sql.gz pg_dumpall | psql -h192.168.1.2 postgres Migracin entre versiones: pg_dumpall -p 5432 | psql -p5433

Se puede backupear solo Datos (-a), solo Estructuras (-s) o Estructuras y Datos. Tambien se puede backupear en diferentes formatos: Formato Fp (plano, es el default) Formato Fc (custom, es comprimido y requiere del pg_restore)

pg_dump pg_dump -Fp h 127.0.0.1 Upostgres nuevadb pg_dump -Fp h 127.0.0.1 Upostgres nuevadb > nuevadb.sql CREATE DATABASE base1 TEMPLATE base0; pg_dump -Fp . | psql -h192.168.1.2 base1 pg_dump -Fc .. | pg_restore -h192.168.1.2 -n esuqema1 base2

pg_restore pg_restore -Upostgres -h192.168.132.113 -dnico_p1 /home/nico.backup

14/21

181089661.odt

P l a n d e A c c i n d e S i s t e m a s

pg_restore -Upostgres -h192.168.132.113 -j4 -dnico_p2 /home/nico.backup

Backup Continuo El Backup continuo en Postgres nos permite maximizar los datos a recuperar en caso de un restore. Esta basado en el respaldo continuo de unos files llamados WAL Segments. En Postgres toda la actividad transaccional se escribe en los Segmentos WAL. Un segmento WAL es un archivo de un tamao dado (16 Mb) que se graba en un directorio de postgres.

Figura 9 Segmentos WAL Ejemplo de FULLBACKUP

Figura 10 FULLBACKUP

Ejemplo Backup Continuo

181089661.odt

15/21

P l a n d e A c c i n d e S i s t e m a s

Figura 11 BACKUP CONTINUO Cada WAL tiene 16 Mb y es un archivo, se almacenan en $PGDATA/pg_xlog. Cada vez que se llena un WAL, se crea el prximo. Sus nombres son de la forma: 000000010000000000000001 al 000000010000000000000009 00000001000000000000000A al 00000001000000000000000Z Para backupear los WAL hay que modificar 2 parmetros en el postgresql.conf: archive_command = on archive_command = 'cp %p /usr/local/carpetadebackupdewals/%f %p es el archivo con el path completo %f es solo el nombre del file

Las transacciones se graban en los WAL segments, y los van llenando. Cuando se llena un WAL Segment Postgres ejecuta el comando del parmetro archive_command. Este comando debera copiar el WAL recin completado a una carpeta en un lugar seguro (disco remoto). Se borra el WAL Segment del directorio pg_xlog (en realidad se lo renombra y se reutiliza el archivo para otro WAL). En algunos casos cuando Postgres necesita swichear al siguiente WAL file renombra uno ya existente que esta backupeado y no tiene transacciones abiertas. Esto puede generar algo de confusin porque podemos ver que el WAL 00000000AA fue modificado a las 10:22 y el WAL 00000000AB fue modificado a las 10:18.

En realidad el archivo WAL 00000000AB es el mismo archivo que antes se llamaba 0000000012,

16/21

181089661.odt

P l a n d e A c c i n d e S i s t e m a s

el cual fue accedido por ltima vez a las 10:18, luego se lo renombr a 00000000AB Ventajas Se maximizan los datos a recuperar en caso de una falla Relativamente Sencillo de implementar. Todo lo que se haga en el servidor Postgres, incluyendo sentencias DLL, se guarda en los segmentos WAL.

Desventajas Hay que mantener un repositorio de backup de WAL Hay que mantener un repositorio con los backups full online

PASOS A SEGUIR PARA REALIZAR EL BACKUP: 1. Desde psql ejecutar # select pg_start_backup(Full Backup Testing); pg_start_backup crea un label, y lo graba en el WAL file. Es opcional, pero se recomienda 2. Desde lnea de comandos hacer un backup base. tar -cvf /usr/local/mi_backup.tar $PGDATA // (ESTE ES EL BACKUP). 3. Desde psql ejecutar # select pg_stop_backup(); pg_stop_backup tambin crea un label y lo graba en el WAL file. Todo backup base tiene un archivo en el pg_xlog con extension .backup que describe ese backup. Preparativos para restaurar un Backup Continuo 1. Se supone que postgres est bajo (sino bajarlo). 2. 3 Elementos Necesarios. 1. El backup BASE (es lo principal, sin esto no hay restore posible) 2. El directorio con los WAL backupeados por Postgres (muy importantes) 3. El directorio pg_xlog (con los WAL aun sin backupear que estaban en pg_xlog al momento de la cada. Contienen las ltimas transacciones. Dependiendo del dao en disco puede ser que se hayan perdido ) 3. Para chequear podemos ver el archivo .backup del backup base que queremos restaurar, para determinar el primer WAL que necesitamos. Ese WAL debe existir en el directorio de 2.2. 4. Renombrar el pg_xlog actual a pg_xlog_recientes 5. Revisar si en pg_xlog_recientes existen WAL segments que no estn backupeados. Backupearlos a mano si queremos recuperarlos.

Restaurar un backup continuo y todos los WAL Segments disponibles

181089661.odt

17/21

P l a n d e A c c i n d e S i s t e m a s

6. Restaurar con un tar (o el comando que corresponda) el backup base (no subir postgres) 7. Modificar el archivo recovery.conf 8. Levantar Postgres Restaurar un Backup Continuo y los WAL Segments con PITR ( Point In Time Recovery) 5. Restaurar con un tar (o el comando que corresponda) el backup base (no subir postgres) 6. Modificar el archivo recovery.conf seteando el parmetro recovery_target_time con la fecha y hora donde queremos parar de restaurar 7. Levantar Postgres

1.8. Indices, Constraints y Vistas.

INDICES El optimizador de Postgres debe decidir cual es la mejor forma de acceder a cada tabla: Barrido Secuencial o Acceso Indexado? Para crear un Index se utiliza el siguiente comando: CREATE [ UNIQUE ] INDEX [CONCURRENTLY] name ON table [USING method] ({ column | ( expression )} [WITH (storage_parameter = value [, ... ] )] [TABLESPACE tablespace ] [ WHERE predicate ] Mtodos posibles para el armado del ndice: B-tree R-tree Hash GiST GIN

ndices B-TREE Es el tipo de ndice que utiliza PostgreSQL por defecto. Es el utilizado por las PRIMARY KEY (claves primarias) en su creacin. Es el nico tipo de ndice que soporta la clausula UNIQUE Usado en bsquedas por = y por < , <= , > , = > Implementacin de arboles B de alta concurrencia (Lehman Yao) Maneja solamente bsquedas por rango de una dimensin. Es el nico (junto con GiST) que soporta indexado por mltiples columnas.

18/21

181089661.odt

P l a n d e A c c i n d e S i s t e m a s

Figura 12 ndices B-TREE ANALISIS DE CONSULTAS Ejemplo de Acceso Indexado. Creamos un ndice por DNI_TITULAR y realizamos una consulta anteponiendo EXPLAIN, para que nos brinde informacin sobre la consulta, tiempos, costos, filas, etc. EXPLAIN select * from CENSO2012 where DNI_TITULAR = 10499752;

Figura 13 Ejemplo EXPLAIN

cost -> costo de i/o + costo de procesamiento rows -> en filas width -> en bytes

Los ndices tienen un costo, relacionado con el mantenimiento. Cada vez que se INSERTA o se ELIMINA una fila, Postgres debe reflejar ese cambio en todos los ndices. Cada vez que se hace

181089661.odt

19/21

P l a n d e A c c i n d e S i s t e m a s

un UPDATE de los campos que forman la clave de un ndice, se debe actualizar ese ndice. En tablas que sufren muchas modificaciones, los ndices pueden hacer las modificaciones mas lentas. No se deben agregar ndices indiscriminadamente, hay que evaluar. CONSTRAINTS Clave primaria: Permiten asegurar que una columna (o varias) no tengan valores duplicados. Postgres crea un ndice nico en forma implcita para garantizar la unicidad. Si ya existe uno, no lo crea. Check Constraints: Permite definir en la tabla que datos permite cierto campo o toda la tabla. Ejemplo: Create table t_con_check ( nombre varchar(20) CHECK (length(trim(nombre)) > 1), sexo char(1) CHECK(sexo IN ('M','F')), fecha_pasada date CHECK(fecha_pasada BETWEEN '1990-01-01' AND CURRENT_DATE), CHECK (upper(trim(nombre)) != 'EMA') --check de tabla );

En este ejemplo nombre debe ser mayor que 1 carcter. Sexo debe ser M o F. fecha_pasda debe estar entre 1990-01-01 y la fecha actual. Por ultimo un check de tabla que el nombre sea distinto a EMA. Clave fornea: Deben REFERENCIAR a una tabla/columna(s) que sean PK (primaria) o UNIQUE. La restriccin del punto anterior nos asegura que en la tabla REFERENCIADA habr un ndice. VISTAS Desde el punto de vista de la aplicacin una vista es como una Tabla, se puede usar en el FROM de un SELECT. La vista tiene columnas igual que una tabla pero es diferente porque: No almacena datos. No sirve para modificar (al menos no es muy til). Toda vista tiene un SELECT asociado que es el que selecciona los datos. Este select asociado, en algn punto accede a una tabla real.

Ejemplo:

20/21

181089661.odt

P l a n d e A c c i n d e S i s t e m a s

CREATE VIEW MI_VISTA AS SELECT nombre, apellido FROM CENSO2012 WHERE codigo_postal IN (1661,1662,1663) SELECT * FROM MI_VISTA

Agustin Moyano Autor

PAS Dirigido a

181089661.odt

21/21