¿Hay vida más allá de Oracle? Lista de verificación de compatibilidad GDPR

La GDPR, o Reglamento General de Privacidad de Datos (UE) 2016/679, entrará en vigor en mayo de 2018. Tiene el potencial de alterar significativamente la forma en que las empresas gestionan y almacenan datos. Con más de 200 páginas, la regulación consolida y reemplaza las numerosas leyes locales de protección de datos, como la Ley de Protección de Datos del Reino Unido de 1998, la Privacywet belga, nuestra LOPD o la Bundesdatenschutzgesetz (BDSG) alemana. Las principales diferencias radican en la severidad de las posibles multas y nuevos requisitos tales como notificación de incumplimiento, derecho de acceso, derecho a ser olvidado, etc.

El objetivo principal de GDPR es fortalecer la seguridad y la protección de la privacidad de las personas. Mientras que GDPR comparte muchos principios de sus predecesores, que consta de 11 capítulos, 99 artículos y 187 considerandos, no es de ninguna manera una adaptación menor.

¿Quién esta sujeto a la GPRD?

El GDPR impone obligaciones legales a todos los controladores y procesadores de datos. se llama controlador de datos como la entidad que determina los propósitos y los medios de procesamiento de los datos personales, el procesador de datos se define como la entidad que procesa los datos personales en nombre del controlador. La GDPR se aplica al procesamiento llevado a cabo por organizaciones dentro del La UE y las organizaciones fuera de la UE que procesan o controlan los datos relacionados con residentes o nacionales de la UE.

Se centra principalmente en datos individuales, que se define en dos categorías de "Datos personales" y "datos personales confidenciales". Los datos personales incluyen datos tales como direcciones de correo electrónico y físicas, así como cualquier información que pueda usarse como un identificador en línea, una dirección IP. Los datos personales confidenciales arrojan una mayor neto y cubre elementos de datos tales como datos de salud, biométricos o genéticos.

Si todavía no cuenta con las herramientas y controles de seguridad necesarios, su la organización tendrá que implementar varios controles de seguridad nuevos, políticas, y procedimientos para demostrar el cumplimiento de GDPR. Por seguridad y organizaciones conscientes de la privacidad, la nueva regulación no debería provocar demasiado mucha sobrecarga técnica Para aquellos que aún no han logrado el cumplimiento de las leyes de protección de datos que GDPR reemplaza, el impacto será mucho mayor.

La GDPR requiere que las organizaciones mantengan un plan para detectar una violación de datos, evaluar regularmente la efectividad de las prácticas de seguridad y documentar evidencia de cumplimiento. En lugar de una dirección técnica específica, la regulación pone la responsabilidad en las organizaciones para mantener las mejores prácticas para la seguridad de los datos.

Punto1: Implementar una herramienta de Información de Seguridad y Gestión de Eventos con gestión de registros capacidades que cumplen con los requisitos de cumplimiento.

El Artículo 30 del GDPR establece que cada controlador y, cuando corresponda, el representante del controlador deberá mantener un registro de actividades de procesamiento bajo su responsabilidad.

Un SIEM (Herramienta de Información de Seguridad y Gestión de Eventos) suele ser una herramienta de seguridad fundamental para muchas organizaciones. Al implementar un SIEM, las compañías pueden monitorear a todos los usuarios y actividad del sistema para identificar el comportamiento sospechoso o malicioso. Esto se logra centralizando registros de aplicaciones, sistemas y establecer una red y correlacionar los eventos para alertar dónde se detecta actividad indeseable.

A continuación, puede investigar la causa de la alarma y crear una vista de lo que ocurrió al determinar si un método de ataque en particular se utilizó, mirando los eventos relacionados, la dirección IP de origen y destino, y otros detalles. También debe tener en cuenta los datos almacenados o procesados ​​en entornos de nube. Si los datos personales están en la nube, están dentro del alcance de GDPR, y por lo tanto es beneficioso elegir un SIEM que pueda mantener un registro de actividad en su nube pública y privada infraestructura, así como en las instalaciones.

Preguntas a responder:

• ¿Tiene una forma de centralizar, analizar y almacenar datos de registro de todos sus entornos?
• ¿Está alertado en tiempo real sobre cualquier actividad sospechosa o anómala?
• ¿Tiene una forma de almacenar de forma segura los datos de registro sin formato y para garantizar su integridad?

