viernes, 26 de abril de 2013

Espejeo

  1. Que es Espejeo (mirroring)?

En Internet, un espejo, (del inglés, mirror), es un sitio web que contiene una réplica exacta de otro. Estas réplicas u espejos se suelen crear para facilitar descargas grandes y facilitar el acceso a la información aún cuando haya fallos en el servicio del servidor principal.
Los espejos suelen sincronizarse periódicamente con el servidor principal para mantener la integridad de la información.
Es un concepto muy utilizado en foros cibernéticos donde los usuarios de estos comparten archivos entre sí, ya que en ocasiones algunos de estos no pueden ser descargados adecuadamente, por lo que se informa sobre un espejo para obtenerlo.
En el caso de las redes, «espejo» (o mirror) también hace referencia al modo en el que trabaja un switch, al hacer réplica de todos los paquetes que este conmuta direccionados a un solo puerto a través del cual, con un analizador de tráfico, se puede observar todo el tráfico de la red.

Mirror o Espejo
 
Son las transacciones diarias que se registran en la Base de Datos. Cuando ocurre un problema se acude a los archivos de logs se hace un REVERSO y tambièn se puede recuperar la ùltima transacción que se hizo.

Seguridad de los Datos
Se presentan cuando no es posible establecer claves de acceso y resguardo en forma uniforme para todo el sistema, facilitando así el acceso a intrusos.
La seguridad de los datos se puede definir en las siguientes aspectos:
  • Objeto a asegurar: el primer objeto a asegurar son los objetos, programas y finalmente al esquema.
  • Codificaciòn de Claves: el DBMS provee la seguridad de los Login (usuario y password).
  • Control de Acceso: se especifican seguridades contra accesos indicados orientado a personas no autorizada.
  1. Beneficios del espejeo de Datos en un DBMS.
4D Server permite efectuar backups de la base en la máquina espejo.

Todos los medios convencionales se pueden utilizar para llevar a cabo backups en la máquina espejo: backup manual vía el comando de menú Archivo, backup periódico definido en las Preferencias o backup programado utilizando los comandos del lenguaje.

Para evitar riesgos de desincronización con la máquina operacional, 4D bloquea automáticamente la máquina espejo cuando se está llevando a cabo una de las dos operaciones básicas: la integración del archivo de historial de la máquina operacional y el backup de la base espejo.
  • Durante la integración del archivo de historial, no es posible llevar a cabo un backup. Si se utiliza el comando BACKUP, se genera el error 1417 (ver la sección ).
  • Cuando un backup está en marcha, todos los procesos se congelan y no es posible poner en marcha la integración de un archivo de historial.
  1. como se hace una Activación de espejeo en un DBMS.
PasoEquipo en operaciónEquipo espejo
1Arranque de la aplicación, back up del archivo de datos y activación (si es necesaria) del archivo de historial.
4D crea el archivo MyDatabase.journal. Para mayor seguridad, el archivo de historial se guarda en un disco duro separado.
Salimos de la aplicación.
Copia de todos los archivos de la base (archivo de historial incluido) en el equipo espejo.
2Reinicio de la aplicación e inicio de la operación (verificar que no haya un backup total programado).Inicio de la aplicación espejo. 4D Server solicita el archivo de historial actual: selección del archivo MyDatabase.journal que fue transferido de la base operacional. Desactivación del historial actual en la página Backup/Configuración de las Preferencias
3Decisión de actualizar el espejo (por ejemplo, después de un cierto periodo de operación).
Ejecución del método que contiene el comando New log file. El archivo guardado se llama MyDatabase[0001-0001].journal.
Envío por programación del archivo MyDatabase[0001-0001].journal al equipo espejo (utilizando 4DIC, Servicios web, etc.).
La base está en operación.
4Detección de un archivo que está esperando a ser integrado. Ejecución del método que contiene el comando INTEGRATE LOG FILE para integrar el archivo MyDatabase[0001-0001].journal.
5Incidente en el equipo; la base es inutilizable. Decisión de pasar al equipo espejo.
Copia del archivo de historial actual MyDatabase.journal al equipo espejo, vía la carpeta de recepción habitual.
6Análisis del incidente y reparación.Detección de un archivo que está esperando a ser integrado. Ejecución del método que contiene el comando INTEGRATE LOG FILE para integrar el archivo MyDatabase.journal.
Por seguridad, creación de un archivo de historial actual en la página Backup/Configuración de las Preferencias.
La base está en operación.
7La máquina se repara. Remplazo de los archivos de la base por los de la base espejo. Inicio de la aplicación. 4D Server solicita el archivo de historial: selección del archivo transferido desde el equipo espejo.Salimos de la base. Volver al paso 2.

  1. ejmplos de Creación de espacios de disco con espejo
La creación de un sistema de backup por espejo lógico se basa en dos nuevos comandos: New log file e INTEGRATE LOG FILE. Estos comandos se describen en el manual Lenguaje de 4D.

Los principios siguientes aplican:
  • La base está instalada en el equipo 4D Server principal (máquina de funcionamiento) y una copia idéntica de la base está instalada en la máquina 4D Server espejo.
  • Una prueba al inicio de la aplicación (por ejemplo, para detectar la presencia de un archivo específico en la carpeta 4D Extensions) permite distinguir entre las dos versiones (operacional y espejo) y por tanto ejecutar las operaciones apropiadas.
  • En la máquina 4D Server en funcionamiento, el archivo de historial es "segmentado" a intervalos regulares con el comando New log file. Dado que ninguna copia de seguridad se lleva a cabo en el servidor principal, la base se mantiene disponible permanentemente en modo lectura-escritura.
  • Cada “segmento” del archivo de historial se envía a la máquina espejo, donde se integra a la base espejo utilizando el comando INTEGRATE LOG FILE.
La creación de este sistema necesita la programación de código específico, en particular:
  • Un contador de tiempo en el servidor principal para la gestión de los ciclos de ejecución del comando New log file,
  • Un sistema de transferencia para los "segmentos" del archivo de historial entre la máquina operacional y la máquina espejo (usando 4D Internet Commands para una transferencia vía FTP o por sistemas de mensajería, servicios web, etc),
  • Un proceso en la máquina espejo destinada a supervisar la llegada de nuevos "segmentos" del archivo de historial y de integrarlos usando el comando INTEGRATE LOG FILE,
  • Un sistema de comunicación y de gestión de errores entre el servidor principal y el servidor espejo.
