REPBLICA BOLIVARIANA DE VENEZUELA

MINISTERIO DEL PODER POPULAR PARA LA EDUCACIN UNIVESITARIA, CIENCIA Y TECNOLOGIA

UNIVERSIDAD POLITCNICA TERRITORIAL DEL ESTADO ARAGUA
FEDERICO BRITO FIGUEROA
LA VICTORIA ESTADO ARAGUA

ADMINISTRACIN DE BASE DE DATOS

AUTORES
Belisario Rebeca C.I. N 19.864.786
Oliveros Leobaldo C.I. N 16.761.622
ABRIL, 2015

Optimizacin del archivo postgresql.conf

Y cambiamos algunas opciones bsicas del archivo postgresql.conf:
shared_buffers = 256MB
shared_buffers': Es la memoria de trabajo compartida para todo el servidor postgreSQL,
fjese que por defecto en Debian GNU/Linux la opcin es 24MB (y el valor por defecto si
comentamos es 32MB), sin embargo, como esta es la memoria utilizada para trabajo de
postgreSQL, es recomendable al menos el 25% de la RAM disponible (y jams > 40%).

temp_buffers = 16MB
temp_buffers': La memoria temporal utilizada por cada sesin para las tablas temporarias y
para apertura de tablas en cada sesin de cada base de datos, tome en cuenta que este valor
depender obviamente de la cantidad de datos que carga cada sesin y depender
muchsimo del sistema que se utiliza.

work_mem = 16MB
work_mem': uno de los valores ms importantes y ms despreciados, work_mem se
refiere a la memoria temporal utilizada por cada sesin, para las operaciones de
ordenamiento (ORDER BY) para las sesiones de diferenciacin (GROUP HAVING y
DISTINCT) y para la gestin de hash (uniones HASH, indices HASH, hash_aggregations),
si en nuestro sistema realizamos muchsimas consultas ordenadas, agrupadas, diferenciadas
por cadenas, etc se crearn mucho de estos buffers de manera paralela, mientras ms
memoria asignemos, menos probabilidades hay que los ordenamientos y otras operaciones
se hagan con archivos temporales en disco (ms lentos que la memoria RAM).

max_stack_depth = 8MB

max_stack_depth': define el tamao del espacio utilizado para cmputo de operaciones

complejas, su valor est asociado al lmite mximo que un usuario (en este caso,
postgres) tiene derecho a reservar un stack, el valor soportado por nuestra distribucin se
determina con ulimit -s.

shared_preload_libraries = '$libdir/plpython2.so'
shared_preload_libraries': Permite cargar una librera especfica cuando arranca el sistema,
si utilizamos muchos procedimientos almacenados en un lenguaje especfico (ej: python,
perl, tcl, java, etc), es bueno pre-cargarla para que est disponible cuando se utilice por
primera vez. Nota: esta opcin ralentiza un poco el reinicio del sistema.

bgwriter_delay = 500ms
bgwriter_delay': El background-writer es un proceso del servidor que se encarga de
escribir a disco todos los shared_buffers modificados, este proceso conlleva una carga de
I/O sobre el disco, su modificacin permite o reducir el valor para evitar en lo ms posible
prdidas de datos en equipos que pueden fallar, o su incremento permite reducir el I/O al
disco duro en sistemas perfectamente protegidos.

Los valores que tiene postgresql.conf estn pensados para trabajar en una
configuracin de hardware mnima.
a) como calcular el valor de SHARED_BUFFERS Shared_buffers nos dice cuanta memoria
va a consumir la dbms, se recomeinda que sea al menos 10% a 25% de la ram disponible en
el sistema y hasta un 40%, el valor nunca puede ser jamas al informado en
/proc/sys/kernel/shmmax.
Para medir el valor correcto debemos contar cuantas pginas caben en la cantidad de ram
asignada en shared_buffers, una pgina generalmente mide 8kb, por ejemplo si tenemos

4gb de ram asignaremos 400mb (400mb no es exacto el 10%): En postgresql.conf

