Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Se aplica a:
SQL ServerAzure SQL DatabaseAzure SQL Managed Instance
Las tablas optimizadas para memoria se crean mediante CREATE TABLE (Transact-SQL).
De forma predeterminada, las tablas optimizadas para memoria son totalmente durables y, al igual que las transacciones en tablas basadas en disco (tradicionales), las transacciones en este tipo de tablas tienen todas las propiedades ACID (atomicidad, coherencia, aislamiento y durabilidad). Las tablas optimizadas para memoria y los procedimientos almacenados compilados de forma nativa admiten solo un subconjunto de características de Transact-SQL.
A partir de SQL Server 2016, y en Azure SQL Database, no existen limitaciones para intercalaciones o páginas de códigos que son específicas de OLTP en memoria.
El almacenamiento principal para las tablas optimizadas para memoria es la memoria principal. Las filas de la tabla se leen y se escriben en la memoria. Una segunda copia de los datos de la tabla se conserva en el disco pero solo por la durabilidad. Vea Crear y administrar el almacenamiento de objetos con optimización para memoria para obtener más información sobre las tablas durables. Los datos de las tablas optimizadas para memoria solo se leen desde el disco durante la recuperación de la base de datos (por ejemplo, después de reiniciar el servidor).
Para obtener mejoras de rendimiento aún mayores, OLTP en memoria admite tablas duraderas con durabilidad de transacción diferida. Las transacciones duraderas retrasadas se guardan en el disco poco después de que se confirma la transacción y el control se devuelve al cliente. A cambio de un mayor rendimiento, las transacciones confirmadas que no se escriben en disco se pierden si el servidor se cae o se produce una conmutación por error.
Además de las tablas optimizadas para memoria duradera predeterminadas, SQL Server también admite tablas optimizadas para memoria no duradera, que no se registran y sus datos no se conservan en el disco. Esto significa que las transacciones en estas tablas no requieren ninguna E/S de disco, pero los datos se pierden si hay un bloqueo del servidor o una conmutación por error.
OLTP en memoria está integrado con SQL Server para proporcionar una experiencia satisfactoria en todas las áreas como el desarrollo, la implementación, la facilidad de uso y la compatibilidad. Una base de datos puede contener objetos en memoria y objetos basados en disco.
Las filas de las tablas optimizadas para memoria tienen versiones. Esto significa que cada fila de la tabla puede tener varias versiones. Todas las versiones de fila se mantienen en la misma estructura de datos de la tabla. El versionado de filas se utiliza para permitir lecturas y escrituras simultáneas en la misma fila. Para obtener más información sobre las lecturas y las escrituras simultáneas en la misma fila, vea Transactions with Memory-Optimized Tables(Transacciones con tablas con optimización para memoria).
La siguiente ilustración muestra la multiversión. La ilustración muestra una tabla con tres filas y cada fila tiene versiones diferentes.
La tabla tiene tres filas: r1, r2 y r3. r1 tiene tres versiones, r2 tiene dos versiones y r3 tiene cuatro. Las diferentes versiones de la misma fila no ocupan necesariamente ubicaciones de memoria consecutivas. Las diferentes versiones de fila pueden estar dispersas por la estructura de datos de la tabla.
La estructura de datos de una tabla optimizada para memoria se puede considerar como una colección de versiones de fila. Las filas de las tablas basadas en disco están organizadas en páginas y extensiones de página, y las filas individuales se identifican mediante el número de página y el desplazamiento dentro de la página, mientras que las versiones de fila de las tablas optimizadas para la memoria se identifican mediante punteros de memoria de 8 bytes.
Se puede tener acceso a los datos de las tablas optimizadas para memoria de dos maneras:
A través de procedimientos almacenados compilados de forma nativa.
Mediante Transact-SQL interpretado, fuera de un procedimiento almacenado compilado de forma nativa. Estas instrucciones de Transact-SQL pueden ser procedimientos almacenados interpretados internamente o pueden ser instrucciones de Transact-SQL ad hoc.
Acceso a datos en tablas con optimización para memoria
Se puede tener acceso a las tablas con optimización para memoria de forma más eficaz desde procedimientos almacenados compilados de forma nativa (Procedimientos almacenados compilados de forma nativa). Se puede tener acceso también a las tablas con optimización para memoria con Transact-SQL interpretado (tradicional). Transact-SQL interpretado hace referencia al acceso a tablas optimizadas para memoria sin un procedimiento almacenado compilado de forma nativa. Algunos ejemplos de acceso interpretado mediante Transact-SQL incluyen el acceso a una tabla optimizada para memoria desde un desencadenador DML, un lote ad hoc de Transact-SQL, una vista y una función de valores de tabla.
En la tabla siguiente se resume el acceso nativo e interpretado mediante Transact-SQL para varios objetos.
| Característica | Acceso con un procedimiento almacenado compilado de forma nativa | Acceso interpretado a Transact-SQL | Acceso a CLR |
|---|---|---|---|
| Tabla con optimización para memoria | Sí | Sí | Nº1 |
| Tipo de tabla con optimización para memoria | Sí | Sí | No |
| Procedimiento almacenado compilado de forma nativa | Ahora se admite el anidamiento de procedimientos almacenados compilados de forma nativa. Puede usar la sintaxis EXECUTE dentro de los procedimientos almacenados, siempre que el procedimiento de referencia también se compile de forma nativa. | Sí | No* |
1No se puede tener acceso a una tabla optimizada para memoria ni a un procedimiento almacenado compilado de forma nativa desde la conexión de contexto (la conexión desde SQL Server al ejecutar un módulo CLR). Sin embargo, puede crear y abrir otra conexión en la que pueda tener acceso a las tablas optimizadas para memoria y a los procedimientos almacenados compilados de forma nativa.
Los datos confidenciales de las tablas optimizadas para memoria se pueden proteger mediante Always Encrypted. Se presentan las siguientes limitaciones:
- Al usar Always Encrypted con enclaves seguros, no se admite el uso de claves con enclave habilitado para columnas en tablas optimizadas para memoria. Esto significa que no se puede usar el cifrado local y el cifrado inicial se realiza en el cliente.
- Always Encrypted no se admite para ninguna columna de una tabla optimizada para memoria cuando se hace referencia a la tabla en un módulo compilado de forma nativa.
Escalabilidad y rendimiento
Los siguientes factores afectan a las mejoras de rendimiento que se pueden lograr con In-Memory OLTP:
Comunicación: Una aplicación que usa muchas llamadas cortas a procedimientos almacenados puede ver una ganancia de rendimiento menor en comparación con una aplicación con menos llamadas y más funcionalidad implementada en cada procedimiento almacenado.
Transact-SQL Execution: OLTP en memoria alcanza el máximo rendimiento cuando se usan procedimientos almacenados compilados de forma nativa en lugar de procedimientos almacenados interpretados o de ejecución de consultas. Acceder a tablas con optimización para memoria desde esos procedimientos almacenados puede aportar ventajas.
Examen de rango frente a búsqueda de punto: los índices no agrupados con optimización para memoria admiten los exámenes de rango y los exámenes ordenados. Para las búsquedas de puntos, los índices hash optimizados para memoria tienen mejor rendimiento que los índices no clúster optimizados para memoria. Los índices no clúster con optimización para memoria tienen mejor rendimiento que los índices basados en disco.
- A partir de SQL Server 2016, el plan de consulta para una tabla optimizada para memoria puede examinar la tabla en paralelo. Esto mejora el rendimiento de las consultas de análisis.
- Los índices de hash también han pasado a poder examinarse en paralelo en SQL Server 2016.
- Los índices no agrupados también han pasado a poder examinarse en paralelo en SQL Server 2016.
Operaciones de índice: Las operaciones de índice no se registran y solo existen en la memoria.
Concurrencia: Las aplicaciones cuyo rendimiento se ve afectado por la concurrencia a nivel de motor, como la contención de latch o los bloqueos, mejoran significativamente cuando migran a OLTP en memoria.
En la tabla siguiente se enumeran los problemas de rendimiento y escalabilidad que se suelen encontrar en las bases de datos relacionales y el modo en que OLTP en memoria puede mejorar el rendimiento.
| Problema | Impacto de OLTP en memoria |
|---|---|
| Rendimiento Uso elevado de recursos (CPU, E/S, red o memoria). |
Unidad Central de Procesamiento (CPU) Los procedimientos almacenados compilados de forma nativa pueden reducir significativamente el uso de la CPU porque requieren menos instrucciones para ejecutar una instrucción Transact-SQL en comparación con los procedimientos almacenados interpretados. In-Memory OLTP puede ayudar a reducir la inversión de hardware en cargas de trabajo escaladas horizontalmente, ya que un servidor puede ofrecer potencialmente el rendimiento de varios servidores. E/S Si encuentra un cuello de botella de E/S entre el procesamiento y las páginas de datos o de índice, In-Memory OLTP puede aliviarlo. Además, la creación de puntos de control de los objetos OLTP en memoria es continua y no da lugar a aumentos repentinos en las operaciones de E/S. Sin embargo, si el espacio de trabajo de las tablas críticas para el rendimiento no cabe en la memoria, In-Memory OLTP no se aplica porque requiere que los datos residan en la memoria. Si experimenta un cuello de botella de E/S en las operaciones de registro, In-Memory OLTP puede reducir ese cuello de botella porque requiere menos operaciones de registro. Si una o más tablas optimizadas para memoria se configuran como tablas no durables, puede eliminar el registro de los datos. Memoria In-Memory OLTP no ofrece ninguna ventaja de rendimiento. OLTP en memoria puede suponer una presión adicional sobre la memoria, ya que los objetos deben residir en la memoria. Red In-Memory OLTP no ofrece ninguna ventaja de rendimiento. Los datos tienen que comunicarse desde la capa de datos en el nivel de aplicación. |
| Escalabilidad La mayoría de los problemas de escalabilidad en las aplicaciones de SQL Server se deben a problemas de concurrencia, como la contención en bloqueos, latches y spinlocks. |
Contención de bloqueos temporales Un escenario típico es la contención en la última página de un índice al insertar filas de forma simultánea siguiendo el orden de la clave. Dado que In-Memory OLTP no acepta bloqueos temporales al acceder a los datos, los problemas de escalabilidad relacionados con las contenciones de bloqueos temporales se eliminan por completo. Contención de spinlock Dado que In-Memory OLTP no utiliza latches al acceder a los datos, los problemas de escalabilidad relacionados con las contenciones de spinlock se eliminan por completo. Contención relacionada con bloqueos Si la aplicación de base de datos encuentra problemas de bloqueo entre las operaciones de lectura y escritura, OLTP en memoria evita dichos problemas porque usa un nuevo formato de control de simultaneidad optimista para implementar todos los niveles de aislamiento de las transacciones. In-Memory OLTP no usa TempDB para almacenar versiones de fila. Si el problema de escalabilidad se debe a un conflicto entre dos operaciones de escritura, como dos transacciones concurrentes que intentan actualizar la misma fila, In-Memory OLTP permite que una transacción se complete correctamente y hace que la otra falle. La transacción fallida debe volver a enviarse, ya sea de forma explícita o implícita, reintentando la transacción. En cualquier caso, debe realizar cambios en la aplicación. Si su aplicación sufre conflictos frecuentes entre dos operaciones de escritura, el valor del bloqueo optimista disminuye. La aplicación no es adecuada para In-Memory OLTP. La mayoría de las aplicaciones OLTP no tienen conflictos de escritura, a menos que estos sean consecuencia del escalado de bloqueos. |
Seguridad de nivel de fila en tablas con optimización para memoria
Laseguridad de nivel de fila es compatible con las tablas optimizadas para memoria. La aplicación de directivas de seguridad de nivel de fila a las tablas optimizadas para memoria es esencialmente igual que para las tablas basadas en disco, con la excepción de que las funciones con valores de tabla en línea que se usan como predicados seguros deben compilarse de manera nativa (se deben crear con la opción WITH NATIVE_COMPILATION). Para obtener más información, vea la sección Compatibilidad entre características del tema Seguridad de nivel de fila .
Varias funciones de seguridad integradas que son esenciales para la seguridad de nivel de fila están disponibles para las tablas optimizadas para memoria. Para obtener más información, vea Funciones integradas en módulos compilados de forma nativa.
EXECUTE AS CALLER : todos los módulos nativos ahora admiten y usan EXECUTE AS CALLER de forma predeterminada, incluso si no se especifica la sugerencia. Esto se debe a que se espera que todas las funciones de predicado de seguridad de nivel de fila usen EXECUTE AS CALLER para que la función y las funciones integradas que se usen en él se evalúen en el contexto del usuario que realiza la llamada.
EXECUTE AS EL LLAMADOR tiene un impacto de rendimiento pequeño (aproximadamente10%) causado por comprobaciones de permisos en el autor de la llamada. Si el módulo especifica EXECUTE AS OWNER o EXECUTE AS SELF explícitamente, se evitan estas comprobaciones de permisos y su costo de rendimiento asociado. Sin embargo, el uso de cualquiera de estas opciones junto con las funciones integradas mencionadas incurre en un mayor impacto en el rendimiento debido al cambio de contexto necesario.
Escenarios
Para obtener una breve descripción de los escenarios habituales en los que OLTP en memoria puede mejorar el rendimiento, vea OLTP en memoria.