• Author / Uploaded
• Anna Sepulveda

• Categories
• PostgreSQL
• SQL
• Unidad central de procesamiento
• Sistema operativo
• Bases de datos

Citation preview

AA2-EV4 PLAN DE CONFIGURACIÓN Y RECUPERACIÓN ANTE DESASTRES PARA SMBD ANA DILIA SEPULVEDA ARENA JOSE FABIO ROZO ROZO

Introducción.

Hemos elegido el SMBD de Postgresql, gestor de código libre con características de control de concurrencias multi versión MVCC, este método agrega una imagen del estado de la base de datos a cada transacción, esto permite realizar transacciones eventualmente consistentes , ofreciendo grandes ventajas de rendimiento, por ejemplo no se requiere usar bloqueos de lectura al realizar transacciones, otra característica es el Hot-Standby que permite generar consultas mientras un servidor está en modo recuperación o espera, el beneficio que aporta este gestor de datos es realizar varias operaciones sin truncar el motor en estados de mantenimiento o recuperación del sistema, cosa que no ofrece algunos motores como MSSQL. La herramienta pgAdmin permite administrar las bases de datos en PostgreSql, a través de esta herramienta nos proporciona gestionar el diseño de la base de datos, gestionar y administrar consultas, recursos físicos y lógicos.

Componentes del SMBD PostgreSql

PostgreSql está formado por numerosos componentes y todos y cada uno de estos componentes influyen en mayor ó en menor medida en el rendimiento de nuestro sistema. En el siguiente gráfico ilustra los posibles diferentes componentes de nuestro sistema de forma jerárquica.

Generalmente, cuando tengamos un problema de rendimiento empezaremos la búsqueda de la causa en la capa inferior (hardware) e iremos subiendo progresivamente a la siguiente capa superior hasta localizar el problema.

AA2-EV4 PLAN DE CONFIGURACIÓN Y RECUPERACIÓN ANTE DESASTRES PARA SMBD ANA DILIA SEPULVEDA ARENA JOSE FABIO ROZO ROZO

Tipos de aplicaciones Desde el punto de vista de un administrador de bases de datos, existen a grandes rasgos tres tipos de aplicaciones: •

Aplicaciones web (Web)

•

Aplicaciones de procesamiento de transacciones en línea (OLTP)

•

Almacenes de datos (data warehouse - DW)

A continuación se muestra las características generales diferenciadoras más importantes de estos tipos de aplicaciones:

Aplicaciones web (Web) •

Base de datos más pequeña que el total de RAM

•

El 90% ó más de las consultas, son consultas simples

•

Limitada por la CPU

• Los problemas típicos que se suelen dar son: cache, pooling, tiempos de conexión.

Aplicaciones de procesamiento de transacciones en línea (OLTP) •

Base de datos ligeramente más grande que el total de RAM y hasta 1 TB

• El 20%-40% de las consultas son pequeñas consultas que actualizan datos •

Unas pocas transacciones grandes y consultas de datos complejas

•

Limitada por CPU ó I/O

•

Los problemas típicos son: bloqueos (locks), cache, transacciones,

velocidad de escritura, registros (logs)

Almacenes de datos (data warehouse - DW) •

Base de datos muy grande (de 100GB a 100TB)

•

Consultas grandes y complicadas para generar informes

•

Actualización de datos en grandes bloques (bulk load)

•

Limitada por I/O ó RAM

AA2-EV4 PLAN DE CONFIGURACIÓN Y RECUPERACIÓN ANTE DESASTRES PARA SMBD ANA DILIA SEPULVEDA ARENA JOSE FABIO ROZO ROZO

• Los problemas típicos son: escaneos secuenciales (seq scans), recursos, consultas inefectivas, actualizaciones masivas (bulk load)

Técnicas y procedimientos

Una vez que hemos visto los posibles componentes que pueden formar parte de nuestro sistema y los diferentes tipos de aplicaciones con los que nos podemos encontrar, vamos a pasar a ver procedimientos y técnicas que podemos utilizar para identificar y arreglar problemas de rendimiento en nuestro sistema.