ponemos: shared_buffers=400mb
Calculamos el valor en shmmax:
400mb x 1024kb = 409600 <-- cantidad de kb a utilizar por el buffer
409600 / 8 = 51200 <-- cantidad de pginas a utilizar por el buffer
51200 x 8192b = 419430400 <-- cantidad mnima de ram en bytes que se debe configurar
Debe considerarse que hay otras aplicaciones que hacen Uso de esta cantidad de ram
asignada.
Abrimos el archivo /etc/sysctl.conf y aadimos:
kernel.shmmax = 421527552 <-- aadimos un par de megas ms para asegurarnos que no
Nos faltar ram.
b) como calcular el valor de WORK_MEM: work_mem es el espacio de memoria que se
usar para los ordenamientos de los datos cuando se ejecutan consultas, no existe una
formula exacta de clculo depender de que tanta data se mueva en las consultas que
ejecutamos y cul es la concurrencia de ejecucin de las consultas.
La regla dice, si las consultas se ejecutan con poca concurrencia entonces asignar entre 2%
a 4% de la ram disponible ser ideal, pero si la concurrencia es alta entonces debe asignarse
menos memoria debido a que cada consulta consume la misma cantidad de ram.
work_men = 163MB <-- 4% de 4gb (redondeado)
c) temp_buffers: Es la cantidad de memoria que tendr asignada cada conexin al dbms
para manejo de tablas temporales, esta no se libera hasta que la sesin muera, cada sesin
podra manejar un tamao diferente y mayor al de default (8mb) pero solo hasta antes de
generar la primera tabla temporal.
d) max_locks_per_transaction: Permite indicar cuantos objetos se pueden bloquear en una
transaccin, un registro no se considera un objeto, el default es 64 solo valdra la pena

subirlo si es que tenemos transacciones que bloquean muchos ms objetos nicos (tablas)
que este valor, obviamente el consumo de memoria crecer.
e) max_connections: Determina cuantas conexiones soportar el dbms, subirlo significar
un consumo de recursos adicional en el OS (sistema operativo), y en realidad no servir de
mucho si es que el OS no soporta esta carga de trabajo.
f) random_page_cost: Determina en qu momento se van a utilizar ndices o bsquedas
secuenciales, el valor por defecto es 4, se recomienda aumentarlo para discos lentos y
bajarlo para discos rpidos.
Considere que los ndices son efectivos si la variedad de datos es alta, si es baja entonces es
probable que aunque se mueva la configuracin se ejecuten bsquedas secuenciales.
g) effective_cache_size: Setea el tamao de cache en RAM que se usar en una consulta, el
valor por defecto es 128Mb, un valor alto facilitar el uso de ndices, un valor bajo har que
se prefiera el uso de bsquedas secuenciales, se recomienda como mximo 50% del total de
la RAM.
h) statement_timeout: Configura cunto tiempo puede demorar un query en ejecutarse,
evita que se lancen querys extremadamente pesados que demoren mucho tiempo en
ejecutarse, por defecto es 0 (desactivado) pero se expresa en milisegundos, OJO
configurarlo afectar todos los querys.
VACUUM
El proceso de vacuum se ocupa de borrar definitivamente las filas borradas en
operaciones de SQL. Las filas no son borradas fsicamente de la base de datos, nicamente
son marcadas a nivel lgico. Por ese motivo es muy necesario lanzar esta tarea cada cierto
tiempo para proceder al borrado de aquellas filas borradas y eliminarlas definitivamente.
Sin parmetros vacuum procesa cada tabla de la base de datos segn los permisos del
usuario conectado. Vacuum tambin puede procesar slo una tabla.

Vacuum analyze adems de ejecutar vacuum analiza cada tabla de la base de datos.
Esto es una combinacin potente para la ejecucin de scripts de mantenimiento.
Lanzar vacuum (sin la opcin full) simplemente reclama el espacio y lo pone a disposicin
para su reutilizacin. El proceso puede lanzarse mientras se estn realizando operaciones de
lectura y escritura en la base de datos, ya que el proceso vacuum no bloquea en modo
exclusivo. Sin embargo el espacio recuperado no se destina al sistema operativo, sino que
pasar a ser reutilizado dentro de la misma tabla desde donde se recuper.
Vacuum (en modo full) reescribe el contenido entero de la tabla en un nuevo fichero
de disco sin espacio adicional permitiendo la devolucin del espacio no usado al sistema
operativo. Esta opcin es mucho ms lento y requiere un bloqueo exclusivo de tabla en el
momento de su procesamiento.
VACUUM [ ( { FULL | FREEZE | VERBOSE | ANALYZE } [, ...] ) ] [ table [ (column
[, ...]) ] ]
VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] [ table ]
VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] ANALYZE [ table [ (column [, ...] ) ] ]
Analyze
Analyze recoge las estadsticas del contenido de las tablas de la base datos y los resultados
del catlogo de sistemas pg_statistic. El anlisis de las tablas permite determinar la manera
ms eficiente en las construccin de los planes de ejecucin de las quieres.
Sin parmetros analyze analiza cada tabla de la base de datos conectada. Con un parmetro
analyze examina solo la tabla indicada, tambin se pueden realizar anlisis de columnas
concretas.
ANALYZE [ VERBOSE ] [ table [ ( column [, ...] ) ] ]
Scripts
Ambas operaciones tanto Vacuum como Analyze son fundamentales para un
mantenimiento ptimo de la bd por lo que se mostrar una estrategia de mantenimiento en