ATENCIÓN: un sistema de backup por espejo lógico no es compatible con los backup "estándar" en una base en uso ya que el uso simultáneo de estos dos modos de backup dará lugar a la desincronización de la bases operacional y espejo. Por consiguiente, debe estar seguro de que ningún backup, automático o manual, se efectúe en la base operacional. Por otra parte, es posible hacer backups de la base espejo (ver el siguiente párrafo).





Publicado por en No hay comentarios:

miércoles, 24 de abril de 2013

problemas de seguridad

Los siguientes siete requisitos son esenciales para la seguridad de la base de datos:

  • La base de datos debe ser protegida contra el fuego, el robo y otras formas de destrucción.
  • Los datos deben ser reconstruibles, porque por muchas precauciones que se tomen, siempre ocurren accidentes.
  • Los datos deben poder ser sometidos a procesos de auditoria. La falta de auditoria en los sistemas de computación ha permitido la comisión de grandes delitos.
  • El sistema debe diseñarse a prueba de intromisiones. Los programadores, por ingeniosos que sean, no deben poder pasar por alto los controles.
  • Ningún sistema puede evitar de manera absoluta las intromisiones malintencionadas, pero es posible hacer que resulte muy difícil eludir los controles. El sistema debe tener capacidad para verificar que sus acciones han sido autorizadas. Las acciones de los usuarios deben ser supervisadas, de modo tal que pueda descubrirse cualquier acción indebida o errónea.
SERVICIOS DE SEGURIDAD

Existen varios servicios y tecnologías relacionadas con la seguridad. Accede a cada una de ellas para conocer qué tecnologías son las más interesantes:
Autenticación: Se examinan las capacidades de logon único a la red, autenticación y seguridad. Además, se proporciona información sobre el interfaz Security Support Provider Interface (SSPI) para obtener servicios de seguridad integrados del sistema operativo. Kerberos es el protocolo por defecto en Windows 2000 para autenticación en red.
Sistema de Archivos Encriptado: El Sistema de Archivos Encriptado (Encrypted File System - EFS) proporciona la tecnología principal de encriptación de archivos para almacenar archivos del sistema de archivos NTFS de Windows NT encriptados en disco.
Seguridad IP: Windows IP Security, del Internet Engineering Task Force, proporciona a los administradores de redes un elemento estratégico de defensa para la protección de sus redes.
Servicios de seguridad en Windows 2000: se examinan los procedimientos relacionados con la gestión de cuentas, autenticación de red a nivel corporativo, así como el Editor de Políticas de Seguridad.
Tarjetas Inteligentes: se examinan los procesos de autenticación utilizando tarjetas inteligentes y los protocolos, servicios y especificaciones asociadas.
Tecnologías de Clave Pública: se revisa la infraestructura de clave pública incluida en los sistemas operativos de Microsoft y se proporciona información sobre criptografía.
Un SMBD cuenta con un subsistema de seguridad y autorización que se encarga de garantizar la seguridad de porciones de la BD contra el acceso no autorizado.

  • Identificar y autorizar a los usuarios: uso de códigos de acceso y palabras claves, exámenes, impresiones digitales, reconocimiento de voz, barrido de la retina, etc.
  • Autorización: usar derechos de acceso dados por el terminal, por la operación que puede realizar o por la hora del día.
  • Uso de técnicas de cifrado: para proteger datos en BD distribuidas o con acceso por red o internet.
  • Diferentes tipos de cuentas: en especial la del ABD con permisos para: creación de cuentas, concesión y revocación de privilegios y asignación de los niveles de seguridad.
  • 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 BD.
Discrecional: se usa para otorgar y revocar privilegios a los usuarios a nivel de archivos, registros o campos en un modo determinado (consulta o modificación).

El ABD asigna el propietario de un esquema, quien puede otorgar o revocar privilegios a otros usuarios en la forma de consulta (select), modificación o referencias. A través del uso de la instrucción grant option se pueden propagar los privilegios en forma horizontal o vertical.
Ejemplo: grant select on Empleado to códigoUsuario

revoke select on Empleado from códigoUsuario.
Obligatoria: sirve para imponer seguridad de varios niveles tanto para los usuarios como para los datos.
Problemas de seguridad.
La información de toda empresa es importante, aunque unos datos lo son más que otros, por tal motivo se debe considerar el control de acceso a los mismos, no todos los usuarios pueden visualizar alguna información, por tal motivo para que un sistema de base de datos sea confiable debe mantener un grado de seguridad que garantice la autenticación y protección de los datos. En un banco por ejemplo, el personal de nóminas sólo necesita ver la parte de la base de datos que tiene información acerca de los distintos empleados del banco y no a otro tipo de información
MEDIDAS DE SEGURIDAD
EN UN ENTORNO DE B.D.
 
CONFIDENCIALIDAD.
Autorización en sistemas de bases de datos.
  • Identificación y autenticación.
  • Código y contraseña.
  • Identificación por Hardware.
  • Características bioantropométricas.
  • Conocimiento, aptitudes y hábitos del usuario.
  • Información predefinida (Aficiones, cultura, etc.)
Privilegios al usuario.
  • Usar una B.D.
  • Consultar ciertos datos.
  • Actualizar datos.
  • Crear o actualizar objetos.
  • Ejecutar procedimientos almacenados.
  • Referenciar objetos.
  • Indexar objetos.
  • Crear identificadores.
Diferentes tipos de autorización.
Autorización explícita.
  • Consiste en almacenar que sujetos pueden acceder a ciertos objetos con determinados privilegios. Se usa una Matriz de Accesos
  • Autorización implícita.
  • Consiste que una autorización definida sobre un objeto puede deducirse a partir de otras.
DISPONIBILIDAD.
Los sistemas de B.D. Deben asegurar la disponibilidad de los datos a los usuarios que tienen derecho a ello, por lo que se proporcionan mecanismos que permiten recuperar la B.D. Contra fallos lógicos o físicos que destruyan los datos.
RECUPERACIÓN.
El principio básico en el que se apoya la recuperación de la base de datos es la Redundancia Física.
EXISTEN DOS TIPOS IMPORTANTES DE FALLOS:
  • Los que provocan la pérdida de memoria volátil, usualmente debidos a la interrupción del fluido eléctrico o por funcionamiento anormal del hardware.
  • Los que provocan la pérdida del contenido de memoria secundaria, por ejemplo, cuando patinan las cabezas en un disco duro.
4.3 Matriz de Autorización
La seguridad se logra si se cuenta con un mecanismo que limite a los usuarios a su vista o vistas personales. La norma es que la base de datos relacionales cuente con dos niveles de seguridad:
  • Relación. Puede permitírsele o impedírsele que el usuario tenga acceso directo a una relación.
  • Vista. Puede permitírsele o impedírsele que el usuario tenga acceso a la información que aparece en un vista.
