Les dejo este excelente link de Microsoft donde encontraran laboratorios virtuales para que puedan ir probando SQL Server 2012

En muchas oportunidades necesitamos hacer un Script de los jobs de producción para llevarlos a otro sitio. Por ejemplo a contingencia.

Para ello podríamos utilizar el siguiente script de Powershell y agregarlo a un step de un job de SQL 2005 / 2008 / R2.

El mismo toma los Jobs que tienen como categoría la palabra producción y genera el script (.sql) de dichos jobs

[System.Reflection.Assembly]::LoadWithPartialName('Microsoft.SqlServer.SMO')| out-null

$RutaScripts = "\\servername\"
# Create an SMO connection to the instance
$s = new-object ('Microsoft.SqlServer.Management.Smo.Server') "SERVIDORSQL" 

$jobs = $s.JobServer.Jobs


$scrp = new-object ('Microsoft.SqlServer.Management.Smo.Scripter') ($s)

$scrp.Options.FileName = $f
$scrp.Options.AppendToFile = $true


foreach ($job in $s.jobserver.jobs) 
{
$a = $job.category




if ($a.toupper() -eq "PRODUCCION")
           
    {
    
     $filename = $job.name + ".sql"
     
     write-host $filename
     
     $f = [System.IO.Path]::Combine($RutaScripts, $filename)
     out-file -filePath $f -inputobject "USE MASTER `nGO`n"


     out-file -filePath $f -inputobject "DECLARE @jobId binary(16) `n SELECT @jobId = job_id FROM msdb.dbo.sysjobs WHERE (name = N'$job') `n  

     IF (@jobId IS NOT NULL) `n  EXEC msdb.dbo.sp_delete_job @jobid `n  go `n " -append

  
     $scrp.Script($job) >> $f

     out-file -filePath $f -inputobject "`n" -append
  
     out-file -filePath $f -inputobject "`n EXEC msdb.dbo.sp_update_job @job_name=N'$job',@enabled=0 `n GO `n" -append


    }

else
 {

 }
}

Una de las cosas que nos sucede muy a menudo es que cuando instalamos un SQL Server luego de debemos aplicar el ultimo services pack y/o hotfix.

Esto no es una tarea para nada difícil pero son dos pasos en la instalación, esto además de consumirnos mas tiempo en la tarea también puede pasar que nos olvidemos de hacerlo y tengamos nuestro servidor sin los parches adecuados.

En esta guía lo que vamos a ver es como armar un paquete de instalación de SQL Server que incluya además el services pack o hotfix.

La metodología que vamos a utilizar se denomina SlipStreamed, este método apareció en SQL Server 2008 a partir de su primer Service Pack.

Paso 1

Debe copiar el medio de instalación de su SQL server a una carpeta, por ejemplo en mi caso arme una carpeta en el disco D llamada SQL2008R2SP1 entonces copiare el medio de SQL original en D:\SQL2008R2SP1

Aquí le aconsejo que copie todo el medio donde se incluye el instalador de x86 y x64.

Paso 2

Baje el hotfix o service pack, en mi caso baje el service pack 1 de SQL 2008 R2, recuerde que debe bajarlo en el mismo idioma que tiene el medio de instalación, en mi caso es en ingles

Recuerde de bajar tanto el de x86 como el de x64 así luego nos queda un solo medio de instalación para ambas tecnologías

SQLServer2008R2SP1-KB2528583-x64-ENU.exe

SQLServer2008R2SP1-KB2528583-x86-ENU.exe

Paso 3

Debemos extraer los contenidos de los archivos que hemos bajado en el punto 2 a una carpeta interna del paso 1.

En mi caso seria D:\SQL2008R2SP1\SP1.

Para hacer esta operación desde la línea de comandos haremos lo siguiente

D:\>SQLServer2008R2SP1-KB2528583-x64-ENU.exe /x:d:\sql2008r2sp1\sp1