entornos de produccin. Esto es un ejemplo y hay muchas otras alternativas, aunque esta
opcin es muy vlida.
Es aconsejable del lanzamiento de un anlisis y de un vacuum todos los das, dicha
ejecucin no provoca bloqueos, ni afecta en gran medida al rendimiento de la base de datos,
por lo que puede ser lanzado todos los das.
Para el lanzamiento de los scripts se va a emplear la herramienta vacuumdb que
permite la ejecucin desde el sistema operativo del comando vacuum. Su sintaxis es la
siguiente:
vacuumdb [connection-option...] [--full | -f] [--freeze | -F] [--verbose | -v] [--analyze | -z]
[--analyze-only | -Z] [--table | -t table [( column [,...] )] ] [dbname]
Script diario de mantenimiento
su - postgres -c "vacuumdb --all --verbose --analyze >
/datos01/data/pg_log/vacuum_analyze.log"
Este script lanza un vacuum con un analyze sobre todas las bases de datos a las que tiene
permiso el usuario postgres. Adems de realizar una limpieza de filas borradas lgicamente
tambin actualizar las estadsticas para la mejora de los planes de ejecucin.
Script semanal de mantenimiento
su - postgres -c "vacuumdb --all --verbose --full --analyze >
/datos01/data/pg_log/vacuum_full.log"
En este caso se lanza un vacuum full y con analyze sobre toda la base datos, esta ejecucin
bloquear las tablas que se estn procesando y afectar a los usuarios en caso de ejecucin,
por ello se aconseja su lanzamiento en tiempos de mnima carga.
En ambos scripts se redirecciona la salida a la carpeta de logs del propio PostgreSQL.
Un ejemplo de planificacin cron
00 00 * * 6 /datos01/vacuum_full.sh
00 00 * * 1-5 /datos01/vacuum_analyze.sh

En dicho ejemplo se muestra un ejecucin diaria de un vacuum con analyze para

mejorar el rendimiento y semanalmente un full. Se busca las 00:00 horas para no afectar
demasiado a los usuarios, aunque esto depende de cada entorno.
REINDEX
El Nombre
REINDEX - reconstruir los ndices
Sinopsis
REINDEX {NDICE | MESA | BASE DE DATOS | SISTEMA} nombre [FORZADO]

Descripcin
REINDEX reconstruye un ndice utilizando los datos almacenados en la tabla de ndice, la
sustitucin de la vieja copia del ndice. Hay varios escenarios en que utilizar REINDEX:

Un ndice se ha daado, y ya no contiene datos vlidos. Aunque en teora esto no

debera ocurrir nunca, en la prctica, los ndices pueden resultar daados debido a
los errores de software o de hardware. REINDEX proporciona un mtodo de
recuperacin.

Un ndice se ha convertido en "hinchado", que es contiene muchas pginas vacas o

casi vacas. Esto puede ocurrir con ndices B-tree en PostgreSQL bajo ciertos
patrones de acceso poco comunes. REINDEX proporciona una manera de reducir el
consumo de espacio del ndice escribiendo una nueva versin del ndice sin las
pginas muertas. Vea la Seccin 23.2 para ms informacin.

Usted ha cambiado un parmetro de almacenamiento (como factor de relleno) para

un ndice, y desea asegurarse de que el cambio ha tenido un efecto completo.

Una creacin de ndice con la opcin CONCOMITANTE fall, dejando a un

ndice "no vlido". Tales ndices son intiles, pero puede ser conveniente
utilizar REINDEX a reconstruirlas. Tenga en cuenta que REINDEX no realizar una
compilacin concurrentes. Para construir el ndice, sin interferir con la produccin
que debe quitar el ndice y vuelva a emitir el comando CREATE INDEX
simultneamente.

Parmetros
NDICE
Vuelva a crear el ndice especificado.
TABLA
Volver a crear todos los ndices de la tabla especificada. Si la tabla tiene una
mesa "Toast" secundario, es decir a indizar tambin.

