lunes, 13 de mayo de 2013

Replicacion


1.  ¿ Que es Replica (replication) de una base de datos?

La replicación es un mecanismo utilizado para propagar y diseminar datos en un ambiente distribuido, con el objetivo de tener mejor performance y confiabilidad, mediante la reducción de dependencia de un sistema de base de datos centralizado.

La réplica proporciona una manera rápida y confiable de diseminar la información corporativa entre múltiples localizaciones en un ambiente de negocio distribuido, permitiendo distribuir la información de manera confiable.

2. Beneficios de la réplica de Datos en un DBMS

Con la replicación se pueden llegar a obtener dos mejoras importantes:

      1. Por un lado, se garantiza que el servicio ofrecido por la aplicación, no se vea interrumpido en caso de que se dé un fallo en alguna de las réplicas. Además, el tiempo necesario para restablecer el servicio en la aplicación podría llegar a ser grande en algunos tipos de fallo.

      2. Por otra parte, la capacidad de servicio se ve incrementada cuando las peticiones efectuadas por los clientes únicamente implican consultas.

 

3.  Ejemplo de una replicación de base de datos

 
En el siguiente link se encuentra la informacion requerida de replicacion:

 
http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=mysql_replicacion

Espejeo


 

1.  ¿Qué es espejeo (mirroring)?

Se conoce como copia espejo (en inglés data mirroring) al procedimiento de protección de datos y de acceso a los mismos en los equipos informáticos implementado en la tecnología de RAID1.

Consiste en la idea básica de tener dos discos duros conectados. Uno es el principal y en el segundo se guarda la copia exacta del principal, almacenando cualquier cambio que se haga en tiempo real en las particiones, directorios, etc, creando imágenes exactas, etc.

De esta forma se consigue tener 2 discos duros idénticos y que permiten, si todo está bien configurado, que ante el fallo del disco principal, el secundario tome el relevo, impidiendo la caída del sistema y la pérdida de los datos almacenados.

En el "mirroring" en una base de datos tenemos un servidor principal/primario que mantiene la copia activa de la base de datos (BD accesible). Otro servidor de espejo que mantiene una copia de la base de datos principal y aplica todas las transacciones enviadas por el Servidor Principal (en el que no se podrá acceder a la BD). Y un servidor testigo/arbitro que permite recuperaciones automáticas ante fallos, monitoriza el servidor principal y el de espejo para en caso de caída cambiar los roles (servidor opcional, no es obligatorio).
 

2.  Beneficios del espejeo de un DBMS.

Además de proporcionar una copia adicional de los datos con el fin de redundancia en caso de fallo de hardware, la duplicación de disco puede permitir que cada disco se acceda por separado para los propósitos de lectura. En determinadas circunstancias esto puede mejorar significativamente el rendimiento ya que el sistema puede elegir para cada lectura que disco puede buscar más rápidamente a los datos requeridos. Esto es especialmente importante cuando hay varias tareas que compiten por los datos en el mismo disco, y el "trashing" (donde el cambio entre tareas ocupa más tiempo que la tarea en sí) se puede reducir. Esta es una consideración importante en las configuraciones de hardware que frecuentemente tienen acceso a los datos en el disco.

En algunas implementaciones, el disco reflejado se puede dividir fuera y se utiliza para la copia de seguridad de datos, permitiendo que el primer disco para permanecer activos. Sin embargo, la fusión de los dos discos se puede requerir un período de sincronización en su caso escribir la actividad I/O ha ocurrido con el disco duplicado.


3.  Como se hace una  Activación de espejeo en un DBMS


En Sql:

1.- Click derecho sobre la base de datos
2.- Tareas
3.- Seleccionamos la opción Reflejar (Mirroring)
4.- Seleccione la instancia principal y la de mirroring.


Recomendaciones:

  • En la base de datos Mirroring debe estar en recuperación no recovery.
  • El firewall debe permitir los puertos usados.
  • Ver que los protocolos TCP IP están habilitados con el SQL Server Configuration Manager.



   4.Creación de espacios de disco con espejo


Una vez preparados los discos, para crear el RAID, y si hemos seguido la misma estructura de mi ejemplo, usaremos las siguientes órdenes, suponiendo que los discos nos los ha identificado como sda, sdb, sdc y sdd:

mdadm --create --level=raid1 --raid-devices=2 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1

mdadm --create --level=raid5 --raid-devices=4 /dev/sda3 /dev/sdb3 /dev/sdc3 /dev/sdd3

 

La primera orden nos creará un RAID de tipo RAID1 con sólo 2 componentes activos, empleando para ello la primera partición de cada disco. Como le indicamos menos dispositivos de raid (2) que dispositivos físicos, lo que hace es poner los otros dos como spares.

