Espejeo en Bases de Datos

Base de Datos Espejo (Database Mirroring) es una configuración donde dos o tres servidores de base de datos, ejecutándose en equipos independientes, cooperan para mantener copias de la base de datos y archivo de registro de transacciones (log).

Tanto el servidor primario como el servidor espejo mantienen una copia de la base de datos y el registro de transacciones, mientras que el tercer servidor, llamado el servidor árbitro, es usado cuando es necesario determinar cuál de los los otros dos servidores puede tomar la propiedad de la base de datos. El árbitro no mantiene una copia de la base de datos. La configuración de los tres servidores de base de datos (el primario, el espejo y el árbitro) es llamado Sistema Espejo (Mirroring System), y el servidor primarioy espejo juntos son llamados Servidores Operacionales (Operational Servers) o Compañeros (Partners).

 

 

 



 

Para hacer el mirror, es necesario como mínimo 2 instancia y como máximo 3. Si utilizamos 2 instancias, una de ellas contiene la base de datos y la otra la espejo. La pega de esta configuración es que el failover no es automático y se necesita intervención humana. Si utilizamos 3 instancias, entonces utilizamos una de ellas como witness server y permite que el failover sea automático, osea que cuando una caiga, la otra se ponga en marcha. Para ello el witness server se encarga de “mirar” el estado de las 2 instancias y cuando una de ellas cae, pone la otra en marcha.
Hacer el mirror son dos pasos principales:
1. Copiar y restaurar la base de datos de la que queremos hacer el mirror desde una instancia a la otra
2. Configurar el asistente de configuración del mirror.
Vamos un ejemplo paso a paso.
Lo primero que tenemos que hacer es hacer un reflejo de nuestra base de datos en otra instancia. En nuestro ejemplo esta base de datos se denomina prueba.

Debemos hacer copia de seguridad de la base de datos y del log (Ojo, la base de datos debe estar en modo Full) con estas sentencias:
Backup Database Prueba to Disk=’D:\prueba.bak’;
Backup Log Prueba to Disk=’D:\logprueba.bak;
Una vez hecha la copia de seguridad, copiamos los ficheros y los restauramos otra instancia donde queremos hacer el reflejo con estas sentencias
Restore Database Prueba from Disk=’D:\prueba.bak’ with NORECOVERY;
Restore Log Prueba from Disk=’D:\logprueba.bak with NORECOVERY;
Fijémonos que tanto la restauración del fichero de datos como el del log, son con el parámetro NORECOVERY. Esto es muy importante porque estamos diciendo al SQL Server que restauramos la base de datos pero que no la ponga en marcha y que la deje lista para poder aplicar más logs, osea los logs que vendrán de la otra base de datos cuando comience el mirror.

Una vez tenemos hecha la restauración de la base de datos que queremos reflejar en la otra instancia, ya podemos configurar el mirror. Para ello, pulsamos en la primera instancia con el botón derecho del ratón sobre la base de datos, y seleccionamos Propiedades. En el cuadro de diálogo de las propiedades de la base de datos, seleccionamos la opción Mirror.

Vemos que aparece un cuadro de diálogo con las opciones de configuración del mirror. Para comenzar a configurarlo, seleccionamos el botón Configure Security.

Vemos que aparece el asistente de configuración del mirror. Lo primero que nos pregunta es si queremos utilizar un witness server. Indicamos que sí. Después debemos indicarle que queremos configurar las 3 instancias para poder hacer el failover automáticamente.

Seguidamente indicamos la instancia que contendrá la base de datos en sí. Fijémonos que por defecto, el asistente abre el puerto 5022 para comunicarse con el resto de instancias. Dicho puerto y el resto que se configuran en el asistente, deben estar abiertos en los firewalls de windows. Fijémonos también que hemos quitado la opción de cifrado, ya que en esta configuración, no tenemos habilitado el cifrado de la base de datos.

Seguidamente configuramos la segunda instancia que será la que contendrá el reflejo de la base de datos. Fijémonos que por defecto configura el puerto 5023.

Por último nos queda configurar el witness server que estará en una tercera instancia. Fijémonos que por defecto configura el puerto 5024.

Un último paso en el asistente es configurar la seguridad. Aquí debemos indicar una cuenta con permisos para acceder al SQL Server. Por ejemplo, podemos indicar la cuenta con la que arrancan los servicios de las instancias.

Para acabar con el asistente pulsamos en Finish. El asistente se pondrá a configurar los puertos (Endpoints) en cada instancia y acabará.

fuentes

http://www.corporacionsybven.com/portal/index.php?option=com_content&view=article&id=362

