Antes de cargar el contenido del fichero, aprovechamos para fijarnos en los archivos WAL, que ya más adelante comentaremos con más detalle.

Transcripción

1 Objetivos: o pg_dump o pg_restore o COPY TO/FROM o OIDs o Vacuum o Reindex Preparación de la práctica: Para estos ejercicios vamos a cargar una base de datos "grande", con muchos datos, para ello nos bajaremos de la web el fichero bdgrande.tar.gz y lo descomprimiremos con: tar xvfz bdgrande.tar.gz Antes de cargar el contenido del fichero, aprovechamos para fijarnos en los archivos WAL, que ya más adelante comentaremos con más detalle. Apagamos la BD, borramos el fichero de log y arrancamos: $ pg_ctl -D $PGDATA stop $ rm $PGLOG para vaciar el fichero y ver mejor su contenido $ pg_ctl -D $PGDATA -l $PGLOG start Ahora vemos el contenido del directorio $PGDATA/pg_xlog: drwx postgres postgres 1024 Oct 19 03:29. drwx postgres postgres 1024 Oct 19 22:10.. -rw postgres postgres Oct 19 22: rw postgres postgres Oct 18 02: A -rw postgres postgres Oct 18 02: B -rw postgres postgres Oct 18 02: C -rw postgres postgres Oct 18 02: D -rw postgres postgres Oct 18 02: E -rw postgres postgres Oct 19 03: F drwx postgres postgres 1024 Jun 13 02:35 archive_status y ahora realizamos la carga de los datos, suponemos que nos conectamos a una base de datos, por ejemplo, usemos la de coches-empresa que se llama "curso", donde existe un usuario llamado "curso": $ psql curso < curso-datos.sql 2>&1 tee curso-datos.log y volvemos a ver el contenido del directorio $PGDATA/pg_xlog: drwx postgres postgres 1024 Oct 19 22:40. drwx postgres postgres 1024 Oct 19 22:10.. -rw postgres postgres Oct 19 22: F -rw postgres postgres Oct 19 22: rw postgres postgres Oct 19 22: rw postgres postgres Oct 19 22: rw postgres postgres Oct 19 22: rw postgres postgres Oct 19 22: rw postgres postgres Oct 19 22: drwx postgres postgres 1024 Jun 13 02:35 archive_status vemos que se han creado 6 archivos de 16Mb, correspondientes a la carga de estos datos. 1

2 TABLAS DE LA BASE DE DATOS: tabla filas pk uk bq 2 pk_busqexp ca 400 pk_codifica cn 2 co 12 pk_campo cp 52 pk_compo cs ds pk_documentos ed 15 pk_entidad es pk_expedientes fk_expedientes_entidad, expedientes_anyo, expedientes_numero la 2 fk_lista_campo lo 18 pk_listado mo 15 pk_macro ol pk_objvincul obj_id2, obj_tabla2 pa pk_pagina pc fk_pagpdoc_pdoc fk_pagpdoc_paginas, fk_pagpdoc_pdoc pq 1 pk_parambusq pt 45 pk_perent fk_perent_perfil, fk_perent_entidad te 2 fk_tipode_campo to 6 pk_tcompo tp 6 pk_tipo tt 8 fk_texto_campo pk_texto va 6 pk_valida vt 15 pk_vista fk_vista_nodo, fk_vista_entidad 2