La segunda orden nos creará un RAID5 con la tercera partición de todos los discos indicados. En este caso, el parámetro --raid-devices=4 es superfluo y se podría omitir, ya que si no decimos nada sobreentiende que queremos usar todos los discos.

jueves, 9 de mayo de 2013

Problemas de seguridad en las BD




·         Monitoreo
Monitoreo en tiempo real de la actividad de base de datos es clave para limitar su exposición, aplique o adquiera agentes inteligentes de monitoreo, detección de intrusiones y uso indebido.

Por ejemplo, alertas sobre patrones inusuales de acceso, que podrían indicar la presencia de un ataque de inyección SQL, cambios no autorizados a los datos, cambios en privilegios de las cuentas, y los cambios de configuración que se ejecutan a mediante de comandos de SQL.

Recuerde que el monitoreo usuarios privilegiados, es requisito para la gobernabilidad de datos y cumplimiento de regulaciones como SOX y regulaciones de privacidad. También, ayuda a detectar intrusiones, ya que muchos de los ataques más comunes se hacen con privilegios de usuario de alto nivel.

El monitoreo dinámico es también un elemento esencial de la evaluación de vulnerabilidad, le permite ir más allá de evaluaciones estáticas o forenses. Un ejemplo clásico lo vemos cuando múltiples usuarios comparten credenciales con privilegios o un número excesivo de inicios de sesión de base de datos.


·         Identificar su sensibilidad
  
Confeccione un buen catálogo de tablas o datos sensibles de sus instancias de base de datos. Además, automatice el proceso de identificación, ya que estos datos y su correspondiente ubicación pueden estar en constante cambio debido a nuevas aplicaciones o cambios producto de fusiones y adquisiciones.

Desarrolle o adquiera herramientas de identificación, asegurando éstas contra el malware, colocado en su base de datos el resultado de los ataques de inyección SQL; pues aparte de exponer información confidencial debido a vulnerabilidades, como la inyección SQL, también facilita a los atacantes incorporar otros ataques en el interior de la base de datos.


·         Evaluación de la vulnerabilidad y la configuración

·         
Evalúe su configuración de bases de datos, para asegurarse que no tiene huecos de seguridad.

Esto incluye la verificación de la forma en que se instaló la base de datos y su sistema operativo (por ejemplo, la comprobación privilegios de grupos de archivo -lectura, escritura y ejecución- de base de datos y bitácoras de transacciones).

Asimismo con archivos con parámetros de configuración y programas ejecutables.

Además, es necesario verificar que no se está ejecutando la base de datos con versiones que incluyen vulnerabilidades conocidas; así como impedir consultas SQL desde las aplicaciones o capa de usuarios. Para ello se pueden considerar (como administrador):
-Limitar el acceso a los procedimientos a ciertos usuarios.
-Delimitar el acceso a los datos para ciertos usuarios, procedimientos y/o datos.
-Declinar la coincidencia de horarios entre usuarios que coincidan.


·         Endurecimiento

Como resultado de una evaluación de la vulnerabilidad a menudo se dan una serie de recomendaciones específicas. Este es el primer paso en el endurecimiento de la base de datos. Otros elementos de endurecimiento implican la eliminación de todas las funciones y opciones que se no utilicen. Aplique una política estricta sobre que se puede y que no se puede hacer, pero asegúrese de desactivar lo que no necesita.


·         Autenticación, control de acceso, y Gestión de derechos

No todos los datos y no todos los usuarios son creados iguales. Usted debe autenticar a los usuarios, garantizar la rendición de cuentas por usuario, y administrar los privilegios para de limitar el acceso a los datos.

Implemente y revise periódicamente los informes sobre de derechos de usuarios, como parte de un proceso de formal de auditoría.

Utilice el cifrado para hacer ilegibles los datos confidenciales, complique el trabajo a los atacantes, esto incluye el cifrado de los datos en tránsito, de modo que un atacante no puede escuchar en la capa de red y tener acceso a los datos cuando se envía al cliente de base de datos.


Medidas de seguridad del DBA:

-Físicas: Controlar el acceso al equipo. Tarjetas de acceso, etc.
-Personal: Acceso sólo del personal autorizado. Evitar sobornos, etc.
-SO: Seguridad a nivel de SO
-SGBD (sistema de gestión de base de datos): Uso herramientas de seguridad que proporcione el SGBD. Perfiles de usuario, vistas, restricciones de uso de vistas, etc.
-Uso de técnicas de cifrado: para proteger datos en Base de Datos distribuidas o con acceso por red o internet.
-Diferentes tipos de cuentas.
-Manejo de la tabla de usuarios con código y contraseña, control de las operaciones efectuadas en cada sesión de trabajo por cada usuario y anotadas en la bitácora, lo cual facilita la auditoría de la Base de Datos.


·         Audite

