Reflexión entre estaciones...

Hola estimados lectores, tal como se los prometí no me tomé un año para mi próximo post, sin embargo, vuelvo con otra reflexión, todo comenzó el viernes 3 de abril, cuando estaba almorzando en Las Mercedes y debía ir a Los Ruices que es donde se encuentra el cliente.

El proyecto consistía en una Entonación OLAP, las consultas que se ejecutaban sobre un cubo de Analysis Services 2005 estaban muy pesadas, en esos casos, lo que toca hacer es ver no sólo la instancia de Analysis Services, sino, el modelo estrella o copo de nieve según sea el caso en el Storage Engine, al ir pensando en ello, las estaciones recorridas fueron: Chacaíto, Chacao, Altamira, Miranda, Los Dos Caminos, Los Cortijos.

De Chacaíto a Chacao: Lo primero que se debe evaluar en el Servidor, es el Sistema Operativo, la cantidad de RAM disponible, y establecer algunas características como la propiedad FastDetect del boot.ini (en Windows Server 2003) en /3GB, y /PAE (Phisical Address Extension) para que tome la cantidad máxima de memoria física instalada en el servidor.



De Chacao a Altamira: Por el lado de SQL Server se tiene la propiedad AWE Enabled (Address Windows Extension), pero esto solamente es posible cuando el SO es de 32 bits, porque en 64 bits no se presenta la limitante mencionada. ¿Y cómo se hace eso? A continuación la respuesta:



De Altamira a Miranda: En el servidor de Analysis Services, se debe hacer la misma actividad que se mencionó en el tramo Chacaíto-Chacao, con la diferencia de que no hay una propiedad como AWE Enabled (como con el Storage Engine ocurre) y por lo tanto al tratarse de una arquitectura de 32 bits, se tiene la limitante de trabajar solamente a 3GB de RAM, desaprovechando lo que se tenga de mas, ahí viene la recomendación de migrar a una arquitectura de 64 bits.

De Miranda a Los Dos Caminos: La FactTable del modelo estrella contenía más de 151 millones de registros, SI, LEYERON BIEN CIENTO CINCUENTA Y UN MILLONES, y pesaba alrededor de 46GB, la recomendación en este caso es colocarla en un File Group diferente a donde reside el resto de la data, y dicho File Group, en un arreglo de discos RAID 5 diferente al arreglo donde reside la data (esto cuando el presupuesto del cliente lo permita; segunda recomendación). Los File Groups se agregan por medio del siguiente menú:



De Los Dos Caminos a Los Cortijos: Mover la base de datos TempDB a un arreglo RAID 1, se recomienda este por encima del arreglo RAID 5 ya que en la presente BD solamente hay operaciones de escritura cuando un cubo es procesado o cuando un alto número de transacciones se ejecuta; tercera recomendación.

Mayor info en este link: http://msdn.microsoft.com/en-us/library/ms175527(SQL.90).aspx.

De Los Cortijos a las instalaciones del cliente: recibí una llamada donde me decían que el Website de SharePoint donde residían los reportes OLAP debe ser movido de servidor, y las recomendaciones me las tuve que guardar para la semana siguiente.

Saludos,

Nos vemos en el próximo post.

Después de casi un año...

Hola estimados lectores, después de casi un año, la reaparición es con un artículo de BI, y de qué manera... no hay nada técnico, simplemente 100% reflexivo.

Todo comenzó un día que no fue ayer, en un cliente al cual ya no estoy asignado, con un Portal de KPI’s desarrollado por alguien que no conozco.

La arquitectura de dicha solución era la siguiente:




Pero… Siempre tiene que haber un pero, esto era un diseño conceptual muy distanciado de la realidad, no porque no fuera esa la arquitectura, sino por la manera en la que se le dio vida a la misma y de ahí es que viene la reflexión. Inspirado en la obra de Oriana Fallaci “Carta a un niño que no llegó a nacer”, La División Technology Information Workers de CONSEIN presenta: “Documentación de un KPI que no se llegó a ver”.

#1) Proceso de Negocios: El enfoque inicial consistía en unas plantillas de Excel generadas con data de SOLOMON, las cuales pasaban a una BD, de ahí a un “Modelo Estrella” vía ETL y posteriormente al cubo. En estos escenarios hay que evaluar un aspecto, y es el ver si los datos provenientes de la hoja de Excel van a sufrir alteraciones una vez llegados a la BD (sumarización, desglose, actualización, etc.), de no ser así, por performance lo recomendable es llevar los datos directamente desde Excel al Modelo Estrella o Copo de Nieve, según sea el caso.