A continuación se evidencia la estrategia a seguir para localizar problemas: 1.

Recolección de información:

Esta es una de las fases más importantes y cruciales, en ella tenemos que intentar entender que está haciendo el sistema que vamos a arreglar, que componentes se están utilizando y como estos componentes funcionan e interactúan entre sí. Tendremos que identificar de qué tipo de aplicación se trata, que intenta hacer la aplicación, como utiliza la base de datos, que tipo de problemas están teniendo los usuarios, etc. En definitiva, obtener una visión general de como el sistema hace las cosas e intentar identificar posibles áreas problemáticas del mismo. 2.

Comprobación general de la configuración básica del sistema:

En esta fase se realiza un recorrido general sobre la configuración del sistema para comprobar en qué estado se encuentra. Comprobaremos la configuración del hardware y el sistema operativo, de PostgreSQL, middleware, si existe, y de la aplicaciones usando el sistema. 3.

Identificación de posibles problemas:

En esta fase se realiza un análisis de los diferentes componentes del sistema para tratar de identificar posibles problemas que afecten al rendimiento. Probablemente ya hayamos identificado varios problemas durante el item1 y 2. 4.

Arreglo del mayor problema identificado:

Una vez identificado el mayor problema, tendremos que buscar la solución del mismo. 5.

Repetición:

Cuando el primer problema más importante esté arreglado volver a repetir los ítems 3 y 4 hasta que estemos seguros con el resultado.

AA2-EV4 PLAN DE CONFIGURACIÓN Y RECUPERACIÓN ANTE DESASTRES PARA SMBD ANA DILIA SEPULVEDA ARENA JOSE FABIO ROZO ROZO

Vamos a ver qué tipo de información deberíamos de recolectar y que deberíamos comprobar en los diferentes componentes del sistema que tengan problemas. Como ya hemos dicho, generalmente empezaremos con el hardware e iremos subiendo progresivamente a las capas superiores, aunque esto dependerá del sistema y algunas veces cambiaremos el orden. A continuación relacionamos la información sobre los componentes y los puntos más comunes que se deberían comprobar: Hardware

• • •

Servidores Modelo de CPU, velocidad de la CPU, numero de CPUs disponibles, arquitectura, uso de las mismas Cantidad de RAM, velocidad de la RAM, configuración de la misma

• • • • • • •

Almacenamiento Tipos de interfaces (controladores, RAID) Tipos de discos, tamaño y velocidad de los mismos Configuración del Array/SAN Red Tipo de red y capacidad de la misma Tarjetas de red usadas, modelos

• • • •

Sistema operativo Sistema operativo Tipo de SO, versión, parches aplicados, modificaciones locales Información sobre los controladores de hardware usados

• • • •

Sistema de ficheros Tipo de sistema de ficheros que estamos utilizando Localización de los ficheros del sistema operativo, PostgreSQL y otras aplicaciones Configuración del sistema de fichero utilizado

•

PostgreSQL

• • • • •

Schema Diseño, modelo de datos Tamaño de los datos Particionado de los datos, tablespaces Índices usados

AA2-EV4 PLAN DE CONFIGURACIÓN Y RECUPERACIÓN ANTE DESASTRES PARA SMBD ANA DILIA SEPULVEDA ARENA JOSE FABIO ROZO ROZO

•

Procedimientos almacenados en uso

• • • •

Configuración ¿Qué cambios se han realizado en la configuración estándar? ¿Se ejecutan trabajos de mantenimiento (VACUUM/ANALYZE)? ¿Con que frecuencia y configuración se ejecutan los trabajos de mantenimiento? Comprobar los parámetros más importantes, unos valores orientativos que se podrían usar serian :

•

• • • • • •

Middelware Controladores, Conexiones y Cache Tipo y versión usada de los controladores DB Método de conexión usada, pooling usado, configuración del pooling Método de cache usado, herramientas usadas para administrarlo, versión y configuración Software ORM utilizado y versión

• • • • • •

Aplicación Consultas SQL,Transacciones Tipo de aplicación Modelo y tipo de transacciones Tipos y números de consultas Herramientas