Aunque es imposible impedir que un usuario tenga acceso directo a una información puede permitírsele acceso a una parte de esta relación por medio de una vista. De tal manera que es posible utilizar una combinación de seguridad al nivel relacional y al nivel de vistas para limitar el acceso del usuario exclusivamente a los datos que necesita.
Un usuario puede tener varias formas de autorización sobre partes de la base de datos. Entre ellas se encuentran las siguientes:
  • Autorización de lectura, que permite leer, pero no modificar la base de datos.
  • Autorización de inserción, permite insertar datos nuevos pero no modificar lo ya existente.
  • Autorización de actualización, que permite insertar modificar la información pero no permite la eliminación de datos.
  • Autorización de borrado, que permite la eliminación de datos.
Un usuario puede tener asignados todos, ninguno o una combinación de los tipos de autorización anteriores. Además de las formas de autorización de acceso de datos antes mencionadas, es posible autorizar al usuario para que modifique el esquema de la base de datos.
  • Autorización de índice, que permite la creación y eliminación de índices.
  • Autorización de recursos, que permite la creación de relaciones nuevas.
  • Autorización de alteración, que permite agregar o eliminar atributos de una relación.
  • Autorización de eliminación, que permite eliminar relaciones.
Las autorizaciones de eliminación y borrado difieren en cuanto a que la autorización de borrado solo permite la eliminación de tuplas. La habilidad para crear nuevas relaciones viene regulada por la autorización de recursos de tal forma que la utilización del espacio del almacenamiento puede ser controlada. La autorización de índice puede aparecer innecesariamente puesto que la creación o eliminación de un índice no altera los datos en las relaciones. Mas bien los índices son una estructura para realizar mejoras.
La forma fundamental de autoridad es la que se le da al administrador de la base de datos. El administrador de la base de datos puede entre otras cosas autorizar nuevos usuarios, reestructurar la base de datos, etc.
REPASO DEL MODELO DE PROTECCIÓN
Mecanismo para controlar el acceso del usuario y de los procesos a los recursos del sistema. El modelo clásico de protección está basado en el concepto de dominio de protección. Un dominio define un conjunto de objetos y los tipos de operaciones que pueden realizarse sobre cada objeto. En cada momento el proceso está asociado, estática o dinámicamente, a un dominio (en UNIX el uid y gid determinan el dominio).
El modelo de protección puede entenderse como una matriz de acceso donde las filas corresponden a dominios y las columnas a objetos. Cada elemento de la matriz especifica las operaciones permitidas sobre el objeto en este dominio. Hay dos formas típicas de almacenar la matriz: por columnas o filas.
LISTAS DE CONTROL DE ACCESO
La matriz se almacena por columnas: asociado a cada objeto se almacena una lista de dominios y operaciones permitidas en cada dominio (ACL). En la práctica normalmente se establecen clases de dominios (como grupos de usuarios de UNIX). Ejemplos:
  • Bits RWX como UNIX. Utilizado en Locus.
  • En AFS se usan ACL con las siguientes características:
  • Permiten establecer derechos positivos y negativos para los usuarios y grupos.
  • Controlan el acceso a directorios, no a ficheros.
  • Las operaciones controladas son: lookup, read, insert, write, delete, lock y administer.
SEGURIDAD

Un aspecto muy importante sobre todo en SD. Incluye servicios tales como:

  • Autentificación: Verificación de la identidad de un componente que genera datos (principal) por parte de otro componente (verificador).

  • Integridad y carácter confidencial de los datos transmitidos.

Los ataques a la seguridad pueden consistir en la escucha de los mensajes que se transmiten por la red, la inyección de mensajes en la red, la retransmisión de mensajes escuchados anteriormente, la suplantación del cliente o del servidor, etc. La solución a estos problemas se basa generalmente en utilizar criptografía tanto para proteger los datos como para autentificación. En la transmisión se aplica un algoritmo de cifrado al mensaje M usando una clave Kc y en la recepción se aplica el algoritmo de descifrado usando Kd. La función de cifrado es muy difícil de invertir sin conocer la clave. Existen dos esquemas:
Publicado por en No hay comentarios:

martes, 16 de abril de 2013

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

Establecer una línea base para el rendimiento


Para determinar si el sistema SQL Server funciona de forma óptima, tome medidas del rendimiento a intervalos regulares, incluso cuando no existan problemas, para establecer una línea base del rendimiento del servidor. Compare cada conjunto de medidas nuevo con las medidas tomadas anteriormente.
Las áreas siguientes afectan al rendimiento de SQL Server:


  • Recursos del sistema (hardware)
  • Arquitectura de red
  • Sistema operativo
  • Aplicaciones de bases de datos
  • Aplicaciones cliente
Como mínimo, utilice las medidas de línea base para determinar:
  • Las horas con el máximo y el mínimo nivel de funcionamiento.
  • Tiempos de respuesta de comandos de procesamiento por lotes o consultas de producción.
  • Tiempos de finalización de operaciones de copias de seguridad y restauración de bases de datos
Cuando haya establecido la línea base para el rendimiento del servidor, compare las estadísticas de la línea base con el rendimiento actual del servidor. Unas cifras demasiado elevadas o demasiado reducidas con respecto a la línea base indican que hay que realizar una investigación más detallada. Pueden indicar áreas que hay que optimizar o volver a configurar. Por ejemplo, si aumenta el tiempo necesario para ejecutar un conjunto de consultas, examine las consultas para determinar si puede volver a escribirlas o si es necesario agregar estadísticas de columnas u otros índices.

 

Determinar la actividad de los usuarios


Se puede supervisar la actividad de cada usuario para identificar el tipo y la ubicación de las transacciones de bloqueo o el rendimiento lento de Microsoft SQL Server.
La supervisión de la actividad de los usuarios ayuda a identificar tendencias como los tipos de transacciones ejecutadas por los usuarios, el número de consultas ineficaces y ad hoc, y los tipos de transacciones que requieren la mayor parte de los recursos. Para recopilar información estadística sobre los usuarios, utilice el SQL Server Profiler o el Monitor de sistema. Utilice el Monitor de actividad de SQL Server Management Studio para la supervisión ad hoc de SQL Server, lo que permite determinar la actividad de los usuarios en el sistema.

 

Aislar problemas de rendimiento