#2) Hechos y Dimensiones: En ese caso se manejaban como dimensiones Empresa, y Tiempo, lo que es perfectamente válido, y en la FactTable cada campo de la misma era un indicador. Pregunta: “¿y si se desea agregar un nuevo indicador?...” Respuesta: “Modificar el ETL y la FactTable”… ¡PLOP! En este contexto hay que manejarse con jerarquías y relaciones reflexivas, crear primero los indicadores átomos, y luego aquellos indicadores que dependan de otros.

#3) Nuevamente con los Indicadores: un indicador debe ser vinculado a una medida de un cubo, y luego con expresiones, calcular su valor, para finalmente asignarle un color de semáforo (rojo, amarillo o verde; o tipo termómetro si son más de tres las bandas), según los rangos que se establezcan, y dicho valor NO DEBE CALCULARSE al llenar la FactTable, esta recomendación viene dada por motivos de performance, ya que un cálculo muy complejo realizado vía T-SQL impactará negativamente sobre los tiempos de ejecución.

Finalmente, los cambios necesarios se hicieron, el proyecto culminó, el cliente quedó satisfecho, y CONSEIN salió por la puerta grande.

Bien... Estimados lectores, no me queda mas que despedirme y decir: nos en el próximo post, claro... no voy a esperar un año para ello. xD.

Saludos,

LeonelJ

Lo prometido es deuda!!

Tal como se los dije en el post anterior, en este hablaré de como invocar un paquete de SQL Server 2005 Integration Services, pero cuando el paquete está guardado en el Engine de SQL Server.

Paso #1 Importar el Siguiente Assembly

Microsoft.SqlServer.Dts.Runtime, para ello hay que agregar las siguientes referencias:

Paso #2 Importar las siguientes librerias:

using Microsoft.SqlServer.Dts;
using Microsoft.SqlServer.Dts.Runtime;
using Microsoft.SqlServer.Dts.Runtime.Wrapper;

El método a utilizar es Application.LoadFromDtsServer, que recibe (en este mismo orden) los siguientes parametros,

1) Nombre del Paquete -> de tipo String
2) Nombre del Servidor -> de tipo String
3) Eventos -> Clase Events, pero este parametro es opcional, en el ejemplo que se ilustra, se le envia el valor null.

public string EjecutarPaqueteSSIS(String NombreServidor, String NombrePaquete, int AlgunValor)
{
try
{
Microsoft.SqlServer.Dts.Runtime.DTSExecResult Results;

Microsoft.SqlServer.Dts.Runtime.Application app =
new Microsoft.SqlServer.Dts.Runtime.Application();

Microsoft.SqlServer.Dts.Runtime.Package package =
(Microsoft.SqlServer.Dts.Runtime.Package)
app.LoadFromDtsServer(NombrePaquete, NombreServidor, null);

Variables vars = package.Variables;
vars["NombreVariable"].Value = AlgunValor;

Results = package.Execute();

return Results.ToString();
}
catch (Exception ex)
{
return ex.ToString();
}
}

OK, y este es todo el camino para invocar un paquete de Integration Services 2005 guardado en el Motor de SQL Server.

Nos vemos en el proximo Post.

Saludos,

LeonelJ

Invocar un paquete de SQL Server Integration Services 2005

Algo que suele presentarse muy frecuentemente es el tener que invocar un paquete de SQL Server Integration Services por programación, en este caso yo seleccioné Visual C#, mi caballito de batallas, aquí se detalla un método, ideal para cuando se guarda el paquete como sistema de archivos (*.dtsx). En el proximo post mostraré como hacerlo si se guarda el paquete en SQL Server.

En primer lugar es necesario habilitar la caracteristica xp_cmdshell, ya que con ella se va a ejecutar el paquete con la utilidad dtexec, (Antiguo dtsrun en SQL Server 2000) como si se estuviera en la linea de comandos. Esta actividad se hace por medio del SQL Server Surface Area Configuration.



El siguiente paso es ir a "Surface Area Configuration for Features" y habilitar el caracteristica mencionada (xp_cmdshell):



La continuación es crear un Stored Procedure que haga uso de xp_cmdshell:

CREATE PROCEDURE usp_CorrerPaqueteSSIS
@Comando VARCHAR(8000)
AS
DECLARE @returncode INT
EXEC @returncode = xp_cmdshell @Comando
RETURN @returncode

