Consejos para disminuir los niveles de contensión y aumentar la concurrencia

Este documento proporciona algunas recomendaciones prácticas que pueden ayudar a disminuir los niveles de contención (bloqueo) en Adaptive Server Enterprise (ASE). Se dan dos enfoques al problema de la contención: desde el punto de vista del diseño físico de bases de datos y desde el punto de vista de las operaciones SQL.

1. Considere cambiar índices clustered por índices nonclustered.

Los índices nonclustered generan menos contención (bloqueos) para operaciones masivas y concurrentes de modificación (insert/delete/update), mejorando así el rendimiento de las aplicaciones. Así mismo, se reduce el riesgo de deadlocks.

Es importante tener en cuenta que los índices nonclustered ocupan más espacio que los clustered y pueden ser algo menos eficientes para ciertas operaciones de lectura (select).

2. Considere disminuir el número de filas por página de datos.

Las tablas densas (muchas filas por página), que sean muy utilizadas, tienden a generar altos niveles de contención, e incluso deadlocks.

Utilizando la cláusula with max_rows_per_page = x del comando create table es posible disminuir el número de filas por página, haciendo que la tabla sea menos densa, lo que eventualmente reduce la contención sobre las páginas de datos y aumenta los niveles de concurrencia.

Es importante resaltar que ASE mantiene constante el valor de max_rows_per_page, a pesar de que la tabla sea modificada.

3. Considere utilizar bloqueo a nivel de fila

Versiones anteriores a la 11.9.2

Utilizando un valor de 1 para la opción max_rows_per_page es posible "simular" un bloqueo a nivel de fila en versiones de ASE anteriores a la 11.9.2, aún cuando éste no es un "verdadero" bloqueo a nivel de fila. Es factible utilizar este procedimiento si:

• Usted no quiere que la aplicación se bloquee debido a la contención de páginas
• Usted experiencia contención de bloqueos
• Usted actualmente tiene más de una fila por página

• Usted se puede dar el lujo de aumentar el espacio de almacenamiento en disco - tenga en cuenta que entre menos filas por página, más espacio ocuparía la tabla en disco.

ASE 11.9.2 en adelante

A partir de ASE 11.9.2 se manejan tres tipos de bloqueos de datos:

• Allpage Locking - Es el esquema tradicional de páginas de datos que siempre ha utilizado ASE, en el cual se bloquean páginas de datos y páginas de índices.
• Datapage Locking - Es el esquema de bloqueo en el que se generan bloqueos de página para los datos, mientras que las páginas de índices permanecen libres de bloqueos. Este nivel de bloqueo proporciona un nivel medio de contención.
• Datarow Locking - Es el esquema de bloqueo conocido como "bloqueo a nivel de fila", en el cual no se bloquean páginas de datos (que pueden contener varias filas), sino filas individuales de datos. Este nivel de bloqueo proporciona el nivel más bajo de contención.

Para mayor información sobre los nuevos niveles de bloqueo introducidos en ASE 11.9.2, vea el documento "Notas Sobre Bloqueo a Nivel de Fila En Adaptive Server Enterprise 11.9.2" (documento número 10025).

4. Considere utilizar el particionamiento de tablas.

Las tablas donde se realicen operaciones masivas y concurrentes de insert son candidatas número 1 a ser particionadas utilizando el comando alter table ... partition x. Esto disminuye la contención sobre las páginas de datos de la tabla, aumentando los niveles de concurrencia.

Recuerde que en ASE 11.0.x NO es posible crear índices de tipo clustered sobre tablas particionadas. A partir de ASE 11.5 no existe esta restricción.

5. Haga uso adecuado de los cursores.

El cursor es un mecanismo utilizado para procesar, una a una, un conjunto de filas asociadas a un comando select. Sin embargo, la utilización inadecuada de los cursores puede causar niveles muy elevados de contención y en consecuencia poca concurrencia.

Para mayor información sobre uso de cursores en ASE, consulte el documento "Cursores: Recomendaciones sobre Rendimiento y Uso" (documento número 10034).

6. Considere la reorganización de los datos para minimizar la fragmentación.

Todos los sistemas de almacenamiento de datos (sistemas operativos, bases de datos, etc.) sufren de un fenómeno conocido como fragmentación. Este fenómeno causa que existan muchas áreas pequeñas no contiguas de datos que pertenecen a un mismo elemento de información (un archivo en un sistema operativo, una tabla en una base de datos, etc.), haciendo que dicho elemento no pueda ser utilizado de forma eficiente.

La fragmentación de datos en ASE ocurre cuando las tablas son modificadas constantemente, agregando nueva información y/o borrando información existente.

Aun cuando la fragmentación de datos en ASE no tiene que ver directamente con los niveles de concurrencia, el hecho de contar con datos contiguos permite a ASE hacer un uso más eficiente del objeto (tabla, índice), mejorando los tiempos de acceso a los datos y en consecuencia reduciendo el tiempo durante el cual se mantienen los bloqueos.

En general, la técnica de reorganización que se utiliza en ASE incluye los siguientes pasos:

Esto permite que los datos vuelvan a un estado mínimo de fragmentación.

ASE 11.9.2 introduce el comando Transact-SQL reorg, el cual reorganiza el uso de espacio de tablas creadas con esquemas de bloqueo datapage y datarow.

Operacione SQL

1. Evite los bloqueos a nivel de tabla. Esto tiene un efecto adverso sobre grandes volúmenes de información.
2. ¡Mantenga las transacciones SQL tan cortas como le sea posible! El mantener bloqueos por largos períodos de tiempo previene que otros usuarios completen sus transacciones.
3. ¡Evite el uso de holdlock cuando le sea posible! Esto hace que los bloqueos se mantengar por períodos más largos de tiempo. La única excepción ocurre en situaciones donde se requiere de consistencia de operaciones de lectura dentro de una transacción.
4. Mantenga todas las sentencias SQL de una transacción dentro de pocos paquetes de red como le sea posible, de tal manera que el rendimiento y los problemas de su red no afecten la duración de los bloqueos.
5. Evite por completo la interacción de usuario dentro de una transacción, de tal manera que la duración de los bloqueos no se encuentre bajo el control humano.
6. Para un mejor rendimiento en bases de datos sometidas a frecuentes operaciones de update, considere diseñar la base de datos para que ocurran operaciones de "actualización en sitio" (update in place). La siguientes condiciones se deben cumplir:
   1. La tabla no puede tener triggers de update.
   2. Las columnas que se actualicen no pueden ser de longitud variable ni aceptar valores nulos.
   3. Las columnas que se actualicen no pueden formar parte del índice utilizado en el plan de ejecución del optimizador.
   4. El update solamente puede afectar una fila a la vez y esta debe poder ser determinada por el optimizador en el plan de consulta (por ejemplo, utilice un argumento de búsqueda que corresponda al índice único).