Sinopsis avanzada sobre la tecnología de base de datos en memoria optimizado para mejorar el rendimiento de las cargas de trabajo OLTP. De manera general, introduciremos los tópicos sobre las tablas de memoria que se optimizan con el fin de accesar los datos eficientemente, libre de contención y procedimientos almacenados nativamente compilados para una ejecución eficaz de lógica de negocio.

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