Diario de SQL Server

General

Vea el cubo medio lleno

Escrito por qwalgrande 06-06-2011 en General. Comentarios (1)

 

No todos los días publica un amigo un libro, y si estamos hablando de Salva Ramos y su nuevo libro de Analysis Services "Vea el cubo medio lleno", ya pasamos a palabras mayores.

 

http://www.sqlserversi.com/2011/06/libro-microsoft-business-intelligence.html

 

Y eso no es todo, encima es gratis. Es un regalo, así que muchas gracias, Salva.

 

 

Contadores con gestión de huecos

Escrito por qwalgrande 29-05-2011 en General. Comentarios (1)

 

Hace unos meses publiqué un hilo en que se exponía cómo obtener un contador sin hacer uso de un identity.

 

Vamos ahora a ampliar un poco uno de esos mecanismos para añadirle una gestión de huecos. La idea consiste en contar con un procedimiento almacenado que dé de alta los huecos cuando estos se produzcan (por el motivo que sea). Y luego, en el procedimiento del contador, consumir esos huecos si existen. Este sería el procedimiento para el alta de huecos, el de obtención del contador que usa huecos y las tablas implicadas. Al final se incluyen unos ejemplos de llamada.

 

 

CREATE TABLE [dbo].[CONTADORES](

                [ID] [smallint] IDENTITY(1,1) NOT NULL,

                [DES_TABLA] [varchar](255) NOT NULL,

                [NUM_ID] [int] NOT NULL,

 CONSTRAINT [PK_CONTADORES] PRIMARY KEY CLUSTERED

(

                [ID] ASC

))

 

GO

 

CREATE TABLE [dbo].[CONTADORES_HUECOS](

                [ID] [smallint] IDENTITY(1,1) NOT NULL,

                [DES_TABLA] [varchar](255) NOT NULL,

                [NUM_ID] [int] NOT NULL,

                [IND_ESTADO]  [bit] NOT NULL default (1),

 CONSTRAINT [PK_CONTADORES_HUECOS] PRIMARY KEY CLUSTERED

(

                [ID] ASC

))

 

GO

CREATE NONCLUSTERED INDEX [IX_CONTADORES_HUECOS_A1] ON [dbo].[CONTADORES_HUECOS]([DES_TABLA], [IND_ESTADO])

GO

 

--Para los huecos

CREATE proc [dbo].[p_NuevoHueco]

                @pTable_Name varchar(255),

                @pId int as

set nocount on

 

declare @ret int

 

insert CONTADORES_HUECOS (DES_Tabla, NUM_Id) values (@pTable_Name, @pId)

--Control de errores

select @ret = @@error

if @ret <> 0 

 begin 

  raiserror('Error en la inserción del hueco.', 1, 16) 

  set nocount off 

  return @ret 

 end 

 

set nocount off

return 0

GO

 

--Para obtener los identificadores

CREATE proc [dbo].p_GetID

                @pTable_Name varchar(255),

                @pNewId int OUTPUT as 

set nocount on 

 

declare @ret int

 

--Se intenta obtener un hueco, en caso de que exista

if exists(select DES_Tabla from CONTADORES_HUECOS where DES_Tabla = @pTable_Name)

                begin

                               set rowcount 1

                               --Se reserva el hueco a la vez que se toma el ID

                               update CONTADORES_HUECOS set @pNewId = NUM_ID, IND_Estado = 0                            

                               where DES_Tabla = @pTable_Name and IND_Estado = 1

                               set rowcount 0

                               --En caso de que no se capture un id porque otro proc lo haya pillado desde que se hizo la comprobación hasta que se lanza el update,

                               --se llama recursivamente al proc de obtención de id, se llama al propio procedimiento almacenado.

                               if @pNewId is null

                                               begin

                                                               exec @ret = pau_CON_CONTADORES_GetId @pTable_Name, @pNewId OUTPUT

                                                               return @ret

                                               end

                               else

                                               begin

                                                               delete CONTADORES_HUECOS

                                                               where DES_Tabla = @pTable_Name and NUM_ID = @pNewId

                                               end

                end

--Se consulta si el contador para la tabla  ya existe en Contadores 

else if exists(select DES_Tabla from Contadores where DES_Tabla = @pTable_Name) 

 begin --Si ya existe, se obtiene el siguiente valor del contador. 

  update Contadores set @pNewID = NUM_ID = NUM_ID + 1 

  from Contadores 

  where

                               DES_Tabla = @pTable_Name

 end 