Solución con Oracle La interfaz de Audit Vault Server proporciona resúmenes gráficos de alertas. Estos incluyen un resumen de la actividad de alerta y las principales fuentes por cantidad de alertas. Puedes mediante un clic en los gráficos de resumen, acceder a informes más detallados. Para informar, las alertas se pueden agrupar por  Fuente.  Categoría de evento. Gravedad del evento.  También puede especificar notificaciones para las alertas generadas, por ejemplo, enviar automáticamente un correo electrónico a un usuario, como un oficial de seguridad o una lista de distribución. Las alertas también se pueden reenviar a syslog para facilitar la integración con un SIEM. Un ejemplo de solución SIEM de terceros es HP ArcSight Security Information Event Management, que es un sistema centralizado para registrar, analizar y administrar mensajes de diferentes fuentes. Audit Vault Server reenvía mensajes al sistema ArcSight SIEM desde los componentes Audit Vault Server y Database Firewall. No es necesario instalar software adicional para admitir esta integración. Se configura a través de la consola de Audit Vault Server y una vez habilitada la configuración se aplica inmediatamente. No es necesario reiniciar el servidor de Audit Vault. Integración Oracle Audit Vault - Remedy y ArcSight Integrar Oracle Audit Vault y Remedy Ticket System Oracle Audit Vault 12c incluye una interfaz estándar para los sistemas de ticketing de BMC Remedy. Puede configurar Oracle Audit Vault para conectarse a BMC Remedy Action Request (AR) System Server 7.x. Esta conexión permite a Oracle Audit Vault generar tickets de problemas en respuesta a las alertas de Audit Vault. Solo se puede configurar un servidor Remedy para cada instalación de Oracle Audit Vault. Después de que se haya configurado la interfaz, un auditor de Audit Vault necesita crear plantillas para mapear y manejar los detalles de la alerta. Integración HP ArcSight El sistema de administración de eventos de información de ArcSight Security de HP (SIEM) es un sistema centralizado para registrar, analizar y administrar mensajes de diferentes fuentes. Oracle Audit Vault puede reenviar mensajes a ArcSight SIEM. No se necesita ningún software adicional para integrarse con ArcSight. La integración se realiza a través de configuraciones en la consola de Audit Vault Server. Los mensajes enviados a ArcSight SIEM Server son independientes de cualquier otro mensaje enviado desde Audit Vault (por ejemplo, feeds de Syslog). Hay tres categorías de mensajes enviados: Sistema: mensajes de syslog de los subcomponentes de Audit Vault Server Info: Registro de cambios específicos de la información del componente de Firewall de base de datos de Oracle AVDF. Debug: una categoría que solo debe usarse bajo la dirección de Oracle Support. Si quieres más información mira este video.

Punto 2: crea un inventario de todos los activos críticos que almacenan o procesan datos confidenciales para permitir para controles más estrictos que se aplicarán.

El GDPR es expansivo y cubre todos los sistemas de TI, redes y dispositivos, incluidos los dispositivos móviles. Por lo tanto, es esencial que hace un inventario de todos los activos en su infraestructura y establece dónde se guardan los datos personales.

Es importante inventariar todos los activos y ubicaciones que procesan o almacenan datos personales, una tarea que parece simple en su superficie, pero a menudo es un área donde las organizaciones luchan. Esto es especialmente cierto en entornos de TI dinámicos, como la nube pública y en casos donde los empleados están usando BYOD o activos no aprobados por IT. Vale la pena señalar que su empresa podría ser expuestos a ataques y multas reglamentarias si los empleados procesan o almacenan datos personales en dispositivos no aprobados.

Sin prácticas sólidas de gobierno en su lugar, puede ser fácil perder el control de los activos. Por tanto, es importante para muestrear sus sistemas, redes y almacenes de datos para determinar si los datos personales están expuestos fuera de los flujos y entornos de datos definidos. Tenga en cuenta que este es un proceso. Los inventarios necesita actualizarse constantemente a medida que cambia su negocio y tecnología.

Preguntas a responder:

• ¿Qué activos están conectados a mi entorno en un momento dado?
• ¿Estos activos procesan o almacenan datos personales?
• ¿Qué puertos y protocolos se usan al transmitir o acceder a información personal?

Solución con Oracle Los sistemas DAM (Gestión de activos digitales) nos ayudan a controlar todo el ciclo de vida de las imágenes, documentos y ficheros multimedia. Nos ahorran inversión en TI ya que centralizan el repositorio de objetos facilitando el acceso mediante bancos, álbumes y vistas, logrando la eficiencia operativa de los usuarios en casi cualquier organización que emplee ficheros de imagen o audiovisuales como parte de sus procesos de negocio. Oracle DIVAdirector es un sistema de administración de activos digitales que le brinda control total de los activos alojados en Oracle DIVArchive a través de una interfaz familiar, de modo que puede ubicar, acceder y administrar rápidamente los medios. Mediante este producto podrás: Visualizar mediante credenciales de inicio de sesión y etiquetar contenido para una variedad de propósitos. Integrar con los servicios de edición y acabado Habilitar restauración parcial basada en código de tiempo (Timestamp)

Punto 3: Emprender el escaneo de vulnerabilidades a identificar dónde existen debilidades que podrían ser explotado.

La verdad sea dicha descubrimos y lo más preocupante, los atacantes descubren nuevas vulnerabilidades en sistemas y aplicaciones surgen casi diario. Por lo tanto, es esencial que su organización se mantenga alerta. Estas vulnerabilidades pueden existir en:

• El software (Java, PHP, Javascript y que decir de nuestro querido .NET)
• Configuración del sistema (Base de datos, servidor de aplicaciones, servidor web)
• En lógica de negocios. (BPM, SOA)
• En lógica de procesos. 

Así es importante considerar todos los aspectos de las vulnerabilidades y dónde ellos pueden existir Sin embargo, simplemente encontrar una vulnerabilidad a menudo no es suficiente. Hay muchos factores que deben considerarse como tales como si los sistemas están en el alcance de GDPR y lo que el la crítica al negocio es si se han intentado intrusiones y cómo los atacantes explotan la vulnerabilidad en el salvaje.

La evaluación efectiva de la vulnerabilidad requiere el escaneo continuo y el monitoreo de los activos críticos sobre los cuales los datos personales reside o es procesado. Es igualmente importante monitorear los entornos de la nube además de los entornos locales.

Al descubrir una vulnerabilidad, nos tenemos que preguntar:

• ¿Cuántos registros personales podrían estar expuestos?
• ¿Se han intentado intrusiones o exploits en el activo vulnerable?
• ¿Cómo es explotada la vulnerabilidad por los atacantes en la naturaleza?

