SQLArgentina – Ciclo de Charlas 2018

Visits: 322

Hola a todos!

Después de algunos meses donde recargamos baterías, nos volvimos a reunir en SQLArgentina y preparar los próximos Webinars de 2018.

Luego de seleccionar los contenidos, hemos conformado el siguiente cronograma de charlas:

Agosto:

Septiembre:

  • 14-9 : Alejandro Cabanchik – DAX 101
  • 28-9: Javier Villegas – Azure SQL Managed Instance

Octubre:

  • 12-10: Gonzalo Bissio – SQL Azure DB
  • 26-10: Alejandro Cabanchik – SQL Server Analysis Services  & PBI

Noviembre:

  • 9-11: Maxi Accotto– SQL Server Best Practices 1
  • 23-11 : Mariano Kovo – SQL Server & Containers

 

En breve a quienes se encuentren suscriptos en SQLArgentina o hayan participado en los eventos anteriores, les llegará la invitación a sus casillas de mail.

En tanto a quienes todavía no estén registrados, los invito a hacerlo:

http://www.sqlpass.org 

(Registración y luego en el perfil, buscar el grupo local SQLArgentina)

Saludos a todos y espero verlos!

MarianoK

[Evento] Microsoft Data & AI – Experience 2018 LATAM

Visits: 599

 

Los Datos y la Inteligencia Artificial están cambiando el mundo e impulsando nuevos negocios y oportunidades en Latinoamérica.

Hoy te invitamos al Microsoft Data & AI Experience 2018 LATAM, donde expertos a nivel mundial anticipan el uso de Machine Learning en cada industria, mejores prácticas de Big Data y analítica avanzada, cómo trabajar Ciencia de Datos, y todo sobre Data, IoT, y Bots para transformar los negocios.

Subite a la Revolución de la Nube Inteligente con innovación y datos conectados para ganar Competitividad e Inteligencia de Negocios antes que tu competencia.

 

El Día 1 contará con sesiones de enfoque técnico sobre Data e Inteligencia Artificial, divididas en 3 tracks de acuerdo a tu perfil: Desarrolladores, Técnico y de Soluciones. (*)

19/03/2018

 

09:00 hs

 

Sheraton Libertador. Av. Córdoba 690, CABA

 

El Día 2 contará con Keynotes de Expertos Mundiales en Data e Inteligencia Artificial, junto con los mejores casos de uso en Latinoamérica. (*).

 

20/03/2018

 

09:00 hs

 

Sheraton Libertador. Av. Córdoba 690, CABA

 
*Cupos limitados

 

SQL Server – Automatizando Tareas con Powershell – dbatools

Visits: 2002

Desde hace un tiempo a esta parte, PowerShell de a poco se ha convertido en un estándar para la automatización de tareas en Windows (principalmente, ya que también Microsoft lo ha disponibilizado en otros sistemas operativos también).

Para los DBAs y los que normalmente trabajan con SQL Server, también ha comenzado la adopción de este lenguaje de scripting y shell de línea de comandos. Pero, debo reconocer que para mí y algunos cuantos colegas no hemos llevado la vanguardia en la implementación PowerShell y a veces nos cuesta abandonar a nuestro querido T-SQL.

Pero lo que me ha motivado a utilizar PowerShell, al menos de mi parte, es para utilizar esta gran herramienta dbatools, desarrollada completamente por la comunidad y para la comunidad en forma libre y sin costo.

Permite realizar cientos (mas de 300) de tareas en forma automatizada, minimizando errores y aplicando las best-practices creadas por cientos de profesionales de SQL Server.

 

Configurar PowerShell

Para comenzar antes que nada, debemos tener instaladas las versiones más actualizadas, ya que dependiendo del sistema operativo que tengamos instalados, estos poseen diferentes versiones de PowerShell (Fig.1)

 