else 

 begin --Si no existe, se inserta el nuevo valor 

  select @pNewID = 1 

  insert Contadores (DES_Tabla, NUM_ID)

                values (@pTable_Name, @pNewID)   

 end 

 

--Control de errores 

select @ret = @@error 

if @ret <> 0 

 begin 

  raiserror('Error en la obtención de nuevo identificador', 1, 16) 

  set nocount off 

  return @ret 

 end 

 

set nocount off 

return 0

 

 

 

GO

 

 

--Ejecuciones:

DECLARE @RC int, @NuevoId int

EXEC @RC = dbo.p_GetID @pTable_Name = 'RECIBOS'  ,@pNewId = @NuevoId OUTPUT

select @RC as Resultado, @NuevoId as Identificador

go

select * from Contadores

go

--Insertamos un hueco, por ejemplo el 2, por un borrado en la tabla que usa el contador

EXEC dbo.[p_NuevoHueco] @pTable_Name = 'RECIBOS'  ,@pId = 2

 

GO

 

--Consumimos el hueco

DECLARE @RC int, @NuevoId int

EXEC @RC = dbo.p_GetID @pTable_Name = 'RECIBOS'  ,@pNewId = @NuevoId OUTPUT

select @RC as Resultado, @NuevoId as Identificador

go

select * from Contadores

Un DBA a merced de los vientos (2 de 2)

Escrito por qwalgrande 30-04-2011 en General. Comentarios (0)

 

