USE [master]
GO
CREATE LOGIN [DEMO1] WITH PASSWORD=N'123',
DEFAULT_DATABASE=[master],
CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
GO
USE [AdventureWorks2019]
GO
CREATE USER [DEMO1] FOR LOGIN [DEMO1]
GO
USE [AdventureWorks2019]
GO
ALTER ROLE [db_owner] ADD MEMBER [DEMO1]
GO
Sin lugar a dudas que la seguridad es muy importante en nuestros entornos de base de datos ya sea on-prem o nube.
Ahora bien, ¿Cómo podríamos saber que tenemos configurado de forma correcta la seguridad en la instancia y bases de datos?
La primer medida es conocer las buenas prácticas de seguridad recomendadas por Microsoft para SQL Server
Pero cómo podemos revisar que nuestros servidores y bases estén de forma correcta?
Bueno para esto se ha incorporado al SSMs (SQL Server Management Studio) unos informes de auditoria que nos ayudaran a revisar toda la configuración e indicarnos las mejoras necesarias.
SQL Server desde su versión 2008 tiene la funcionalidad TDE (Transparent Data Encryption) la cual permite encriptar toda la base de datos de forma transparente.
Esta funcionalidad hasta MSSQL 2019 solo estaba disponible en la edición Enterprise pero a partir de 2019 ya se puede usar en la Standard.
En el siguiente video te muestro paso a paso como se configura TDE y funciona como así también algunos tips que seria bueno considerar.
Para poder descargar el material que utilice en el video lo podes hacer desde el siguiente link
Este post tiene como objetivo demostrar uno de los mitos que escucho muy frecuentemente entre programadores y DBA en donde afirman que las variables tipo tabla son mejores que las tablas temporales porque no usan la tempdb y se almacenan en memoria RAM.
Te dejo primero este video explicativo donde te cuento sobre este mito y demuestro que no es así, pero también te cuento como podes realmente usar variables tipo tabla que si residan en memoria RAM.
En el primer ejemplo declaramos una variable tipo tabla y verificamos en la Tempdb si la usa o no.
USE ADVENTUREWORKS2019
-------------------------------------------------
-- PRUEBA 1
-------------------------------------------------
DECLARE @T AS TABLE ([NAME] VARCHAR(255),
[OBJECT_ID] INT,
[SCHEMA_ID] INT,
[TYPE_DESC] VARCHAR(255),
[CREATE_DATE] DATETIME
)
INSERT INTO @T
SELECT TOP 100
NAME,
OBJECT_ID,
SCHEMA_ID,
TYPE_DESC,
CREATE_DATE
FROM SYS.OBJECTS
-- MIRAMOS TEMPDB
SELECT
NAME,
PS.INDEX_ID,
PS.ROW_COUNT,
(PS.USED_PAGE_COUNT * 8.00)/1024.00 AS ESPACIO_MB,
CREATE_DATE,
MODIFY_DATE
FROM TEMPDB.SYS.OBJECTS AS SO
JOIN TEMPDB.SYS.DM_DB_PARTITION_STATS PS ON SO.OBJECT_ID = PS.OBJECT_ID
WHERE
NAME LIKE N'#%'
AND ROW_COUNT > 0
GO
La siguiente imagen muestra el resultado de nuestra prueba
Aquí podemos observar que la variable tipo tabla USA la tempdb.
Variables tipo tabla que si usan la memoria
Si deseamos usar variables tipo tabla que realmente usen la RAM y no la Tempdb debemos utilizar memory-optimized table type
Veamos un ejemplo:
USE AdventureWorks2019
CREATE TYPE dbo.inMemoryTableType
AS TABLE
(
[NAME] VARCHAR(255) INDEX IX1,
[OBJECT_ID] INT,
[SCHEMA_ID] INT,
[TYPE_DESC] VARCHAR(255),
[CREATE_DATE] DATETIME
)
WITH (MEMORY_OPTIMIZED = ON);
GO
DECLARE @T AS dbo.inMemoryTableType
INSERT INTO @T
SELECT TOP 100
O.NAME,
O.OBJECT_ID,
O.SCHEMA_ID,
O.TYPE_DESC,
O.CREATE_DATE
FROM SYS.OBJECTS O
-- MIRAMOS TEMPDB
SELECT
NAME,
PS.INDEX_ID,
PS.ROW_COUNT,
(PS.USED_PAGE_COUNT * 8.00)/1024.00 AS ESPACIO_MB,
CREATE_DATE,
MODIFY_DATE
FROM TEMPDB.SYS.OBJECTS AS SO
JOIN TEMPDB.SYS.DM_DB_PARTITION_STATS PS ON SO.OBJECT_ID = PS.OBJECT_ID
WHERE
NAME LIKE N'#%'
AND ROW_COUNT > 0
Conclusiones
Las variables tipo tabla usan la TEMPDB al igual que las tablas temporales, entonces ¿Cuál es la diferencia entre ambas? pues de funcionalidad , aquí les paso el siguiente cuadro.
El pasado 1 de diciembre de 2021 en conjunto con el Grupo de Usuarios Microsoft Argentina (MUG) di una charla en donde te cuento en base a mi experiencia como deberías encarar un proyecto de migración de tu SQL Server ya sea hacia ambientes on-premise o la nube.
Comparto el video de la misma como así también la presentación y material