A menudo suele ser más efectivo utilizar conjuntamente varias herramientas de Microsoft SQL Server o Microsoft Windows para aislar los problemas de rendimiento de una base de datos que usar sólo una herramienta cada vez. Por ejemplo, la característica Plan de ejecución gráfico, denominada también plan de presentación, le ayuda a reconocer los interbloqueos en una sola consulta. Sin embargo, puede reconocer más fácilmente otros problemas de rendimiento si utiliza conjuntamente las características de supervisión de SQL Server y Windows.
El SQL Server Profiler puede utilizarse para supervisar y solucionar problemas de Transact-SQL o problemas relacionados con las aplicaciones. Asimismo, puede utilizar el Monitor de sistema para supervisar problemas relativos al hardware y otros problemas relacionados con el sistema.
Puede supervisar las siguientes áreas para solucionar problemas:
  • Procedimientos almacenados de SQL Server o lotes de instrucciones Transact-SQL enviadas por aplicaciones de usuarios.
  • Actividad de los usuarios, como bloqueos o interbloqueos.
  • Actividad del hardware, como el uso de los discos.
Algunos problemas posibles son:
  • Errores de programación de aplicaciones debidos a instrucciones Transact-SQL escritas incorrectamente.
  • Errores de hardware, como los relativos a discos o a la red.
  • Bloqueo excesivo debido a un diseño incorrecto de la base de datos.
Herramientas para solucionar problemas comunes de rendimiento



Igual de importante es la correcta selección del problema de rendimiento que desea que cada herramienta supervise u optimice. La herramienta y la utilidad dependen del tipo de problema de rendimiento que desee resolver.
En los temas siguientes se describen diversas herramientas de supervisión y optimización y los problemas que ayudan a solucionar.
Identificar cuellos de botella
Minimizar los interbloqueos
Administrar la memoria para bases de datos de gran tamaño
Supervisar el uso de la memoria
Optimizar el diseño físico de las bases de datos

 

Identificar cuellos de botella




El acceso simultáneo a recursos compartidos causa cuellos de botella. En general, los cuellos de botella están presentes en todos los sistemas de software y son inevitables. Sin embargo, la demanda excesiva de recursos compartidos causa un tiempo de respuesta largo, y debe identificarse y corregirse.
Entre las causas de estos cuellos de botella se incluyen:
  • Recursos insuficientes que requieren componentes adicionales o actualizados.
  • Recursos del mismo tipo que no distribuyen de forma equilibrada las cargas de trabajo; por ejemplo, cuando un recurso monopoliza un disco.
  • Recursos que funcionan incorrectamente.
  • Recursos mal configurados.



La duración excesiva de varios eventos es un indicador de cuello de botella que puede corregirse.
Por ejemplo:
  • Otros componentes pueden evitar que la carga alcance este componente, lo que aumenta el tiempo que se tarda en completar la carga.
  • Las solicitudes de cliente pueden tardar más tiempo debido a una congestión de la red.
A continuación se indican cinco áreas clave que hay que supervisar para realizar un seguimiento del rendimiento del servidor e identificar cuellos de botella.

Posible área del cuello de botellaEfectos en el servidor
Uso de la memoriaSi no se asignó o no hay disponible suficiente memoria para Microsoft SQL Server, el rendimiento disminuirá. Los datos se deben leer en el disco, y no directamente en la caché de datos. Los sistemas operativos Microsoft Windows realizan una paginación excesiva intercambiando datos con el disco cuando son necesarias las páginas.
Uso de la CPUUn uso excesivo continuo de la CPU puede indicar que las consultas de Transact-SQL deben optimizarse o que es necesaria una actualización de la CPU.
Entrada/salida (E/S) de disco Las consultas de Transact-SQL se pueden optimizar para reducir la E/S innecesaria; por ejemplo, mediante el uso de índices.
Conexiones de usuarioPuede haber demasiados usuarios obteniendo acceso al servidor de forma simultánea, lo que disminuye el rendimiento.
Bloqueos de cierreLas aplicaciones diseñadas incorrectamente pueden causar simultaneidad de obstáculos y bloqueos, lo que genera tiempos de respuesta más largos y un menor rendimiento de las transacciones.
 

 

Minimizar los interbloqueos




A pesar de que los interbloqueos no se pueden evitar totalmente, si se siguen ciertas convenciones de codificación se puede reducir su generación. La minimización de los interbloqueos puede aumentar el rendimiento de las transacciones y reducir la sobrecarga del sistema, debido a que:
  • Se revierten menos transacciones, al deshacer todo el trabajo que realiza la transacción.
  • Las aplicaciones vuelven a enviar menos transacciones debido a que se revirtieron cuando se produjo el interbloqueo.
Para ayudar a reducir los interbloqueos:
  • Obtenga acceso a los objetos en el mismo orden.
  • Evite la interacción con los usuarios en las transacciones.
  • Mantenga transacciones cortas y en un proceso por lotes.
  • Utilice un nivel de aislamiento inferior.
  • Utilice un nivel de aislamiento basado en las versiones de las filas.
    • Establezca la opción de base de datos READ_COMMITTED_SNAPSHOT en ON para que las transacciones de lectura confirmada utilicen las versiones de filas.
    • Utilice el aislamiento de instantánea.
  • Utilice conexiones enlazadas.



Si todas las transacciones simultáneas tienen acceso a los objetos en el mismo orden, es menos probable que se produzcan interbloqueos. Por ejemplo, si dos transacciones simultáneas obtienen un bloqueo en la tabla Supplier y, a continuación, en la tabla Part, una transacción se bloquea en la tabla Supplier hasta que finalice la otra transacción. Una vez confirmada o revertida la primera transacción, continúa la segunda, por lo que no se produce un interbloqueo. La utilización de procedimientos almacenados para todas las modificaciones de datos puede normalizar el orden de acceso a los objetos.
Diagrama en el que se muestra el modo de evitar un interbloqueo
Evite escribir transacciones que incluyan la intervención del usuario, ya que la velocidad de ejecución de los lotes que no requieren esta intervención es mucho mayor que la velocidad con la que el usuario debe responder manualmente a las consultas como, por ejemplo, contestar a la petición de un parámetro por parte de una aplicación. Por ejemplo, si una transacción espera una entrada del usuario y éste sale a comer o no vuelve hasta pasado el fin de semana, dicho usuario retrasa la finalización de la transacción. De esta forma, se degrada el rendimiento del sistema, ya que los bloqueos que mantiene la transacción sólo se liberan cuando se confirma o se revierte la transacción. Aunque no surja una situación de interbloqueo, las demás transacciones que obtienen acceso a los mismos recursos se bloquean mientras esperan a que la transacción finalice.
Mantener transacciones cortas y en un proceso por lotes