D:\>SQLServer2008R2SP1-KB2528583-x86-ENU.exe /x:d:\sql2008r2sp1\sp1

Paso 4

Copiar los archivos que se descomprimieron en el paso anterior en la carpeta raíz del instalador exceptuando Microsoft.SQL.Chainer.PackageData.dll,

esto se debe hacer por cada una de las plataformas de instalación (x64 y x86)

En el caso del ejemplo deberíamos copiar desde

d:\sql2008r2sp1\sp1\x64 a d:\sql2008r2sp1\x64 y

d:\sql2008r2sp1\sp1\x86 a d:\sql2008r2sp1\x86

Yo voy a utilizar el comando Robocopy que ya viene en mi SO.

D:\>robocopy D:\SQL2008R2SP1\SP1\x86 D:\SQL2008R2SP1\x86 /XF Microsoft.SQL.Chainer.PackageData.dll

D:\>robocopy D:\SQL2008R2SP1\SP1\x64 D:\SQL2008R2SP1\x64 /XF Microsoft.SQL.Chainer.PackageData.dll

Paso 5

Copiar Setup.exe y Setup.rll que se encuentra dentro de la carpeta d:\sql2008r2sp1\sp1 hacia d:\sql2008r2sp1\ reemplazando los que están originales.

D:\>robocopy D:\SQL2008R2SP1\SP1 D:\SQL2008R2SP1 Setup.exe

D:\>robocopy D:\SQL2008R2SP1\SP1 D:\SQL2008R2SP1 Setup.rll

Paso 6

Editar el archivo defaultsetup.ini que se encuentra en cada una de las carpetas del medio original para cada plataforma (x86 y x64), en el caso del ejemplo deberíamos editar los archivos de las siguientes ubicaciones

D:\SQL2008R2SP1\x86\DefaultSetup.ini

D:\SQL2008R2SP1\x64\DefaultSetup.ini

A cada archivos hay que agregarle la siguiente línea

PCUSOURCE=".\SP1"

Ya tenemos listo el proceso y ahora simplemente ejecutaremos el setup.exe .

En este video muestro cuales son los pasos para poder configurar el correo saliente en SQL Server a partir de la versión 2005 que ya incluye SMTP sin la necesidad de instalar un cliente MAPI como en versiones anteriores.

Además muestro como es la configuración para utilizar el SMTP de gmail o google si es que deseamos salir por ahí.

En este video muestro como se puede generar el script de una o mas tablas pero no solamente incluyendo sus estructuras sino que también los datos.

Esto nos puede ser útil en muchos casos, por ejemplo si tenemos tablas de nuestro sistema con valores de startup con esta técnica nuestro script de implementación podrá incluir esos datos

Para ello es necesario utilizar la versión 2008 o superior del Management Studio (SSMS)

Nuestro SQL Server dispone de varios parámetros de configuración, en muchos casos es necesario hacerle modificaciones a ellos con el cuidado necesario.

Muchas veces me he encontrado que se tocan parámetros sin medir consecuencias y se puede afectar al buen funcionamiento del servidor en si.

Por ello decidí armar este mini video de como podemos saber que parámetros se han modificado pero además saber cuales son los valores que estos tienen por defecto.

Cuando necesitamos por ejemplo hacer una migración , ya sea a un nuevo equipamiento y/o a una nueva versión, una de las técnicas para pasar las bases de datos de un lugar al otro es el método Attach / Detach.

Ahora bien, si tenemos pocas bases de datos no hay ningún problema porque hacer el Attach no llevaría mucho tiempo.

Ahora que sucede si tenemos muchas bases de datos? es una tarea bastante engorrosa hacer una por una, yo utilizo para esto un script que generar el código de attach con las ubicaciones de los Data y Log de cada base de datos.

Este script es el que utilizo al hacer este tipo de trabajos y la verdad que no solo me hace ahorrar mucho tiempo sino también cometer menos errores cuando hay una cantidad de bases de datos grande en nuestra instancia.