Existen numerosas herramientas que se pueden utilizar para intentar localizar diferentes problemas en nuestro sistema. Dependiendo de la parte del sistema que estemos analizando usaremos unas u otras. Hardware y sistema operativo

Herramientas del sistema operativo Estas herramientas suelen ser muy fáciles de usar, no suelen afectar al resto del sistema mientras que las utilizamos y nos pueden ayudar a monitorizar y obtener estadísticas de cómo está funcionando el hardware y nuestro sistema en general. ps: Nos permite ver los procesos postgreSQL que se están ejecutando en nuestro servidor. Nos da una idea de la cantidad de procesos concurrentes y el uso de CPU y memoria que tienen. También nos permite identificar consultas que se han colgado, que están bloqueadas ó que llevan ejecutándose mucho tiempo.

AA2-EV4 PLAN DE CONFIGURACIÓN Y RECUPERACIÓN ANTE DESASTRES PARA SMBD ANA DILIA SEPULVEDA ARENA JOSE FABIO ROZO ROZO

pg_top: Este programa nos suministra mucha de la información que ps nos da y otra relacionada exclusivamente con postgreSQL. mpstat: Nos proporciona información sobre el uso de todas las CPU de nuestro sistema. Podemos encontrar los recursos de CPU que se están usando, si estamos usando todas las CPU disponibles ó si tenemos problemas de 'cambio de contexto'(context-switch) vmstat, free: Nos permite ver el uso que estamos haciendo de la memoria. Podemos ver si la memoria está saturada, si podemos tener más información en cache ó si estamos utilizando el swap de nuestro sistema. iostat: Para monitorizar el uso de los dispositivos de almacenamiento de nuestro sistema. Podemos ver si el subsistema I/O está saturado, si alguno de los dispositivos está causando un embotellamiento del resto de los dispositivos, ó si tenemos subidas puntuales del tráfico en los discos debido a los 'checkpoint' generados por PostgreSQL. sar: Se puede utilizar para obtener información de la actividad del sistema durante un periodo de tiempo definido. Test de rendimientos Los test de rendimientos suelen ser muy intrusivos y suelen afectar al resto del sistema mientras que se ejecutan. Por esto, no siempre se pueden usar en sistemas en producción que están funcionando con ciertos problemas pero que tienen que seguir funcionando aunque su rendimiento no sea el óptimo. Permiten comparar resultados entre sistemas con mismo hardware y sistema operativo. dd: Lee y escribe datos de manera secuencial bonnie++: Para comprobar el rendimiento y posibles problemas con I/O. Comprueba entre otras cosas, la velocidad de búsqueda (seek) y escritura aleatoria del sistema. IOzone: Comprueba las velocidades de diferentes operaciones. PostgreSQL Views y funciones de sistema Muy fáciles de usar, su uso no afecta al rendimiento de nuestro sistema. Nos proporcionan información sobre lo que está ocurriendo internamente en nuestra base de datos y nos pueden ayudar a identificar problemas relacionados con el diseño/modelo de datos, consultas, procedimientos almacenados y bloqueos. pg_stat_database, pg_database_size(): Para conseguir estadísticas de tráfico generales, números de conexiones, número de transacciones válidas (commits) y abortadas (rollback), proporción de aciertos de datos en cache, tamaño de la base de datos.

AA2-EV4 PLAN DE CONFIGURACIÓN Y RECUPERACIÓN ANTE DESASTRES PARA SMBD ANA DILIA SEPULVEDA ARENA JOSE FABIO ROZO ROZO