http://miblogtecnico.wordpress.com/tag/sql-server-mirror-espejo-en-sql-server-mirror-en-sql-server-alta-disponibilidad-en-sql-server/

 

 

problemas de seguridad comunes en una bd

Nombre de usuario/password en blanco, por defecto o débil.

No es nada raro conseguir en el día a día pares de usuario/password como sa/1234, esta el la primera línea de defensa y un punto fundamental de la armadura de nuestras bases de datos.

sol. hacer revisiones periódicas de credenciales.

 

Características de base de datos innecesariamente habilitadas.

Cada instalación de base de datos viene con paquetes adicionales de todas las formas y tamaños que en su mayoría rara vez son utilizados por una sola organización. Dado que el nombre del juego en materia de seguridad de base de datos es el de reducir las superficies de ataque.

sol.las empresas necesitan buscar los paquetes que no utilizan y desactivarlos. Esto no sólo reduce los riesgos de ataques a través de estos vectores, sino que también simplifica la gestión de parches.

 

Configuración de seguridad ineficiente.

Del mismo modo, las bases de datos tienen una gran cantidad opciones de configuración y consideraciones diferentes a disposición de los administradores para ajustar el rendimiento y funcionalidades mejoradas.

sol.Las organizaciones necesitan conseguir y desactivar aquellas configuraciones inseguras que podrían estar activadas por defecto para mayor comodidad de los DBA o desarrolladores de aplicaciones. Las configuraciones de bases de datos en producción y desarrollo deben ser radicalmente diferentes.

 

Desbordamientos de búfer.

Un favorito de los piratas cibernéticos, las vulnerabilidades de desbordamiento de búfer, son explotadas por las inundaciones de las fuentes de entrada con valores diferentes o muy superiores a los que aplicación espera - por ejemplo, mediante la adición de 100 caracteres en un cuadro de entrada pidiendo un número de Seguro Social.

Los proveedores de bases de datos han trabajado duro para solucionar los problemas técnicos que permiten estos ataques se produzcan. Esta es otra razón por la cual los parches son tan importantes.

sol. actualizar constantemente con parches para evitar estos desbordamientos.

 

Bases de datos sin actualizar.

Esto podría sonar repetitivo, pero vale la pena repetirlo. Los administradores de base de datos a veces no aplican un parche en el momento oportuno porque tienen miedo de este dañe sus bases de datos. Pero el riesgo de ser hackeado hoy es mucho más alto que el riesgo de aplicar un parche que descomponga la base de datos. Además existen ante esos temores los backups y las réplicas. Quizás este punto pudo haber sido válido hace cinco años,pero hoy en dia no.

sol.actualizar siempre que sea posible.

 

Inyecciones SQL.

 

 

Cuando la plataforma de base de datos falla para desinfectar las entradas, los atacantes son capaces de ejecutar las inyecciones SQL de forma similar a como lo hacen en los ataques basados en Web, lo que les permite elevar sus privilegios y obtener acceso a una amplia gama de funcionalidades.

Muchos de los proveedores han dado a conocer soluciones para evitar estos problemas, pero no servirá de mucho si los parches no se aplican o no se toman los correctivos correspondientes.

Seguridad contra el acceso no autorizado

Existen dos tipos de mecanismos de seguridad contra
el acceso no autorizado:Discrecionales, se usan para otorgar privilegios a los usuarios.

Obligatorios, sirven para imponer seguridad de múltiplesniveles clasificando los datos los usuarios en varias clases deseguridad e implementando después la política de seguridadapropiada de la organización. Además se pueden crear cuentas de acceso a la basede datos para los distintos usuarios, las cuales sepodrían agrupar en roles.

En una base de datos estadística no se deber permitir tener acceso a información confidencial detallada sobre individuos específicos. En ocasiones es posible deducir ciertos hechos relativos a los individuos apartir de consultas, lo que tampoco debe permitirse.
Otra técnica de seguridad es el cifrado de datos.

 

fuentes

http://www.e-securing.com/novedad.aspx?id=58
http://www.itescam.edu.mx/principal/sylabus/fpdb/recursos/r1335.PDF
http://www.argeniss.com/research/OracleSecurity.pdf
 

Indices

Indices
Un índice es un archivo usado para agilizar la recuperación de los registros.

Es redundante puesto que la información que almacena se encuentra en el archivo al cual indexa.

La ventaja, sin duda, viene por la vía de recuperar los registros de manera más rápida.


Tipos de índices
Existen diversos criterios para identificar los distintos tipos de índices, algunos de éstos son:

 Campo de indexación: según el campo usado para construir el índice, éste se llamará primario, de grupos o secundario.

a) índice primario (principal) : se construye sobre el campo clave de ordenamiento de un archivo ordenado de registros.