Punto 4: Realice evaluaciones de riesgos y aplique modelos de amenazas relevantes para su negocio.

El artículo 35 del GDPR requiere que las organizaciones realicen una evaluación de impacto de la protección de datos (DPIA) o similar. Considerando que el artículo 32 de la regulación requiere que las organizaciones "implementen medidas técnicas y organizativas apropiadas para asegurar un nivel de seguridad apropiado para el riesgo ".

El uso de un marco de seguridad de la información puede ayudar proporcionando un punto de partida para que las organizaciones comprendan mejor los riesgos que enfrenta el negocio. Los marcos existentes como NIST, ISO / IEC 27001 o estándares similares pueden ayudar a las empresas en emprender y apoyar el proceso DPIA.

Si bien GDPR no especifica un marco para las evaluaciones de riesgo o el modelado de amenazas, una empresa el cumplimiento de cualquier norma bien establecida e internacionalmente reconocida demostrará el cumplimiento de los artículos 32 y 25 es mucho más probable en caso de incumplimiento.

Preguntas a responder:

• En caso de una violación de datos, ¿puedo demostrar que se implementaron los controles de seguridad adecuados?
• ¿Sé a qué amenazas se enfrenta mi organización y la probabilidad de que se materialicen?
• ¿Estoy al tanto de qué sistemas y unidades de negocios son de alto riesgo?

Punto 5: Realice pruebas regularmente para asegurarse de que los controles de seguridad funcionan según lo previsto.

El artículo 32 de la GDPR cubre la seguridad del procesamiento de datos personales. Entre los ejemplos que proporciona, se solicita un proceso para regularmente probando, evaluando y evaluando la efectividad de las medidas técnicas y organizativas para asegurar seguridad del procesamiento.

Evaluar y evaluar la efectividad de los controles de seguridad no es una hazaña fácil. Por lo general, cuanto mayor es el entorno TI, cuanto más dispares sean las pilas de tecnología, y cuanto más complejo sea el entorno. Por lo tanto, más difícil es ganar garantía.

Existen tres amplias técnicas para validar la efectividad de los controles de seguridad:

• Manual de cumplimiento. Esto implica auditorías, revisiones de aseguramiento, pruebas de penetración y actividades del Equipo Rojo (el término Equipo Rojo se usa tradicionalmente para identificar a grupos altamente calificados y organizados que actúan como rivales ficticios).
• Productos de seguridad integrados y consolidados, de modo que es necesario administrar e informar menos productos puntuales.
• El uso de tecnologías de aseguramiento automatizadas.

Con estos métodos, puede obtener una medida de seguridad de que sus sistemas

están asegurados según lo previsto. Sin embargo, vale la pena recordar que la seguridad no es un esfuerzo de una sola vez, sino un proceso continuo y repetible.

Preguntas a responder:

• ¿Qué nivel de confianza tiene en sus herramientas de seguridad?
• Si una herramienta o sistema falla, ¿se alertaría automáticamente?
• ¿Se están utilizando todas las herramientas de seguridad como se ha definido?

Punto 6: Implemente controles de detección de amenazas para informarle de manera oportuna cuando ocurra una infracción.

La GDPR requiere que las organizaciones informen al organismo regulador dentro de las 72 horas de estar al tanto de la infracción. Para alto riesgo eventos, el controlador debe notificar a los interesados ​​sin demora indebida (Artículo 31). El tiempo de compromiso típico continúa midiéndose en minutos, mientras que el tiempo de descubrimiento permanece en semanas o meses, en tales circunstancias, es esencial tener capacidades integrales de detección de amenazas que puedan detectar problemas tan pronto como ocurren.

Las amenazas pueden materializarse internamente en la empresa (normalmente) o externamente. Pueden estar en las instalaciones (on premise) o en entornos de nube (on cloud). Por lo tanto, es importante poder recopilar y correlacionar eventos rápidamente; y complementa la información con inteligencia de amenazas confiable para estar al tanto de las amenazas emergentes.

No hay un solo lugar o herramienta que sea apto para todos los propósitos. A veces se descubre una amenaza en el punto final, el perímetro o analizando el tráfico interno. Por lo tanto, los controles deben colocarse en consecuencia en el ambiente para aumentar la probabilidad de detectar amenazas tan pronto como ocurran.

Preguntas a responder:

• ¿Podrás identificar y responder a una violación tan pronto como ocurra?
• ¿Conoce los tipos de ataques a los que su empresa está sometida?
• ¿Conocen los empleados cómo informar una infracción?

Punto 7: Supervisar el comportamiento de la red y del usuario para identificar e investigar incidentes de seguridad rápidamente.

La GDPR se centra en garantizar que los datos de los ciudadanos se recopilen y utilicen de manera adecuada para los fines que se establecieron. Por lo tanto es importante enfocarse no solo en amenazas externas o malware, sino también para detectar si los usuarios están accediendo a los datos adecuadamente. 

El contexto es crítico cuando se evalúa el comportamiento del sistema y la red. Por ejemplo, una gran cantidad de tráfico de Skype en la red utilizada por su equipo interno de ventas es probablemente una parte normal de las operaciones. Sin embargo, si el servidor de la base de datos alberga su lista de clientes de repente muestra una explosión de tráfico de Skype, algo es probable que esté mal.

