Replicacion

Que es Replica (replication) de una base de datos

Replicación es el proceso de copiar y administrar objetos de base de datos, tales 

como tablas, hacia múltiples bases de datos en localidades remotas que son parte de un 

sistema de bases de datos distribuido. Los cambios ejecutados en una localidad son 

capturados y guardados localmente antes de ser aplicados a las localidades remotas. Los términos sistemas de bases de datos distribuidas y replicación de bases de datos, 

están relacionados, pero no son equivalentes. En un sistema puro de bases de datos 

distribuidas se maneja o administra una sola copia de todos los objetos de la base de 

datos y sus datos, es decir que existe de manera única la ocurrencia de un objeto de base 

de datos en todas las localidades, es decir la información se encuentra particionada de 

manera horizontal entre todas las localidades. Las aplicaciones en una base de datos 

distribuida utilizan transacciones distribuidas para acceder y modificar tanto los datos 

locales como remotos. 

El término replicación se refiere a la operación de copiar y administrar objetos de 

base de datos en múltiples bases de datos a lo largo de un sistema distribuido, en este 

caso, existen varias copias del mismo objeto en diferentes localidades. Dado que la 

replicación depende de una tecnológica de base de datos distribuida, la replicación 

ofrece beneficios en las aplicaciones, que no son posibles en un ambiente puro de base 

de datos distribuida, tal como la disponibilidad y rendimiento.

Beneficios

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

·         Disponibilidad.-El modo en que la replicación incrementa la disponibilidad de los datos para los usuarios y aplicaciones.

·         Fiabilidad.- Al haber múltiples copias de los datos disponibles en el sistema, se dispone de un mecanismo excelente de recuperación cuando existan fallos en nodos.

·         Rendimiento.- Se mejora para las transacciones de consulta cuando se introduce la replicación en un sistema que estuviera aquejado de sobrecarga de recursos centralizados.

·         Reducción de la carga.- Modo en que se utiliza la replicación para distribuir datos en ubicaciones remotas

·         Copia de seguridad:En condiciones normales, una base de datos replicada de forma correcta es válida como copia de seguridad.Además se puede realizar copias de seguridad usando un servidor esclavo para así no interferir al servidor maestro.

·         Mejorar la escalabilidad:Podríamos configurar nuestras aplicaciones para balancear las consultas de lectura (SELECT) entre los servidores replicados.

·         Alta disponibilidad:En aplicaciones y entornos en donde sólo se requieren lecturas, podríamos configurar nuestras aplicaciones para balancear las consultas de lectura (SELECT) entre los servidores replicados de manera que si uno se cae se continue prestando servicio.

·         Las replicas locales constituyen una ayuda especialmente útil cuando se desea trabajar en una computadora que en ocasiones no estará conectada a la red donde se encuentra el servidor en el que reside el curso.


Ejemplo de una replicacion de una base de datos

Espejeo

Que es Espejeo?

Base de Datos Espejo (Database Mirroring) es una configuración donde dos o tres servidores de dase 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).

Beneficios de el Espejeo

La gran ventaja de este método es que permite el failover automático sin intervención humana (siempre que se instale un tercer servidor witness). De hecho, en la cadena de conexión de las aplicaciones de .NET, podemos especificar cuando conectamos con la aplicación el servidor de sql al que nos conectamos y un failover partner, osea un servidor mirror para que en caso de failover, la aplicación pueda reconectar automáticamente al otro servidor.  La desventaja del mirror, respecto el log shipping y la replicación, es que sólo podemos tener una máquina secundaria o mirror y que esta no es accesible y no podemos tenerla en modo lectura.

Como Activar el Espejeo.

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.

Base de datos de prueba que queremos reflejar

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.

Base de datos de Prueba restaurada en modo NORECOVERY

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.

Opción Mirror de las propiedades de la base de datos

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.

Botón que lanza el asistente de configuración del Mirror

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.

Configuración de las 3 instancias del mirror

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.

Configuración de la primera instancia

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.

Configuración de la segunda instancia

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

Configuración de la tercera instancia

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.

Configuración de la seguridad del mirror

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

Configuración de los EndPoints

