Factores claves a tener en cuenta al evaluar los sistemas de la caché de archivo de terceros con SQL Server

Seleccione idioma Seleccione idioma
Id. de artículo: 917043 - Ver los productos a los que se aplica este artículo
Expandir todo | Contraer todo

En esta página

Resumen

Este artículo describen algunos de los factores clave clientes deben tener al evaluar un archivo de terceros almacenamiento en caché del sistema.

Las implementaciones de caché de archivo de terceros pueden aumentar el rendimiento de bases de datos de Microsoft SQL Server cuando se implementa correctamente. Las configuraciones de estos productos y las implementaciones específicas, sin embargo, pueden dejar las bases de datos SQL Server un alto riesgo de pérdida de datos. Los clientes deben probar completamente la configuración para garantizar la integridad datos adecuados.

La información contenida en este documento, incluidas las direcciones URL y otras referencias a sitios de Internet, está sujeta a cambios sin previo aviso. A menos que se indique lo contrario, compañías, organizaciones, productos, nombres de dominio, direcciones de correo electrónico, logotipos, personas, lugares y acontecimientos mencionados son ficticios. No tienen asociación alguna con ninguna compañía real, se pretende ni debe deducirse. El cumplimiento de todas las leyes de copyright aplicables es responsabilidad del usuario. Sin limitar los derechos protegidos bajo copyright, ninguna parte de este documento se puede reproducir, almacenada en o introducida en un sistema de recuperación o transmitir de ninguna forma ni por ningún medio (electrónico, mecánico, photocopying, grabación o en caso contrario) con ningún propósito, sin el permiso expreso de Microsoft Corporation.

Microsoft puede tener patentes, aplicaciones de patentes, marcas, derechos de autor y otros derechos de propiedad intelectual sobre los contenidos de este documento. Excepto en lo dispuesto expresamente en cualquier contrato de licencia escrito de Microsoft, el suministro de este documento no le otorga ninguna licencia sobre estas patentes, marcas, derechos de autor y otros derechos de propiedad intelectual.

© 2006 Microsoft Corporation. Todos los derechos reservados.

Microsoft, Windows, Windows Server y SQL Server son marcas registradas o marcas comerciales de Microsoft Corporation en Estados Unidos y/o en otros países.

En este artículo está escrito específicamente para SQL Server, pero generalmente se aplica a las bases de datos de Jet utilizados también productos Active Directory y Exchange Server.

Más información

Esta sección describe los requisitos y proporciona ejemplos detallados que se discutirá completamente con un proveedor de terceros antes de implementar cualquier solución. Los clientes también deben tener especial cuidado para probar varios escenarios de recuperación para asegurarse de integridad de los datos se mantiene correctamente.

Requisitos de entrada/salida (E/s) de SQL Server

Cualquier archivo de copia de seguridad de base de datos o de SQL Server requiere los fundamentos de almacenamiento compatible con el protocolo de escritura anticipada registro (WAL). Estos fundamentos se describen en los siguientes artículos:
Conceptos básicos de E/s de SQL Server 2000
http://technet.microsoft.com/en-us/library/cc966500.aspx
Nota El artículo también se aplica a SQL Server 2005.
230785Algoritmos de almacenamiento de datos y registro de SQL Server 7.0, SQL Server 2000 y SQL Server 2005 amplían la confiabilidad de los datos
Ésta es una lista de algunos requisitos importantes:
  • Debe mantenerse el orden de escritura.
  • Debe mantenerse la coherencia de escritura dependientes.
  • Escribe siempre debe protegerse en o en medios estables.
  • Debe aparecer la prevención de E/s incompletas.

Certificaciones de producto de socio no son una garantía de compatibilidad o seguridad

Un producto de terceros o un proveedor determinado, puede recibir una certificación del logotipo de Microsoft. Sin embargo, certificación de socio o un logotipo de Microsoft específico no certificar compatibilidad o idoneidad para un fin determinado para SQL Server, Exchange Server o Active Directory.