Normalmente, los interbloqueos se producen cuando varias transacciones de larga duración se ejecutan simultáneamente en la misma base de datos. Cuanto más dure la transacción, más tiempo se mantendrán los bloqueos exclusivos o de actualización, con lo cual se bloquean otras actividades y se originan posibles situaciones de interbloqueo.
Al mantener las transacciones en un proceso por lotes, se minimizan los viajes de ida y vuelta en la red durante una transacción y se reducen los posibles retrasos al completar la transacción y liberar los bloqueos.
Utilizar un nivel de aislamiento inferior



Determine si una transacción se puede ejecutar con un nivel de aislamiento inferior. Al implementar la lectura confirmada, se permite a una transacción leer los datos previamente leídos (no modificados) por otra transacción, sin tener que esperar a que la primera transacción finalice. Utilizar un nivel inferior de aislamiento, como la lectura confirmada, mantiene los bloqueos compartidos durante menos tiempo que un nivel superior de aislamiento, como el nivel serializable. De esta forma, se reduce la contención de bloqueos.
Utilizar un nivel de aislamiento basado en las versiones de las filas



Si la opción de base de datos READ_COMMITTED_SNAPSHOT se ha establecido en ON, la transacción que se ejecuta con el nivel de aislamiento de lectura confirmada utiliza la versión de filas en lugar de bloqueos compartidos durante las operaciones de lectura.

 

 

Administrar la memoria para bases de datos de gran tamaño






SQL Server utiliza la API de las Extensiones de ventana de dirección (AWE) para admitir los tamaños de memoria física muy grandes. SQL Server admite hasta un máximo de 64 GB de memoria física en sistemas operativos Microsoft Windows de 32 bits: Microsoft Windows XP Professional; Windows 2000 Standar Edition; Windows 2000 Advanced Server; Windows 2000 Datacenter Server; Windows Server 2003 Enterprise Edition; o Windows Server 2003 Datacenter Edition.
SQL Server asigna de forma dinámica memoria AWE asignada cuando se ejecuta con cualquiera de las ediciones del sistema operativo Windows Server 2003. En otras palabras, el grupo de búferes puede administrar dinámicamente memoria AWE asignada para equilibrar el uso de memoria de SQL Server con los requisitos globales del sistema.
AWE soluciona una limitación inherente a las aplicaciones de 32 bits: éstas no pueden tener acceso a más de 4 gigabytes (GB) de espacio de direcciones del proceso. (Un puntero de 32 bits no puede mantener una dirección de memoria mayor que 4 GB).
Con AWE, las aplicaciones pueden reservar directamente memoria física hasta la cantidad máxima permitida por el sistema operativo como memoria no paginada. El uso de AWE permite a SQL Server copiar en caché más información, en vez de leerla desde los archivos de paginación del sistema en el disco. A su vez, esto proporciona beneficios de rendimiento con un acceso a datos más rápido y reduce la frecuencia de acceso al disco.

 

 

Supervisar el uso de la memoria




Supervise una instancia de SQL Server periódicamente para confirmar que la utilización de la memoria se encuentra dentro de los intervalos normales.
Para supervisar las condiciones de memoria insuficiente, utilice los contadores de objetos siguientes:
  • Memoria: Bytes disponibles
  • Memoria: Páginas/seg
El contador Bytes disponibles indica en bytes la memoria disponible actualmente para procesos. El contador Páginas/seg indica el número de páginas que se han recuperado del disco debido a errores de página no recuperables o que se han escrito en disco para liberar espacio en el espacio de trabajo debido a errores de página.
Un valor bajo en el contador Bytes disponibles puede indicar una escasez general de memoria en el equipo o que un programa no está liberando memoria. Un valor alto en el contador Páginas/seg puede indicar una paginación excesiva. Supervise el contador Memoria: Errores de página/s. para asegurarse de que la actividad del disco no está causada por la paginación.
Una tasa baja de paginación (y por tanto, de errores de página) es normal, incluso si el equipo tiene mucha memoria disponible. El Administrador de memoria virtual (VMM) de Microsoft Windows sustrae páginas de SQL Server y otros procesos a medida que recorta los tamaños del espacio de trabajo para estos procesos, lo que suele provocar errores de página. Para determinar si SQL Server u otro proceso, está causando una paginación excesiva, supervise el contador Proceso: Errores de página/s. de la instancia del proceso de SQL Server.
Para obtener más información acerca de cómo solucionar la paginación excesiva, vea la documentación del sistema operativo Windows.
Aislar la memoria que utiliza SQL Server



De forma predeterminada, SQL Server cambia dinámicamente sus necesidades de memoria según los recursos del sistema disponibles. Si SQL Server necesita más memoria, consulta el sistema operativo para determinar si hay memoria física disponible y la utiliza. Si SQL Server no necesita la memoria que tiene asignada actualmente, la libera para el sistema operativo. Sin embargo, el uso dinámico de la memoria puede anularse mediante las opciones de configuración de servidor min server memory y max server memory . Para obtener más información, vea el documento sobre las opciones de memoria del servidor.
Para supervisar la cantidad de memoria que utiliza SQL Server, examine los siguientes contadores de rendimiento:
  • Proceso: Espacio de trabajo
  • SQL Server: Buffer Manager: Frecuencia de aciertos de caché del búfer
  • SQL Server: Buffer Manager: Total de páginas
  • SQL Server: Memory Manager: Memoria total del servidor (KB)
El contador Espacio de trabajo muestra la cantidad de memoria que utiliza un proceso. Si este número es constantemente inferior a la cantidad de memoria establecida en las opciones del servidor min server memory y max server memory, SQL Server está configurado para utilizar más memoria de la que necesita.
El contador Frecuencia de aciertos de caché del búfer es específico de la aplicación. Sin embargo, es preferible un porcentaje del 90% o superior. Agregue más memoria hasta que el valor sea superior al 90%, lo que indica que se ha atendido más del 90% de todas las peticiones de información de la caché de datos.
Si el valor del contador Memoria total del servidor (KB) es constantemente alto en comparación con la cantidad de memoria física del equipo, puede que indique que se necesita más memoria.

 

 

Optimizar el diseño físico de las bases de datos