Hay muchos métodos que se pueden implementar para monitorear patrones de comportamiento. Un método es utilizar el análisis de NetFlow, que proporciona las tendencias de alto nivel relacionadas con qué protocolos se usan, qué hosts usan el protocolo y el ancho de banda uso. Cuando se utiliza en conjunto con un SIEM, puede generar alarmas y recibir alertas cuando su NetFlow va por encima o debajo de ciertos umbrales.

Preguntas a responder:

• ¿Sabes cómo se ve el tráfico "normal" en tu red?
• ¿Sería capaz de detectar si un usuario legítimo está extrayendo datos de clientes?
• ¿Un aumento o caída en el tráfico elevará las alarmas?

Punto 8: Tener un plan de respuesta a incidentes documentado y practicado.

Para cumplir con las regulaciones de GDPR, las organizaciones deben tener un plan para detectar y responder a una potencial violación de datos para minimizar su impacto en los ciudadanos de la UE. En el caso de un ataque o intrusión, un proceso simplificado de respuesta a incidentes puede ayudarlo a responder de manera rápida y eficaz para limitar el alcance de la exposición.

Si tiene procesos y controles unificados de detección de amenazas para alertarlo sobre un incidente, su plan de respuesta a incidentes debe poder determinar de forma rápida y precisa el alcance del impacto. Debe investigar todos los eventos relacionados en el

contexto de otra actividad en su entorno de TI para establecer una línea de tiempo, y la fuente de ataque debe ser investigada para contener el incidente.

Una vez que haya contenido el incidente, debe evaluar si se produjo una posible infracción de los datos personales y decidir si se requieren informes según GDPR. Luego, debe priorizar y documentar todas las tácticas de respuesta y reparación. Asegúrese de verificar que las actividades de respuesta a incidentes hayan solucionado correctamente el problema. Tendrá que informar al regulador de todos los pasos dados y, cuando sea necesario, informar a los ciudadanos de la UE afectados.

Preguntas a responder:

• ¿Están todas las partes relevantes informadas y conscientes de qué hacer en caso de un incidente?
• ¿Se practica el plan de respuesta a incidentes para garantizar que funcione en escenarios del mundo real?
• ¿La documentación está completa y actualizada?

Punto 9: Tener un plan de comunicación para notificar a las partes relevantes.

En caso de incumplimiento, su organización debe informar al organismo regulador dentro de las 72 horas de haber tenido conocimiento de la infracción. Para eventos de alto riesgo, el responsable del tratamiento debe notificar a los interesados sin demora (Artículo 31).

La notificación a la autoridad que supervisa la GDPR, en cada país, es requerida por lo menos para:

• Descripción la naturaleza de la violación.
• Proporcionar el nombre y los datos de contacto del responsable de protección de datos de la organización, normalmente el CSO.
• Describir las posibles consecuencias de la violación.
• Describir las medidas tomadas o propuestas a tomar por el controlador de datos para abordar la violación y mitigar sus efectos adversos.

Preguntas a responder:

• ¿Puedo identificar si los sistemas en el alcance de GDPR se ven afectados en una violación?
• ¿Tengo los detalles de contacto del organismo regulador que debo notificar?
• Si es necesario, ¿tengo un mecanismo confiable para contactar a los clientes afectados?

Punto 10:  ¡Enhorabuena! Estas preparado para el desafío de la GDPR.

¿Hay vida más allá de Oracle? Características de Postgres SQL para un DBA de Oracle

Esta entrada en el blog contiene información para ayudar a un DBA de Oracle a entender algunos términos y la administración de una base de datos PostgreSQL. Pretendo dar una introducción a PostgreSQL, no un tutorial o una definición completa de cómo administrar una base de datos PostgreSQL. Para obtener la documentación completa, consulte los manuales de PostgreSQL.

¿Que es una base de datos Oracle?

Un servidor de base de datos Oracle consiste en una instancia de Oracle y una base de datos Oracle.
Una instancia de Oracle consiste en los procesos en segundo plano de Oracle y la memoria asignada dentro del área global compartida (SGA) y el área global del programa (PGA).
Los procesos en segundo plano de Oracle constan de lo siguiente:

• Proceso del escritor de la base de datos (DBWn)
• Proceso de registro de registro (LGWR)
• Proceso de punto de control (CKPT)
• Proceso de supervisión del sistema (SMON)
• Process Monitor Process (PMON)
• Proceso de Recuperación (RECO)
• Archivar procesos (ARCn)
• Una base de datos Oracle consiste en los archivos de datos de la base de datos, los archivos de control, los archivos de registro de rehacer, los archivos de registro de archivos y el archivo de parámetros. Para acceder de forma remota a una base de datos Oracle, existe un proceso separado denominado Listener Oracle.
• En la configuración del Servidor Dedicado (frente a la configuración del Servidor Compartido), cada sesión de base de datos establecida tiene su propio proceso ejecutándose en el servidor.

Para mantener las cosas simples, cualquier comparación con una base de datos Oracle siempre se referirá a una sola instancia que administre una sola base de datos, RAC y Data Guard no serán mencionados. 

Nota: PostgreSQL también tiene el concepto de un modo de espera en caliente (desde 8.2) con el envío de registros de archivo (introducido en 8.0).

PostgreSQL

Procesos de servidor de base de datos

El programa de servidor de base de datos postgres son todos los procesos del servidor. No hay procesos nombrados por separado como en Oracle para las diferentes tareas dentro del entorno de la base de datos. Si mirara la lista de procesos (ps), el nombre de los procesos sería postgres. Sin embargo, en la mayoría de las plataformas, PostgreSQL modifica su título de comando para que los procesos individuales del servidor puedan identificarse fácilmente. Es posible que deba ajustar los parámetros utilizados para comandos como ps y top para mostrar estos títulos actualizados en lugar del nombre del proceso ("postgres").