FILE_FLAG_WRITETHROUGH y FILE_FLAG_NO_BUFFERING

Productos de la base de datos de Microsoft específicamente utilizar la escritura a través y sin indicadores de almacenamiento en búfer al abrir archivos de base de datos para evitar la pérdida de datos. Cualquier solicitud de escritura a estos archivos debe estar protegido a los medios estables. En caso contrario, puede perder datos. Enumerados son ejemplos específicos que pueden exponer las cachés de sistema de archivo:
  • escribir combinar y reordenación de escritura
    Para reducir solicitudes de E/s físicas, las cachés de batería no basado en a menudo combinan y reordenar las operaciones de escritura, interrumpir inmediatamente los requisitos de protocolo WAL.
  • tamaño de bloque de E/s
    Similar a la escritura combinar y reordenación son el tamaño del bloque E/s. Las cachés intentará completar E/s según el tamaño de bloque de ruta de acceso de E/s. De nuevo, esto puede proporcionar una mejora del rendimiento pero abre la base de datos a los daños y interrumpe inmediatamente los requisitos de protocolo WAL.

Puntos de charla y ejemplos

La sección siguiente proporciona ejemplos de claves y charla puntos relativas a la integridad de los datos y seguridad. Utiliza eléctrico como un punto común de error y claridad, pero a menudo se pueden sustituir con varios otros problemas que conduce a problemas de integridad de base de datos similar.

Ejemplo 1: Pérdida de datos y daños físicos o lógicos

Tenga en cuenta la situación siguiente:
  1. Un registro está escrito para la página 100 en la base de datos.
  2. Un registro se mantiene en caché no basados en la batería, pero el motor de base de datos se indicará que la escritura de registro es completa "segura para estable medios".
  3. El motor de base de datos se considera el LSN reforzado y problemas de escritura para la página 100.
  4. 100 De la página también se almacena en caché en función de batería no.
  5. Confirmar transacción finaliza sin errores.
El motor de base de datos continúa el procesamiento como si compromete correctamente las escrituras a medios estables. Un corte del suministro eléctrico en este momento, sin embargo, dará como resultado la pérdida de datos inmediatos porque los cambios existían nunca físicamente fuera de la caché de seguridad de batería no. Recuperación de errores no indica un error porque no conoce el registro pierde recuperación tras bloqueo y no intentar rehacer el trabajo. Ampliar los distintos tipos de daños de la base de datos que pueden producirse varios escenarios de modificación de objeto (clave principal p. ej., inserciones de claves externas).

Hay varios otros problemas que pueden surgir con pequeñas modificaciones a cómo la caché controla las operaciones de E/s. Una derivación breve supone que deshace la transacción fue, pero medios página 100 hecho a física. Recuperación tras bloqueo nuevo no conoce el registro (nunca realizado que estable medios), así se 100 de página no recibir las operaciones de deshacer durante la recuperación de errores, dejando la base de datos lógica y físicamente posiblemente dañado.

Ejemplo 2: Base de datos sospecha

Algunos proveedores permiten "opt de archivos" y a menudo se recomienda dejar el archivo de base de datos de registro (.ldf para SQL Server) optado por de la memoria caché. La directiva "opt" es tal que el administrador tiene específicamente marcar los archivos pasará por el software de almacenamiento en caché. En caso contrario, se incluye automáticamente el archivo.

Esto es una mala suposición, como resaltar los siguientes ejemplos. Microsoft recomienda que todos los de base de datos y archivos de copia de seguridad se optó por fuera de tal una caché.
  1. El archivo de registro es optado por fuera, por lo que escribe reciben a medios estables.
  2. 100 De la página se modifica.
  3. El motor de base de datos ejecuta una operación punto de control.
  4. El motor se le indica todas las páginas base de datos y registros son seguros (momento up to punto de control considera reforzado). Sin embargo, las páginas de datos no son todos almacenan en o en medios estables.
  5. La base de datos SQL Server está en modo de recuperación "SIMPLE" para que punto de control ahora trunca los registros.
  6. 100 De página que se ha señalado de verificación sólo se modifica de nuevo.