pg_tables, pg_relation_size(): Para obtener información sobre las tablas de nuestra base de datos, cuantas existen, si tienen disparadores, índices ó reglas asociadas, y el tamaño de las tablas e índices de la base de datos pg_stat_activity: Para comprobar la actividad actual en la base de datos, consultas en ejecución, bloquedas, conexiones concurrentes, ociosas (idle), etc pg_locks: Para descubrir y comprobar conflictos con bloqueos. pg_stat[io]_user_tables, pg_stat[io]_user_indexes: Para comprobar la actividad relacionada con las tablas y los índices de nuestra base de datos, informacion sobre 'seq scans', I/O, etc pg_stat_bgwriter: Para comprobar estadísticas relacionadas con el proceso 'background writer' encargado de los ficheros WAL. pg_stat_user_functions (8.4): Para obtener los tiempos de ejecución de nuestras funciones, diferenciando entre tiempos de llamada y ejecución del código. pg_stat_statements (contrib 8.4): Este módulo 'contrib' se puede utilizar para obtener una relación de consultas en ejecución junto con información sobre las más frecuentes y las más lentas PostgreSQL logs, pgfouine y auto-explain No hay nada como un buen fichero log para obtener información sobre lo que ha ocurrido en nuestro sistema. pg_log: Existen multitud de opciones en el fichero de configuración postgresql.conf para activar/desactivar los datos que nos interese registrar. La información obtenida mediante el log de postgreSQL se podrá analizar para obtener información en el caso de tener problemas. pgfouine: Se puede utilizar para calcular estadísticas generales de las consultas enviadas a la base de datos. Las consultas más frecuentes y más lentas no serán un misterio después de utilizar este producto. auto-explain (8.4): Registra en el fichero log de postgreSQL la información sobre 'explain plans' de las consultas que queramos. Se puede activar/desactivar dinámicamente. Explain analyze El comando SQL 'explain analyze [consulta SQL]' se puede utilizar con consultas lentas para obtener información sobre las causas de la falta de velocidad. Muchas veces podremos arreglar la causa rápidamente y otras nos darán información sobre posibles causas a investigar. El resultado de este comando es un árbol invertido de nodos el cual deberíamos de empezar a leer de abajo hacia arriba. Habría que empezar a buscar el nodo más bajo con problemas e intentar interpretar el resultado de

AA2-EV4 PLAN DE CONFIGURACIÓN Y RECUPERACIÓN ANTE DESASTRES PARA SMBD ANA DILIA SEPULVEDA ARENA JOSE FABIO ROZO ROZO

manera integral/global, ya que algunos nodos se pueden ejecutar en paralelo e influenciarse mutuamente. Algunas de las cosas que se deberían de comprobar y buscar en el resultado del comando 'Explain analyze' son: • • •

Estimaciones erróneas del número de filas en una tabla 'Index scans' y 'seq scans' lentos Ordenación de datos en disco en vez de en memoria

Test de rendimientos •pgbench: Test de rendimiento muy simple con el que se puede comprobar el subsistema I/O y la velocidad a la que se procesan las conexiones. No comprueba bloqueos, computación de datos ó 'query planning'. Util para demostrar problemas importantes de hardware ó en el sistema operativo. • • •

DBT2: Test muy completo y costoso de ejecutar. Basado en TPCC es un completo test de rendimiento para sistemas OLTP. DBT3: Nuevo test OLTP + DW Otros: pgUnitTest, EAstress, BenchmarkSQL

Middelware / aplicación Existen también una serie de herramientas que se pueden utilizar a nivel del middelware/aplicación que nos pueden ayudar a obtener información valiosa que nos ayude a localizar nuestro problema. Enumeramos solo algunas de las más importantes: • • •

Herramientas para servidores de aplicaciones: Se pueden usar para analizar los tiempos de respuesta, monitorización de la actividad de la base de datos, y monitorización del uso del cache. Simulación de cargas: Herramientas como lwp y reproductores de información contenida en ficheros log. Herramientas para detectar bugs: Valgrind, MDB, GDB

Problemas de rendimiento típicos Problemas de rendimiento más comunes. Problemas con el subsistema I/O Cuando tenemos problemas con el subsistema I/O, lo más normal es que las CPUs estén subutilizadas, tengamos memoria disponible y al menos un dispositivo de almacenamiento con el I/O saturado. Estos problemas suelen darse en sistemas del tipo OTLP y DW (data warehouse), bases de datos muy grandes ó bases de datos con un ratio de escritura muy alto. Las causas comunes de este tipo de problemas son:

AA2-EV4 PLAN DE CONFIGURACIÓN Y RECUPERACIÓN ANTE DESASTRES PARA SMBD ANA DILIA SEPULVEDA ARENA JOSE FABIO ROZO ROZO

• • • • •

Problemas con el hardware/software encargado del subsistema I/O Mala configuración del subsistema I/O No suficiente memoria Demasiados datos demandados por la aplicación Schema no óptima, falta de índices ó particionamiento de datos

Problemas con CPU Cuando tenemos problemas con el uso de la CPU, lo más normal es que estemos usando el 90% ó más de la capacidad de CPU disponible, tengamos memoria disponible y el subsistema I/O noe esté saturado. Estos problemas suelen darse en sistemas del tipo Web y OTLP, bases de datos con una gran cantidad de consultas de lectura ó consultas en las que se realizan cálculos complejos. Las causas comunes de este tipo de problemas son: • • • • •

Demasiadas consultas Insuficiente cache/pooling Demasiados datos demandados por la aplicación Consultas mal construidas Schema no óptima, falta de índices

Problemas de bloqueos Cuando tenemos este tipo de problema, lo más normal es que ni la base de datos, ni la aplicación estén trabajando al máximo, pero tengamos muchas consultas con grandes periodos de espera, un alto índice de 'cambio de contexto' (context switching), y pg_locks mostrando consultas bloqueadas. Estos problemas suelen darse en sistemas del tipo OTLP y DW (data warehouse), ó trabajos que usen bloqueos pesimistas ó procedimientos almacenados. Las causas comunes de este tipo de problemas son: • • • • • •

Ejecuciones de larga duración de transacciones ó procedimientos almacenados Cursores mantenidos durante mucho tiempo Bloqueos pesimistas en vez de optimistas ó bloqueos definidos por los usuarios Gestión mala de transacciones Varias configuraciones de buffers en postgresql.conf con valores muy bajos Límites en la escalabilidad de PostgreSQL en sistemas SMP

Problemas con la aplicación Cuando tenemos este tipo de problema, lo más normal es que la base de datos no esté trabajando al máximo, pero el uso de la memoria y/o la CPU en el servidor de aplicación estén al máximo.

AA2-EV4 PLAN DE CONFIGURACIÓN Y RECUPERACIÓN ANTE DESASTRES PARA SMBD ANA DILIA SEPULVEDA ARENA JOSE FABIO ROZO ROZO

Estos problemas suelen darse en sistemas J2EE Las causas comunes de este tipo de problemas son: • • • •

No tenemos suficientes servidores de aplicaciones Demasiados datos/consultas demandados por la aplicación Mala configuración del cache/pooling Problemas con los controladores DB Configuración en postgresql.conf

Para cargar fácilmente grandes cantidades de datos a una base de datos de PostgreSQL, es posible que deba aumentar los valores de shared_buffers y max_locks_per_transaction en el archivo postgresql.conf. shared_buffers El parámetro shared_buffers designa la cantidad de memoria que se utiliza para los búfers de memoria compartida. La documentación de PostgreSQL indica que, por razones de rendimiento, es probable que deba utilizar una configuración mayor al valor mínimo de 128 KB o 16 KB multiplicado por el número que se configuró como el valor de max_connections. Se recomienda configurar shared_buffers para utilizar varias decenas de megabytes en las instalaciones de producción. Cuando carga grandes cantidades de datos, es muy probable que necesite una mayor configuración de shared_buffers que el valor predeterminado de 32 MB. Después de cambiar este parámetro en el archivo postgresql.conf, deberá reiniciar el cluster de base de datos. max_locks_per_transaction El valor de max_locks_per_transaction indica la cantidad de objetos de base de datos que se pueden bloquear de manera simultánea. En la mayoría de los casos, el valor predeterminado de 64 es suficiente. Sin embargo, cuando se carga una gran cantidad de datasets (por ejemplo, varios miles) a la vez, la cantidad de bloqueos de objeto concurrentes para la transacción puede exceder 64. No hay una relación de uno a uno entre bloqueos concurrentes y la cantidad de datasets; en otras palabras, si carga 3.000 datasets, no debe aumentar el valor de max_locks_per_transaction a 3.000. Primero aumente el valor a 100 antes de aumentar las cargas. Cuando cambia el valor del parámetro max_locks_per_transaction, debe reiniciar el servidor. El aumento del valor de alguno de estos parámetros puede producir que la base de datos solicite más memoria compartida que la que el sistema operativo (SO) UNIX tiene disponible. Para obtener más información sobre cómo puede