El rendimiento de los sistemas de bases de datos empresariales depende de una configuración eficaz de las estructuras de diseño físico de las bases de datos que componen dichos sistemas. Entre las estructuras de diseño físico se incluyen índices, clúster, vistas indizadas y particiones, cuyo objetivo es mejorar el rendimiento y la facilidad de uso de las bases de datos. SQL Server proporciona el Asistente para la optimización de motor de base de datos, una herramienta que analiza los efectos del rendimiento de las cargas de trabajo (un conjunto de instrucciones Transact-SQL que se ejecuta en las bases de datos que se desean optimizar) en una o más bases de datos.
En esta sección se presenta el Asistente para la optimización de motor de base de datos, se describe cómo utilizarlo y se proporciona información de solución de problemas.

 

Fuente

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

 

RENDIMIENTO DE UNA BASE DE DATOS TIEMPO DE RESPUESTA

Puede experimentar los síntomas siguientes en SQL Server:
  • Una base de datos no se expandirá automáticamente aunque tiene la opción de crecimiento automático ..
  • El archivo de registro de errores no contiene los mensajes que indican que la base de datos está lleno.
  • Los equipos cliente que intentan modificar los datos de esta base de datos de un mensaje "Tiempo de espera agotado" en sus transacciones de usuario.
  • El analizador de SQL muestra un evento de "Atención" en una conexión y, si el equipo está ejecutando SQL Server 7.0, el analizador de SQL también muestra un "error de excepción 822".
Nota: el mensaje "Tiempo de espera agotado" es un mensaje genérico que puede aparecer en otras situaciones.

Puede observar estos síntomas cuando:
  • Ejecutar el analizador de SQL durante mucho tiempo, capturar el evento de excepción y la columna IntegerData y, a continuación, busque una aparición de la "822" error de excepción.

    - O -
  • Se utiliza la -y822 parámetro para iniciar SQL Server. Después de la base de datos no se expande automáticamente, compruebe el archivo de registro de errores para un volcado de pila debido a de la "822" error de excepción.
Nota: puede expandir automáticamente el archivo de base de datos, pero el tiempo de espera se produce cuando se está inicializando el archivo para su uso, que debe transcurrir para que la base de datos sea útil.
Cuando una conexión emite una instrucción de idioma de modificación de datos (DML) que requiere espacio adicional en una base de datos, SQL Server intenta expandir automáticamente la base de datos, si ha configurado la opción de crecimiento automático . El cliente que ha emitido la instrucción puede agotar el tiempo mientras se está expandiendo la base de datos, dependiendo del valor de tiempo de espera de consulta que se ha configurado en el lado del cliente. Varias aplicaciones de utilizan un valor de tiempo de espera predeterminado de 30 segundos. Este tiempo de espera finaliza la conexión del cliente y la expansión automática de la base de datos se le pida.
Para evitar este comportamiento, utilice uno de los métodos siguientes:
  • Expanda la base de datos manualmente. Para expandir la base de datos manualmente, utilice la instrucción ALTER DATABASE o el Administrador corporativo de SQL Server.
  • Aumentar el valor de tiempo de espera de consulta de cliente de la aplicación que solicita la DML para que el servidor tenga tiempo para expandir la base de datos. El DML solicita para expandir la base de datos.

    Por ejemplo, si está utilizando el analizador de consultas SQL, el valor de tiempo de espera de consulta predeterminado es 0 (infinito). Si utiliza el valor predeterminado, no experimenta este comportamiento. Si no utiliza el valor predeterminado, aumente el valor de tiempo de espera de consulta.

    Para otras aplicaciones (ya sean basadas en Web o no), puede realizar el cambio en la aplicación. Por ejemplo, si utiliza ADO, puede cambiar la propiedad CommandTimeout del objeto de conexión o comando ..
  • Determinar cuánto tarda la expansión de la base de datos en el servidor. Para determinar esto, ejecute la instrucción ALTER DATABASE en el analizador de consultas SQL y, a continuación, ver la barra de estado. Después de determinar esto, establezca al cliente el valor de tiempo de espera en un valor mayor que este valor.
  • No cambie el valor de tiempo de espera del cliente. Realice la expansión automática de prueba para ver cuánto expansión completa en menor que el valor de tiempo de espera del cliente. Establezca la opción de crecimiento automático a este nuevo valor (menor).
FUENTE:
http://support.microsoft.com/kb/305635/es
Publicado por en No hay comentarios:

viernes, 12 de abril de 2013

Actividad #22


Investigar que es un archivo índice, tipos de indices
Investigar como crear los Indices en Mysql y oracle
Crear minimo 4 archivos indices de su base de datos (veterinaria), capturar pantallas y publicar en el blog

INDICE EN MYSQL

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.
Algunas bases de datos amplían la potencia del indexado al permitir que los índices sean creados de funciones o expresiones. Por ejemplo, un índice puede ser creado sobre la función upper(apellido), que almacenaría en el índice solamente las versiones mayúsculas del campo apellido. Otra opción a veces soportada, es el uso de índices "filtrados", donde las entradas del índice son creadas solamente para los registros que satisfagan una cierta expresión condicional. Un aspecto adicional de flexibilidad es permitir la indexación en funciones definidas por el usuario, también como expresiones formadas de un surtido de funciones incorporadas. Todos estos refinamientos de la indexación son soportados en Visual FoxPro y otros lenguajes de programación, por ejemplo.
Los índices pueden ser definidos como únicos o no únicos. Un índice único actúa como una restricción en la tabla previniendo filas idénticas en el índice.

Crear índices (motor de base de datos)