BASE DE DATOS
Volver a crear todos los ndices dentro de la base de datos actual. ndices en los
catlogos del sistema compartidos se omiten excepto en modo autnomo (ver ms
abajo). Esta forma de REINDEX no puede ejecutarse dentro de un bloque de transaccin.

SISTEMA
Volver a crear todos los ndices de catlogos del sistema dentro de la base de datos
actual. Los ndices de las tablas de usuario no se procesan. Adems, los ndices sobre los
catlogos de sistema compartidos se omiten excepto en modo autnomo (ver ms
abajo). Esta forma de REINDEX no puede ejecutarse dentro de un bloque de transaccin.

El nombre
El nombre del ndice, tabla o base de datos especfica para ser indexada. Los
nombres de ndice y de mesa puede ser calificado por el esquema. Actualmente, REINDEX
base de datos y SISTEMA REINDEX slo pueden indexar la base de datos actual, por lo
que su parmetro debe coincidir con el nombre de la base de datos actual.

FUERZA
Esta es una opcin obsoleta; se ignora si se especifica.

Notas
Si usted sospecha que la corrupcin de un ndice en una tabla de usuario, slo tiene que
reconstruir

ese

ndice,

todos

los

ndices

de

la

tabla,

usando NDICE

REINDEX o REINDEX TABLE.

Las cosas son ms difciles si usted necesita para recuperarse de la corrupcin de un

ndice en una tabla del sistema. En este caso es importante para que el sistema no ha
utilizado ninguna de las propias ndices sospechosos. (De hecho, en este tipo de escenario
puede encontrarse con que los procesos de servidor se estn estrellando inmediatamente en
el arranque, debido a la dependencia de los ndices daados.) Para recuperar de forma
segura, el servidor se debe iniciar con la opcin -P, lo que le impide la utilizacin de ndices
para bsquedas en el catlogo del sistema.

Una forma de hacerlo es cerrar el servidor e iniciar un servidor PostgreSQL de un

solo usuario con la opcin -P incluye en su lnea de comandos. Entonces, BASE DE
DATOS

REINDEX,

SISTEMA

REINDEX,

TABLA

REINDEX o REINDEX

NDICE pueden ser emitidos, dependiendo de la cantidad que desea reconstruir. En caso de
duda, utilice SISTEMA REINDEX para seleccionar la reconstruccin de todos los ndices
del sistema en la base de datos. A continuacin, salga de la sesin de servidor de un solo
usuario y reiniciar el servidor regular.

Alternativamente, una sesin de servidor regular puede iniciarse con -P incluido en

sus opciones de lnea de comandos. El mtodo para hacer esto vara segn los clientes, pero
en

todo

LIBPQ clientes

basados,

es

posible

establecer

la

variable

de

entorno PGOPTIONS a -P antes de iniciar el cliente. Tenga en cuenta que, si bien este
mtodo no requiere bloquear a otros clientes, todava podra ser prudente para evitar que
otros usuarios se conecten a la base de datos daada hasta que las reparaciones se han
completado.

Si se sospecha de la corrupcin en los ndices de cualquiera de los catlogos del

sistema compartidos (que son pg_authid, pg_auth_members, pg_database, pg_pltemplate,
pg_shdepend,

pg_shdescription y pg_tablespace), a

continuacin,

un

servidor

independiente debe ser utilizado para repararlo. REINDEX no procesar catlogos

compartidos en modo multiusuario.

Para todos los ndices, excepto los catlogos del sistema compartidos, REINDEX es
crash-seguro y transaccionales. REINDEX no se estrelle-seguro para los ndices
compartidos, por lo que no est permitido este caso durante el funcionamiento normal. Si se
produce un error mientras reindexacin uno de estos catlogos en modo autnomo, no ser
posible reiniciar el servidor regular hasta que se rectifica el problema. (El sntoma tpico de

un ndice compartida parcialmente reconstruido es "ndice no es un btree" errores.)

REINDEX es similar a una cada y volver a crear el ndice en que el contenido del ndice se
reconstruyen a partir de cero. Sin embargo, las consideraciones de bloqueo son bastante
diferentes. REINDEX bloquea escrituras pero no lee de la tabla padre del ndice. Tambin
tiene un bloqueo exclusivo en el ndice especfico que se est procesando, que bloquear
dice que el intento de utilizar ese ndice. Por el contrario, DROP INDEX toma
momentneamente bloqueo exclusivo en la tabla padre, bloqueando tanto escribe y lee. La
posterior CREATE INDEX bloquea escrituras pero no lee; ya que el ndice no est all, hay
lectura intentar utilizarlo, lo que significa que no habr bloqueo pero lecturas podran ser
forzados a exploraciones secuenciales caros.