b) índice agrupado (clusterizado): se construye sobre un campo de ordenamiento que abarca varios registros con el mismo valor, dentro de un archivo ordenado de registros.

c) índice secundario: se construye sobre un campo que no se utiliza para ordenar el archivo.

Número de referencias: si el índice tiene una entrada por cada registro del archivo se denomina denso, en caso contrario, dicho índice se llama no denso o disperso.

Tipo de referencias: si la entrada en el índice contiene un puntero físico al
área de datos, es decir, un puntero que indica la dirección física de un registro en el disco, el índice se llama físico.

Estructura de las referencias: las referencias al área de datos se pueden estructurar como;

a) entrada de largo fijo, con un puntero al área de datos (bloque oregistro).

b) registros de largo variable en el índice, con un campo repetitivo que permita almacenar un puntero a cada bloque de disco que contiene un registro. Este esquema se llama archivo o lista invertida.

c) mantener entradas en el índice de largo fijo y tener una única entrada por cada valor del campo de indexación, pero creando un nivel extra de indirección para manipular los múltiples punteros.

d) entradas en el índice de largo fijo y tener un bitmap asociado acada una de ellas, el cual tenga un bit por cada bloque del archivo de datos; el bitmap guarda un valor 1 en los bits de los bloques que contiene un registro con el valor de la entrada, y un valor 0 en caso contrario.

Modos de Operacion de un SGBD

MySQL

¿Qué es una transacción?

“Secuencia de operaciones que se ejecutan completamente o bien no se realizan”.

§ No puede quedarse en un estado intermedio.

§ Ejemplo: una transferencia entre dos cuentas no puede quedarse en un estado intermedio: O se deja el dinero en la primera cuenta o en la segunda, pero no se puede sacar el dinero de la primera cuenta, que falle algo en ese momento y no entregarlo en la segunda.

Es una secuencia de una o varias instrucciones de SQL que forman conjuntamente una unidad lógica de trabajo. Cuando una transacción finaliza con éxito, se graba (COMMIT). Si fracasa, se restaura el estado anterior (ROLLBACK.

Instrucciones COMMIT y  ROLLBACK.

SQL acoge las transacciones de base de datos mediante dos instrucciones de procesamiento de transacciones de SQL:

§ COMMIT: La instrucción COMMIT señala la conclusión con éxito de una transacción. Indica al SGBD que la transacción se ha completado; se han ejecutado todas las instrucciones que conforman la transacción, y la base de datos es autoconsistente.

§ ROLLBACK: La instrucción ROLLBACK señala el fracaso de una transacción. Indica al SGBD que el usuario no desea completar la transacción; en lugar de ello, el SGBD debe volverse atrás de las modificaciones realizadas en las BD durante la transacción. En efecto, el SGBD devuelve la base de datos a su estado previo al comienzo de la transacción.

Ejemplo:

mysql> CREATE TABLE t (name CHAR(20), UNIQUE (name)) TYPE = INNODB;

mysql> BEGIN;

mysql> INSERT INTO t SET name = 'William';

mysql> INSERT INTO t SET name = 'Wallace';

mysql> COMMIT; mysql> SELECT * FROM t;

+---------+

| name    |

+---------+

| Wallace |

| William |

+---------+

mysql> BEGIN;

mysql> INSERT INTO t SET name = 'Gromit';

mysql> INSERT INTO t SET name = 'Wallace';

ERROR 1062: Duplicate entry 'Wallace' for key 1

mysql> ROLLBACK;

mysql> SELECT * FROM t;

+---------+

| name    |

+---------+

| Wallace |

| William |

+---------+

mysql> DROP TABLE t;

mysql> CREATE TABLE t (name CHAR(20), UNIQUE (name)) TYPE = INNODB;

mysql> SET AUTOCOMMIT = 0;

mysql> INSERT INTO t SET name = 'William';

mysql> INSERT INTO t SET name = 'Wallace';

mysql> COMMIT;

mysql> SELECT * FROM t;

+---------+

| name    |

+---------+

| Wallace |

| William |

+---------+

Oracle

COMMIT

Para dejar los cambios echos permantentes en una transaccion utiliza COMMIT statement.
La sintaxis de COMMIT Statement es


COMMIT [WORK] [COMMENT ‘your comment’];

WORK es opcional.


COMMENT es opcional, especifica cuando quieres identificar una transaccion en el diccionario de datos. DBA_2PC_PENDING.

ejemplo

insert into emp (empno,ename,sal) values (101,’Abid’,2300);

commit;

ROLLBACK


To rollback the changes done in a transaction give rollback statement. Rollback restore the state of the database to the last commit point.

ejemplo:


delete from emp;

rollback; /* undo the changes */