El documento presenta una guía detallada sobre MS SQL Server 2014 y su capacidad de procesamiento in-memory OLTP, centrándose en su arquitectura, optimización de datos y procedimientos almacenados en memoria. Se abordan conceptos claves como la administración de memoria, niveles de aislamiento de transacciones y limitaciones en tipos de datos y características. Además, se describen herramientas para identificar escenarios de uso y se resuelven mitos y realidades sobre esta tecnología.

1. MS SQL Server 2014
In Memory OLTP
José Redondo – Kenneth Ureña
DPA SolidQ | SDP Bits America Colombia | SQL Server MVP – Database Manager
Correo: redondoj@gmail.com – urecak@gmail.com
Twitter: @redondoj - @sqlcr
Blog: redondoj.wordpress.com – www.sqlcr.com

2. Expositor
 Jose Redondo
 DPA, SolidQ – Specialist Data Platform, BITS Americas
Colombia
 MCP | MCTS – MS SQL Server; MTA – DAF | MS SQL Server
MVP

3. Diamond Sponsors
Bronze Sponsors
SQL Saturday Sponsors

4. MS SQL Server 2014
In Memory OLTP

5. AGENDA
 Arquitectura
 Objetos de trabajo
 Requerimientos
 Limitaciones
 Herramientas para identificar escenarios
candidatos

6. ARQUITECTURA

7. Conceptos
 Conceptos
 In-Memory
 Libre de bloqueos
(Versionamiento de
registros)
 Compilación Nativa de
Procedimientos
Almacenados

8. Optimización
 Optimización en el
almacenamiento de
datos
 Estructuras de datos
optimizadas en memoria
 Optimización del
Registro de
Transacciones
 Escritura en bloque
 No permite deshacer

9. Optimización
 Optimización en el almacenamiento de datos
 Optimización de
los archivos de
datos
 Escritura secuencial
 Combinación de
escritura
 Optimización de
Índices
 Solo In-Memory
 No ejecuta persistencia en disco
 No genera registro (Logging)
 No utiliza la base de datos TempDB
 Optimización del recolector de basura, ;-)

10. Comportamiento
 Comportamiento en ejecución
 Opción
“Transitoria”
“Breve”
“Corta”

11. Mitos | Realidades
 Mitos y Realidades
 Mitos
a. Igual a DBCC PINTABLE
b. Si el servidor se bloquea,
todos los datos se pierden
 Realidades
a. Nuevo diseño construido completamente desde cero
b. Es persistente en disco. Recuperable totalmente

12. Sinopsis
• Optimizado para datos In-Memory
• Índices son en memoria
• No hay pool de buffers. B-Tree
• Almacenamiento basado en secuencias
Memoria Principal Optimizada
• T-SQL compilado a código maquina mediante
generador de código C y VC
• Llamar a un procedimiento seria solamente un
DLL como punto de partida
• Optimizaciones agresivas en tiempo de
compilación
T-SQL compilado a
Código Maquina
• Control de Multi-Versión de concurrencia
optimista con soporte completo ACID
• Núcleo del motor de datos utiliza algoritmos sin
bloqueo
• Ningún Administrador de Bloqueos, Latches o
Spinlocks
Alta Concurrencia
• Misma experiencia tanto en el rol de
administrador así como el de desarrollador
• Consultas & transacciones integradas
• Alta Disponibilidad integrada con Recuperación
de Desastres (Copia de seguridad /
Restauración)
Integración con SQL Server

13. Estructura
Tabular Data Stream (TDS) – Administración y Gestión de Sesiones
Ejecución de
Consultas
T-SQL
Pool de buffer para
Tablas e Índices
Parser, Catalogo
y Optimizador
Interoperabilidad de
las Consultas
Motor de Almacenamiento
para Tablas e Índices
Optimizados en Memoria
Compilador Nativo
de Procedimientos
Almacenados y
Schema
Compilador Nativo
In-Memory
Memoria Optimizada para
Tablas en Grupos de
Archivos
Registros de Transacciones Grupo de Archivos de Datos
AplicaciónCliente
SQLservr.exe
Tipos de Componentes
Claves
Componente
SQL
DLL Generado
Componente
In-Memory OLTP

14. OBJETOS DE TRABAJO

15. Objetos de trabajo
 Administración de la memoria
 Estructuras de datos en memoria
 Tablas de datos en memoria
 Procedimientos Almacenados en memoria
 Usando la arquitectura de libre bloqueo para