Reindexacin un nico ndice o tabla requiere ser el dueo de ese ndice o

tabla. Reindexacin una base de datos requiere de ser el propietario de la base de datos
(tenga en cuenta que el propietario, por tanto, puede reconstruir los ndices de las tablas que
pertenecen a otros usuarios). Por supuesto, siempre superusuarios pueden indexar cualquier
cosa.

Antes de PostgreSQL 8.1, REINDEX BASE DE DATOS procesa slo ndices del
sistema, no todos los ndices, como es de esperar de la marca. Esto ha sido cambiado para
reducir

el

factor

sorpresa. El

comportamiento

anterior

se

encuentra

disponible como SYSTEM REINDEX.

Antes de PostgreSQL 7.4, REINDEX TABLA no procesar automticamente las

tablas de pan tostado, y por lo que aquellos tuvieron que ser a indizar por comandos
separados. Esto sigue siendo posible, pero redundante.

Ejemplos
Reconstruir un nico ndice:
REINDEX NDICE my_index;
Reconstruye todos los ndices de la my_table tabla:
REINDEX my_table TABLE;
Reconstruye todos los ndices en una base de datos en particular, sin confiar en los ndices
del sistema sea vlida ya:
$ PGOPTIONS exportacin = "- P"
$ Psql broken_db
...
broken_db => REINDEX broken_db base de datos;
broken_db => \ q
TABLESPACES
Los Tablespaces permiten a los administradores de Bases de Datos definir las
ubicaciones en el sistema de archivos de los objetos que representan las bases de datos que
se pueden almacenar. Dicho de otra manera, nos permiten decirle a PostgreSQL donde
queremos almacenar nuestras tablas. Y para qu sirve esto? Pues por ejemplo para
optimizar el rendimiento; si sabemos que tablas son ms usadas y las que apenas se usan,
podramos almacenar las menos usadas en un disco duro antiguo o de menos prestaciones y
las que ms se usan en un disco ms rpido, de mejor calidad y por lo tanto ms caro.
Para definir un tablespace, utilice la sentencia CREATE TABLESPACE comando, por
ejemplo:
CREATE TABLESPACE fastspace LOCATION '/ mnt/sda1/postgresql/data';
La ubicacin debe ser una existente, directorio vaco que es de propiedad del usuario
del sistema de PostgreSQL. Posteriormente, todos los objetos creados dentro de tablas se
almacenan en los archivos bajo este directorio

Creacin de TABLESPACES debe hacerse como una base de datos de superusuario, pero
despus de que se puede permitir que la base de datos comn a los usuarios hacer uso de
ella. Para ello, les concedan el permiso CREATE en l.
Tablas, ndices, bases de datos enteras puede ser asignado a los TABLESPACES. Para
ello, un usuario con el privilegio de CREATE en un determinado tablespace deben aprobar
el nombre de tablas como un parmetro al comando. Por ejemplo, la siguiente crea una
tabla en la tablespace space1:
CREATE TABLE foo (i int) TABLESPACE space1;
Como alternativa, utilice el parmetro default_tablespace:
SET default_tablespace = space1;
CREATE TABLE foo (i int);
Cuando se establece default_tablespace a nada, pero una cadena vaca, que suministra
una clusula implcita TABLESPACE para CREATE TABLE y CREATE INDEX
comandos que no tienen una explcita.
Tambin hay un parmetro temp_tablespaces, que determina la colocacin temporal
de tablas e ndices, as como los archivos temporales que se utilizan para fines tales como la
clasificacin de grandes conjuntos de datos. Esto puede ser una lista de nombre de
tablespace, en lugar de uno slo, de modo que la carga asociada a los objetos temporales se
puede propagar a travs de mltiples tablespaces
Por lo general no tiene mucho sentido en la toma de ms de una lgica de tablas por
sistema de archivos, ya que no puede controlar la ubicacin de los archivos individuales
dentro de un sistema lgico de archivos. Sin embargo, PostgreSQL no garantice el
cumplimiento de cualquier limitacin de este tipo y, de hecho, no es directamente
consciente de los lmites del sistema de archivos en su sistema. Slo almacena los archivos
en los directorios que decirle que para su uso.