Los procesos vistos en una lista de procesos pueden ser algunos de los siguientes:

• Proceso maestro: inicia los otros procesos, procesos de fondo y sesión.
• Proceso de Writer: proceso en segundo plano que coordina las escrituras de la base de datos, las escrituras de registro y los puntos de control.
• Proceso de recopilación de estadísticas: proceso en segundo plano que recopila información sobre la actividad del servidor.
• Procesos de sesión de usuario.

Los procesos del servidor se comunican entre sí utilizando semáforos y memoria compartida para garantizar la integridad de los datos a través del acceso simultáneo a los datos.

Clúster de base de datos PostgreSQL

Dentro de un servidor, se pueden construir una o más instancias de Oracle. Las bases de datos están separadas una de otra, por lo general compartiendo solo el proceso de escucha de Oracle. PostgreSQL tiene el concepto de un cluster de base de datos. Un clúster de base de datos es una colección de bases de datos que se almacena en una ubicación común del sistema de archivos (el "área de datos"). Es posible tener varios clústeres de bases de datos, siempre que utilicen diferentes áreas de datos y diferentes puertos de comunicación.
Los procesos junto con los componentes del sistema de archivos se comparten en el clúster de la base de datos. Todos los datos necesarios para un clúster de base de datos se almacenan dentro del directorio de datos del clúster, comúnmente denominado PGDATA (después del nombre de la variable de entorno que se puede usar para definirlo). El directorio PGDATA contiene varios subdirectorios y archivos de configuración.
Los siguientes son algunos de los archivos de configuración del clúster:

• postgresql.conf - Parámetro o archivo de configuración del servidor principal.
• pg_hba.conf - Archivo de configuración de autenticación de cliente.
• pg_ident.conf - Mapa de la cuenta del sistema operativo al archivo de la cuenta PostgreSQL.

Los subdirectorios de clúster:

• base - Subdirectorio que contiene subdirectorios por base de datos
• global - Subdirectorio que contiene tablas de todo el cluster
• pg_auth - Archivo de autorización que contiene definiciones de usuario y rol.
• pg_control - Archivo de control.
• pg_database - Información de bases de datos dentro del clúster.
• pg_clog - Subdirectorio que contiene datos de estado de confirmación de transacción
• pg_multixact - Subdirectorio que contiene datos de estado de múltiples movimientos (usado para bloqueos de filas compartidos)
• pg_subtrans - Subdirectorio que contiene datos de estado de subtransacción
• pg_tblspc - Subdirectorio que contiene enlaces simbólicos a espacios de tabla
• pg_twophase - Subdirectorio que contiene archivos de estado para transacciones preparadas
• pg_xlog - Subdirectorio que contiene archivos WAL (Write Ahead Log)

De forma predeterminada, para cada base de datos en el clúster hay un subdirectorio dentro de PGDATA / base, que recibe el nombre del OID de la base de datos (identificador de objeto) en pg_database. Este subdirectorio es la ubicación predeterminada para los archivos de la base de datos; en particular, sus catálogos de sistema están almacenados allí. Cada tabla e índice se almacenan en un archivo separado, que recibe su nombre del número de archivo de la tabla o índice, que se puede encontrar en pg_class.relfilenode.

Varios componentes que los DBA de Oracle normalmente igualan a una base de datos se comparten entre bases de datos dentro de un cluster de PostgreSQL, incluido el archivo de parámetros, el archivo de control, los registros de rehacer, los espacios de tabla, las cuentas, los roles y los procesos en segundo plano.

Archivos de datos de espacios de tablas y objetos

PostgreSQL introdujo la administración del tablespace en la versión 8.0. La representación física de un espacio de tabla dentro de PostgreSQL es simple: es un directorio en el sistema de archivos, y la asignación se realiza a través de enlaces simbólicos.
Cuando se crea una base de datos, el espacio de tablas predeterminado es donde se almacenan por defecto todos los objetos de la base de datos. En Oracle esto sería similar al Sistema, al Usuario y a los espacios de tablas temporales. Si no se define ningún espacio de tabla predeterminado durante la creación, los archivos de datos entrarán en un subdirectorio de PGDATA / base. Preferiblemente, la ubicación de la información del catálogo del sistema y las estructuras de datos de la aplicación residirían en espacios de tablas gestionados por separado. Esto está disponible.
Al igual que en Oracle, la definición de una tabla PostgreSQL determina qué espacio de tablas reside el objeto. Sin embargo, no existe limitación de tamaño, excepto los límites físicos que el sistema operativo coloca en el dispositivo. Los datos de la tabla individual se almacenan dentro de un archivo dentro del tablespace (o directorio). El software de la base de datos dividirá la tabla entre múltiples archivos de datos en caso de que los datos de la tabla superen 1 GB.

Desde la versión 8.1, es posible dividir una tabla en espacios de tabla separados (o lo mismo). Esto se basa en la característica de herencia de tablas de PostgreSQL, que utiliza una capacidad del planificador de consultas denominada exclusión de restricciones.

No existe capacidad para separar columnas específicas (como LOB) en espacios de tabla definidos por separado. Sin embargo, además de los archivos de datos que representan la tabla (en múltiplos de 1 GB), hay una separación de archivos de datos para columnas dentro de una tabla que están TOAST. El sistema de almacenamiento PostgreSQL llamado TOAST (la técnica de almacenamiento de atributo de gran tamaño) almacena automáticamente valores mayores que una página de base de datos única en un área de almacenamiento secundaria por tabla. La técnica TOAST permite columnas de datos de hasta 1 GB de tamaño.