O.S. Executable Execution Policy PowerShell Version
2008 R2 – PowerShell type SQLPS.exe RemoteSigned 2.0
2008 R2 – CmdExec type powershell.exe via cmd.exe System Configured Latest Installed
2012 – PowerShell type SQLPS.exe RemoteSigned 2.0
2012 – CmdExec type powershell.exe via cmd.exe System Configured Latest Installed
2014 – PowerShell type SQLPS.exe RemoteSigned 4.0
2014 – CmdExec type powershell.exe via cmd.exe System Configured Latest Installed
2016 – PowerShell type SQLPS.exe RemoteSigned 4.0
2016 – CmdExec type powershell.exe via cmd.exe System Configured Latest Installed

FIG. 1. Fuente – Derik Hammer: https://www.sqlhammer.com/running-powershell-in-a-sql-agent-job/

Para obtener la actualización de Powershell podemos ir directamente a la descarga desde Microsoft:

Ref. https://docs.microsoft.com/en-us/powershell/scripting/setup/installing-windows-powershell?view=powershell-6#upgrading-existing-windows-powershell

Configurar el Execution Policy

Otro punto importante es la Política de Ejecución (Execution Policy), que también dependiendo de la versión cambia su configuración.

Según la teoría, la Política de Ejecución se encuentra por razones de precaución y no seguridad. Es decir que intencionalmente se puede modificar el Scope de aplicación  según la necesidad del script a correr. Y la función principal es prevenir la ejecución de código no seguro, aunque no es una política activa de Seguridad que proactivamente puede detener una ejecución.

Ref: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_execution_policies?view=powershell-6

Y precisamente para ejecutar las funciones de dbatools minimamente requiere que esta opción se encuentre en “Remote Signed”, es decir que se podrán ejecutar Scripts que no están alojados en la computadora local deben estar firmados digitalmente para ser ejecutados.

Desde una ventana PowerShell con permisos elevados de Administrador, se puede ver el ExecutionPolicy y cambiarlo:

Código:  Set-ExecutionPolicy RemoteSigned


Instalación de dbatools

Luego de actualizar PowerShell y configurar la Execution Policy, tenemos que instalar el modulo de dbatools.

Esto se puede realizar en forma offline, sino se dispone una conexión a internet y se puede realizar siguiendo los pasos muy bien descriptos del sitio de dbatools: https://dbatools.io/offline/

Básicamente se descarga el módulo, ya sea desde la Galería de PowerShell oficial de Microsoft, o desde el sitio oficial de dbatools, se descomprimen los scripts y luego se ejecuta localmente la instalación.

Y la otra opción (y más directa) si se dispone de una conexión a internet, es utilizando desde la linea de comandos de PowerShell ejecutando el comando “Install-Module dbatools”

Aunque previamente hay que ejecutar unos comandos adicionales para confiar en el repositorio y luego importar los módulos instalados.

El paso a paso se puede ver : https://dbatools.io/soup2nutz/

Y en el tutorial de YouTube: installing modules from the powershell gallery

Con esto completo ya tendremos en nuestro servidor o equipo, las herramientas instaladas y podremos ejecutar todos los comandos para automatizar las tareas como Backups y Restores entre diferentes ambientes, o realizar migraciones completas de todas las bases de datos desde un server a otro, y tantas otras más como la lista a continuación:

https://dbatools.io/functions/

Los invito a probarla y porque no a colaborar en esta gran herramienta abierta para la comunidad.

En el próximo post, vamos a ver como programar tareas automatizadas de dbatools y PowerShell desde SQL Server Agent.

 

Agradecimientos y Referencias

Equipo de dbatools : https://dbatools.io/

Blog de Derik Hammer: https://www.sqlhammer.com/running-powershell-in-a-sql-agent-job/

SQL Datawarehouse 101 – Parte 1

Visits: 846

Vamos a comenzar con esta serie de posts dedicados a esta tecnología que brinda Microsoft hace ya un tiempo y cobra mucho valor en estas épocas de volúmenes masivos de información.