Seguimos y concluimos aquí con esta serie "Un DBA a merced de los vientos". En el capítulo anterior (http://qwalgrande.blogspot.es/1303315380/un-dba-a-merced-de-los-vientos-(1-de-varios)/), comentamos los primeros tres puntos (enfermedad, almacenamiento y services packs). Continuamos para bingo:

 

4.- La monitorización no monitoriza. Es el dicho "ojos que no ven, corazón que no siente" el que mejor resume este punto. Lo que pasa es que no sentirlo, en este caso, no ayuda mucho, porque si hay un problema y no te enteras el primero, debido a que la monitorización implementada no es eficaz, te acabas enterando porque alguien te avisa (un usuario con incidencias), cuando repasando alguna otra cosa tropiezas con el problema y, en general, tarde y a contrapié. Y una vez que el primer problema pasa inadvertido, lo siguiente es la angustia. ¿Se habrá caído de nuevo y no me he enterado? El sistema de monitorización acaba por ser nuestra propia persona que se conecta día y noche a mirar si aquello sigue vivo, con lo que el que seguro que no vive es uno mismo. Es un tema crítico y tengo la sensación de que no se le da la importancia que tiene. Bien es cierto que implementar este tipo de soluciones de monitorización global, tipo SCOM, Patrol, Open View, requiere de dinero, porque son caras, y de tiempo, porque cuesta afinarlas y dominarlas. Este handicap puede hacer desistir de su implementación o de su correcta implementación a veces.

Cuando menos, tenemos que cubrirnos las espaldas de manera artesanal, desde el propio servidor de bases de datos o desde otro. No sé, lanzar un ping cada X minutos con un job. La última que he tenido que implementar es para saber si en un cluster se había producido un failover, lo dejo a modo de ejemplo ilustrativo.

 

select Nodo_Cluster = serverproperty('ComputerNamePhysicalNetBIOS'), Arriba_Desde = create_date from sys.databases where name = 'tempdb'

 

En general, son cosas sencillas de montar para que podamos dormir un poco más tranquilos.

 

Luego está el caso justo al contrario, que recibamos muchas alertas hasta el punto de ignorarlas, las pocos importantes y las muy importantes camufladas entre las que no lo son. O que el problema sea por falsas alarmas. Esto es peor incluso, porque recibes el aviso, pero lo ignoras, ni siquiera te queda la excusa mental de culpar al sistema de monitorización. Lo ideal es recibir los avisos en su justa medida, a ser posible muy pocos, para que cuando lleguen, sepamos que algo pasa. Lleva su esfuerzo, pero lo contrario es estar ciego y sordo.

 

5.- El desarrollador virtuoso. Una de las misiones de un DBA consiste en intentar mantener dentro de cierto orden lo que tiene lugar dentro de la base de datos. Para ello, uno diseña unas reglas de pasos a producción, vigila el seguimiento de unas buenas prácticas en el desarrollo y en general, persigue (triste es, sin duda) que el equipo de desarrolladores no haga más burradas de las tolerables. Dentro del variopinto conglomerado de programadores, tenemos una figura especialmente peligrosa. Se trata del "desarrollador virtuoso", como le he denominado. Se trata de buenos profesionales, que aprenden mucho y rápido, captan los mensajes y son capaces de llevar a cabo con éxito los desarrollos algo más complicados. Hasta ahí, bueno, estupendo, suena muy bien. Lo malo es que suelen dejarse tentar por el lado oscuro, intentan ir más allá, con buenas intenciones, y es frecuente que se extralimiten, generando monstruitos de código que incluso a ellos mismos les cuesta desentrañar. Cuando aquello es ingobernable, entonces te llaman porque no consiguen rizar el último rizo. Y ahí descubres lo que hay, horas o días de trabajo que no hay quien comprenda. ¿Qué hacer en esas circunstancias? Lo primero, armarse de paciencia.

 

Lo siguiente es la pedagogía. Hay que mirar el lado bueno, cuentas con un recurso capaz de exprimir el código, así que es una fuerza que, debidamente orientada, será muy beneficiosa. Digo que lo siguiente es la pedagogía porque hay que hilar fino para reconducir la situación de forma que se consiga que el individuo programe de forma brillante, a la vez que suficientemente simple como para que lo entienda el resto del planeta, todo ello en un tono constructivo. Una estrategia pasa por hacerle ver que hay que mirar por el coste de mantenimiento del código, que cualquiera debe entender y, si llega el caso modificar ese procedimiento o función. Referencias a que o lo hace más simple o no volverás a irte de vacaciones porque no hay quien pueda mantener aquello salvo tú, también tienen su impacto. Es difícil contener el talento, pero encomendarle las tareas más complejas, valorándolo en su justa medida, también alentará al desarrollador virtuoso en la línea que pretendemos que siga. Y mucho ojo, lo que personas de este perfil hagan bien, te ahorrará mucho trabajo (porque no tendrás que ser tú quien haga lo más difícil), y del mismo modo, lo que no hagan de una forma productiva, te penalizará enormemente, porque serás tú quien deba rehacerlo. Y eso es malo en todos los sentidos, por el tiempo que requiere, por lo tenso de la situación que se genera. Recuerdar, persona brillante a la que se le echa por tierra su trabajo, difícil para un ego subido, que choca con otro carácter altanero (el de uno mismo). Eso es viento huracanado en contra.

 

Otra precaución a tomar para protegerse de estos comportamientos consiste en dosificar las enseñanzas que se transmiten. Suena un poco burdo, pero hay que tener en cuenta que cuantas más armas tengan estos virtuosos, peor. El día que descubren lo que es una CTE o las funciones PIVOT, sus posibilidades se incrementan exponencialmente.

 

6.- Copy & Paste. Este es un tema que ya he tocado alguna vez antes, así que no me extenderé mucho. Uno aporta una solución a un problema concreto y luego eso mismo se extrapola a situaciones que nada tienen que ver, con el agravante de "si me dijiste tú que lo hiciera así". Para este vicio, muy poco se puede hacer, salvo revisar el código detenidamente. También es práctico ir dejando la huella de uno en lo que se hace. De esta forma, uno puede detectar más fácilmente las "reproducciones no autorizadas". Y no hay que resquebrajarse mucho la cabeza para ello. Por ejemplo, si uno pone en el filtro del where algo no habitual, pero absurdo, como "where 'Copy' <> 'Paste' and … ", dudo mucho que haya alguien que copie, pegue, y luego elimine tu "firma".

 

7.- Las prisas. Una de topicazos. Nunca hay tiempo para hacerlo bien, pero siempre hay tiempo para hacerlo dos veces. Este punto aplica a cualquier proyecto de desarrollo de software, lo que incluye a SQL Server y al trabajo de un DBA. Y por desgracia estamos tan habituados a ello como a hacer horas de más, nos parece normal cuando sólo es lo habitual, con lo que hay veces en las que se pierde la perspectiva. Existiendo numerosas tecnologías de desarrollo, como Agile, SCRUM, etc., elegimos, o más bien, nos eligen siempre la metodología ASM, A Salto de Mata, término que yo obtuve del Maestro Miguel Egea.

 

¿Y por qué? Porque la primera vez lo hicimos y generamos la sensación de que era posible, cuando no es así, el olmo no va a dar siempre peras, nos comemos ese retraso y vamos a la carrera y como pollos sin cabeza, con lo que los errores se multiplican, y lo que en un principio se hace para salir del paso, se encalla ahí para siempre, aún sabiendo que está mal hecho. Así que salvo que seas un mal torero, las prisas no son buenas y descuidar las pruebas, realizar las cosas a deshora cuando uno ya no está fresco como para pensar con claridad y todas esas cosas que ya sabes que no debes hacer, pero que aun así haces, conllevan muchísimo riesgo. La presión se libera, pero sólo a corto plazo, ganar tiempo es la excusa, pero es hacerse trampas al solitario. Todos hemos tenido que pasar por situaciones en las que el jefe, como un niño en un viaje largo, pregunta cada diez minutos "¿Falta mucho?", y generalmente ese que lo pregunta también lo vivió en el pasado, así que es muy posible que entienda que las cosas llevan su tiempo y que preguntar más, lejos de reducir el tiempo que se requiere, lo aumenta. Además, ese requerimiento que surge sin saber cómo y que tiene que estar para ayer, generalmente, como viene se va, de hecho no suele ser importante. Teniendo en cuenta las circunstancias, hay que intentar contemporizar.

 

Luego, existe un caso concreto en el que no merece la pena, ni por asomo, correr riesgos, como son los sistemas de reporting o data warehouse. En una urgencia, lo normal es meter la pata, generar información incorrecta y perder el prestigio que da la fiabilidad, ganado durante meses, y que puede marcharse en una mala madrugada. Así que, frente a las prisas, ante todo mucha calma.

 

8.- PEBKAC. Siglas de "Problem Exists Between Keyboard And Chair", que significa que el problema está entre el teclado y la silla. Todos cometemos errores, y nuestro trabajo es evitarlos y/o corregirlos, pero en este caso me refiero, no a los de los demás, sino a los propios, que son los que más nos descoloran. Los ajenos, bueno, acostumbrados estamos a ellos, los asumimos como un gaje más del oficio. Pero los de uno mismo, eso ya es otro cantar. En la mayoría de los casos se resumen en una palabra: autoconfianza. Para terminar, el peor enemigo, uno mismo y nuestra propia creencia de infalibilidad, falsa por supuesto, lo que se agrava por no tener a nadie que nos audite, la mayor parte de los casos. Además chocamos con la propia soberbia y una absurda sobrestimación de la memoria. ¿Por qué no apuntamos las cosas?

 

Una receta muy simple para evitar que nuestro poder ilimitado nos lleve a errores infantiles consiste en aplicarnos a nosotros mismos las reglas y procedimientos que exigimos a los demás, esto es, realizar pruebas unitarias, documentar los procesos, etc. Otro buen mecanismo consiste en trabajar con un login de SQL Server que no sea plenipotenciario, de tal forma que si, por un casual, confundimos un entorno con otro y lanzamos un update sin where, obtengamos un error de permisos, en lugar de un "22.000.000 rows affected". El mejor de los remedios, la modestia, está fuera del alcance de la mayoría de los DBAs y desde luego del mío. Pero bueno, también somos pesimistas y hacemos backups, por lo que a las malas, aunque metemos la pata, somos los que luego desfacemos el entuerto.

 

Pongo aquí el final a esta recopilación, si bien es cierto que cabrían otra muchas más situaciones en las que nos vemos desprovistos del poder de controlar lo que pasa a nuestro alrededor.

 

 

Un DBA a merced de los vientos (1 de varios)

Escrito por qwalgrande 20-04-2011 en General. Comentarios (1)

 

En estas últimas semanas, en las que la naturaleza, a base de terremotos y tsunamis, ha puesto en su sitio a un hombre que la desafía con centrales nucleares, hemos vuelto a oír una frase más propia de una aventura de Homero, que del siglo XXI:

 

"Si los vientos nos son propicios…"

 

Pues sí, en esas estamos, es una desgracia, pero es lo que hay, y es sinónimo de la más completa pérdida del control de una situación.

 

Llevándolo al mundano plano de la vida de un DBA, son un buen montón de situaciones las que nos dejan así, a merced de los vientos, confiando en que la fortuna. Los hay que hasta rezan o hablan de ponerle velas a los santos. Y desde luego que uno puede hacer mucho por detectar el golpe y minimizar los daños, pero vamos, ni por ésas. Voy a poner una de esas situaciones en las que eso ocurre y qué puede hacer uno para prepararse ante esas circunstancias, además de aceptarlas con resignación.

 

1.- Enfermar. Es evidente que es algo que no está en manos de uno, aunque una vida y hábitos saludables influyen mucho. Lo curioso es que a mí en concreto, que llevo una mala racha importante, me dicen "Alberto, tienes que comer más", a lo que yo no respondo, pero pienso "Y trabajar menos". Cuando vas teniendo una edad que empiezan a parecer dos, hay que cuidarse más. Porque, aunque no sé aún cómo y sólo tengo pruebas empíricas, los sistemas SABEN CUÁNDO ESTÁS DÉBIL, y lo aprovechan, lo huelen como dicen que los perros huelen el miedo.

El caso es que una vez que enfermas, sólo queda confiar en el resto del equipo te respalde, porque tendrás que combatir en inferioridad de condiciones, algo que por otra parte no debe impedir nuestra victoria, siguiendo con nuestra filosofía "Always On". Ojo, también saben cuándo enferman las personas de tu entorno familiar, así que no basta con comer una manzana al día, procura que tu equipo pueda respaldarte y sepa cómo. Fórmales, documenta (sí, ya, y la luna), oblígales a llevar ellos una vida saludable también y, sobre todo, pide refuerzos.

 

2.- El almacenamiento. Ahora que estoy en un, como siempre traumático, procedimiento de cambio de almacenamiento (cambio de tecnología, marca, modelo y todo lo demás), me viene a la mente el símil de los coches. Hace unos años, cualquiera que fuera un poco mañoso, no es mi caso, sabía cómo reparar un embrague, así como otra serie de averías menores. Ahora, sólo hay un tipo de avería: fallo en la electrónica. Hay que llevarlo a un taller para que lo miren, no gratis. Molesta porque lo que allí hacen parte de conectarse al coche por una especie de puerto USB, para que una aplicación muestre en pantalla "Error -998: Embrague defectuoso". Pero claro, tú no tienes ese cable ni ese software tan estupendo. Evidentemente no es así, pero imagino que no ha de ser muy diferente.

Con las cabinas cada vez me veo más en esa línea. No es que nunca haya entendido mucho, pero uno podía decir "RAID 1 para el log, RAID 5 para el data". Ahora no, ya todo son "especies de RAID megacomplejos y supereficaces". Lo que tenemos, o al menos a mí me lo parece, son enormes cajas negras en las que uno no tiene ni un triste log de errores normal que mirar. Hay que llamar al "experto" de la casa siempre. Lo de las comillas no es casual. Antes sabías que los discos se rompían y bueno, tenían que romperse dos discos para perder datos. Si bien la ruptura de uno podía provocar la del espejo, había a qué agarrarse. Ahora, no pasa nada, puedes perder bandejas de discos enteras y ni enterarte. Sólo te enteras de que el servidor de bases de datos dejó de ver los discos, no uno ni una bandeja, todos, por "errores oscuros que sólo el experto conoce", algo que pasa, y mucho, a pesar de que te perjuran de que es imposible para, justo después y rápidamente, reconducir a "el Windows". Oh, qué gran excusa, ¿por qué no se me habrá ocurrido a mí eso? ¿Y por qué todos los técnicos de almacenamiento dicen "el Windows", en un tono despectivo? ¿Hacen lo mismo cuando el sistema operativo es Unix, dicen "el Unix"? Tendrían que tratarle con más cariño, ya que es el comodín que les queda, al menos conmigo. Su otra baza es "el SQL", pero ahí a mí no me pillan nunca, porque SQL Server sí suele dejar datos reveladores de las circunstancias que le suceden. El resumen es que, al menos yo, sólo puedo confiar en que no le pase muchas veces, porque cada vez que pasa estoy vendido.

Sobre las cosas que podemos hacer frente a este tipo de circunstancias, están apuntar las cosas en un cuaderno y no en discos, o si no, dado que la comprensión se antoja quimérica, al menos llegar a un punto de conocimiento de los problemas típicos que puedan sucederle al almacenamiento para poder reaccionar de una forma ágil (antes de que volvamos a cambiar de cabinas). Por supuesto, toma datos y guárdalos (estadísticas de esperas, contadores de rendimiento, etc.), porque hará falta justificarse ante esas imposibles cosas que suceden y que tan claramente dejan registrados tus propios logs. Frente a los técnicos de almacenamiento, todavía no tengo ni remedios paliativos ni vacuna. Quizá sea como ante la radiación, la única protección válida son las barreras físicas. Y bueno, otra opción es conseguir que sea el problema de otro, es decir, pasarse a SQL Azur, si bien ahí tienes limitaciones tales, en cuanto a tamaño esencialmente, que quizá sea un pelín pronto. Con 50 Gb por base de datos, poco margen de migración existe si tenemos un sistema de cierta entidad entre manos.

 

3.- Los service packs y otros parches de sistema operativo. (n.a.: El traductor ortográfico me ha sustituido "los services packs" por "los serviles pacos". ¿Alguien puede reproducir ese comportamiento?). Cada vez que toca instalar un service pack en un servidor crítico, me acongojo. La situación suele ser también de salto al vacío. No hay nada que invite a pensar que algo puede ir mal, pero de hecho pasa. No suelen ser tampoco errores catastróficos, sino sutilezas, normalmente un permiso extraño, una política que cambia, un valor por defecto que no se modifica. Suficientemente oculto como para que las pruebas en entornos no productivos no lo saquen a la luz. Suficientemente leve como para que no se decida dar marcha atrás y desinstalarlo (¿y venir otro sábado? Uff, no, eso lo penúltimo). Pero podrá torturarte durante meses. Prestad especial atención a los service packs recién salidos del horno, que pueden salir rana. La última vez (SP1 de W2K8 R2) piqué como un borrego. Yo pretendía ponerlo antes de pasar un servidor a producción por ahorrarme el malísimo trago. Por circunstancias no se pudo instalar y justo la misma semana se publicó que venía con taras.

La forma de esquivar estas eventualidades pasa por contar con entornos de testing similares a los productivos y usarlos. Ponerlos en los entornos de pruebas en ocasiones puede ayudar, siempre que se usen y se parezcan al entorno de producción. Digamos que es el mínimo. Otras precauciones, no muy útiles normalmente, son hacer una pequeña búsqueda por internet para ver qué problemas ha planteado el service pack en otros entornos o abrir un prewarning con MS. En cualquier caso, sobre todo con los parches de seguridad, es mayor el riego de no poner los parches que el de ponerlos. La instalación de los service packs sí quizá requiera de algo más de preparación y meditaciones.

 

Como esto en vez de un post empieza a parecer una tesina, voy a dividirlo en varios. Seguiremos con el punto 4, la monitorización no monitoriza.

Agenda PASS Spanish Group – Primer semestre 2011

Escrito por qwalgrande 04-04-2011 en General. Comentarios (0)


A continuación os detallo la agenda de los diversos Webcasts que impartiremos desde PASS Spanish Group en el primer semestre de 2011. Todos ellos se impartirán en directo el día indicado a las 19:00 (GMT+01:00, Madrid, París). También os incluimos el link de registro para cada uno de ellos. Esperamos que os resulten interesantes.

 

Cómo funciona el Query Optimizer

Descripción: Esta sesion describe cómo funciona el Query Optimizer y los pasos más importantes que SQL Server ejecuta desde que recibe un query hasta que un plan de ejecución es generado.
Ponente: Benjamín Nevarez

 

Cómo gestionar eficientemente las BBDD de una instalación Sharepoint 
Descripción: En esta sesión analizaremos los aspectos fundamentales que debemos de tener en cuenta a la hora de desplegar un entorno de SharePoint 2010, desde el punto de vista de un DBA de SQL Server. 
Ponente: Antonio Soto

 

Optimizando procesos ETL con Integration Services

Descripción: Sesión práctica donde se verán diversos paquetes de Integration Services en los que se utilizan buenas prácticas de diseño y optimización de los paquetes aplicadas a cargar tablas de staging, de dimensiones y de hechos, obteniendo trazabilidad de todo lo ocurrido.

Ponente: Salvador Ramos

 

PASS, asociación de profesionales

 Descripción: Las siglas PASS significan asociación de profesionales de SQL Server. No es sólo SQL Server, estamos hablando de una profesión, la de administrador y/o desarrollador de bases de datos, un oficio apasionante pero duro, estresante y muy exigente en ocasiones. Y es una asociación en la que buscamos colaborar entre todos.

Ponente: Alberto López Grande

 

Desplegando datos Geo Espaciales en Reporting Services 2008 R2

Descripción: Uno de las mejores características que tenemos en la nueva versión de SQL Server (2008 R2) es poder generar reportes de nuestros datos Geo-Espaciales sin necesidad de comprar herramientas especializadas.
Ponente: Jesús Gil

 

¿Nuestra solución de SSAS va lenta? Comenzando con la optimización de Analysis Services 2008 
Descripción: Cuando nuestro requisito principal es analizar nuestra información de la forma más rápida posible es cuando entra en juego la utilización de buenas prácticas dentro del modelo multidimensional.
Ponente: Rubén Pertusa