versiones de registros
 Niveles de aislamiento de transacciones
 Recolector de basura en memoria

16. Administración de la memoria
 Tablas residentes en
memoria todo el tiempo
 Sin paginación
 Se debe configurar en las
opciones de SQL con
suficiente memoria para
almacenar las tablas en
memoria optimizada. Lo
máximo soportado es de
512GB
 La falta de asignación de
memoria generara falla en la
carga del trabajo
transaccional en tiempo de
ejecución

17. Estructuras de datos en memoria
 Registros
 Nuevo formato de registro
 La estructura del registro es optimizada
para residir y ser accesado en memoria
 Una sola copia por registro
 Los índices señalan a los registros,
no duplicándolos
 Índices
 Índices HASH para búsquedas similares
 Memoria optimizada B-Tree para la
búsqueda de rangos e igualdades
(En CTP2)
 No existe en disco – Se recrean durante la recuperación

18. Tablas de datos en memoria
 Necesidad de Filestream Filegroup (Grupo de archivos
Filestream)

19. Creación de la base de datos
CREATE DATABASE CostaRicaSS282_DB
ON PRIMARY
(
NAME = [CostaRicaSS282_DB_PRIMARY],
FILENAME = 'C:CostaRicaSS282_testsqlservrdataCostaRicaSS282_DB_data.mdf„
),
FILEGROUP [CostaRicaSS282_DB_FG] CONTAINS MEMORY_OPTIMIZED_DATA
(
NAME = [CostaRicaSS282_DB_DIR],
FILENAME = 'C:CostaRicaSS282_testsqlservrdataCostaRicaSS282_DB_DIR„
)
LOG ON
(
NAME = [CostaRicaSS282_DB_LOG],
FILENAME='C:CostaRicaSS282_testsqlservrdataCostaRicaSS282_DB.ldf', SIZE=100MB
)

20. Creación de la tabla DDL

21. Creación de la tabla DDL
CREATE TABLE DDL
Generación y Compilación
del código
Tabla DDL generada
Tabla DDL cargada

22. Almacenamiento de la Tabla
 Filestream es el
mecanismo subyacente
de almacenamiento de la
información
 Archivos de datos
 Solamente se escriben los
datos sobre “tx.commit()”
 Delta Files
 Almacenar los registros
eliminados (Las actualizaciones
se comporta como una inserción / eliminación según sea el caso)

23.  Se utiliza el registro
de transacciones
de SQL para
almacenar contenido
 Todo el registro es lógico
 No hay registro para las modificaciones de estructuras
físicas
 No hay índices específicos / Mantenimiento de los índices
en el registro de transacciones
 No hay información para deshacer cuando se registra en el
Log
Registro de Transacciones (Logging)

24. Procedimientos Almacenados en memoria
 Contexto Nativo
 Compilado en lenguaje C y compilado en un archivo DLL
usando VC (Visual C++)
 Optimizado agresivamente en tiempo de
compilación
 Sólo pueden acceder a tablas en memoria
 No todas las construcciones de T-SQL y
funciones son soportadas
 No es permitido modificar el Procedimiento
Almacenado – Se deberá Eliminar y Recrearlo
nuevamente

25. Procedimientos Almacenados en memoria
 Generación
CREATE PROC DDL
Optimización de la
consulta
Generación y Compilación
de Código
Procedimiento DDL
generada
Procedimiento DDL
cargada

26. Procedimientos Almacenados en memoria
 Creación

27. Usando la arquitectura de libre bloqueo para
versiones de registros
 SQL Server 2014 - Bases de datos en memoria no tiene
períodos de bloqueos
 Las versiones de registros se usan para mantener las
actualizaciones
 No aplica "TempDB"
 Las versiones de registros
que ya no se hacen referencia,
son basura a recogerse
 Soporta niveles de aislamiento
Snapshot (instantánea),
Repeatable Read y Serializable

28.  Snapshot (Instantánea)
 Las lecturas son consistentes
a partir del inicio de la
Transacción
 Las Escrituras son siempre
consistentes
 Repeatable Read
 Las operaciones de lectura
ceden a las mismas versiones
de registros, si se repiten en el
momento de aplicarse
 Serializable
 Transacción que se ejecuta como si no hubieran transacciones concurrentes – Todas
acciones suceden en un punto único de serialización (Commit Time)
Niveles de aislamiento de
transacciones