Las siguientes tareas forman parte de la estrategia recomendada para crear índices:
  1. Diseñar el índice.
    El diseño de índices es una tarea crítica. El diseño de índices incluye la determinación de las columnas que se utilizarán, la selección del tipo de índice (por ejemplo, agrupado o no agrupado), la selección de opciones de índice adecuadas y la determinación de grupos de archivos o de la ubicación de esquemas de partición. Para obtener más información, vea Diseñar índices.
  2. Determinar el mejor método de creación. Los índices se crean de las siguientes maneras:
    • Definiendo una restricción PRIMARY KEY o UNIQUE en una columna mediante CREATE TABLE o ALTER TABLE
      SQL Server Database Engine (Motor de base de datos de SQL Server) crea automáticamente un índice único para hacer cumplir los requisitos de unicidad de una restricción PRIMARY KEY o UNIQUE. De forma predeterminada se crea un índice clúster único para hacer cumplir una restricción PRIMARY KEY, a menos que ya exista un índice clúster en la tabla o que usted especifique un índice no clúster único. De forma predeterminada se crea un índice único no clúster para hacer cumplir una restricción UNIQUE a menos que se especifique de explícitamente un índice clúster único y no exista un índice clúster en la tabla.
      También se pueden especificar las opciones de índice, la ubicación del índice, el grupo de archivos o el esquema de la partición.
      Un índice creado como parte de una restricción PRIMARY KEY o UNIQUE recibe automáticamente el mismo nombre que la restricción. Para obtener más información, vea Restricciones PRIMARY KEY y Restricciones UNIQUE.
    • Creando un índice independiente de una restricción utilizando la instrucción CREATE INDEX , o el cuadro de diálogo Nuevo índice en el Explorador de objetos de SQL Server Management Studio
      Debe especificar el nombre del índice, de la tabla y de las columnas a las que se aplica el índice. También se pueden especificar las opciones de índice, la ubicación del índice, el grupo de archivos o el esquema de la partición. De forma predeterminada, se crea un índice que no es único y no está agrupado si no se especifican las opciones únicas o agrupadas. Para crear un índice filtrado, use la cláusula opcional WHERE. Para obtener más información, vea Directrices generales para diseñar índices filtrados.
  3. Crear el índice.
    Un factor importante que debe tenerse en cuenta es si el índice se creará en una tabla vacía o en una tabla con datos. La creación de un índice en una tabla vacía no tiene implicaciones de rendimiento en el momento de creación del índice; sin embargo, el rendimiento se verá afectado cuando se agreguen los datos a la tabla.
    La creación de índices en tablas grandes debe planearse con cuidado para que el rendimiento de la base de datos no se vea afectado. La mejor manera de crear índices en tablas de gran tamaño es empezar con el índice clúster y, a continuación, generar los índices no clúster. Considere la posibilidad de establecer la opción ONLINE en ON cuando cree índices en tablas existentes. Cuando se establece en ON, los bloqueos a largo plazo no se retienen, lo que permite que continúen consultas o actualizaciones a la tabla subyacente. Para obtener más información, vea Realizar operaciones de índices en línea.
Consideraciones de implementación
En la siguiente tabla se enumeran los valores máximos que se aplican a los índices clúster, no clúster, espaciales, filtrados y XML. A menos que se especifique lo contrario, las limitaciones se aplican a todos los tipos de índices.
Límites de índice máximosValorInformación adicional
Índices clúster por tabla1
Índices no clúster por tabla999Incluye índices no clúster creados por restricciones PRIMARY KEY o UNIQUE e índices filtrados, pero no índices XML.
Índices XML por tabla249Incluye índices XML principales y secundarios en columnas de tipos de datos xml.
Índices en columnas del tipo de datos XML
Índices espaciales por tabla249Trabajar con índices espaciales (motor de base de datos)
Número de columnas de clave por índice16*El índice clúster está limitado a 15 columnas si la tabla también contiene un índice XML principal o un índice espacial.
Tamaño máximo de las claves de índices.
Tamaño del registro de clave de índice900 bytes*No se aplica a índices XML ni a índices espaciales.
Para que una tabla admita el uso de índices espaciales, el tamaño máximo del registro de clave de índice es de 895 bytes.
Tamaño máximo de las claves de índices.
*Puede evitar limitaciones de tamaño de registro y de columna de clave de índice de índices no clúster incluyendo columnas sin clave en el índice. Para obtener más información, vea Índice con columnas incluidas.
Tipos de datos
Generalmente, se puede indizar cualquier columna de una tabla o de una vista. En la siguiente tabla se muestran todos los tipos de datos que tienen una participación de índice restringida.
Tipo de datosParticipación de índiceInformación adicional
Tipo definido por el usuario CLR Se puede indizar si el tipo admite el orden binario.Trabajar con tipos definidos por el usuario para CLR
Tipos de datos de objetos grandes (LOB): image, ntext, text, varchar(max), nvarchar(max), varbinary(max) y xmlNo pueden ser una columna de clave de índice. No obstante, una columna XML puede ser una columna de clave en una tabla o en un índice XML secundario o principal.
Pueden participar como columnas sin clave (incluidas) en un índice no clúster, excepto image, ntext y text.
Pueden participar si son parte de una expresión de columna calculada. 		Índice con columnas incluidas
Índices en columnas del tipo de datos XML
Columnas calculadasNo se pueden indizar. Esto incluye columnas calculadas definidas como invocaciones de métodos de una columna del tipo definido por un usuario CLR, mientras los métodos se marquen como deterministas.
Las columnas calculadas que se derivan de tipos de datos LOB se pueden indizar como columna con clave o sin clave mientras el tipo de datos de columna calculada se permita como columna de clave de índice o columna sin clave.		Crear índices en columnas calculadas
Columnas de Varchar de inserción no consecutivaLa clave de índice de un índice clúster no puede contener columnas varchar con datos existentes en la unidad de asignación ROW_OVERFLOW_DATA. Si un índice clúster se crea en una columna varchar y los datos existentes están en la unidad de asignación IN_ROW_DATA, las acciones de inserción o actualización posteriores de la columna que constituirían inserciones no consecutivas producirán un error.

Organización de tablas e índices
Datos de desbordamiento de fila superiores a 8 KB

geometrySe puede indizar con varios índices espaciales.

Tipos de datos espaciales
Consideraciones adicionales
A continuación se ofrecen algunas consideraciones adicionales para crear un índice:
  • Puede crear un índice si tiene el permiso CONTROL o ALTER en la tabla.
  • Cuando se crea, el índice se habilita automáticamente y está disponible para su uso. Puede quitar el acceso a un índice deshabilitándolo. Para obtener más información, vea Deshabilitar índices.
Requisitos de espacio en disco
El espacio en disco necesario para almacenar el índice depende de los siguientes factores:
  • El tamaño de cada fila de datos de la tabla y el número de filas por página. Así se determina el número de páginas de datos que se deben leer del disco para crear el índice.
  • Las columnas del índice y los tipos de datos utilizados. Así se determina el número de páginas de índice que se deben escribir en disco. Para obtener más información, vea Estimar el tamaño de un índice clúster y Estimar el tamaño de un índice no clúster.
  • Espacio temporal en disco necesario durante el proceso de creación del índice. Para obtener más información, vea Determinar requisitos de espacio en disco del índice.