OK, hasta aqui se tiene toda la estructura de ejecución, pero la gran pregunta: "Y que valor se le manda al parametro @Comando?"...

La Respuesta: una cadena que cumpla con la siguiente sintaxis:

dtexec /f "[Ruta del Archivo]" /De [Clave de Cifrado]

dtexec /f "C:\Pruebas\Paquete1.dtsx" /De Pa$$w0rd

/f indica que el paquete fue guardado en Sistema de Archivos

/De es el atributo que indica el password con el cual fue cifrada la data critica del paquete (El Password del Connection String)

Finalmente el codigo C# con el cual se llama al Stored Procedure, aclaro que este codigo no esta basado en las mejores prácticas, esto simplemente ilustra como invocar a usp_CorrerPaqueteSSIS:

private int InvocarPaquete(string Ruta, string Password)
{
int resultado;
string parametro = "dtexec /f " + Ruta + " /De " + Password;
string connStr =
"Server=(local); Database=Pruebas; uid=usuario; pwd=password;";
SqlConnection conexion = new SqlConnection(connStr);
conexion.Open();
SqlCommand comando = new SqlCommand("usp_CorrerPaqueteSSIS", conexion);
comando.CommandType = CommandType.StoredProcedure;
comando.Parameters.Add(new SqlParameter("@Comando", parametro));
resultado = comando.ExecuteScalar();
return resultado;
}

Un pequeño detalle, el usuario que se utilice en el connection string debe estar en el esquema "sys" de la base de datos, de lo contrario todo esto resultará en un SqlException.

Ya para finalizar con este post, si el paquete recibe parámetros (Variables, ó Variables Globales como se llamaban en SQL Server 2000), a la sintaxis del comando hay que agregarle lo siguiente:

dtexec /f "[Ruta del Archivo]" /De [Clave de Cifrado] /SET \package\DataFlowTask.Variables[User::NombreVariable].Value;Valor

La diferencia esta en el atributo /SET.

Nos vemos en el proximo post.

Saludos,

Leonel J

Migrar de SQL Server 2000 a 2005 con Detach y Attach!!

Hola estimado lector, en este pequeño post, se muestra como llevar una base de datos desde SQL Server 2000 a SQL Server 2005, a través de un Detach & Attach...

El siguiente script ya fue probado en una Virtual PC con Windows Server 2003 R2 SP1, SQL Server 2000 Developer Edition y SQL Server 2005 Developer Edition, la base de datos fue Stores

1) Correr desde SQL Server 2000 (Query Analyzer) el Stored Procedure sp_detach_db:

USE master;
GO
EXEC sp_detach_db @dbname = N'Stores';
GO


2) Crear en SQL Server 2005 la base de datos en activando la opción Atach, esto es un CREATE DATABASE común y corriente:

USE master;
GO
CREATE DATABASE Stores
ON PRIMARY
(FILENAME = 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\Stores.mdf') LOG ON (FILENAME = 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\Stores_log.ldf')
FOR ATTACH;
GO


3) Correr desde SQL Server 2005 el Stored Procedure sp_attach_db:

USE master;
GO
EXEC sp_attach_db @dbname = N'Stores',
@filename1 = N'C:\Program Files\Microsoft SQL Server\MSSQL\Data\Stores.mdf', @filename2 = N'C:\Program Files\Microsoft SQL Server\MSSQL\Data\Stores_log.ldf';
GO

Algo para tener en cuenta: Es ALTAMENTE recomendable (para no decir obligatorio, jejejeje) que se ejecute la sentencia DBCC UPDATEUSAGE, ya que algunas páginas (las tablas de SQL Server se componen de páginas), índices o particiones podrían quedar corruptas. Acá la documentación de ella: http://msdn.microsoft.com/en-us/library/ms188414.aspx, finalmente, para no tener problemas de inconsistencia con la metadata, se recomienda visitar este link, porque quizá (no siempre pasa, pero Murphy anda suelto) se tenga que crear nuevamente, ya que hubo cambio de versión en la DB. Acá la documentación: http://msdn.microsoft.com/en-us/library/ms187580.aspx

Ah, casi lo olvido, estas dos últimas tareas lo más recomendable es que la ejecute la figura del DBA.... Nadie conoce el servidor de bases de datos mejor que el :-)

Saludos,

Nos vemos en el proximo Post!!