Al igual que en Oracle, la definición de índice determina en qué espacio de tabla reside. Por lo tanto, es posible obtener la ventaja de rendimiento de separar los discos de los datos de una tabla frente a su indexación, aliviando la contención de E / S durante la manipulación de datos.
En Oracle existen espacios de tablas temporales donde se utiliza la información de clasificación y el espacio de evaluación temporal necesarios para declaraciones distintas y similares. PostgreSQL no tiene este concepto de un tablespace temporal; sin embargo, requiere almacenamiento para poder realizar estas actividades también. Dentro del espacio de tabla "predeterminado" de la base de datos (definido en la creación de la base de datos), hay un directorio llamado pgsql_tmp. Este directorio contiene el almacenamiento temporal necesario para la evaluación. Los archivos que se crean dentro del directorio existen solo mientras se está ejecutando la instrucción SQL. Crecen muy rápido, y lo más probable es que no estén diseñados para la eficiencia del espacio sino más bien para la velocidad. Tenga en cuenta que la fragmentación del disco podría ser el resultado de esto, y debe haber suficiente espacio en el disco para admitir las consultas del usuario. Con el lanzamiento de 8.3, hay definiciones de espacios de tablas temporales usando el parámetro temp_tablespaces.roles y los procesos en segundo plano.

REDO y Archivado

PostgreSQL usa Write-Ahead Logging (WAL) como su enfoque para el registro de transacciones. El concepto central de WAL es que los cambios en los archivos de datos (donde residen las tablas y los índices) deben escribirse solo después de que esos cambios hayan sido registrados, es decir, cuando los registros de registro que describen los cambios hayan sido descargados al almacenamiento permanente. Si seguimos este procedimiento, no es necesario que limpiemos las páginas de datos en el disco en cada compromiso de transacción, porque sabemos que, en caso de falla, podremos recuperar la base de datos utilizando el registro: cualquier cambio que no se haya aplicado a las páginas de datos se pueden rehacer desde los registros de registro. (Esta es la recuperación de avance, también conocida como REDO).

PostgreSQL mantiene su (WAL) en el subdirectorio pg_xlog del directorio de datos del cluster.

WAL se introdujo en PostgreSQL en la versión 7.1. Para mantener la consistencia de la base de datos en caso de falla, las versiones anteriores forzaron todas las modificaciones de datos en el disco antes de que cada transacción se confirmara. Con WAL, solo debe descargarse un archivo de registro al disco, lo que mejora enormemente el rendimiento al tiempo que agrega capacidades como la Recuperación puntual y el archivo de transacciones.

Un sistema PostgreSQL teóricamente produce una secuencia indefinidamente larga de registros WAL. El sistema divide físicamente esta secuencia en archivos de segmentos WAL, que normalmente son de 16 MB cada uno. El sistema normalmente crea algunos archivos de segmento y luego los "recicla" al cambiar el nombre de los archivos de segmento que ya no se necesitan a números de segmento más altos. Si tuviera que realizar una lista del directorio pg_xlog, siempre habría un puñado de archivos cambiando de nombre a lo largo del tiempo.

Para agregar el archivo de los archivos WAL, existe un parámetro dentro del archivo de parámetros donde se agrega un comando para ejecutar el proceso de archivo. Una vez hecho esto, las copias de seguridad del sistema operativo "en línea" están disponibles ejecutando los comandos pg_start_backup y pg_stop_backup, que suspenden y reanudan la escritura en los archivos de datos mientras continúan escribiendo las transacciones en los archivos WAL y ejecutando el proceso de archivo.
La inclusión del archivo WAL y los comandos de respaldo en línea se agregaron en la versión 8.0.

Rollback o Undo

Es interesante cómo se utiliza la asignación dinámica de espacio en disco para el almacenamiento y procesamiento de registros dentro de las tablas. Los archivos que representan la tabla crecen a medida que la tabla crece. También crece con las transacciones que se realizan en su contra. En Oracle existe un concepto de rollback o deshacer segmentos que contienen la información para revertir una transacción. En PostgreSQL, los datos se almacenan dentro del archivo que representa la tabla. Por lo tanto, cuando se realizan eliminaciones y actualizaciones en una tabla, el archivo que representa el objeto contendrá los datos anteriores. Este espacio se reutiliza pero para forzar la recuperación del espacio usado, se debe ejecutar un proceso de mantenimiento llamado vacío.

Archivo de registro del servidor

Oracle tiene el archivo de registro de alerta. PostgreSQL tiene el archivo de registro del servidor. Una opción de configuración incluso tendría la información de conexión que normalmente vemos en listener.log de Oracle aparece en el registro del servidor de PostgreSQL. Los parámetros dentro del archivo de configuración del servidor (postgresql.conf) determinan el nivel, la ubicación y el nombre del archivo de registro.
Para ayudar con el mantenimiento del archivo de registro del servidor (crece rápidamente), existe una funcionalidad para girar el archivo de registro del servidor. Los parámetros se pueden configurar para determinar cuándo rotar el archivo según el tamaño o la antigüedad del archivo. La administración de los archivos antiguos se deja al administrador.

Aplicaciones

El comando initdb crea un nuevo clúster de base de datos PostgreSQL.
El comando psql inicia el front-end basado en terminal a la solicitud de comando de PostgreSQL o SQL. Las consultas y los comandos se pueden ejecutar de forma interactiva o mediante archivos. El símbolo del sistema psql tiene varias características atractivas:

• Completa ayuda en línea para los comandos psql y la sintaxis SQL.
• Historial de comandos y edición de línea.
• Los comandos SQL pueden existir en múltiples líneas y se ejecutan solo después del punto y coma (;).
• Se pueden ingresar varios comandos SQL separados por punto y coma en una sola línea.
• Formato de salida flexible.
• Múltiples comandos de descripción de objetos que son superiores a DESCRIBE de Oracle.

Dependiendo de las configuraciones de seguridad de los entornos, las conexiones se pueden establecer local o remotamente a través de TCP / IP. Debido a estas conexiones de seguridad separadas, las contraseñas pueden o no ser necesarias para conectarse.
El comando pg_ctl es una utilidad para mostrar el estado, iniciar, detener o reiniciar el servidor de base de datos PostgreSQL (postgres). Aunque el servidor se puede iniciar a través del ejecutable de postgres, pg_ctl encapsula tareas tales como redirigir la salida del registro, separarla adecuadamente del terminal y del grupo de procesos, y proporcionar opciones para el apagado controlado.

Los comandos pg_dump y pg_restore son utilidades diseñadas para exportar e importar los contenidos de una base de datos PostgreSQL. Los volcados pueden salir en formato de archivo de script o de archivo. El formato de archivo de script crea archivos de texto sin formato que contienen los comandos SQL necesarios para reconstruir la base de datos al estado en el que se encontraba en el momento en que se generó. El formato de archivo de archivo crea un archivo para ser utilizado con pg_restore para reconstruir la base de datos.
Los formatos de archivos de almacenamiento están diseñados para ser portátiles en todas las arquitecturas. Históricamente, cualquier tipo de actualización al software PostgreSQL requeriría un pg_dump de la base de datos antes de la actualización. Luego, un pg_restore después de la actualización. Ahora, para versiones menores (es decir, el tercer decimal - 8.2.x) las actualizaciones se pueden hacer en su lugar. Sin embargo, cambiar las versiones en el primer o segundo decimal aún requiere un pg_dump / pg_restore.

Existe una herramienta gráfica llamada pgAdmin III desarrollada por separado. Se distribuye con las versiones de Linux y Windows de PostgreSQL. La conexión a un servidor de base de datos se puede establecer de forma remota para realizar tareas administrativas. Debido a que la herramienta está diseñada para administrar todos los aspectos del entorno de la base de datos, la conexión a la base de datos debe realizarse a través de una cuenta de súper usuario.
La herramienta pgAdmin III tiene las siguientes características atractivas estándar:

• Diseño intuitivo
• Estructura de árbol para crear y modificar objetos de base de datos 
• Revisión y almacenamiento de SQL al modificar o crear objetos

¿Hay vida más allá de Oracle? El Oráculo en la nube de las amazonas

Como bien reza el título del artículo sacado de una película de serie b de los cincuenta, en este artículo vamos a abordar como Amazon Web Services (AWS) te ofrece la posibilidad de ejecutar nuestra base de datos favorita en su nube pública. 

La ejecución de Oracle Database en la nube de AWS es muy similar a  ejecutar Oracle Database en su centro de datos. Para un administrador o desarrollador de base de datos, no hay diferencias entre los dos entornos. Sin embargo, hay una serie de consideraciones de la plataforma AWS relacionadas con

• La seguridad
• El almacenamiento de la información
• La gestión de la configuración 
• Administración y monitoreo de la base de datos

que nos facilitan a obtener lo mejor de su base de datos Oracle implementación en AWS. 

En este artículo proporcionaremos las mejores prácticas para lograr  un mejor rendimiento, disponibilidad y confiabilidad óptimas, y, por supuesto, un menor coste  (TCO) mientras ejecuta Oracle Database en AWS. 

El público objetivo para este artículo incluye administradores de bases de datos, arquitectos empresariales, administradores de sistemas y desarrolladores que deseen ejecutar su base de datos Oracle en AWS.

Introducción a AWS

Amazon Web Services (AWS) proporciona un conjunto integral de servicios y herramientas para implementar Oracle Database en la infraestructura confiable y segura de nube de AWS. AMAZON ofrece a sus clientes dos opciones para ejecutar Oracle Database en AWS:

Amazon RDS para bases de datos Oracle

Utilizando Amazon Relational Database Service (Amazon RDS) para Oracle, que es un servicio de base de datos administrado que ayuda a simplificar el aprovisionamiento y la administración de bases de datos Oracle. Amazon RDS facilita la configuración, el funcionamiento y la escalabilidad de una base de datos relacional en la nube al automatizar la instalación, el aprovisionamiento y la administración del disco, el parcheo, las actualizaciones menores de la versión, el reemplazo fallido de instancias y las tareas de respaldo y recuperación.

La función Multi-AZ de Amazon RDS opera dos bases de datos en múltiples zonas de disponibilidad con replicación síncrona, creando así un entorno de alta disponibilidad con failover automático. La función de escalado de botón de Amazon RDS le permite escalar la instancia de la base de datos hacia arriba y hacia abajo fácilmente para una mejor gestión de costos y rendimiento. Amazon RDS también viene con una opción de licencia incluida, que permite pagar por uso por hora.

Base de datos Oracle autogestionada Amazon EC2