3 1. Usando pg_dump, volcar el contenido del esquema coches y luego cargarlo en una base de datos nueva, llamada bdimport, con un usuario nuevo llamado import en un esquema. El fichero de volcado tiene que tener las siguientes características: ser un fichero plano de texto, donde se borre el esquema y los objetos previamente, con sentencias Insert, con codificación LATIN9, sin información de los propietarios ni de privilegios. Para tener claro, creamos la base de datos, el usuario (normal) $ createdb bdimport -E latin9 $ createuser import así probamos el entorno interactivo realizamos la exportación de datos $ pg_dump -f coches.sql -F p -c -d -E latin9 -n coches -O -x curso y luego cargamos estos datos en la nueva base de datos: $ psql -U import bdimport < coches.sql 2. El anterior ejercicio, se crean las tablas en el esquema public, qué habría que hacer para que los creara en un esquema llamado impcoches? Vamos a ver aquí un ejemplo de cómo cambiar de sesión sin salir de psql. Con el usuario import, creamos el esquema (veremos que no tenemos privilegios y se los daremos con el usuario postgres): $ psql -U import bdimport postgres=> create schema impcoches; responde que no tiene privilegios postgres=> \c bdimport postgres postgres=> grant create on database bdimport to import; postgres=> \c bdimport import postgres=> create schema impcoches; postgres=> set search_path=impcoches,pg_catalog; postgres=> \i coches.sql 3. Supongamos que necesitamos copiar el cluster que tenemos, con todos los usuarios, bases de datos, etc en otro cluster, pero que este cluster, y sus bases de datos, estén en UTF8. Realizar las operaciones necesarias (crear el cluster nuevo, exportar los datos del antiguo e importar en el nuevo). El hecho de que el cluster nuevo esté en una codificación distinta dificulta nuestra operación, porque si no fuera por este cambio, haríamos lo siguiente: Exportar todo el cluster $ pg_dumpall > cluster5432.sql Crear el cluster nuevo y ponerlo en marcha, por ejemplo en el puerto 6000 e importar $ export PGDATA6=/home/postgres/data1 $ export PGLOG6=$PGDATA6/server.log $ initdb -D $PGDATA6 -E UTF8 --locale=es_es $ pg_ctl -D $PGDATA6 -l $PGLOG6 -o "-i -p 6000" start con el "-i" evitamos tener que cambiar listen_addresses (postgresql.conf) y solo tenemos que añadir "host all all /0 trust" en pg_hba.conf y recargar $ psql -p 6000 template1 < cluster5432.sql 3

4 Pero lo anterior nos presenta varios problemas, uno es el comentado del cambio de codificación y el otro el hecho de que en el cluster original hay definidos varios tablespaces que no se van a poder crear porque apuntan a los mismos directorios. Para solucionar estos problemas, hay que realizar las operaciones por pasos. Admitimos que el cluster ha sido bien creado y arrancado, lo que vamos a cambiar es la exportación de datos y la importación. Un resumen de los pasos a seguir es: exportar únicamente la parte global del cluster (usuarios, tablespaces, roles), modificar los tablespaces para que apunten a otras rutas, exportar las bases de datos cambiando la codificación e importar cada uno de los ficheros creados anteriormente. Exportamos la parte global del cluster 5432: $ pg_dumpall -p g > cluster5432_global.sql editamos el fichero para cambiar las rutas a los tablespaces así como creamos los directorios de dichas rutas. $ mkdir $HOME/data6/tbs00 ponemos estas rutas por ej. $ mkdir $HOME/data6/tbs01 ponemos estas rutas por ej. El siguiente paso es determinar qué base de datos hay que exportar/importar: $ psql -p l así vemos que son "bdimport" y "curso" las que hay que exportar: $ pg_dump -p f bdimport.sql -E utf8 bdimport $ pg_dump -p f curso.sql -E utf8 curso no usamos la opción "-C" porque se crearían las bases de datos en LATIN9. Ahora cargamos la parte global en el nuevo cluster: $ psql -p 6000 < cluster5432_global.sql > rdo.log y ahora creamos las bases de datos en UTF8 $ createdb -p D tbs00 -E utf8 -T template1 bdimport $ createdb -p D tbscurso -E utf8 -T template1 curso finalmente, importamos las bases de datos: $ psql -p 6000 bdimport < bdimport.sql > rdobdimport.sql $ psql -p 6000 bdimport < curso.sql > rdocurso.sql 4. Ahora vamos a suponer que tenemos que exportar la tabla curso.grande."es" del esquema "grande" en la base de datos "curso" a la base de datos "bdimport" al esquema "public" y lo queremos hacer exportando en formato comprimido. Realizar la exportación y luego importar la tabla. Exportamos la tabla $ pg_dump -f es.dat -F c -t es curso Para importar, se puede hacer directamente o convirtiendo el fichero en un SQL: modo 1: $ pg_restore -d bdimport -F c -t es es.dat modo 2: $ pg_restore -f es.sql -F c -t es es.dat $ psql bdimport < es.sql 4

