Novedades en SSMS 2016

Standard

SQL Server Management Studio 2016 viene con algunas novedades.

Independencia del motor: Ahora se podrá instalar y actualizar el SSMS independiente del SQL Server, es una herramienta como lo son las de BI, con lo cual podrá hacer una instalación web y la misma herramienta tendrá las opciones de actualización.

Actualización automática: Se podrá actualizar la herramienta desde la web o desde el cliente buscando las actualizaciones mas recientes

Posibilidad de saltear guardar script al salir: Ahora se puede configurar que al salir del SSMS no aparezca el mensaje de guardar el script

Actualización del Wizard import / export: Se ha actualizado el Wizard pudiendo soportar ahora los nuevos servicios de Azure (SQL database) basic , standard y Premium.

Datazen Publisher para windows 7

Standard

Como muchos de ustedes sabrán Datazen Publisher solo estaba disponible para Windows 8 / 8.1 desde el store. En este mes de junio se libero su versión preliminar para poderlo instalar en Windows 7.

Datazen es una de las ultimas adquisiciones de Microsoft el cual se integra con SQL Server permitiendo desarrollar tableros que se los puede consumir desde distintas plataformas como Windows, Android, iOS o Windows Phone

Datazen Publisher for Windows 7

image

SSIS Feature Pack para Azure

Standard

En este mes Microsoft ha liberado los Feature Pack de SSIS (SQL Server Integration Services) los cuales permiten conectar a SSIS con algunos componentes de Azure como pueden ser los Blob Storage o HDInsight permitiendo así poder transferir o recibir información de ellos por medio de paquetes DTSx.

Estos paquetes de integración están disponibles para SQL Server 2012 y SQL Server 2014.

Aquí dejos los links para poderlos descargar e integrar con SSIS

SSIS Feature Pack Azure SQL 2012

SSIS Feature Pack Azure SQL 2014

Depurar datos de una tabla con OUTPUT

Standard

En algunos sistemas disponemos de información en las tablas grandes que no se usan de forma frecuente. Para este tipo de situaciones existen varias alternativas de solución que van desde borrar o mover los datos a una base de history hasta la utilización de particiones dentro de la misma tabla (Edición Enterprise de SQL Server).

En este post nos vamos a dedicar a una de estas opciones que básicamente es mover los datos a otra base de datos. Supongamos que deseamos mover todas las órdenes menores a una determinada fecha a una base de datos de historia.

¿Que sucede cuando deseamos implementar algo así? , básicamente el problema es que debería borrar de la tabla origen los registros e insertarlos en la tabla destino, para ello se me podrían ocurrir distintos tipos de alternativas como por ejemplo:

Triggers: Se crea un Trigger para la operación Delete en la tabla origen, ese trigger tiene el código necesario que hace el INSERT en la base destino. Este mecanismo me asegura que cuando borro registros en la tabla origen se pasan a la destino, si falla no se pasan ya que están dentro de la misma transacción. Ahora bien, esta solución tiene un problema, el trigger se va a disparar no solo para mi proceso de depuración sino que para cualquier operación DELETE que se haga sobre la tabla, lo cual no resulta funcional a lo que deseo o bien de hacerlo debería agregar alguna lógica en el trigger lo cual podría hacer que las operaciones de DELETE se hagan más lentas.

Proceso de depuración: Otra opción es hacer este proceso de depuración con lógica TSQL, lo primero que deberíamos hacer es saber que registros borrar y por ejemplo guardarlos en una tabla temporal y luego esos ID empezar a borrarlos de la tabla origen e insertarlos en la tabla destino.

OUTPUT: Este es el mecanizo que usaremos en este post, la instrucción OUPUT existe desde SQL Server 2005 y permite obtener la salida de una operación de modificación como puede ser INSERT, UPDATE y DELETE.