Esta situación ha expuesto a la base de datos a la pérdida de datos y suele en una base de datos sospechosa. De nuevo, si un corte del suministro eléctrico tiene lugar, recuperación de errores no tiene registro registros porque ya no existen debido al truncamiento. El motor de base de datos no tiene ninguna información que indica que las páginas de la base de datos faltan datos que deben proteger durante la punto de control. Recuperación tras bloqueo intenta analizar la segunda modificación en la página 100 pero falla porque página 100 no se correctamente segura a los medios estables en el momento del punto de control.

Recuperación de errores, utiliza el valor LSN almacenado en el encabezado de página para determinar las necesidades de recuperación.
  • Si el LSN de la página es igual o posterior el registro, recuperación no ningún trabajo adicional en la página porque la página ya es coherente con el registro basado en LSN comparación.
  • Si el LSN de la página es mayor que el registro, recuperación debe realizar las operaciones adecuadas para devolver la página al estado correcto. Recuperación falla si recuperación se hayan descubierto una condición de falta de datos y correctamente no puede devolver la página a su estado correcto.
En el ejemplo, el LSN anterior almacenado en el registro de la segunda modificación de la página 100 no existe en el encabezado de página, y no hay ningún registro anterior registro presente para rehacer la página. Por lo tanto, la base de datos se marca como sospechosa, como recuperación segura no puede continuar.

Ejemplo 3: Copias de seguridad no son válidos - cadena de copia de seguridad silenciosa salto

Ejemplo 2 es sólo una fracción de estos tipos de problemas que podrían estar experimentados. En este ejemplo, en lugar de modo de recuperación "SIMPLE", permítanos colocar la base de datos en modo "FULL RECOVERY" pero realizar copias de seguridad regulares del registro y la base de datos. En primer lugar, parece que esto sería mejor ya que tiene una cadena de registro intacto y sólo puede ejecutar una secuencia de restauración para corregir el problema.

No puede ser una suposición válida, como algunas implementaciones de caché de utilizan la directiva "opt out" para que el archivo de copia de seguridad o partes de ella se pueden almacenar en inesperadamente caché. Cuando SQL Server vacía el archivo de copia de seguridad, SQL Server requiere que todas las escrituras en el medio de copia de seguridad se almacenan correctamente en o en medios estables mediante la función API de Win32 FlushFileBuffers . Por lo tanto, si el proveedor de caché no garantiza la todas las escrituras se vacían correctamente durante la llamada de función FlushFileBuffers a estable medios antes de la operación correctamente finalice, la base de datos de motor puede truncar el registro sin una copia de seguridad protegida. De nuevo, un corte de alimentación resultado en este momento una condición donde faltan los registros adecuados y pueden provocar la recuperación tras bloqueo un error. Lo más importante es que la recuperación de bloqueo no podrá detectar esto debido de registros de registro que faltan de la base de datos y la cadena de copia de seguridad podría estar dañada silenciosamente. Sólo cuando se intenta realizar una restauración de la copia de seguridad el motor de base de datos podrán indicar que se ha dañado la copia de seguridad.

Ejemplo 4: Estados de base de datos no válido

Archivos de base de datos contienen las dependencias entre sí requerir estricta escritura a través y orden cumplimiento para aplicar a todos ellos como grupo. Punto de control, cambia de tamaño de archivo, las copias de seguridad diferenciales, operaciones no registradas y el modelo de recuperación MASIVAS son entre algunas de las actividades de base de datos clave que requieren escritura en archivos de datos, realizar las directivas como optando sólo el archivo de registro una suposición no válida.

Ejemplo 5: Pérdida de datos base de datos de instantáneas: puede ser silenciosa