Azure SQL Datawarehouse es un servicio Cloud de Microsoft Azure, que ofrece una base de datos relacional con procesamiento paralelo masivo (MPP) capaz de procesar volúmenes masivos de datos.

Bien, hasta ahí la definición de diccionario para este componente de la familia de SQL Server de Microsoft. Pero para entender a este hermano mayor de SQL Server, tendremos que hacer un mínimo de historia y repaso de la arquitectura de Procesamiento Paralelo Masivo (MPP) y como esta difiere con la arquitectura tradicional de SQL Server (SMP o Symmetric Multi-Processing ).

Arquitectura de Procesamiento MPP y SMP

Vamos las definiciones de ambas arquitecturas y como se componen.

SMP: Symmetric Multi-Processing, es un sistema multi-procesador con un alto nivel de acoplamiento donde cada procesador comparte los recursos. Estos recursos son un único Sistema Operativo (OS), Memoria, Dispositivos de I/O e interconectados en un BUS común.

Dicho de una manera simple y sencilla, se trata de un servidor de arquitectura tradicional que conocemos normalmente en las implementaciones de SQL Server.

Fig. 1 Arquitectura SMP

MPP: Massively Parallel Processing , es el procesamiento coordinado de una única tarea realizara por múltiples procesadores, que utilizan sus propio Sistema Operativo y Memoria y que se comunica con cada otro utilizando una interfaz de mensajería. Esta arquitectura se puede implementar con un sub-sistema de disco de tipo shared-nothing (discos locales) o shared-disk (discos en un arreglo, SAN, NAS, etc.)

En la arquitectura Shared-Nothing, no existe ningún punto de contención en el sistema completo y los nodos no comparten recursos de memoria o almacenamiento, Los datos son particionados horizontalmente por cada nodo, para que cada uno de éstos tenga un sub-set de filas de cada tabla almacenada en la base de datos. De esta forma cada nodo procesará solo la porción de registros que posee en sus discos. Los sistemas basados en esta arquitectura pueden escalar en forma masiva ya que no poseen un un punto “cuello de botella” que pueda afectar la performance de todo el sistema.

Fig. 2 Arquitectura MPP shared-nothing

SQL Data Warehouse Componentes y Características

Bien, ahora que ya repasamos la arquitectura MPP, podemos decir que SQL Data Warehouse es un sistema de base de datos distribuido de Procesamiento Paralelo Masivo (MPP, definición larga y de diccionario :-))

Por debajo del capot, el motor de SQL Data Warehouse distribuye los datos en muchas unidades de procesamiento y un almacenamiento shared-nothing (claro que siempre con un criterio! Y tratando de que se haga lo más parejo posible, salvo que nosotros le indiquemos otra cosa, que ya veremos más adelante).

Los datos se almacenan en forma redundante en una capa de Storage de tipo Premium (recordemos que es un servicio de Azure) que a su vez se vincula dinámicamente con los nodos de computo que ejecutan las consultas.

SQL Data Warehouse trabaja bajo el concepto de “división y conquista” para ejecutar cargas de trabajo y querys complejos. Los requerimientos son recibidos por un solo nodo llamado Control Node, el cual optimiza y prepara la distribución del trabajo, para luego enviarlos a los otros servidores que se llaman Compute Nodes, los cuales trabajan en paralelo.

Debido a la arquitectura desacoplada de Almacenamiento y Cómputo, y al ser un servicio de Azure, SQL Datawarehouse puede cumplir con los siguientes:

  • Aumentar o reducir el tamaño del almacenamiento en forma independiente a los recursos de cómputo
  • Aumentar o reducir la capacidad del cómputo sin mover datos
  • Pausar la capacidad de cómputo dejando intactos los datos, y en consecuencia solo pagar por el almacenamiento
  • Reactivar la capacidad de cómputo durante las horas de operación  del negocio