29. Recolector de basura en memoria
 Versionamiento de registros
 Actualizaciones, eliminaciones y las
operaciones de inserción
abortadas, crean versiones de fila que
(Eventualmente) ya no son visibles
para cualquier transacción
 Análisis de estructuras de índice más
lento
 Crear memoria sin usar que necesita
ser reclamada (Por
ejemplo, Recogida de basura)

30. Recolector de basura en memoria
 Recolector de basura
(GC)
 Análogo a la versión del
"Store Cleanup Task for
Disk" dando soporte al
'Read Committed
Snapshot' (RCSI)
directamente
 El Sistema mantiene un
hit de la
transaccionabilidad activa
más antigua en ejecución

31. Recolector de basura en memoria
 Propósitos de diseño
 No hay bloqueos, Es
cooperacional, Eficiente,
Responsivo, Escalable
 Las transacciones
activas trabajan de
manera cooperativa y
recoger todos los
elementos de trabajo del
GC
 Ser subproceso del
sistema dedicado a
hacer GC

32. DEMO

33. REQUERIMIENTOS

34. Requerimientos
 Utiliza todo el ecosistema existente
de Hardware
 Funciona perfectamente con todos
los objetos de SQL Server en la
actualidad
 Es compatible con ACID
 Se pueden mezclar tablas basadas
en memoria y en disco en la misma
base de datos
 Las transacciones pueden abarcar
tanto en memoria y como en disco
basado en tablas

35. Requerimientos
 No, no puede tener tablas
particionadas en memoria
 Sí, se puede y esta permitido
llenar al 100% en memoria los
objetos a utilizar en el servidor
 También podemos limitar cuánta
memoria es utilizada por las
tablas en memoria (Pensado para las agrupaciones [Pool]
de
recursos)
 Sí, podemos tener y aplicar Alta Disponibilidad

36. DEMO

37. LIMITACIONES

38. Limitaciones
 El tamaño de los registros (Filas) no pueden
ser mayores de 8060 bytes (Incluyendo las
columnas con tipo de datos de longitud
'Variable')
 No se admiten los tipos de datos
Datatimeoffset, Geo, Jerárquicos, LOB,
UDTs, NText, Varchar(MAX), SQL_Variant y
XML
 No es permitido utilizar Clave Externa
('Foreing Key'), Unique y las restricciones
'Check'
 Tampoco se admiten Columnas de Identidad
y las Secuencias
 El almacenamiento FILESTREAM no es
soportado

39. Limitaciones
 No hay desencadenadores 'Triggers' DML
 No ALTER TABLE (Es necesaria el recrear
la tabla)
 No se permite agregar o quitar ningún índice
(Es necesaria el recrear la tabla)
 Los índices pueden ser reconstruidos
'REBUILD INDEX' (Consideren el tiempo de
inicio del proceso)
 Índice Clustered no son soportado
 Las tablas como memoria optimizada
soportan un máximo de ocho índices
 Los Índices de Almacenamiento Columnar
no son soportados
 La compresión de los datos no es soportada

40. Limitaciones
 Database Mirroring no esta soportado
 La opción AUTO_CLOSE no es
soportado
 Database Snapshots no es soportado
 No Copias de Seguridad diferenciales
 DBCC (CHECKDB & CHECKTABLE)
no trabaja bajo este contexto
 ROWGUIDCOL no son soportado
 Los archivos en disco son combinados
('Fusionan') mientras se están
cargando
 Ejecutando fuera de memoria
 Multiple Active Result Sets (MARS) y el
Change Data Capture no es soportado

41. HERRAMIENTAS PARA IDENTIFICAR
ESCENARIOS CANDIDATOS

42. Herramientas para identificar escenarios
candidatos
 Herramientas (AMR) – Analizar, Migrar y
Reportar
 SSMS
 Management Data Warehouse (MDW)
 Data Collection

43. DEMO

44. PREGUNTAS & RESPUESTAS

45. MS SQL Server 2014
In Memory OLTP
Jose Redondo – MS SQL Server MVP
Correo: redondoj@gmail.com
Twitter: @redondoj
Blog: redondoj.wordpress.com

46. MS SQL Server 2014
In Memory OLTP
Kenneth Ureña – MCSA, MCTS, MCITP, MTC
Correo: urecak@gmail.com
Twitter: @sqlcr
Blog: www.sqlcr.com

47. Los invitamos al

48. Muchas gracias por su participación