Una vez que haya creado una configuración y controles de endurecimiento, realice auto evaluaciones y seguimiento a las recomendaciones de auditoría para asegurar que no se desvíe de su objetivo (la seguridad).

Automatice el control de la configuración de tal forma que se registre cualquier cambio en la misma. Implemente alertas sobre cambios en la configuración. Cada vez que un cambio se realice, este podría afectar a la seguridad de la base de datos.


·         Pistas de Auditoría

Aplique pistas de auditoría y genere trazabilidad de las actividades que afectan la integridad de los datos, o la visualización los datos sensibles.

Recuerde que es un requisito de auditoría, y también es importante para las investigaciones forenses.

La mayoría de las organizaciones en la actualidad emplean alguna forma de manual de auditoría de transacciones o aplicaciones nativas de los sistemas gestores de bases de datos. Sin embargo, estas aplicaciones son a menudo desactivadas, debido a:
-su complejidad
-altos costos operativos
-problemas de rendimiento
-la falta de segregación de funciones y
-la necesidad mayor capacidad de almacenamiento.
Afortunadamente, se han desarrollado soluciones con un mínimo de impacto en el rendimiento y poco costo operativo, basado en tecnologías de agente inteligentes.

martes, 23 de abril de 2013

Rendimiento de una BD



Técnicas de estimación de rendimiento
Para trabajar con tablas muy grandes debemos tener en cuenta tres claves: Buffers, Índices y Consultas.

Buffers
Un buffer es una ubicación de la memoria reservada para el almacenamiento temporal de información digital. La primera cosa que deberíamos tener muy clara es el hecho de que hay una gran diferencia entre “Datos que están en memoria” y “Datos que no están en memoria”.

Índices
Los índices son usados para encontrar rápidamente los registros que tengan un determinado valor en alguna de sus columnas. Sin un índice, MySql tiene que iniciar una búsqueda por el primer registro y leer toda la tabla para encontrar los registros relevantes.

Consultas
La optimización de las consultas podría ser el punto más extenso de los tres por la gran variedad de posibilidades que tenemos a la hora de optimizar consultas.
Puedes conseguir que MySQL rinda a buen rendimiento con grandes cantidades de datos pero para ello debes tener en cuenta sus limitaciones y saber cuales son las características que ofrecen mejor rendimiento.


Re
ndimiento transaccional

Se debe comprobar que el SGBD puede efectuar la cantidad necesaria de transacciones por unidad de tiempo, para proporcionar a los usuarios un tiempo de respuesta adecuado. En general, este punto es difícil de definir teóricamente. En primer lugar, porque la información necesaria para calcular la carga de transacciones que deberá soportar el sistema, es compleja y difícil de obtener y, en segundo lugar, porque las medidas de transacciones por segundo, que ofrecen los distintos fabricantes, no siempre son comparables.  Además, el rendimiento de un mismo SGBD es ampliamente variable, según las características de la máquina en la que esté instalado (capacidad y velocidad de los discos, cantidad de memoria, potencia de la UCP, etc).  Por todo ello, lo más conveniente es diferir la resolución sobre este punto, hasta que se pueda comprobar experimentalmente realizando una prueba en la propia instalación.  A pesar de lo comentado, existen varias pruebas de rendimiento (benchmark) estándar que ofrecen datos útiles. Los más interesantes para SGBDs, son los del Transaction Processing Performance Council, organismo fundado en 1988, al que pertenecen más de cuarenta fabricantes de plataformas físicas y lógicas de bases de datos, que ha definido especificaciones de benchmarks estándar para sistemas de proceso de transacciones en entornos comerciales.
Técnicas de estimación de respuesta

 El tiempo que tarda una SGBD en procesar una petición se divide en:

1) Tiempo de ejecución de las instrucciones correspondientes, es decir, tiempo de consume del procesador(CPU).

2) Tiempo esperando algún suceso. Aquí puede haber multiples causas, pero las más importantes y comunes son dos:

a) Tiempo de espera de las operaciones de Entrada/Salida, es decir, espera por los accesos de discos.

b) Tiempo de espera por algún recurso que está bloqueado (locked). 

manejo de indices



El índice de una base de datos es una estructura de datos que mejora la velocidad de las operaciones, permitiendo un rápido acceso a los registros de una tabla en una base de datos. Al aumentar drásticamente la velocidad de acceso, se suelen usar sobre aquellos campos sobre los cuales se hacen frecuentes búsquedas.

El índice tiene un funcionamiento similar al índice de un libro, guardando parejas de elementos: el elemento que se desea indexar y su posición en la base de datos. Para buscar un elemento que esté indexado, sólo hay que buscar en el índice dicho elemento para, una vez encontrado, devolver el registro que se encuentre en la posición marcada por el índice.

Tipos de indices

HASH