Fig. 3 SQL Datawarehouse detalles de componentes

Control node: El Control node administra y es el encargado de optimizar los querys. Es la capa de presentación que interactúa con todas las aplicaciones y conexiones. En un SQL Data Warehouse, el Control node internamente no es otra cosa que una instancia de Azure SQL Database, y una vez que nos conectamos a él se puede ver que es lo mismo que una conexión a SQL Server tradicional. La diferencia es que el Control node coordina todo el movimiento de datos y el procesamiento requerido para ejecutar los querys en forma paralela sobre los datos distribuidos. Cuando se envía un query T-SQL a ejecutar,  el Control node lo transforma en querys separados para que puedan ejecutarse en paralelo en cada Compute Node.

Compute nodes: Cada Compute node es el músculo detrás del SQL Data Warehouse. Cada uno de éstos, son instancias Azure SQL Database que almacenan los datos y procesan los querys. Cada vez que se añade información,  el SQL Data Warehouse distribuye los registros en cada Compute node que posee la implementación. Estos Compute nodes son los que trabajan en paralelo para ejecutar cada query sobre la porción local de datos que posee cada uno. Luego de procesar, estos le pasan los resultados al Control node. Y para finalizar el Control node realizar las agregaciones de todas las partes para devolver el resultado final.

Storage: Toda la información es almacenada en Azure  Blob storage. Cuando los Compute nodes trabajan con los datos, estos escriben y leen directamente desde y hacia al blob storage. Debido a la característica de Azure storage que pude expandirse transparente y ampliamente, , SQL Data Warehouse hereda esta característica. Además, dado que el almacenamiento y el cómputo se encuentran separados, SQL Data Warehouse puede escalar el almacenamiento en forma independiente de escalar los nodos de cómputo y vice-versa (maximizando el costo y eficiencia de uso de la solución). Asimismo, Azure Blob storage es una solución de almacenamiento que es completamente tolerante a fallos, y automatiza el proceso de  backup y restore.

Data Movement Service: El servicio de Data Movement  (DMS) es el encargado de “mover” los datos entre los nodos. El DMS otoga a los Compute nodes acceso a los datos que necesitan para los joins y las agregaciones . El DMS no es un servicio de Azure, es un servicio de Windows que se ejecuta al lado del servicio de Azure SQL Database en todos los nodos.. El DMS es un proceso background que no puede ser accedido en forma directa. Sin embargo, se pueden ver los query plans y observar las operaciones del DMS, ya que el movimiento de datos es requerido normalmente para ejecutar un query en paralelo.

Resumen

Como hemos podido ver, SQL Datawarehouse es más que una sola caja corriendo un gran SQL Server, es una arquitectura distribuida y con el corazón en el servicio de DMS y el Control Node. Si bien existen ofertas de Hardware de DELL o HP para ejecutar esta arquitectura on-premises, el beneficio completo se ve en el servicio de Azure ya que a diferencia de on-premises se puede escalar y disminuir tanto la capacidad de cómputo como el almacenamiento, y en consecuencia se maximiza la performance y el costo al mismo tiempo.

Y desde mi perspectiva, el punto más importante es que toda la solución utiliza código T-SQL, lo que permite apalancar cualquier solución existente de SQL Server (con algún cambio menor obviamente) y utilizar la potencia de procesamiento en paralelo.

En las próximas series, veremos cómo aprovisionar un entorno de SQL Datawarehouse en Azure y como probar las distintas características del motor.

Links y Referencias

SQL DW: https://azure.microsoft.com/es-es/services/sql-data-warehouse/

Doc. Producto: https://docs.microsoft.com/es-es/azure/sql-data-warehouse/

TRIAL: https://azure.microsoft.com/en-us/services/sql-data-warehouse/extended-trial/?wt.mc_id=AID627566_QSG_SCL_183831&utm_source=t.co&utm_medium=referral