AA2-EV4 PLAN DE CONFIGURACIÓN Y RECUPERACIÓN ANTE DESASTRES PARA SMBD ANA DILIA SEPULVEDA ARENA JOSE FABIO ROZO ROZO

aumentar la configuración de la memoria compartida para el SO, consulte "Administrar recursos de kernel" en la documentación de PostgreSQL. Mejorar el rendimiento de la consulta espacial de SQL Cuando ejecuta consultas de SQL que devuelven columnas espaciales de ST_Geometry desde una tabla de negocios, puede aumentar el rendimiento de la consulta si configura una variable de entorno del sistema, ST_GEOMETRY_OUTPUT_FORMAT, con salida hacia el tipo ST_Geometry en vez de la representación de texto conocido extendido (WKT). Por defecto, la variable ST_GEOMETRY_OUTPUT_FORMAT se configura como TYPE, que significa que se devuelve una representación hexabinaria. Es necesario para crear una copia de seguridad útil de la geodatabase. Únicamente debe cambiar esta variable a ST_GEOMETRY si desea mejorar el rendimiento de la consulta SQL. Si configura esta variable porque planea hacer varias consultas espaciales de SQL, asegúrese de quitarla después de terminar las consultas, a continuación reinicie el cluster de base de datos de PostgreSQL. • • • • • • • • •

La variable se debe configurar en el equipo donde se ejecuta PostgreSQL. Para un SO Linux, configure la variable para el shell desde donde emite las consultas SQL. Para el shell bash, la sintaxis es la siguiente: ST_GEOMETRY_OUTPUT_FORMAT=ST_GEOMETRY Para un shell csh, la sintaxis es setenv ST_GEOMETRY_OUTPUT_FORMAT ST_GEOMETRY En Windows, cree una variable de entorno del sistema en las propiedades del sistema. Nombre de la variable: ST_GEOMETRY_OUTPUT_FORMAT Valor de la variable: ST_GEOMETRY Después de configurar la variable, debe reiniciar el cluster de base de datos de PostgreSQL.

WORK_MEM Este parámetro configura el espacio de memoria que postgres utiliza para realizar ordenaciones de tablas o de resultados parciales de consultas, sobre todo en cláusulas ORDER BY, CREATE INDEX o MERGE JOIN. Este valor es más dificil de configurar porque depende, por un lado, de lo grande que sean las tablas o resultados que hay que ordenar, y por otro, del número de peticiones simultáneas para esa misma consulta (para cada una se empleará la misma cantidad de memoria). Un buen comienzo es asignar entre un 2% y un 4% del total de la memoria si prevemos pocos accesos simultáneos a grandes sesiones de ordenación y mucho menor, si esperamos muchos accesos simultáneos a sesiones de ordenación pequeñas. Como antes, lo mejor es ir probando distintos valores y

AA2-EV4 PLAN DE CONFIGURACIÓN Y RECUPERACIÓN ANTE DESASTRES PARA SMBD ANA DILIA SEPULVEDA ARENA JOSE FABIO ROZO ROZO

ver en qué pueden afectar a la paginación adversa (swap pagein). El valor hay que expresarlo en KB. En nuestro ejemplo, hemos optado por usar un 4% de la memoria: El 4% de 1 GB: 41943 KB (1048576 KB*4)/100 work_men = 41943 PostgreSQL utiliza roles para iniciar la sesión en el cluster de bases de datos y en las bases de datos. Se pueden agregar roles al cluster de bases de datos PostgreSQL. Los usuarios de bases de datos individuales se llaman roles de inicio de sesión. Para todos los roles de inicio de sesión que serán propietarios de objetos en la geodatabase, también debe crear un esquema en esa base de datos. El esquema debe tener el mismo nombre y ser propiedad del rol de inicio de sesión. También puede crear grupos de roles a los que se pueden agregar roles de inicio de sesión. A continuación, puede especificar permisos para el grupo que se aplicarán a todos los roles de inicio de sesión asociados.