SQL Server 2005 introduce bases de datos instantánea para punto en las consultas de tiempo. Utiliza tecnología de base de datos de copia por escritura para ayudar a proteger una copia de una página de datos en la base de datos de instantánea antes de realiza una modificación nueva a la página de datos en la base de datos base. Este proceso requiere que la página se proteja en la base de datos instantánea pueda continuar la transacción. Si no está protegida la página en medio estable o, se conservarán los problemas de integridad de datos. La base de datos instantánea no contiene un registro de transacciones, por tanto, la escritura de la página es importante. Si se produjo algo parecido a un corte del suministro eléctrico, es posible que la página principal de la base de datos ha cambiado, pero la instantánea no refleja la imagen anterior porque se ha perdido la escritura en caché.

Cómo configurar

Cómo configurar un producto proporciona caché de archivos de algo como caché de seguridad de batería no es específico de la implementación de proveedor. Unas reglas, sin embargo, pueden aplicarse:
  • Deben completarse todas las escrituras en o en medios estables antes de la caché indica al sistema operativo que ha terminado la E/s.
  • Pueden ser almacenar en caché datos siempre que una solicitud de lectura atendida desde la caché devuelve la misma imagen como ubicados en o en medios estables.
Estas reglas básicamente significan que la caché de seguridad de batería no puede ser eficaz para las operaciones de lectura pero no debe utilizarse para las solicitudes de escritura. Con la configuración adecuada, esto puede proporcionar una mejora del rendimiento para el motor de base de datos. Esto debe, sin embargo, puede probar con cuidado, porque establecer aparte algo como RAM que podría utilizarse por SQL Server puede degradar el rendimiento general. SQL Server puede utilizar la memoria adicional con más precisión que un mecanismo de caché genérico.

Bases de datos de sólo lectura

Bases de datos de sólo lectura pueden ser un buen ejemplo donde excel estos tipos de productos. Si la base de datos se creó primero y se almacena en o en medios estables para garantizar la integridad de datos, la instrucción ALTER DATABASE utilizado para marcar la base de datos READ ONLY y la base de datos asignada posteriormente al mecanismo de almacenamiento en caché, mejoras de rendimiento pueden producirse. Algunas implementaciones tenga comprimidas imágenes de las páginas de base de datos en la caché, que permite que se recuperan de la caché de datos físicos más y reducir la E/s física.

Precaución La base de datos nunca debe realizarse lectura escritura cuando asigna a una caché que no mantener el protocolo WAL.

Seguridad

Introducción a una caché, como por ejemplo la caché de sistema de archivos basada en RAM, presenta otra ubicación de "en memoria" para datos. Productos como un motor de base de datos pueden suponer datos críticos se ha almacenado en o en medios estables y conservan correctamente las protecciones de lista (ACL) de control de acceso. La caché de RAM podría exponer los datos a un conjunto de problemas de seguridad que son únicos en comparación con medios estables. Por ejemplo, si la aplicación está diseñada para utilizar algo parecido a la función SecureZeroMemory cada vez que ha finalizado con información crítica, la aplicación tiene una expectativa de que los datos ya no existen en la RAM. Sin embargo, si un formulario de los datos puede permanecer en caché cuando la aplicación espera que sea en o en medios estables, podría modificar las consideraciones de seguridad.

Comprobaciones de integridad de datos

Microsoft siempre recomienda una estrategia de integridad de datos fuerte y claro. Esto debe incluir, pero no se limita a restaurar copias de seguridad y operaciones de DBCC CHECKDB normales en la producción y la base de datos restaurada.

Microsoft también recomienda aumentar la frecuencia de estas pruebas de seguridad al evaluar e implementar los cambios del entorno o si los problemas surgen relativas a la estabilidad del entorno.

Para obtener más información sobre cómo utilizar el SQLIOStress utilidad, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
231619Cómo utilizar la utilidad SQLIOStress para resaltar un subsistema de disco, como SQL Server

La base de datos TEMPDB

