Mostrando entradas con la etiqueta SQL Server 2005. Mostrar todas las entradas
Mostrando entradas con la etiqueta SQL Server 2005. Mostrar todas las entradas

martes, 13 de abril de 2010

Recuperar las tablas y los procedimentos de una base de datos

Hola,

Hoy algo facilitio y rápido, como recuperar las tablas que hemos creado y los procedimientos en una base de datos:

SELECT * FROM information_schema.routines order by SPECIFIC_NAME

select * from information_schema.tables

Fácil, no?

Saludos


lunes, 22 de diciembre de 2008

SQL Server 2005: crear tabla con datos

Hola de nuevo,

Hoy me tiro a la piscina y escribo una entrada sin estar muy seguro de lo que escribo :-P

Yo recuerdo que en Sql Server 2000 se podía crear un script que me generaba la base de datos con las tablas y los datos. En Sql Server 2005 no he encontrado esa opción por ningún lado y si alguien me sabe decir como se hace de una forma rápida se lo estaré eternamente agradecido.

El caso es que como me he empeñado en hacer eso he perdido parte de mi tiempo buscando y preguntando al señor Google y al final lo he conseguido siguiendo estos pasos (gracias a este post http://blog.sqlauthority.com/2007/11/16/sql-server-2005-generate-script-with-data-from-database-database-publishing-wizard/)

Para conseguir un script que me permita crear una base de datos con sus tablas y - lo más importante - sus datos es necesario descargarse de la web de MS la app "Microsoft SQL Server Database Publishing Wizard 1.1"

http://www.microsoft.com/downloads/details.aspx?FamilyId=56E5B1C5-BF17-42E0-A410-371A838E570A&displaylang=en

Esta pequeña duplicación es un asistente igual que los de Sql Server que me permite seleccionar una base de datos, sus tablas y la forma de exportar: Sólo Esquema, sólo datos o esquema y datos

Y como Gon es tu amigo... problema resuelto!

Salu2

miércoles, 20 de agosto de 2008

SSIS y ORACLE en plataformas de 64-bit

Hola a todos,

Hoy amiguitos os voy a contar una bonita historia sobre SSIS (SQL Server Integration Services) y Oracle en una plataforma de 64-bit a la hora de ejecutar unos jobs con el SQLAgent.

Resulta que haces un desarrollo en un entorno x86, crees que todo está perfecto y ¿sabes lo que pasa cuando lo llevas a producción en un entorno x64?... Exacto, que no funciona, que se producen errores y si no estás prevenido o encuentras la solución tu proyecto se puede ir rápidamente al traste.

Esto ocurre por lo siguiente:

En un entorno de 32-bits se instala BIDS(Business Intelligence Development Studio) de 32-bits, el cliente Oracle de 32-bits y DTEXEC (SQLAgent) de 32-bits. No hay problema.

Sin embargo, en entornos de 64-bits BIDS se instala de 32-bits (no hay versión de 64), Oracle de 64 y ya tenemos el primer problema. Primera solución: Instalar el cliente Oracle de 32 bit en la máquina de producción.

Pero esto provoca que cuando DTEXEC (de 64-bit) quiere ejecutar el ETL que llama al cliente Oracle (ahora de 32-bit) vuelve a fallas. HORROR!!!

La solución es no ejecutar con el SQLAgent SSIS directamente y utilizar CMDExec de 32-bits

Vaya lio, ¿no?

Venga, que con la información condensada es más fácil

- Instalar el cliente Oracle 10.2.0.1 versión de 32-bit

- Instalar el parche Oracle #4547817 (que actualiza a 10.2.0.2)

- Instalar el parche #5383042 (arregla el bug #3807408)

- Desarrollar con los paquetes con SSIS

- Ejectuar el ETL con CMDExec que usa la versión de 32-bit de DTEXEC (C:\Program Files(x86)\Microsoft SQL Server\90\DTS\binn). Próximamente en un post contaré como hacer esto y alguna cosa mas

Para terminar avisaros que los dos parches son de pago. Si, como lo lees, Oracle te hace pagar por arreglar un fallo en su aplicación, jajajaja. Y luego dicén de MS….

En fin, que a ver si con esto se solucionan vuestros problemas. Os dejo un link que me sirvió para ver la luz y poder hacer todo esto. Suerte!

http://portal.sqltrainer.com/2007/11/sql-server-integration-services-oracle.html

Salu2

martes, 1 de julio de 2008

10 best practices SSIS

En el post anterior he comentado algo sobre las 10 mejores prácticas de Integration Services. Via http://geeks.ms/blogs/elbruno/archive/2007/05/23/10-best-practices-para-sql-server-integration-services.aspx (el bruno) os indico cuales son:

  1. La Reutilización es una de las capacidades más aprovechadas dentro de SSIS. En otras palabras, podemos hablar de paquetes standards que pueden ser reutilizados en diferentes entornos de desarrollos ETL. Dentro de SSIS, esto puede lograrse utilizando templates. Los SSIS templates packages, son paquetes reutiilzables que pueden ser utilizados en cualquier proyecto una cantidad ilimitada de veces. Para más información consultar http://support.microsoft.com/kb/908018
  2. Es recomendavle evitar la utilización de puntos (.) en los nombres de los paquetes. La utilización de puntos se cruza con la nomenclatura de nombres que utiliza SQL Server y por lo tanto debe ser evitada. Un buen approach consiste en la utilización de guión bajo (_) en lugar de punto (.). Además es conveniente asegurarse que los nombres de los paquetes no excedan los 100 caracteres de largo. Durante el despliegue de los packages, los caracteres que excedan el largo de 100, serán quitados del nombre. Esto puede ocasionar que el SSIS package tenga errores durante el período de ejecucion, especialmente cuando se utiliza "Execute Package Tasks" dentro de otro paquete.
  3. El flujo de datos de en un paquete es una tarea intensiva para la memoria, en cada uno de los pasos y a nivel componente debemos revisar cuidadosamente que no estamos pasando columnas innecesarias en el flujo de datos. Esto ayuda en evitar tiempos adicionales del tiempo total de ejecución del paquete y adicionalmente mejora el funcionamiento total de la ejecución del paquete.
  4. Mientras se configura a cualquier conexion OLEDB como fuente, se debe evitar usar "Table or View" como el modo de acceso de los datos, éste es similar al "SELECT * FROM <TABLE_NAME>", y como la mayor parte de nosotros sabe, "SELECT *" es nuestro enemigo, esta sentencia toma en cuenta todas las columnas incluyendo las que incluso no se requieren. Intentar siempre utilizar el modo "SQL Command" como modo de acceso de los datos e incluir solamente los nombres de las columnas requeridas en la declaración "SELECT". De esta manera se evita pasar columnas innecesarias en flujo de datos.
  5. En los Data Flow Tasks, utilizar muy cuidadosamente el Flat File Connection Manager, crear un Flat File Connection Manager con la configuración por defecto utilizará el tipo de datos [DT_STR] por defecto para todos los valores de la columna. Ésta no es siempre la opción correcta porque porque puede existir algun tipo de dato numérico, número entero o columnas boleanas en la fuente, pasándolo como string en el flujo hacia abajo se utilizaría memoria innecesaria y puede causar cierto errores en las fases posteriores de la ejecución del paquete.
  6. El ordenar datos es una operación que consume mucho tiempo; en SSIS puedes ordenar los datos que vienen desde un componente superior utilizando un 'Sort transforming', no obstante esto es una tarea que consume mucha memoria y el resultado degrada el funcionamiento total de la ejecución del paquete. Como mejor práctica, en los lugares en donde sabemos que los datos están viniendo de las tablas de la base de datos SQL Server, es mejor realizar la operación de ordenar los mismos en motor de la base de datos utilizando una sentencia TSQL dentro del Query apropiado. Esto es mucho mejor porque el ordenamiento de datos en la base de datos es una tarea mucho mas refinada y depurada en SQL Server.
  7. Durante el desarrollo de los paquetes de SSIS, la mayor parte del tiempo uno tiene que compartir su paquete con otros miembros del equipo o uno tiene que desplegar el mismo paquete a cualquier otro desarrollador, UAT o entorno de producción. Una cosa que un desarrollador tiene que cerciorarse es utilizar el nivel correcto de la protección del paquete. Si alguien va con el nivel de la protección del paquete del defecto 'EncryptSenstiveWithUserKey' entonces el mismo paquete no pudo ejecutarse según lo esperado en otros ambientes porque el paquete fue cifrado con la llave personal del usuario. Para hacer la ejecución del paquete común a través de diferentes entornos, uno tiene que primero entender el comportamiento de la característica del nivel de la protección del paquete, es aconsejable leer http://msdn2.microsoft.com/en-us/library/microsoft.sqlserver.dts.runtime.dtsprotectionlevel.aspx. Generalmente, para evitar los errores mas comunes durante el despliegue de paquetes a partir de un sistema a otro sistema, fijar la protección del paquete a 'DontSaveSenstive'.
  8. Una buena práctica es utilizar Secuence Containers en paquetes de SSIS para agrupar diversos componentes en el 'Control Flow Level'. Esto ofrece_
    1. Proporciona un scope para las variables de un grupo de tareas relacionadas y de los contenedores que puede ser utilizado.
    2. Proporciona la facilidad para manejar las propiedades de múltiples tareas fijando la propiedad en el 'Secuence Container Level'
    3. Proporciona facilidad para definir el nivel de aislamiento de la transacción del sistema en el Container Level.
      Para más información sobre los envases de la secuencia, ver por favor http://msdn2.microsoft.com/en-us/library/ms139855.aspx.
  • Si estás diseñando una solución de ETL para una pequeña, media o grande parte del negocio de una empresa, siempre es bueno tener una característica que permita reiniciar los paquetes fallados a partir del punto de la falla. SSIS tienen una característica de fábrica llamada 'Checkpoint' para soportar el reinicio de paquetes fallidos desde el punto de la excepción. Sin embargo, es necesario configurar la característica del Checkpoint en el nivel del paquete. Para más información, ver http://msdn2.microsoft.com/en-us/library/ms140226.aspx.
  • Excecute SQL Task es nuestro mejor amigo en SSIS; podemos utilizar esto para ejecutar una declaración simple o múltiple de sentencias SQL a la vez. La belleza de este componente es que puede retornar resultados en diferentes formatos, por ejemplo: single row, full row set y XML. Puedes crear diversos tipo de conexiones usando este componente como OLEDB, ODBC, ADO, ADO.NET y SQL Mobile. Personalmente prefiero utilizar este componente la mayor parte del tiempo con mis sentencias FOR EACH para definir las iteraciones y verificar si ejecuto la tarea SQL. Para más información, ver http://msdn2.microsoft.com/en-us/library/ms141003.aspx y http://www.sqlis.com/58.aspx.
    1. Espero os sean de utilidad

      Salu2

      SSIS y Query Oracle con parametros

      O lo que es lo mismo "SSIS Query Oracle with parameters" :-)

      Escribo este post porque despues de pegarme mucho (muchiisimo) con SSIS (Integration Services) y Oracle para poder hacer una consulta en un OLEDBSource Task (Origen OLDB) con parámetros he conseguido encontrar la solución.

      Lo primero es crear una variable que contenga la consulta y tantas variables como parámetros. En propiedades indicar lo siguiente:
      - Evaluate as Expression en propiedades a True
      - Expression Property: "select xxx from xxx where job = '" + @[User::NbVariable] + "'"

      Por su parte el Origen OLDB lo configuraremos para que el access mode sea a SQL Command de Variable e indicaremos la variable definida anteriormente.

      Si pinchamos en vista previa veremos que nos devuelve los datos.

      el post que me ha ayudado.... http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=1530650&SiteID=17

      Curiosamente ademas es una de las 10 best practices

      Proximamente comentaré algo sobre ejecutar un paquete de SSIS en una maquina de x64 atacando a un oracle x64 sin el driver de Oracle OLEDB de x32

      Salu2

      sábado, 14 de junio de 2008

      Mi PPS no me muestra bases de datos

      Hola,

      Hoy toca solucionar un problema que me he encontrado cuando he querido crear un Datasource a mi base de datos de Analysis Services y Performance Point Server no me la mostraba en el desplegable...

      Solución:

      Dentro de Roles, en el DataWarehouse, crear un nuevo perfil con full control y como Membership asginarle Everyone (Todos).

      Con esto deberia ser suficiente para que desde PPS podamos engancharnos sin problemas.

      Salu2

      martes, 10 de junio de 2008

      Dimensión de tiempo con granularidad de horas.....

      Hola a todos,

      Hoy esto va de un poquito de BI. Resulta que para una prueba necesitaba tener una tabla de dimensión de tiempo con granularidad de horas y por lo que he visto SSAS permite crear esta dimensión pero se queda en el día. Buscando en la web (no mucho la verdad) he encontrado este enlace que proporciona un script para crear y cargar la tabla:

      http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3353754&SiteID=1

      Y el script es el siguiente:

      /***************************************
      Script: Creates and Populates an Hour Dimension Table

      Note: This script does hours and minutes. If seconds are needed,
      then modify the datepart on the last line that increments the date.
      Obviously the table will be bigger when you include seconds.

      Author: Ibrahim Hafidh
      Date: 10/11/2005
      ****************************************/

      if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[dimHour]') and OBJECTPROPERTY(id, N'IsUserTable') = 1)
      drop table [dbo].[dimHour]
      GO

      CREATE TABLE dimHour
      (
      HourID INT IDENTITY (1, 1) NOT NULL PRIMARY KEY
      , TheDate DATETIME NOT NULL
      , TheTime Datetime NOT NULL
      , MilitaryHour INT NOT NULL
      , StandardHour INT NOT NULL
      , TheMinute INT NOT NULL
      , TheSecond INT NOT NULL
      , Standard varchar(2) NOT NULL
      )


      DECLARE @startdate DATETIME
      DECLARE @enddate DATETIME
      DECLARE @date DATETIME

      SET @startdate = '1/1/2005 12:00:00 AM'
      SET @enddate = '1/1/2005 23:59:59 PM'
      SET @date = @startdate

      WHILE @date <= @enddate
      BEGIN
      INSERT INTO dimHour (TheDate, TheTime, MilitaryHour, StandardHour, TheMinute, TheSecond, Standard)
      VALUES (
      @date --TheDate
      , convert(nvarchar(11), @date, 114) --Time format
      , DATEPART(hh, @date) --Military Hour
      , CONVERT(varchar(2),
      CASE
      WHEN DATEPART([hour], @Date) > 12 THEN CONVERT(varchar(2), (DATEPART([hour], @Date) - 12))
      WHEN DATEPART([hour], @Date) = 0 THEN '12'
      ELSE CONVERT(varchar(2), DATEPART([hour], @Date))
      END) -- Standard Hour
      , DATEPART(mi, @date) --Minute
      , DATEPART(ss, @date) --Second
      , CASE WHEN DATEPART(hh, @date) between 0 and 11 THEN 'AM' ELSE 'PM' END
      )


      SET @date = DATEADD(mi, 1, @date) -- ** Modify the datepart to ss if seconds are needed

      END



      Por otra parte dejo también este enlace muy útil de conversiones de fechas en SQL Server 2005

      http://www.dreamincode.net/forums/showtopic42872.htm

      Y esto es todo por hoy....


      A2