Consideraciones adicionales para cualquier método: Cualquier proceso de depuración se debería hacer en lotes de registros ya que sino la transacción puede ser muy grande y esto generar otros problemas de performance en las aplicaciones. También sería recomendable decirle al SQL (si es que la tabla ya no lo tiene) que los loqueos no hagan un escalamiento lo cual podría pasar que por querer borrar 10.000 registros se termine bloqueando la tabla completa o páginas de otros registros que no están relacionados con mi depuración, si bien esto hará mas uso de la memoria del servidor y habrá que analizarlo en términos generales termina siendo una buena práctica.

Código ejemplo de cómo usar OUTPUT en un depurador:

 

Material charlas SQL Server Saturday

Standard

El día 22 de mayo de 2015 se realice en Buenos Aires el primer SQL Server Saturday, un evento donde han participado mas de 100 asistentes.

En dicha ocasión me ha tocado participar en tres charlas (SQL en ambientes virtualizados, tuning avanzado para DBA´s y SQL 2014 CE).

En este link comparto el material de mis 3 charlas

SQL SATURDAY BS AS

Si desean ver algunas fotos del evento lo pueden hacer aquí

RLS (Row Level Security) en SQL 2016

Standard

RLS (Row Level Security) es una funcionalidad solicitada ya hace un tiempo. Si bien la misma hoy se encuentra disponible en SQL Database V12 o superior ya en el SQL Server 2016 cTP2 lo podemos probar para nuestro ambiente on-premise.

¿De que se trata RLS? La idea es poder dar permisos a nivel registro, supongamos que tenemos una tabla de ventas y que deseamos que ciertas personas puedan solo ver los datos de Buenos Aires, cuando hablamos de esto obviamente que estamos hablando de usuarios de base de datos con lo cual se seguridad la maneja el propio motor de SQL Server mas allá de lo que pueda o no hacer la aplicación.

El siguiente es un ejemplo de como podemos usar RLS

Ahora vamos a probar la seguridad con RLS para cada usuario

image

image

image

JSON en SQL 2016

Standard

Si señores, como en su momento fue la integración de XML a SQL Server ahora podemos ejecutar queries que retornen un JSON Smile . Simplemente con usar el FOR JSON podremos generar los JSON en nuestros Select

image

image

image

SQL Server 2016 CTP2 preview Download

Standard

Hoy se acaba de publicar el CTP2 de SQL Server 2016 para su descarga.

Algunas de las keys de SQL 2016

Key Capabilities in SQL Server 2016 CTP2

Always Encrypted

Always Encrypted, based on technology from Microsoft Research, protects data at rest and in motion. With Always Encrypted, SQL Server can perform operations on encrypted data and best of all, the encryption key resides with the application in the customers trusted environment. Encryption and decryption of data happens transparently inside the application which minimizes the changes that have to be made to existing applications.

Stretch Database

This new technology allows you to dynamically stretch your warm and cold transactional data to Microsoft Azure, so your operational data is always at hand, no matter the size, and you benefit from the low cost of Azure.  You can use Always Encrypted with Stretch Database to extend data in a more secure manner for greater peace of mind.

Real-time Operational Analytics & In-Memory OLTP

For In-Memory OLTP, which customers today are using for up to 30x faster transactions, you will now be able to apply this tuned transaction performance technology to a significantly greater number of applications and benefit from increased concurrency.  With these enhancements, we introduce the unique capability to use our in-memory columnstore delivering 100X faster queries on top of in-memory OLTP to provide real-time operational analytics while accelerating transaction performance.

Additional capabilities in SQL Server 2016 CTP2 include:

PolyBase – More easily manage relational and non-relational data with the simplicity of T-SQL.

AlwaysOn Enhancements – Achieve even higher availability and performance of your secondaries, with up to 3 synchronous replicas, DTC support and round-robin load balancing of the secondaries.

Row Level Security– Enables customers to control access to data based on the characteristics of the user. Security is implemented inside the database, requiring no modifications to the application.

Dynamic Data Masking – Supports real-time obfuscation of data so data requesters do not get access to unauthorized data.  Helps protect sensitive data even when it is not encrypted.