Ejecución de una base de datos Oracle autogestionada directamente en Amazon Elastic Compute Cloud (Amazon EC2). Esta opción le brinda control total sobre la configuración de la infraestructura y el entorno de la base de datos. Ejecutar la base de datos en Amazon EC2 es muy similar a ejecutar la base de datos en su propio servidor. Tu tienes el control  total de la base de datos y tienes acceso a nivel de sistema operativo, por lo que puedes ejecutar agentes de supervisión y administración y usar tu elección de herramientas para la replicación de datos, la copia de seguridad y la restauración. Además, tiene la capacidad de utilizar cada módulo opcional disponible en Oracle Database. Sin embargo, esta opción requiere que se configure, administre y ajuste todos los componentes, incluidas las instancias de Amazon EC2, los volúmenes de almacenamiento, la escalabilidad, las redes y la seguridad, según las mejores prácticas de arquitectura de AWS.

Arquitecturas para seguridad y rendimiento

Ya sea que elijas ejecutar Oracle Database en Amazon RDS o Amazon EC2, la optimización de cada componente de la infraestructura mejorará la seguridad, el rendimiento y la confiabilidad. En las siguientes secciones, analizaremos las mejores prácticas para optimizar la configuración de la red, el tipo de instancia y el almacenamiento de la base de datos en una implementación de Oracle Database en AWS.

Configuración de la red

La nube privada virtual de Amazon (Amazon VPC) le permite aprovisionar una sección aislada lógicamente de la nube de AWS que está dedicada a su cuenta. Tiene control total sobre su entorno de red virtual, incluida la selección de su propio rango de direcciones IP, la creación de subredes y la configuración de tablas de rutas y puertas de enlace de red, y la configuración de seguridad.

Una subred es un rango de direcciones IP en su Amazon VPC. Puede iniciar los recursos de AWS en una subred que seleccione. Utilice una subred pública para recursos que deben estar conectados a Internet, y una subred privada para recursos que no estarán conectados a Internet.

Para proteger los recursos de AWS en cada subred, puede usar varias capas de seguridad, incluidos los grupos de seguridad y las listas de control de acceso a la red (ACL).

La siguiente tabla describe las diferencias básicas entre los grupos de seguridad y las ACL de red.

Amazon VPC proporciona aislamiento, seguridad adicional y la capacidad de separar instancias de Amazon EC2 en subredes, y permite el uso de direcciones IP privadas. Todos estos son importantes en la implementación de la base de datos. Implemente la instancia de Oracle Database en una subred privada y permita que solo los servidores de aplicaciones dentro de Amazon VPC, o un host Bastion dentro de Amazon VPC, accedan a la instancia de la base de datos. Cree grupos de seguridad apropiados que permitan el acceso solo a direcciones IP específicas a través de los puertos designados. Estas recomendaciones se aplican a Oracle Database independientemente de si está utilizando Amazon RDS o Amazon EC2.

Sobre las licencias Oracle

Como se indica en el documento de Oracle en el site My Oracle Support Doc ID: 2174134.1, Oracle es totalmente compatible con la implementación de Oracle Database en AWS. (Si quieres ver el documento, ha de registrarse para obtener una cuenta de Oracle, que es gratuita.) Las licencias de Oracle Database en AWS se basan en el tamaño de la instancia en la que está instalada la base de datos. 
Algunos puntos clave:

• El recuento de núcleos virtuales de las instancias de Amazon EC2 se considera igual al recuento de núcleos físicos para fines de licencia. Para conocer el recuento de núcleos virtuales de cada tipo de instancia de Amazon EC2, consulte Núcleos virtuales de Amazon EC2 y Tipo de instancia de base de datos de RDS.
• Oracle Database Standard Edition solo puede tener licencia en instancias de Amazon EC2 que tengan hasta 16 núcleos virtuales.
• Oracle Standard Edition One y Standard Edition Two solo pueden tener licencia en instancias de Amazon EC2 que tengan hasta 8 núcleos virtuales.
• Para Oracle Database Standard Edition, Standard Edition One o Standard Edition Two, las instancias de Amazon EC2 con 4 o menos núcleos virtuales se cuentan como un solo socket.
• Para Oracle Database Enterprise Edition, las instancias de Amazon EC2 con 2 o menos núcleos virtuales se cuentan como un solo socket.

Portabilidad de licencia de Oracle a AWS

Sujeto a los términos y condiciones del acuerdo de licencia específico, las licencias de Oracle pueden ser transferibles a AWS. En otras palabras, sus licencias existentes se pueden transferir para su uso en AWS. Éstas incluyen:

• Licencias basadas en servidor (basadas en CPU utilizadas)
• Acuerdos de licencia empresarial (ELA)
• Acuerdos de licencia ilimitados (ULA)
• Licencias de Business Process Outsourcing (BPO)
• Licencias de Oracle PartnerNetwork (OPN)
• Licencias de User Plus con nombre

Es posible que se apliquen condiciones o limitaciones adicionales (incluidos los posibles costos) para las licencias que se transfieren a AWS. Verifique su contrato de licencia específico para obtener detalles y limitaciones adicionales.

Las licencias de Oracle se aplican de manera similar a Oracle Database en Amazon RDS y en Amazon EC2, con la excepción de que las licencias por hora solo están disponibles en Amazon RDS.

Conclusión

Dependiendo de su escenario de uso, puede utilizar Amazon RDS para Oracle Database o ejecutar una base de datos Oracle autogestionada en Amazon EC2. Independientemente de su elección, seguir las mejores prácticas proporcionadas en este artículo te ayudará a aprovechar tu implementación de Oracle Database en AWS.