Una vez acabado el asistente, aparece una pantalla en donde nos indica que ha acabado de configurar el mirror y que ya podemos ponerlo en marcha pulsando en Start Mirroring.

Comienzo del mirror

Desde ese preciso instante, cualquier cambio que se haga en la base de datos de la primera instancia, será reflejado en la base de datos de la segunda instancia. Para ello restaura automáticamente el log de cambios de la primera en la segunda. Además desde ese momento, si la primera instancia falla, la segunda se pondrá automáticamente en marcha, porque una tercera se lo indica.

Para comprobar que el mirror se ha efectuado correctamente, tenemos que mirar la base de datos de la primera instancia y la de la segunda. La primera será accesible e indicará (Principal, Synchronizing) y la segunda no será accesible e indicará (Mirror, Syncronized / Restoring).

Bases de datos Principal y Reflejada del Mirror

Como podemos observar, hay una base de datos que es la que proporciona el servicio (Principal) y la otra es la Reflejada (Mirror). Cuando falle la instancia o la base de datos de la primera, el witness hará que automáticamente cambie los roles y el mirror pase a principal y el principal a mirror.

Si queremos cambiar los roles, por ejemplo porque queremos instalar y actualizar software en la primera instancia y necesitamos pararla, entonces podemos forzar el failover de una instancia a la otra. Para ello, desde el cuadro de configuración del mirror, podemos pulsar el botón Failover. En el momento lo pulsemos, veremos que la primera instancia se convierte en mirror y la segunda en Principal.

Failover manual de la base de datos en mirror

Problemas de seguridad que se pueden presentar en relación a las bases de datos

1.        La seguridad de las bases de datos

La gran mayoría de los datos sensibles del mundo están almacenados en sistemas gestores de bases de datos comerciales tales como Oracle, Microsoft SQL Server entre otros, y atacar una bases de datos es uno de los objetivos favoritos para los criminales.
Esto puede explicar por qué los ataques externos, tales como inyección de SQL, subieron 345% en 2009, “Esta tendencia es prueba adicional de que los agresores tienen éxito en hospedar páginas Web maliciosas, y de que las vulnerabilidades y explotación en relación a los navegadores Web están conformando un beneficio importante para ellos”[*]
Para empeorar las cosas, según un estudio publicado en febrero de 2009 The Independent Oracle Users Group (IOUG), casi la mitad de todos los usuarios de Oracle tienen al menos dos parches sin aplicar en sus manejadores de bases de datos [1].
 Mientras que la atención generalmente se ha centrado en asegurar los perímetros de las redes por medio de, firewalls, IDS / IPS y antivirus, cada vez más las organizaciones se están enfocando en la seguridad de las bases de datos con datos críticos, protegiéndolos de intrusiones y cambios no autorizados.
En las siguientes secciones daremos las siete recomendaciones para proteger una base de datos en instalaciones tradicionales.

2.        Principios básicos de seguridad de bases de datos

En esta sección daremos siete recomendaciones sobre seguridad en bases de datos, instaladas en servidores propios de la organización.

2.1 Identifique su sensibilidad

No se puede asegurar lo que no se conoce.

Confeccione un buen catálogo de tablas o datos sensibles [2] 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 [3], colocado en su base de datos el resultado de los ataques de inyección SQL [4]; 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.

2.2 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.

2.3 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.

2.4 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.

2.5 Monitoreo

Monitoreo en tiempo real de la actividad de base de datos es clave para limitar su exposición, aplique o adquiera agentes inteligentes [5] 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.

2.6 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.

2.7 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 [6] 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.

Problemas de seguridad

Existen dos tipos de mecanismos de seguridad contra el acceso no autorizado: en Discrecionales, se usan para otorgar privilegios a los usuarios. Obligatorios, sirven para imponer seguridad de múltiples niveles clasificando los datos los usuarios en varias clases de seguridad e implementando después la política de seguridad apropiada de la organización. Además se pueden crear cuentas de acceso a la base de datos para los distintos usuarios, las cuales se podrí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 a partir de consultas, lo que tampoco debe permitirse. en Otra técnica de seguridad es el cifrado de datos.


Seguridad de la base de datos y el DBA