Es posible buscar la base de datos TEMPDB en ciertos sistemas de almacenamiento en caché. Varios factores deben ser cuidadosamente considera y probados al evaluar la ubicación de almacenamiento de la base de datos TEMPDB en esta configuración. El siguiente artículo de Microsoft Knowledge Base describe los requisitos, límites de compatibilidad asociado y el rendimiento posible de E/s.
917047Requisitos del subsistema de E/s de Microsoft SQL Server para la base de datos TEMPDB

Soporte técnico

Soporte técnico de Microsoft SQL Server ayudará a los clientes, mediante técnicas de recuperación de datos estándar. Si los productos instalados en el equipo dibujar integridad de datos en la pregunta, Microsoft SQL Server, Active Directory y soporte técnico de Exchange puede pedirle que se desinstalará el producto y no se participar en análisis de causas raíz hasta tal vez se puede reproducir el problema sin dicho producto.

Microsoft no certifica ni validar que los productos de otros fabricantes funcionen correctamente con SQL Server. Además, Microsoft no proporciona ninguna garantía, garantía o instrucción de idoneidad de cualquier producto terceros para su uso con SQL Server.

Referencias

Considere detenidamente la información adicional proporcionada por las siguientes referencias para evaluar la mejora del rendimiento de SQL Server:

826433SQL Server agregados diagnósticos adicionales para detectar problemas de E/s no notificados
828339Mensaje de error 823 puede indicar problemas de hardware o problemas del sistema en SQL Server
234656Using Disk Drive Caching with SQL Server ("Utilización del almacenamiento en caché en las unidades de disco con SQL Server", este artículo está en inglés)
110352Optimizar el rendimiento de Microsoft SQL Server
304261Descripción de la compatibilidad con archivos de base de datos de red en SQL Server
910716Compatibilidad con soluciones de reflejo remoto de terceros utilizado con SQL Server 2000 y las bases de datos de usuario de 2005
913945Microsoft no certificar que los productos de otros fabricantes funcionarán con Microsoft SQL Server
SQL Server requiere los sistemas admiten ? garantiza la entrega a medios estables ? como se describe en el programa de revisión de solución de almacenamiento de Microsoft SQL Server Always-On. FOPara obtener más información sobre los requisitos de entrada y salidos para el motor de base de datos de SQL Server, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
967576Microsoft SQL Server Database Engine E/s requisitos

Propiedades

Id. de artículo: 917043 - Última revisión: viernes, 2 de noviembre de 2007 - Versión: 1.5
La información de este artículo se refiere a:
  • Microsoft SQL Server 7.0 Standard Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 2000 Enterprise Edition
  • Microsoft SQL Server 2000 Developer Edition
  • Microsoft SQL Server 2000 Workgroup Edition
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2000 Personal Edition
  • Microsoft SQL Server 2008 Developer
  • Microsoft SQL Server 2008 Enterprise
  • Microsoft SQL Server 2008 Express
  • Microsoft SQL Server 2008 Standard
Palabras clave: 
kbmt kbexpertiseadvanced kbinfo KB917043 KbMtes
Traducción automática
IMPORTANTE: Este artículo ha sido traducido por un software de traducción automática de Microsoft (http://support.microsoft.com/gp/mtdetails) en lugar de un traductor humano. Microsoft le ofrece artículos traducidos por un traductor humano y artículos traducidos automáticamente para que tenga acceso en su propio idioma a todos los artículos de nuestra base de conocimientos (Knowledge Base). Sin embargo, los artículos traducidos automáticamente pueden contener errores en el vocabulario, la sintaxis o la gramática, como los que un extranjero podría cometer al hablar el idioma. Microsoft no se hace responsable de cualquier imprecisión, error o daño ocasionado por una mala traducción del contenido o como consecuencia de su utilización por nuestros clientes. Microsoft suele actualizar el software de traducción frecuentemente.
Haga clic aquí para ver el artículo original (en inglés): 917043

Enviar comentarios

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com