Diario de SQL Server

PowerShell, el poder

Escrito por qwalgrande 27-02-2010 en General. Comentarios (0)

Aunque desde hace tiempo me llama la atención, nunca he podido meterme con PowerShell para SQL Server. Esta semana he empezado, he hecho tres cositas bajadas de internet en su mayor parte y me he quedado boquiabierto. Mira que me habían dicho que con PowerShell, lo que quieras, pero aún así hasta que no lo ves por ti mismo no empiezas a comprender ese poder.

 

Os dejo aquí mi "Hola, mundo", que no es más que un script que te permite, a su vez, crear un script de sql server con todos los objetos de una base de datos, algo que ha surgido un par de veces en el foto esta semana. Este sería el script:

 

 

# Script all tables in the AdventureWorks2008 database
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SqlServer.SMO") | out-null
 
$s = new-object ('Microsoft.SqlServer.Management.Smo.Server') $args[0]
$db = $s.Databases[$args[1]]
 
$scrp = new-object ('Microsoft.SqlServer.Management.Smo.Scripter') ($s)
 
$scrp.Options.AppendToFile = $True
$scrp.Options.ClusteredIndexes = $True
$scrp.Options.DriAll = $True
$scrp.Options.ScriptDrops = $False
$scrp.Options.IncludeHeaders = $True
$scrp.Options.ToFileOnly = $True
$scrp.Options.Indexes = $True
$scrp.Options.WithDependencies = $True
 
$scrp.Options.FileName = $args[2]
 
$scrp.Script($db.Tables)


 

 

Este texto, copiado a un notepad, guardado con un nombre y extensión ".ps1", por ejemplo "CreateTables.ps1", guardado en una carpeta C:\Scripts.

 

Para llamarlo, hay que abrir la consola de PowerShell (por ejemplo) y tras posicionarse en la carpeta en la que alojamos nuestro script (en el ejemplo, "cd C:\scripts"), ejecutarlo, pasándole los tres parámetros (servidor, base de datos y nombre y ruta del fichero que queremos generar:

 

.\CreateTables.ps1 'NOMBRE_INSTANCIA' 'BASE_DE_DATOS' 'C:\Scripts\BASE_DE_DATOS.sql'

 

Como decía, es mi modesto "Hola, Mundo". Los límites, pues pocos, muy pocos.

 

Integration Services: En casa del herrero...

Escrito por qwalgrande 15-02-2010 en General. Comentarios (0)

Si antes digo que SSIS es un gran desconocido, que aún nos colean DTS de SQL Server 2000 por ahí, antes me topo con dos de ellos... Y voy a contar la experiencia porque pone bien a las claras hasta qué punto se conservan estructuras antiguas sin razón aparente con un coste más que aparente.

 

Me pide un compañero del equipo de desarrollo que, por favor, le pase las consultas que se ejecutan en un DTS dado, que lo hizo hace ya tanto que ni sabe lo que hace. Ahí me acuerdo por primera vez del post de ayer.

 

Voy a mirarlo. Efectivamente, es un DTS que se almacena en un servidor que es SQL Server 2005, pero que se ejecuta en una máquina secundaria, con una tarea programada, debido a que este servidor es de 64 bits (pregunta retórica 1: ¿cómo es posible que la herramienta ETL de SQL Server 2000 no funcionara en un motor de 64 bits?). Para ver el DTS tengo que encontrar una máquina que tenga el cliente de SQL Server 2005 y las herramientas de compatibilidad.

 

En mi equipo (faltaría más) no tenía ni tendré instaladas las Backward compatibility tools de 2005. Busco otro equipo, pero sin suerte, y al final, le pido a un colaborador que lo mire en su equipo. Simple como el asa de un cubo, el DTS consiste en una sentencia de borrado y en un volcado posterior de DB2 a SQL Server. Y cuando pretendo ver la sentencia del volcado y en qué tabla se vuelca, me sorprende un horrendo error no controlado que me lo impide.

 

El error se debe a la falta del driver ODBC para la conexión con DB2. Así que intento dar un rodeo: migrar el DTS a DTSX. Si total, desde hacía ya mucho rato tenía más que claro que lo iba a hacer, pues así ya empiezo. La migración se ejecuta como la seda y me las prometo muy felices  mientras se abre el Visual Studio. La cruda realidad me muestra un dtsx de mentira, ya que sólo es una caja con una tarea de ¡ejecución de DTS que no puedo ver porque me arroja el mismo error que al principio!

 

Así que tengo que buscar una máquina que tenga el cliente de SQL Server 2005 y el driver de ODBC para DB2, en la que instalarle las Backward Compatibility tools. Tras tanto rodeo, ya sí, consigo ver que la sentencia era la recarga de los datos recién borrados en el otro paso que tenía el DTS.

 

En resumen, unos treinta minutos para ver un DTS que no se tarda en hacer ni tres minutos. Como para dejarte alguna duda sobre si ese DTS verá otro lunes...

 

Integration Services, ese gran desconocido

Escrito por qwalgrande 14-02-2010 en General. Comentarios (1)

Parece mentira que más de cinco años después de su aparición de Integration Services siga siendo frecuente tropezarnos con algún DTS. Los DTS, una herramienta potente sin duda. Pero para mí, Integration Services es casi como la invención de la imprenta, en comparación, con lo que los DTS quedaron como una rémora, algo para ser migrado y desaparecer.´

 

Pues los hay. Y muchos. Duermen el sueño de los justos con el argumento de la falta de tiempo para su migración... Excusas.

 

Y otra excusa: "Los DTS los domino, pero Integration Services...". Desde luego, no se puede pretender realizar una transformación compleja con Integration Services de un día para otro. Pero hacer lo que se hace con un DTS, sí que se consigue en un día. A lo sumo en dos.

 

Cuando además, eso es sólo una pequeña parte de lo que se puede lograr con Integration Services, que cubre la totalidad de los procesos ETL y carga de un data warehouse. Hay numerosos procesos de negocio que se pueden optimizar notablemente con el empleo de un dtsx. De hecho, casi cualquier cosa que precise cruzar datos de dos servidores es un candidato a ser un dtsx.

 

Y una vez que empiezas a trabajar con ello, te documentas y coges algo de soltura, rápidamente comienzas a sacarle una pequeña parte de aquello que se puede conseguir... que es casi cualquier cosa.