Aquí les dejo el código y el adjunto del script, espero les sea útil como me fue a mi

DECLARE @dbid int
 DECLARE @name varchar(50)
 DECLARE @file varchar(150)
 DECLARE @IDFILE INT
 DECLARE @CMD VARCHAR(4000)
 SET @CMD = ''
 SET @IDFILE = 1

DECLARE cAttach CURSOR
 READ_ONLY
 FOR SELECT dbid, name FROM 
 sysdatabases 
 where name not in 
 ('master','tempdb','model','msdb','northwind', 'pubs','distribution' )
 
OPEN cAttach
 
FETCH NEXT FROM cAttach INTO @dbid, @name
 WHILE (@@fetch_status <> -1)
 BEGIN
 IF (@@fetch_status <> -2)
 BEGIN
 
 -- buscamos los archivos
 DECLARE archivos CURSOR
 READ_ONLY FOR
 select [filename] FROM  sysaltfiles 
                   where dbid = @dbid
                   order by fileid 
 
 OPEN archivos
 FETCH NEXT FROM archivos INTO @file
 WHILE (@@fetch_status <> -1)
 begin
 
 BEGIN
   
   SET @CMD = @CMD +  ',@FILENAME' +CONVERT(varchar(10),@IDFILE) + '=' 
   + '''' + rtrim(@file) + '''' + CHAR(13)
   set @IDFILE = @IDFILE + 1
 end
 FETCH NEXT FROM archivos INTO @file
end
 CLOSE archivos
 DEALLOCATE archivos
 