Consideraciones de rendimiento
El tiempo que ocupa la creación física de un índice depende en gran medida del subsistema de disco. Los factores importantes que se deben tener en cuenta son:
  • El modelo de recuperación de la base de datos. El modelo de recuperación optimizado para cargas masivas de registros proporciona un rendimiento mucho mayor y un consumo de espacio de registro más reducido que la recuperación completa durante la operación de creación del índice. Sin embargo, la recuperación por medio de registros de operaciones masivas reduce la flexibilidad para la recuperación a un momento dado. Para obtener más información, vea Elegir un modelo de recuperación para las operaciones de índice.
  • RAID (matriz redundante de discos económicos) utilizada para almacenar los archivos de base de datos y del registro de transacciones. Normalmente, los niveles de RAID que utilizan la creación de bandas tienen un ancho de banda de E/S mejor.
  • Número de discos de la matriz de discos, si se utiliza RAID. Más unidades en la matriz aumentan las tasas de transferencia de datos proporcionalmente.
  • Dónde se almacenan las ordenaciones intermedias de los datos. Si utiliza la opción SORT_IN_TEMPDB puede reducir el tiempo necesario para crear un índice cuando tempdb se encuentra en un conjunto de discos diferente que la base de datos del usuario. Para obtener más información, vea tempdb y la creación de índices.
  • Creación del índice en línea o sin conexión.
    Cuando se crea un índice sin conexión (valor predeterminado), los bloqueos exclusivos se mantienen en la tabla subyacente hasta que la transacción que crea el índice se ha completado. La tabla no está accesible para los usuarios mientras se crea el índice.
    Excepto en el caso de los índices XML y los índices espaciales, es posible especificar que se cree el índice en línea. Cuando la opción en línea está establecida en ON, los bloqueos de la tabla a largo plazo no se conservan, lo que permite que las consultas o actualizaciones a la tabla subyacente continúen mientras se crea el índice. Aunque recomendamos operaciones de índice en línea, se debe evaluar el entorno y los requisitos específicos. Puede ser mejor ejecutar operaciones de índice sin conexión. Al hacerlo así, los usuarios tienen acceso restringido a los datos durante la operación, pero la operación acaba con mayor rapidez y utiliza menos recursos. Para obtener más información, vea Realizar operaciones de índices en línea.
Para crear una restricción PRIMARY KEY o UNIQUE al crear una tabla
  • CREATE TABLE
Para crear una restricción PRIMARY KEY o UNIQUE en una tabla existente
  • ALTER TABLE
Para crear un índice
  • CREATE INDEX
  • CREATE SPATIAL INDEX (Transact-SQL)
  • CREATE XML INDEX (Transact-SQL)
  • Cómo crear un índice espacial (SQL Server Management Studio)


Crear índices con columnas incluidas
 
En SQL Server 2005, un índice no clúster se puede ampliar incluyendo columnas sin clave además de las columnas de clave de índice. Las columnas sin clave se almacenan en el nivel hoja del árbol b del índice.
Los índices que incluyen columnas sin clave resultan especialmente útiles cuando abarcan la consulta. Esto significa que los índices contienen todas las columnas a las que se hace referencia en la consulta. Para obtener más información, vea Índice con columnas incluidas.
Requisitos de espacio en disco
Al agregar columnas sin clave al índice, se utiliza más espacio en disco para almacenar el índice. Concretamente, el hecho de agregar los tipos de datos varchar(max), nvarchar(max), varbinary(max) o xml como columnas sin clave puede aumentar de forma significativa los requisitos de espacio en disco, ya que los valores de las columnas se copian en el nivel hoja del índice y también permanecen en la tabla o el índice clúster.
El proceso para determinar los requisitos de espacio en disco para los índices con columnas incluidas es el mismo que el de los índices no clúster. Para obtener información, vea Determinar requisitos de espacio en disco del índice
Consideraciones de rendimiento
Las mejoras en el rendimiento se consiguen porque el optimizador de consultas puede localizar todos los datos de columnas necesarios del índice sin tener acceso a la tabla ni al índice clúster. No obstante, la presencia de un número excesivo de columnas puede aumentar el tiempo necesario para realizar operaciones de inserción, actualización o eliminación en la tabla subyacente o la vista indizada, ya que aumentará el mantenimiento del índice.
Ejemplos

A. Abarcar una consulta

En el ejemplo siguiente se crea un índice no clúster en la tabla Person.Address con cuatro columnas incluidas. La columna de clave de índice es PostalCode y las columnas sin clave son AddressLine1, AddressLine2, City, y StateProvinceID.
Copiar
USE AdventureWorks2008R2;
GO
CREATE NONCLUSTERED INDEX IX_Address_PostalCode
ON Person.Address (PostalCode)
INCLUDE (AddressLine1, AddressLine2, City, StateProvinceID);
GO
El índice abarcará esta consulta.
Copiar
SELECT AddressLine1, AddressLine2, City, StateProvinceID, PostalCode
FROM Person.Address
WHERE PostalCode BETWEEN '98000' and '99999';
GO

B. Superar el límite de tamaño del índice

En el ejemplo siguiente, la cláusula INCLUDE de la instrucción CREATE INDEX se utiliza para indizar columnas que normalmente superarán el límite de tamaño máximo de 900 bytes de la columna de clave. La tabla Production.ProductReview incluye las columnas ProductID(int), ReviewerName(nvarchar (50)) y Comments (nvarchar (3850)). Estas columnas se utilizan con frecuencia en consultas, pero el tamaño de la columna Comments es demasiado grande para participar como una columna de clave de índice. No obstante, la cláusula INCLUDE permite agregar la columna Comments como una columna sin clave en el índice.
Copiar
USE AdventureWorks2008R2;
GO
CREATE NONCLUSTERED INDEX IX_ProductReview_ProductID_ReviewerName
ON Production.ProductReview (ProductID, ReviewerName)
INCLUDE (Comments);
GO
El índice abarcará esta consulta.
Copiar
SELECT Comments
FROM Production.ProductReview 
WHERE ProductID = 937;
GO

Para crear un índice con columnas incluidas

CREATE INDEX (Transact-SQL).
ORACLE
 
INDICES
El índice es un instrumento que aumenta la velocidad de respuesta de la consulta, mejorando su rendimiento y optimizando su resultado. El manejo de los índices en ORACLE se realiza de forma inteligente, donde el programador sólo crea los índices sin tener que especificar, explícitamente, cuál es el índice que va a usar.
Es el propio sistema, al analizar la condición de la consulta, quien decide qué índice se necesita. Por ejemplo cuando en una consulta se relacionan dos tablas por una columna, si ésta tiene definido un índice se activa, como en el caso cuando relacionamos la tabla de clientes y ventas por la columna código para identificar al cliente (WHERE clientes.codigo=ventas.codigo)
Publicado por en No hay comentarios:
Suscribirse a: Entradas (Atom)