Almacenamiento

Se puede crear una base de datos en una localización diferente a la establecida por defecto durante la instalación. Recuerde que todos los accesos a base de datos ocurren realmente a traves del proceso en segundo plano, así que éste debe poder acceder acualquier especificación. Se crean localizaciónes alternativas y referencias mediante una variable de entorno queda el path absoluto hasta la situación de almacenamiento deseada. Esta variable deentorno debe estar definida antes de que el proceso en segundo plano sea arrancado y debe ser modificable mediante la cuenta del administrador de postgres. Cualquier variable de entorno puede ser utilizada para referirse a una localización alternativa, si bien se recomienda la utilización de un nombre de variable con prefijo PGDATA para evitar confusión y conflicto con otras variables. No olvidar que En versiones previas de Postgres, también estaba permitido utilizar un nombre de path absoluto para especificar una localización de almacenamiento alternativa. Se prefiere el método de especificación de variables de entorno, puesto que concede al administrador del sistema más flexibilidad en la gestión del almacenamiento en disco. Si prefiere utilizar paths absolutos, puede hacerlo definiendo "ALLOW_ABSOLUTE_DBPATHS" y recompilando Postgresql

AA2-EV4 PLAN DE CONFIGURACIÓN Y RECUPERACIÓN ANTE DESASTRES PARA SMBD ANA DILIA SEPULVEDA ARENA JOSE FABIO ROZO ROZO

Sistema de recuperación de desastres y copias de seguridad

El proceso de creación de Backup en PostgreSQL se realiza por medio de pg_dump, y la automatización para su ejecución se puede lograr por medio de herramientas como las que se incluye en PGADMIN haciendo uso de los Job, steps y schedules o mediante el sistema operativo, que en esta caso serna Windows y Linux.

A través de foros se pudo observar distintas formas de hacer Backup, pero la mejor sería si es Automático, ya que así el DBA no tendrá la necesidad de estar presente cuando deba respaldar la Base de Datos. Desde la Página de PostgreSQL se puede constatar que, es una Base de Datos Robusta, además de ser Opensource llega a ver los Respaldos de manera Lineal para el negocio transaccional, es así que además de Respaldos PostgreSQL se pueda notificar al DBA de los sucesos ocurridos en dicho Respaldo. Las encuestas que se realizaron a los DBA tuvieron sus Positivismo y Negativismo en la Propuesta de Automatización de Respaldos PostgreSQL; la mayoría de los Administradores acogieron y aceptaron que Automatizar los Respaldos de una Base Respaldos PostgreSQL Automáticos y Notificaciones Vía Mail 53 de Datos seria ahorrar tiempo además de que el proceso garantiza la Integridad de los Datos, que es de suma importancia al momento de restaura o recuperar una Base de Datos, muy poco fue la negatividad de los DBA sobre la Automatización ya que la ven como un proceso no seguro que no resguardara la información de manera correcta , que además no garantiza la integridad de la información, pero sobre todo eso la gran parte de DBA acepta el cambio Automático como una Herramienta útil en su Administración Diaria. El proceso de Respaldos Automáticos consiste en lo siguiente: Se realizan los Respaldos Automáticos a través de Tareas Programadas en Windows y Cron en Linux. Genera LOG de sucesos de los Respaldos de la Base de Datos. Envía dicho LOG por mail al DBA para que revise el suceso si hubo o no error en los Respaldos.

Por último es importante crear tareas programadas con el sistema operativo con el propósito de exportar la data a otros sistemas de almacenamiento para tener a mano la información en casos extremos o de urgencia para restaurar el sistema de información.

AA2-EV4 PLAN DE CONFIGURACIÓN Y RECUPERACIÓN ANTE DESASTRES PARA SMBD ANA DILIA SEPULVEDA ARENA JOSE FABIO ROZO ROZO