Hash se refiere a una función o método para generar claves o llaves que representen de manera casi unívoca a un documento, registro, archivo, etc., resumir o identificar un dato a través de la probabilidad, utilizando una función hash o algoritmo hash. Un hash es el resultado de dicha función o algoritmo. Una función de hash es una función para resumir o identificar probabilísticamente un gran conjunto de información, dando como resultado un conjunto imagen finito generalmente menor (un subconjunto de los números naturales por ejemplo).

B-TREE

Los árboles-B ó B-árboles son estructuras de datos de árbol que se encuentran comúnmente en las implementaciones de bases de datos y sistemas de archivos. Los árboles B mantienen los datos ordenados y las inserciones y eliminaciones se realizan en tiempo logarítmico amortizado. La idea tras los árboles-B es que los nodos internos deben tener un número variable de nodos hijo dentro de un rango predefinido. Cuando se inserta o se elimina un dato de la estructura, la cantidad de nodos hijo varía dentro de un nodo. 


Cómo crear los indices en MySQL

CREATE [UNIQUE|FULLTEXT|SPATIAL] INDEX index_name
    [USING index_type]
    ON tbl_name (index_col_name,...)

index_col_name:
    col_name [(length)] [ASC | DESC]
Ejemplo:

CREATE TABLE lookup (id INT) ENGINE = MEMORY;
CREATE INDEX id_index USING BTREE ON lookup (id);



Cómo crear los indices en Oracle

CREATE [UNIQUE] INDEX index_name
  ON table_name (column1, column2, ... column_n)
  [ COMPUTE STATISTICS ];
Ejemplo:

CREATE INDEX supplier_idx
  ON supplier (supplier_name);

modos de operacion de un SGBD



Rollback: En tecnologías de base de datos, un rollback es una operación que devuelve a la base de datos a algún estado previo. Los Rollbacks son importantes para la integridad de la base de datos, a causa de que significan que la base de datos puede ser restaurada a una copia limpia incluso después de que se han realizado operaciones erróneas.

Commit: En el contexto de la Ciencia de la computación y la gestión de datos, commit (acción de comprometer) se refiere a la idea de consignar un conjunto de cambios "tentativos, o no permanentes". Un uso popular es al final de una transacción de base de datos.

Recovery: El Modo de Recuperación, también conocido como Modelo de Recuperación ó Modo de Registro, es una opción de configuración de base de datos que indica cómo se gestiona el uso del LOG de Transacciones de SQL Server para dicha base de datos (esta opción se configura para cada base de datos de forma independiente).

 Como realizar estas operaciones en MySQL

1) Creamos una tabla

mysql> CREATE TABLE innotest (campo INT NOT NULL PRIMARY KEY) TYPE = InnoDB;
Query OK, 0 rows affected (0.10 sec)

mysql> INSERT INTO innotest VALUES(1);
Query OK, 1 row affected (0.08 sec)

mysql> INSERT INTO innotest VALUES(2);
Query OK, 1 row affected (0.01 sec)

mysql> INSERT INTO innotest VALUES(3);
Query OK, 1 row affected (0.04 sec)

mysql> SELECT * FROM innotest;
+-------+
| campo |
+-------+
|     1     |
|     2     |
|     3     |
+-------+
3 rows in set (0.00 sec)


2) Ahora realizamos una transacción


mysql> BEGIN;
Query OK, 0 rows affected (0.01 sec)

mysql> INSERT INTO innotest VALUES(4);
Query OK, 1 row affected (0.00 sec)

mysql> SELECT * FROM innotest;
+-------+
| campo |
+-------+
|     1     |
|     2     |
|     3     |
|     4     |
+-------+
4 rows in set (0.00 sec)

Si aplicamos el Rollback los cambios no tendran efecto:

mysql> ROLLBACK;
Query OK, 0 rows affected (0.06 sec)

mysql> SELECT * FROM innotest;
+-------+
| campo |
+-------+
|     1     |
|     2     |
|     3     |
+-------+
3 rows in set (0.00 sec)

3) Si hacemos una operación commit por lo contrario, los cambios se realizaran:

mysql> BEGIN;
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO innotest VALUES(4);
Query OK, 1 row affected (0.00 sec)

mysql> COMMIT;
Query OK, 0 rows affected (0.02 sec)

mysql> SELECT * FROM innotest;
+-------+
| campo |
+-------+
|     1     |
|     2     |
|     3     |
|     4     |
+-------+
4 rows in set (0.00 sec)

Como hacer el recovery:

Backup:mysqldump –host IP_DEL_SERVER –user USUARIO –opt DATABASE -p > BACKUP_NAME(La opción –opt optimiza el proceso de backup y es recomenado su uso)
Restore:mysql –host IP_DEL_SERVER -u USUARIO -p DATABASE < BACKUP_NAME