El administrador de bases de datos (DBA) es la autoridad central que controla un sistema de este tipo. El DBA tiene una cuenta privilegiada en el SGBD, a veces denominada cuenta del sistema, que confiere capacidades extraordinarias no disponibles para cuentas y usuarios ordinarios de la base de datos. El DBA ejecuta los siguientes tipos de acciones:

• Creación de cuentas
• Concesión de privilegios
• Revocación de privilegios
• Asignación de niveles de seguridad El DBA es el responsable de la seguridad global del sistema de base de datos.

 Violaciones de Seguridad

Entre las formas de acceso malintencionado se
encuentran:

•La lectura no autorizada de los datos (robo de información)
•La modificación no autorizada de los datos
•La destrucción no autorizada de los datos

La seguridad de las bases de datos se refiere a la protección frente a accesos malintencionados. Para proteger la base de datos hay que adoptar medidas de seguridad en varios niveles:

• Sistema de bases de datos
• Sistema operativo
• Red
• Físico
• Humano

Debe conservarse la seguridad en todos estos niveles si hay que asegurar la seguridad de la base de datos. La debilidad de los niveles bajos de seguridad (físico o humano) permite burlar las medidas de seguridad estrictas de niveles superiores (base de datos). La seguridad dentro del sistema operativo se aplica en varios niveles, que van desde las contraseñas para el acceso al sistema hasta el aislamiento de los procesos concurrentes que se ejecutan en el sistema. El sistema de archivos también proporciona algún nivel de protección.

Rendimiento de una base de datos

Técnicas de estimación para   medir el rendimiento de la base de datos 

La evaluación continua del rendimiento de la base de datos ayuda a minimizar los tiempos de respuesta y a maximizar el rendimiento, obteniendo como resultado un rendimiento óptimo. El tráfico de red, la E/S de disco y el uso de la CPU eficientes son factores clave para obtener un buen rendimiento. Es necesario analizar a fondo los requisitos de las aplicaciones, comprender la estructura lógica y física de los datos, evaluar el uso de la base de datos y negociar contrapartidas, como el procesamiento de transacciones en línea (OLTP) frente a los sistemas de ayuda a la toma de decisiones.

Las condiciones cambiantes se traducen en cambios en el rendimiento. En sus evaluaciones, los cambios de rendimiento se aprecian a medida que el número de usuarios aumenta, los métodos de acceso y conexión de los usuarios cambian, el contenido de la base de datos crece, las aplicaciones cliente cambian, los datos de las aplicaciones cambian, las consultas son más complejas y el tráfico de red crece. Con la ayuda de las herramientas de SQL Server para supervisar el rendimiento, puede asociar algunos cambios del rendimiento con las condiciones cambiantes y las consultas complejas. A continuación se muestran algunos escenarios a modo de ejemplo:

•             Mediante la supervisión de los tiempos de respuesta para las consultas utilizadas con frecuencia, puede determinar si es necesario modificar la consulta o los índices de las tablas donde es necesario ejecutar las consultas.

•             Mediante la supervisión de las consultas Transact-SQL cuando se ejecutan, puede determinar si están escritas correctamente y si producen los resultados esperados.

•             Mediante la supervisión de los usuarios que intentan conectarse a una instancia de SQL Server, puede determinar si la seguridad está configurada de forma correcta y probar las aplicaciones o sistemas de desarrollo.

El tiempo de respuesta se mide como el tiempo necesario para devolver la primera fila del conjunto de resultados al usuario, en forma de confirmación visual de que se está procesando una consulta. El rendimiento es el número total de consultas controladas por el servidor durante un periodo determinado.

A medida que aumenta el número de usuarios, aumenta la competencia para obtener recursos de un servidor, y esto hace que el tiempo de respuesta aumente y el rendimiento global disminuya.

Si trabajas habitualmente con MySQL probablemente habrás escuchado queMySql no es la elección acertada para manejar tablas con mas de 1,000.000 de registros.

Pero entonces porque MySql es el motor de compañías como Google, Yahoo o Technorati,

El motivo de este gran rendimiento es que estas tablas que tienen cientos de millones de registros están diseñadas y entendidas para trabajar con MySql.

Por ello 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”.

Pongamos que comenzamos con un tamaño de memoria y notamos un descenso gradual del rendimiento porque la base de datos está creciendo, la solución sería asegurarnos que tenemos memoria suficiente para el volumen de datos que estamos utilizando.