Native JSON support – Allows easy parsing and storing of JSON and exporting relational data to JSON.

Temporal Database support – Tracks historical data changes with temporal database support.

Query Data Store – Acts as a flight data recorder for a database, giving full history of query execution so DBAs can pinpoint expensive/regressed queries and tune query performance.

MDS enhancements – Offer enhanced server management capabilities for Master Data Services.

Enhanced hybrid backup to Azure – Enables faster backups to Microsoft Azure and faster restores to SQL Server in Azure Virtual Machines.  Also, you can stage backups on-premises prior to uploading to Azure.

SQL 2016–Novedades en tablas in-memory

Standard

En el ultimo evento Ignite de 2015 se presentaron algunas de las novedades de SQL Server 2016 entre ellas las mejoras en tablas in-memory.

El siguiente cuadro compara la primer versión de SQL2014 y lo que tendrá SQL 2016

Feature/Limit SQL Server 2014 SQL Server 2016
Maximum size of durable table 256 GB 2 TB
LOB (varbinary(max), [n]varchar(max)) Not supported Supported*
Transparent Data Encryption (TDE) Not supported Supported
Offline Checkpoint Threads 1 1 per container
ALTER PROCEDURE / sp_recompile Not supported Supported (fully online)
Nested native procedure calls Not supported Supported
Natively-compiled scalar UDFs Not supported Supported
ALTER TABLE Not supported / (DROP / re-CREATE) Partially supported / (offline – details below)
DML triggers Not supported Partially supported / (AFTER, natively compiled)
Indexes on NULLable columns Not supported Supported
Non-BIN2 collations in index key columns Not supported Supported
Non-Latin codepages for [var]char columns Not supported Supported
Non-BIN2 comparison / sorting in native modules Not supported Supported
Foreign Keys Not supported Supported
Check/Unique Constraints Not supported Supported
Parallelism Not supported Supported
OUTER JOIN, OR, NOT, UNION [ALL], DISTINCT, EXISTS, IN Not supported Supported
Multiple Active Result Sets (MARS) / (Means better Entity Framework support.) Not supported Supported
SSMS Table Designer Not supported Supported

Tipos de datos Unicode e impacto en la performance

Standard

Los tipos de datos UNICODE que podemos usar con el NCHAR() o NVARCHAR() en muchos casos son útiles si deseamos guardar caracteres de este tipo. Ahora bien, cual es el problema si diseñamos una base con este tipo de caracteres y no los tenemos? en principio uno podría decir que nada ya que si no están el tipo de dato guardara los caracteres normales, pero….  para poder guardar los Unicode necesita el SQL un byte mas por carácter por ello el máximo de un varchar o char común es de 8000 y el de un NChar o Nvarchar es de 4000.

Lo que haremos en este post es observar que sucede con la performance si usamos uno u otro tipo de dato

Primer paso:

Lo primero que haremos es crear dos tablas iguales solo que una esta definida como Unicode y la otra no. Luego a cada una de ellas le insertaremos 1Millon de registros iguales

Segundo paso:

Observaremos el espacio ocupado por cada una de estas tablas usando SP_SPACEUSED

 

image

Como podemos observar en los resultados la tabla con Unicode pesa casi el doble que la otra tabla.

Prueba de performance:

Ahora lo que vamos a hacer es un SELECT de ambas tablas las cuales harán el mismo plan de ejecución (Query Plan) pero al ser mas pesado uno que el otro lo veremos representado en los costos de cada QP

image

 

Conclusiones:

Como siempre decimos hay que ser muy cuidadoso con los tipos de datos a elegir porque el peso juega en la performance, siempre hay que recordar que el costo de un plan de ejecución toma en cuenta el costo de CPU y el de I/O.

Con los datos Unicode recomiendo al igual que los otros tipos de datos analizarlos con cuidado y solo aplicarlos donde se considere será necesario.