print '';
 print 'EXEC sp_attach_db @dbname = ''' + (@name) + '''' ;

 print @cmd + ';'
 
 SET @CMD = ''
 SET @IDFILE = 1

END
 FETCH NEXT FROM cAttach INTO @dbid, @name
 END
 
CLOSE cAttach
 DEALLOCATE cAttach
 GO

En una migración de servidores desde SQL2000 a 2005 o 2008 si tenemos servidores vinculados (Linked Server) podemos llegar a tener el siguiente error al querer aplicar el Script en el destino (por ejemplo SQL 20008).

Aquí muestro un ejemplo del script

sp_addlinkedserver 'CASACENTRAL','SQL SERVER',

'SQLOLEDB','SQLPROD','','','SERVICECENTRAL'

go

Al ejecutar este script en un 2008 o 2005 nos encontramos con el siguiente error

Msg 15428, Level 16, State 1, Procedure sp_addlinkedserver, Line 40
You cannot specify a provider or any properties for product 'SQL SERVER'.

El problema se da porque el driver SQLOLEDB no existe en 2008 o 2005, para lo cual deberíamos modificar el script como muestro a continuación

EXEC sp_addlinkedserver

@server='CASACENTRAL', 

@srvproduct='',

@provider='SQLNCLI', 

@datasrc='SQLPROD'

go

Aquí solo se ha modificado el Provider por SQLCLI, ahora si nuestro Script va a funcionar y podemos migrar nuestro Linked Server.

Debo mencionar que esto no sucede con todos los Linked sino que básicamente sobre aquellos que usamos un nombre distinto al del servidor SQL,

como pudimos ver en nuestro ejemplo el servidor se llama SQLPROD y el Linked CASACENTRAL.

Además de esto, muchas veces me preguntan como se migran estos linked server, hay varias opciones, a mi me gusta mucho usar esta tool free.

http://www.codeproject.com/cs/database/ScriptLinkedServers.asp

Como muchos otros productos de Microsoft, ahora SQL Server y a partir de su versión 2008 nos permite manejar políticas a nivel motor.

Estas políticas son una herramienta muy potente para los DBA y equipos de desarrollo ya que con ella vamos a poder controlar y garantizar por ejemplo nuestras buenas prácticas de trabajo.

Una de las cosas que sucede es que en una empresa se definen estándares de trabajo para la base de datos o también llamados buenas prácticas, ahora bien, ¿cómo hacemos para poder controlar esto y también dentro de lo posible que no se generen cosas fuera de estas buenas practicas?

El manejo de políticas en SQL Server nos va a permitir hacer esto y mucho más.

Yo utilizo bastante esta herramienta y la verdad que está muy piola

En este post les voy a dejar una serie de links al respecto como así también un video demo de cómo se utiliza “Policy Management”.

Enterprise Policy Management Framework with SQL Server 2008

Blog de Policy Management

SQL Server Central Management System

Este error se da al tratar de modificar un job el cual fue creado en un servidor con un nombre distinto al nombre que actualmente tiene

Hay varias formas de resolver este problema, una de ellas es seguir el siguiente link

http://support.microsoft.com/kb/281642

Pero además de esta solución la cual obliga a cambiar nombres, reiniciar servicios, re armar los job con los Script, aquí les paso un método el cual aplica los cambios.

use msdb 
DECLARE @srv sysname 
SET @srv = CAST(SERVERPROPERTY('ServerName') AS sysname) 
select @srv 
select * from sysjobs 
UPDATE sysjobs SET originating_server = @srv 
select * from sysjobs

En toda instalación de SQL Server hay un login llamado SA el cual es el Sysadmin (Súper Usuario)

Si usamos el método de autentificación mixta (Windows y SQL Server) vamos a poder usar este Login.

Ahora bien, como sabemos que en toda instalación hay un SA y en muchas de esas instalaciones esta el modo mixto, si yo fuera una persona que quiero hacer daño sobre la base de datos lo que intentaría es de descubrir la password de ese SA.

Antes de 2005 no teníamos una opción de a un Login deshabilitarlo , o sea que este definido pero no tenga acceso a Logon.

A partir de 2005 podemos hacer esto con nuestros Logins y lo piola es que incluye al SA.

Como buena practica deberíamos crear otro Login que sea Sysadmin y deshabilitar el SA, esto a los efectos de mejorar nuestra seguridad y así también que ninguna aplicación pueda usar en su conexión string este Login.

En este mini video les muestro como se deshabilita un Login en SQL Server

Como todos sabrán en SQL Server Analysis Service (SSAS) por defecto los administradores local del equipo también lo son de SSAS, ahora bien, en muchas empresas esto no es deseable para lo cual queremos que los Admin del equipo no tengan acceso sobre el SSAS.

Este post indica paso a paso de como deshabilitar a los administradores.

· Inicie el SSMS (Sql Server Management Studio)

· Conecte contra el servidor de SSAS (debe tener permisos para poder hacerlo claro)

· Vaya a las propiedades del servidor pulsando el botón alterno del mouse

· Acceda a las opciones de Seguridad y deje ahí solo los administradores del SSAS

Ahora que ha definido a los Administradores del SSAS lo que debemos hacer es deshabilitar a los admin locales, por mas que los hayamos sacado de la opción security también es necesario deshabilitarlo desde las opciones avanzadas, entonces

· Vaya a la solapa general y pulse el botón “Show Advanced (all) Properties”

· Busque ahora dentro de la grilla de opciones la que dice “Security \ BuiltinAdminsAreServerAdmins” y ponga su valor en false

Con esto ya los administradores locales no tendrán acceso a nuestro SSAS.

La tarea de pasar Login entre servidores es algo casi habitual entre los DBA, esta tarea se puede deber a migraciones de versiones, cambios de servidores, etc..

Como todos sabrán SQL Server dispone de dos tipos de Logins, los de Windows y los de SQL.

Bien, como pasamos los logins de un servidor a otro? pues Microsoft ha publicado unos script muy interesantes para estas tareas, uno para SQL 2000 y el otro para SQL 2005 / 2008.

Los Script están muy buenos de verdad pero carecen de una funcionalidad muy importante para mi gusto que es pasar los roles de esos login, pues bien como esta tarea es repetitiva me he tomado el trabajo de modificar estos dos script y agregarle la funcionalidad faltante.

Es importante usar estos Script ya que pasan datos importantes como la Password y el SID, este ultimo asegura que luego no tengamos problemas de usuarios huérfanos

Si tienen integrado a Sherepoint (ya sea el portal o bien el services) son Reporting services y ejecutan un reporte que dura mas de dos minutos les aparecerá del lado de Sharepoint el siguiente error: Error inesperado o bien “An unexpected error has occurred” en ingles.

Por defecto existe un timeout a nivel ASP que es de 2 minutos, para cambiar este valor habrá que hacer los siguientes pasos desde el servidor de Sharepoint

1. Abrir el archivo web.config de la aplicación sharepoint (por ejemplo \inetpub\wwwroot\wss\VirtualDirectories\80)
2. Buscar dentro del archivo httpRuntime
3. Agregar executionTimeout con un valor en segundos deseado, por ejemplo 1800

<httpRuntime maxRequestLength="51200" executionTimeout = "1800" />

Esto nos permitirá extender el timeout del sharepoint haciendo que si tenemos reportes con una duración mayor a dos minutos los podamos ejecutar sin errores. Les recomiendo poner 1800 segundos ya que también ese valor es el predeterminados a nivel Reporting Service para un timeout de Reporte.

Aquí les dejo el link original de donde he sacado la solución y me ha funcionado perfecto.

Una de las operaciones que muchas veces necesitamos hacer es la de poder generar script de las estructuras de nuestros objetos o bien de toda una base de datos.

Esta opción esta disponible desde viejas versiones del producto donde con el Enterprise Manager o bien el Management Studio de 2005 se podía hacer lo mas bien.

Pero hasta SQL 2008 lo único que nos dejaba generar script eran justamente estructuras y no datos de ellas (registros).

Imaginemos que tenemos una tabla de configuración que necesitamos además de hacer el script de las estructuras que también incluya los registros, para lo cual se debería transformar en sentencias INSERT de nuestro script .SQL.

Para poder hacer este tipo de tareas por lo general debíamos recurrir a herramientas de terceras partes, ahora y a partir de SQL Server 2008 usando el Management Studio (el de Express también lo soporta y es gratuito) podemos a nuestros script darle la posibilidad de generar datos.

Aquí les muestro como lo hacemos

Primero debemos entrar al SSMS (SQL Server Management Studio) para conectarnos al servidor.

Luego sobre la solapa base de datos, pulsaremos el botón alterno del mouse para seleccionar Task y luego Generate Script el cual nos aparecerá el siguiente Wizard.

Lo que aquí debemos seleccionar es la base de datos a la cual necesitamos armar los script, por ejemplo MUG1 y luego pulsar sobre el botón siguiente, al hacer esto nos aparecerá una segunda ventana con distintas opciones, por ejemplo si queremos generar los script de índices, los logins, etc.

En el SSMS de 2008 tenemos un nuevo chiche y es que una de esas opciones en la sección de tablas es de generar la data, debemos poner en true (viene en false por defecto)

Al seleccionar esa opción ya nuestro script resultante no solo incluirá las estructuras sino que también los datos con sentencias INSERT.

La siguiente ventana nos permite seleccionar que tipos de objetos queremos hacer el script, para este ejemplo seleccionaremos Tables

Al seguir al nuevo paso tendremos el listado de tablas las cuales podemos seleccionar o una o mas de una

Por ultimo nos preguntara el wizard donde queremos enviar el resultado, aquí yo le pondré en una nueva ventana para que podamos observarlo

Bien, luego de hacer esto y dejar que termine el proceso, tendremos en nuestra nueva ventana el script resultante.

Aquí copio mi resultado donde se podrá observar que no solo armo las sentencias DDL para la tabla sino que también las DML para insertar el registro que tiene la tabla.

USE [MUG1]
GO

SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO

CREATE TABLE [ventas].[Clientes](
    [Codigo] [varchar](15) NOT NULL,
    [Nombre] [varchar](100) NULL,
    [Direccion] [varchar](100) NULL,
    [fecha] [date] NULL,
    [id] [int] IDENTITY(100,10) NOT NULL,
    [fecha_nac] [date] NULL,
 CONSTRAINT [PK_Clientes_1] PRIMARY KEY CLUSTERED 
(
    [Codigo] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, 
IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

SET ANSI_PADDING OFF
GO
SET IDENTITY_INSERT [ventas].[Clientes] ON
INSERT [ventas].[Clientes] 
([Codigo], [Nombre],[Direccion], 
[fecha], [id], [fecha_nac]) 
VALUES (N'1', N'mug', N'riv...', NULL,
100, CAST(0x16310B00 AS Date))

SQL-Dinámico y seguridad dentro de SQLServer 2005

El SQL-dinámico es una técnica la cual nos permite ejecutar sentencias TSQL de forma dinámica,  para poder hacer uso de esta técnica es necesario utilizar o bien el store procedure sp_executesql o sino EXEC(@str).

Este articulo no tiene como objetivo entrar en detalle del SQL-dinámico ya que hay otros escritos al respecto como por ejemplo el siguiente link el cual recomiendo leer

Aquí nos concentraremos en la seguridad y los cambios que hay en SQL2005 al respecto.

Una de las mayores contras que tiene el uso de SQL-Dinámico es que si lo ponemos dentro de un Store Procedure el usuario que ejecute tal Store no solo deberá tener permisos de execute sino que también deberá tener permisos sobre los objetos que haga referencia el SQL-Dinámico.

Para poder ser más específicos veamos un ejemplo al respecto

Como se ha podido observar en el ejemplo el segundo Store ha fallado cuando el usuario Federico lo invoco ya que no tenia permisos sobre los objetos internos del mismo, en este caso la tabla "Empleados".

Esto atenta contra el buen uso de un Store procedure ya que una de sus virtudes es aislar a los usuarios del acceso directo a los objetos, con lo cual si deseamos en este caso usar SQL-Dinámico deberíamos darle permisos de Select a la tabla correspondiente.

Esto funciona así en 2000 y no hay solución al respecto, por lo cual yo no recomiendo mucho el uso de SQL-Dinámico y de usarlo tener en claro lo que está sucediendo.

¿Que cambios hay en 2005?

SqlServer 2005 permite dentro de un objeto como el Store Procedure indicarle el contexto de ejecución, esto es totalmente nuevo y se indica con la sentencia WITH EXECUTE AS (Caller, Owner o Username)

• Caller es utilizado por defecto y representa a quien llama (como vimos en el ejemplo 1)
• Owner indica que se impersonificara como el usuario propietario del objeto, en este caso como entre con la cuenta de SA entonces estamos impersonificando con ella.
• User_name nos permite indicar con que login deseamos que se impersonifique

El siguiente ejemplo modifica el  Store con SQL Dinámico pero utilizando Execute AS

Aquí se ve claramente que ahora Federico no necesito permisos sobre la tabla "Empleados" para poder hacer uso del SQL-Dinámico.

Con esto lo que logramos es seguir manteniendo una de las enormes virtudes que tienen los Stores Procedures que es el aislamiento con respecto a los objetos base.

No confundir el Execute AS del Store con el luego utilizado en el query para dentro del management Studio impersonificarnos como Federico sin la necesidad entrar a otra ventana.

Estos ejemplos deben ser probados desde SQL2005, si desea probar el primer ejemplo desde SQL2000 deberá sacar la sentencia Execute AS y probar la seguridad entrando con el correspondiente login y password.

Bueno espero les sea de utilidad y espero sus comentarios.

Nos vemos!