Í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 yleer toda la tabla para encontrar los registros relevantes.

Un error común es pensar que los índices no afectan en tablas con poco volumen de datos, aún en tablas pequeñas (1.000 registros) es por lo menos 100 veces más rápido leer datos utilizando un índice, sin este índice estaríamos haciendo una lectura secuencial.

Por lo tanto queda claro que los índices son realmente eficaces para acelerar el acceso a datos.

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.

Rendimiento 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.

A continuación, se relacionan dichas pruebas de rendimiento:

Técnicas de estimación del tiempo de respuesta

Componentes del tiempo de respuesta de la base de datos

El tiempo que tarda el DB2 en preocsar una petición SQL se divide en:

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

2. Tiempo esperando algun suceso. Aquí puede habir multiples causas, pero las mas importantes y comunes son dos:

a) Tiempo de espera de las operaciones de entrada / salida, es decir, espera por los accesos a disco.

b) Tiempo de espera por algun recurso que esta bloqueado. Estos tiempos de espera los registra el DB2 Performance Monitos en el epígrafe de tiempos de clase 3.

En resumen, para evaluar el diseño físico, como ya hemos dicho, hay que estimar el rendimiento que vamos a obtener. Esto implica estimar el tiempo de respuesta de los programas en sus peticiones de datos, para lo cual simplificaremos considerando solamente los tres componentes citados: CPU, E/S y bloqueos.

Fuentes de consulta:

http://www.tufuncion.com/optimizar_MySQL

http://msdn.microsoft.com/es-mx/library/ms179440(v=sql.105).aspx

http://www.ongei.gob.pe/publica/metodologias/Lib5083/cap2063.HTM

Libro:

Bases de datos relacionales: diseño físico: Orientada al DB2 para z/OS de IBM)

 By Enrique Rivero Cornelio, Carlos Guardia Rivas, José Carlos Reig Hernández

Indices

Concepto

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.
Los índices pueden ser creados usando una o más columnas, proporcionando la base tanto para búsquedas rápidas al azar como de un ordenado acceso a registros eficiente.
Los índices son construidos sobre árboles B, B+, B* o sobre una mezcla de ellos, funciones de cálculo u otros metodos.
El espacio en disco requerido para almacenar el índice es típicamente menor que el espacio de almacenamiento de la tabla (puesto que los índices generalmente contienen solamente los campos clave de acuerdo con los que la tabla será ordenada, y excluyen el resto de los detalles de la tabla), lo que da la posibilidad de almacenar en memoria los índices de tablas que no cabrían en ella. En una base de datos relacional un índice es una copia de una parte de la tabla.


Crear 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]


Crear 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);


Para mas informacion visite: http://www.programacion.com/articulo/indices_y_optimizacion_de_consultas_305/2

Modos de operación de un sgbd

Rollback

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. Son cruciales para la recuperación de crashes de un servidor de base de datos; realizando rollback(devuelto) cualquier transacción que estuviera activa en el tiempo del crash, la base de datos es restaurada a un estado consistente.

Commit

 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.

Una sentencia COMMIT en SQL finaliza una transacción de base de datos dentro de un sistema gestor de base de datos relacional (RDBMS) y pone visibles todos los cambios a otros usuarios. El formato general es emitir una sentencia BEGIN WORK, una o más sentencias SQL, y entonces la sentencia COMMIT. Alternativamente, una sentencia ROLLBACK se puede emitir, la cual deshace todo el trabajo realizado desde que se emitió BEGIN WORK. Una sentencia COMMIT publicará cualquiera de los savepoints (puntos de recuperación) existentes que puedan estar en uso.

En términos de transacciones, lo opuesto de commit para descartar los cambios "en tentativa" de una transacción, es un rollback.

Recovery

Los procesos de restauración ( restore o recovery) de los que todo SGBD dispone pueden reconstruir la BD y darle el estado consistente y correcto anterior al incidente. Esto se acostumbra a hacer gracias a la obtención de copias periódicas de los datos( se denomina copias de seguridad o back-up) y mediante el mantenimiento continuo de un diario (log) donde el SGBD va anotando todas las escrituras que se hacen en la BD.