5 otra forma de ejecutar, con tuberías: $ pg_restore -F c -t es es.dat psql bdimport 5. Usando el comando SQL "COPY TO " y "COPY FROM ", copiar los distribuidores cuyo cifc sea menor que '0004' a una tabla, llamada empresa.dist3 que se supone que ya existe y es una copia de coches.distribucion. Las operaciones hay que hacerlas con un superusuario, "postgres". $ psql curso Creamos la tabla que se supone que ya existe postgresql=> create table empresa.dist3 as select * from coches.distribucion; Creamos una tabla temporal para volcar a disco postgresql=> CREATE TEMP TABLE tmpdist AS select * FROM coches.distribucion WHERE cifc < '0004'; se borrará cuando se termine la sesión. postgresql=> COPY tmpdist TO '/home/postgres/temp/tmpdist.dat'; postgresql=> COPY empresa.dist3 FROM '/home/postgres/temp/tmpdist.dat'; 6. Pueden existir filas con OIDs repetidos en una tabla?. Teóricamente no se puede, pero vamos a demostrar que es posible, para ello haremos lo siguiente: crearemos una tabla con OIDs basándose en otra, luego exportaremos con COPY y OIDs esa tabla a un fichero y luego la importaremos con OIDs. Veremos que se repiten los OIDs. Creamos la tabla $ psql curso postgresql=> create table empresa.dist with oids as select * from coches.distribucion postsql=> copy empresa.dist to '/home/postgres/temp/distoid.dat' with oids; postsql=> copy empresa.dist from '/home/postgres/temp/distoid.dat' with oids; postsql=> select oid,* from empresa.dist order by cifc,codcoche; vemos que salen OIDs repetidos. 5

6 7. Para entender mejor el tema de los OIDs, vamos a realizar el siguiente ejercicio. Veamos primero si la tabla coches tiene OIDs. Luego creamos una tabla vehículos con los datos de coches pero con OIDs. Nos fijamos en el OID de un coche y luego lo borramos, después copiamos otra vez ese coche desde coches y comparamos el nuevo OID con el antiguo. Se puede actualizar un OID?, Se pueden introducir registros con un OID determinado? $ psql -U mgrcoches curso SQL> select oid,* from coches; responde que no hay oids SQL> create table vehiculos with oids as select * from coches; SQL> select oid,* from vehiculos; si que hay oids, nos fijamos que el oid del coche '001' es SQL> delete from vehiculos where codcoche = '001'; SQL> insert into vehiculos select codcoche from coches where codcoche = '001'; ahora el oid del coche '001' es , es distinto y no podemos actualizarlo ni insertarlo a voluntad, si jecutamos las dos sentencias siguientes, daran mensajes de error: SQL> update vehiculos set oid = where codcoche = '001'; SQL> insert into vehiculos (oid,codcoche,cifm,marca,modelo) values ( ,'001',....); 8. Realizar un vacuum analyze de la base de datos que contiene el esquema grande. Mirar cuanto vale la marca de tiempo del identificador de transaction antes y después de ejecutar el vacuum. También podemos fijarnos en el contenido de los directorios pg_clog y pg_xlog. $ select datname, age(datfrozenxid) from pg_database; responde $ vacuumdb -d curso -z -f después del vacuum, responde para la base de datos "curso", las demás siguen igual. Realizar un vacuum apenas afecta los ficheros de control de transacciones (en pg_clog) y apenas influye en los de WAL. 9. Realizar un vacuum completo de todo el cluster. Realizar las mismas comprobaciones $ vacuumdb -a -z -f después del vacuum, age(datfrozenxid) es del órden de para todas las bases de datos, menos para template1. Realizar un vacuum no afecta los ficheros de control de transacciones (en pg_clog) y apenas influye en los de WAL 10. Reindexar toda la base de datos. Realizar las mismas comprobaciones $ reindexdb -a después del vacuum, age(datfrozenxid) es del órden de para todas las bases de datos, menos para template1. Realizar un vacuum no afecta los ficheros de control de transacciones (en pg_clog) y apenas influye en los de WAL. Pero atención, si en la base de datos hubieran muchas actualizaciones, al reindexar cambiarían los ficheros WAL. 6