Administración de búfer
El propósito principal de una base de datos de SQL Server es almacenar y recuperar datos, por lo que una E/S de disco intensiva es una de las características principales de Database Engine (Motor de base de datos). Debido a que las operaciones de E/S de disco pueden consumir muchos recursos y tardar bastante tiempo en completarse, SQL Server se centra en hacer la E/S muy eficaz. La administración de búfer es un componente clave para lograr esta eficacia. El componente de administración de búfer consta de dos partes: el administrador de búfer para obtener acceso a las páginas de bases de datos y actualizarlas y la caché del búfer (también conocida como grupo de búferes) para reducir la E/S de archivos de base de datos.
Cómo funciona la administración de búfer
Un búfer es un página de 8 KB en memoria (el mismo tamaño que una página de índice o de datos). Por lo tanto, la caché del búfer está dividida en páginas de 8 KB. El administrador de búfer administra las funciones para la lectura de páginas de índice o de datos de los archivos de disco de base de datos en la caché del búfer y para la escritura de páginas modificadas nuevamente en el disco. Una página permanece en la caché del búfer hasta que el administrador del búfer necesite el área del búfer para leer en ella nuevos datos. Los datos sólo vuelven a escribirse en el disco si se han modificado. Los datos de la caché del búfer se pueden modificar varias veces antes de que se vuelvan a escribir en el disco. Para obtener más información, vea Leer páginas y Escribir páginas.
Cuando SQL Server se inicia, calcula el tamaño del espacio de direcciones virtuales para la caché del búfer basándose en varios parámetros, como la cantidad de memoria física en el sistema, el número máximo configurado de subprocesos de servidor y diferentes parámetros de inicio. SQL Server reserva la cantidad calculada de su espacio de direcciones virtuales del proceso (llamada memoria objetivo) para la caché del búfer, pero sólo adquiere (confirma) la cantidad necesaria de memoria física para la carga actual. Puede realizar una consulta en las columnas bpool_commit_target y bpool_committed en la vista de catálogo sys.dm_os_sys_info para devolver el número de páginas reservadas como memoria objetivo y el número de páginas actualmente confirmadas en la caché del búfer, respectivamente.
El intervalo entre el inicio de SQL Server y el momento en que la caché del búfer obtiene su memoria objetivo se llama arranque. Durante este período, las solicitudes de lectura llenan los búferes según sea necesario. Por ejemplo, una solicitud de lectura de una página llena una única página de búfer. Esto significa que el arranque depende del número y el tipo de solicitudes del cliente. El arranque se agiliza mediante la transformación de solicitudes de lectura de una página en solicitudes de ocho páginas alineadas. Esto permite que el arranque finalice mucho más rápido, especialmente en equipos con mucha memoria.
Debido a que el administrador de búfer utiliza la mayor parte de la memoria en el proceso de SQL Server, coopera con el administrador de memoria para permitir que otros componentes utilicen sus búferes. El administrador de búfer interactúa principalmente con los siguientes componentes:
Administrador de recursos, para controlar la utilización de memoria general y, en plataformas de 32 bits, para controlar el uso del espacio de direcciones.
Administrador de bases de datos y SQL Server Operating System (SQLOS), para operaciones de E/S de archivos de bajo nivel.
Administrador de registros, para registros de escritura anticipada.
Características admitidas
El administrador de búfer admite las características siguientes:
El administrador de búfer está preparado para el acceso no uniforme a memoria (NUMA, Non-Uniform Memory Access). Las páginas de la caché del búfer se distribuyen por los nodos NUMA de hardware, que permiten que un subproceso tenga acceso a una página de búfer que esté asignada en el nodo NUMA local y no desde una memoria externa. Para obtener más información, vea Cómo SQL Server es compatible con NUMA. Para entender cómo se asignan las páginas de memoria desde la caché del búfer cuando se utiliza NUMA, vea Aumentar o reducir el grupo de búferes en NUMA.
El administrador de búfer admite la función de Agregar memoria sin interrupción, que permite a los usuarios agregar memoria física sin reiniciar el servidor. Para obtener más información, vea Agregar memoria sin interrupción.
El administrador de búfer admite la asignación de memoria dinámica en plataformas Microsoft Windows XP de 32 bits y Windows 2003 de 32 bits si AWE está habilitada. La asignación dinámica de memoria permite que Database Engine (Motor de base de datos) adquiera y libere memoria eficazmente en la caché del búfer para admitir la carga de trabajo actual. Para obtener más información, vea Administración dinámica de memoria.
El administrador de búfer admite páginas grandes en plataformas de 64 bits. El tamaño de página es específico de la versión de Windows. Para obtener más información, consulte la documentación de Windows.
El administrador de búfer proporciona diagnósticos adicionales que se muestran mediante vistas de administración dinámica. Puede utilizar estas vistas para supervisar diversos recursos del sistema operativo específicos de SQL Server. Por ejemplo, puede usar la vista sys.dm_os_buffer_descriptors para supervisar las páginas de la caché del búfer. Para obtener más información, vea Vistas de administración dinámica relacionadas con el sistema operativo de SQL Server (Transact-SQL).
E/S de disco
El administrador de búfer sólo realiza tareas de lectura y escritura en la base de datos. Las otras operaciones con archivos, como la apertura, el cierre, la extensión y la reducción, las realizan el administrador de base de datos y los componentes del administrador de archivos.
Las operaciones de E/S de disco que realiza el administrador de búfer tienen las siguientes características:
Todas las operaciones de E/S se realizan de forma asincrónica, lo que permite que el subproceso de llamada siga con el procesamiento mientras la operación de E/S se realiza en segundo plano.
Todas las operaciones de E/S se emiten en los subprocesos de llamada a menos que la opción de afinidad de E/S esté en uso. La opción de máscara de afinidad de E/S enlaza la E/S del disco de SQL Server a un subconjunto específico de unidades CPU. En entornos de procesamiento de transacciones en línea (OLTP) de SQL Server de grandes prestaciones, esta extensión puede mejorar el rendimiento de los subprocesos de SQL Server que emiten E/S.
Las operaciones de E/S de múltiples páginas se logran con E/S por dispersión y recopilación, que permite transferir datos a áreas no contiguas de memoria, o desde ellas. Esto significa que SQL Server puede llenar o vaciar rápidamente la caché del búfer y, a la vez, evitar múltiples solicitudes de E/S física.
Solicitudes de E/S largas
El administrador de búfer informa sobre cualquier solicitud de E/S que haya quedado pendiente durante al menos 15 segundos. Esto ayuda al administrador del sistema a distinguir entre problemas de SQL Server y problemas del subsistema de E/S. El mensaje de error 833 se notifica y aparece en el registro de errores de SQL Server de la siguiente forma:
SQL Server ha detectado %d instancias de peticiones de E/S que están tardando más de %d segundos en completarse en el archivo [%ls] de la base de datos [%ls] (%d). El identificador de archivo del SO es 0x%p. El desplazamiento de la operación de E/S más reciente y más larga es: %#016I64x.
Una E/S larga puede ser de lectura o de escritura, pero esto no se indica actualmente en el mensaje. Los mensajes de E/S larga son advertencias, no errores. No indican problemas con SQL Server. Los mensajes se notifican para ayudar a los administradores del sistema a encontrar la causa de los tiempos de respuesta largos de SQL Server con mayor rapidez y a distinguir problemas que estén fuera del control de SQL Server. Por eso, no es necesario tomar ninguna acción, pero el administrador del sistema debe investigar por qué la solicitud de E/S tardó tanto tiempo y si ese tiempo es justificable.
Causas de solicitudes de E/S largas
Un mensaje de E/S larga puede indicar que una E/S está permanente bloqueada y que nunca se completará (también llamada E/S perdida), o que simplemente no se completó aún. No es posible saber con los datos del mensaje de qué caso se trata, aunque una E/S perdida casi siempre llevará a un tiempo de espera de bloqueo temporal.
Las E/S largas suelen indicar una carga de trabajo de SQL Server demasiado intensa para el subsistema de disco. Se puede indicar un subsistema de disco inadecuado cuando:
Aparecen múltiples mensajes de E/S largas en el registro de errores durante una carga de trabajo pesada de SQL Server.
Los contadores de rendimiento muestran latencias de disco prolongadas, colas de disco largas o no muestran el tiempo de inactividad de disco.
Otra posible causa de las E/S largas es que un componente de la ruta de acceso de E/S (por ejemplo, un controlador o el firmware) posponga de forma continua el servicio para una solicitud de E/S antigua en favor de dar servicio a solicitudes nuevas que están más cerca de la posición actual del cabezal del disco. La técnica corriente de procesar solicitudes según su prioridad sobre la base de las que están más cerca de la posición actual del cabezal de lectura/escritura se conoce como "búsqueda de elevador". Esto puede resultar difícil de corroborar con la herramienta Monitor del sistema de Windows (PERFMON.EXE) porque a la mayor parte de las E/S se las da servicio inmediatamente. Las solicitudes de E/S largas pueden agravarse con cargas de trabajo que realicen un gran número de operaciones de E/S secuenciales, como copias de seguridad y restauración, recorridos de tablas, ordenaciones, creación de índices, cargas masivas y puestas a cero de archivos.
Las E/S largas aisladas que no están relacionadas con ninguna de las situaciones anteriores pueden estar causadas por un problema con el hardware o el controlador. El registro de eventos del sistema puede contener un evento relacionado que ayude a diagnosticar el problema.
Detección de errores
Las páginas de bases de datos pueden utilizar uno de los dos mecanismos opcionales que ayudan a garantizar la integridad de la página desde el momento en que se escribe en el disco hasta que se vuelve a leer: protección contra página rasgada y protección de suma de comprobación. Estos mecanismos permiten emplear un método independiente para verificar la corrección, no sólo del almacenamiento de datos, sino también de los componentes de hardware, como controladores, cables e incluso el sistema operativo. La protección se agrega a la página justo antes de escribirla en el disco y se comprueba después de que se lee desde el disco.
Protección contra página rasgada
La protección contra página rasgada, característica implementada en SQL Server 2000, es básicamente una forma de detectar errores en las páginas a causa de problemas con el suministro eléctrico. Por ejemplo, es posible que por un problema con el suministro eléctrico sólo se escriba una parte de la página en el disco. Cuando se utiliza la protección contra página rasgada, se coloca una firma de 2 bits al final de cada segmento de 512 bytes en la página (después de haber copiado los dos bits originales en el encabezado de la página). La firma alterna entre 01 y 10 binarios con cada escritura, por lo que siempre es posible saber cuándo sólo una parte de los sectores se escribieron en el disco: si hay un bit con el estado incorrecto cuando la página se lee posteriormente, la página se escribió de forma incorrecta y se detecta una página rasgada. La detección de página rasgada utiliza un mínimo de recursos; sin embargo, no detecta todos los errores causados por fallos del hardware del disco.
Protección de suma de comprobación
La protección de suma de comprobación, característica implementada en SQL Server 2005, proporciona una comprobación de integridad de datos más sólida. Se calcula una suma de comprobación para los datos de cada página que se escribe y se almacena en el encabezado de la página. Cada vez que se lee desde disco una página con una suma de comprobación almacenada, el motor de base de datos vuelve a calcular la suma de comprobación para los datos de la página y muestra el error 824 cuando la nueva suma de comprobación no coincide con la suma almacenada. La protección de suma de comprobación puede detectar más errores que la protección contra página rasgada porque tiene en cuenta cada byte de la página; sin embargo, consume una cantidad de recursos considerable. Cuando la suma de comprobación está habilitada, los errores que cause cualquier problema con el suministro eléctrico y cualquier problema de hardware o firmware pueden detectarse cada vez que el administrador de búfer lea una página del disco.
El tipo de protección de página que se utilice es un atributo de la base de datos que contiene la página. La protección de suma de comprobación es la protección predeterminada para bases de datos creadas en SQL Server 2005 y en versiones posteriores. El mecanismo de protección de páginas se especifica al crear la base de datos y se puede modificar con ALTER DATABASE. La configuración de protección de página actual se puede determinar consultando la columna page_verify_option de la vista de catálogo sys.databases o la propiedad IsTornPageDetectionEnabled de la función DATABASEPROPERTYEX. Si se modifica la configuración de protección de página, la nueva configuración no afecta a toda la base de datos de forma inmediata. En cambio, las páginas adoptan el nivel de protección actual de la base de datos cuando se vuelven a escribir. Esto significa que la base de datos puede estar compuesta de páginas con distintos tipos de protección.