Bienvenido

sp_addlinkedserver y sp_addlinkedsrvlogin

lunes, 23 de marzo de 2009

sp_addlinkedserver
Crea un servidor vinculado. Un servidor vinculado permite obtener acceso a consultas heterogéneas distribuidas en orígenes de datos OLE DB. Después de crear un servidor vinculado mediante sp_addlinkedserver, se pueden ejecutar consultas distribuidas en este servidor. Si el servidor vinculado se define como una instancia de SQL Server, se pueden ejecutar procedimientos almacenados remotos.(Fuente:Libros en pantalla de SQL SERVER).
En otras palabras, nos permite realizar consultas o ejecutar procedimientos almacenados(Instancia SQL SERVER) pertenecientes a un servidor distinto al nuestro.
Caso Practico 1
Suponiendo que, la instancia de nuestro servidor SQL SERVER: SvrDestino y nuestra base de datos bd_Destino tiene como usuario: sa y clave: sa123456.
Se desea: Obtener todos los registros de la tabla: TablaOrigen, que se encuentra en la base de datos: bd_Origen con usuario: sa y clave: sa123456, en el servidor SvrOrigen.

Paso 1: Correr el procedimiento almacenado
exec sp_addlinkedserver 'SvrOrigen'
Paso 2: Ejecutar la consulta
Select [SvrOrigen].[bd_Origen].dbo.[TablaOrigen]

Listo, obtenemos todos los registros de TablaOrigen, desde nuestro servidor SvrDestino utilizando sp_addlinkedserver.

Consideracion: Estos pasos son suficientes para devolver todos los registros de TablaOrigen, pero,¿Que sucece si el usuario y clave de las base de datos no coinciden?

sp_addlinkedsrvlogin
Crea o actualiza una asignación entre un inicio de sesión en la instancia local de SQL Server y una cuenta de seguridad en un servidor remoto.(Fuente:Libros en pantalla de SQL SERVER)
Caso Practico 2
Suponiendo que, la instancia de nuestro servidor SQL SERVER: SvrDestino y nuestra base de datos bd_Destino tiene como usuario: sa y clave: sa123456.
Se desea: Obtener todos los registros de la tabla: TablaOrigen, que se encuentra en la base de datos: bd_Origen con usuario: sa y clave: sa123, en el servidor SvrOrigen.

Paso 1: Correr el procedimiento almacenado
exec sp_addlinkedserver 'SvrOrigen'
Paso 2: Correo el procedimiento almacenado
exec sp_addlinkedsvrlogin 'SvrOrigen',False,NULL,'sa','sa123'
Paso 3: Ejecutar la consulta
Select [SvrOrigen].[bd_Origen].dbo.[TablaOrigen]

Listo, obtenemos todos los registros de TablaOrigen, desde nuestro servidor SvrDestino utilizando sp_addlinkedservery sp_addlinkedsrvlogin.

Para mayor informacion:
Libros en pantalla de SQL SERVER
sp_addlinkedserver:
http://technet.microsoft.com/es-es/library/ms190479.aspx
sp_addlinkedsrvlogin:
http://technet.microsoft.com/es-es/library/ms189811.aspx

Variable Table vs. Tablas Temporales

sábado, 21 de marzo de 2009

Es comun la utilizacion de tablas temporales, a pesar de que todos sabemos que no las deberiamos de utilizar,no podemos evitar recurrir a ellas debido a que muchas veces nos facilitan la resolucion del problema.Un consejo ¡No Utilizarlas! (¡cursores excluidos!, ya lo veremos en otra oportunidad)Podemos usar consultas o subconsultas, normalmente usar una subconsulta mejora drásticamente el rendimiento respecto a usar tablas temporales.

Pero si no tenemos otra opcion ¡Utilizarlas Correctamente!

Algo de teoria
1.- Tablas Temporales

a) #Locales sólo se pueden utilizar en la conexión en la que el usuario las crea. Cuando la conexión termina la tabla temporal desaparece. Es aconsejable eliminarlas nosotros mismos no esperar a que termine la conexion, si tenemos un conjunto de sentencias largo y creamos una tabla temporal al principio y no la vamos a utilizar en el resto del tiempo no tiene sentido tener esa tabla ahí ocupando espacio y memoria(DROP #tablaTemporal).

##Golbales Son visibles por cualquier usuario conectado al Servidor. Una cosa más, estas tablas desaparecen cuando ningún usuario está haciendo referencias a ellas, NO cuando se desconecta el usuario que la creo.
b) Estas tablas se almacen en la base da datos temdb, y al crearlas se producen varios bloqueos sobre esta base de datos como por ejemplo en las tablas sysobjects y sysindexes. Al momento de crearlas es necesario que se realicen accesos de escritura al disco. (no siempre si las tablas son pequeñas)
c) Se puede efectuar las mismas operaciones que una tabla común, incluyendo el poder agregar índices. CREATE INDEX IDX_TBLCUSTOMER_LASTNAME on #TBLCUSTOMER (Last_Name)
d) Un Procedimiento almacenado que haga uso de tablas temporales, puede que se recompile seguido, lo que involucra perder la ventaja de tener al Procedimento almancenado compilado. De todos modos, en SQL Server 2005 se mejoro la forma en que se precompilan los Procedimentos almancenados que usan tablas temporales, mejorando la performance.
e) La operaciones estan logueadas en el Registro de Transacciones y por lo tanto se toman en cuenta en el ROLLBACK o COMMIT.
f) Es Posible hacer uso de SELECT INTO.


2.- Variables Tipo Table

a) Una variable table se comporta como una variable local. Tiene un ámbito bien definido. Dicho ámbito es la función, el procedimiento almacenado o el lote en que se declara.
b) El contenido de una variable de tabla casi siempre esta completamente en memoria, lo que aumenta su rendimiento. En caso de que se inserte una alta cantidad de registros a la variable, se almacenará en tempdb.
c) No se pueden agregar índices en variables de tabla. Esto es una gran desventaja a la hora de trabajar con un conjunto gran de datos. Sin embargo, existe una manera de tener índices. Para eso, hay que definir una PRIMARY o UNIQUE KEY cuando se crea la tabla, aunque claro, no siempre nos sirve. DECLARE @TBLTemporal TABLE (INDICE int, PRIMARY KEY ([INDICE]))
d) Un Procedimiento almacenado que haga uso de variables table, no va a sufrir recompilaciones.
e) Si necesitamos que sea transaccional(ROLLBACK,COMMIT) la operación, no lo podemos hacer con este tipo de estructuras. En caso de que se haga un INSERT/UPDATE/DELETE contra la variable, dentro de una transacción, al hacer ROLLBACK, el contenido seguirá siendo el mismo.
f) No es posible hacer uso de SELECT INTO.

Entre otras cosas ...


Un Ejemplo:


-- USANDO TABLAS TEMPORALES

DECLARE @HoraInicio DATETIME
create table #TblTemporal(Producto varchar(100),Cantidad float)
set @HoraInicio=GETDATE()
INSERT INTO #TblTemporal

SELECT P.PRODUCTNAME AS PRODUCTO,SUM(QUANTITY) AS CANTIDADFROM ORDERS O INNER JOIN [ORDER DETAILS] D ON O.ORDERID=D.ORDERIDINNER JOIN PRODUCTS P ON D.PRODUCTID=P.PRODUCTIDWHERE CONVERT(VARCHAR(8),ORDERDATE,112)>='19960704' AND CONVERT(VARCHAR(8),ORDERDATE,112)<='19980506'GROUP BY P.PRODUCTNAME

UPDATE #TblTemporalSET CANTIDAD=CANTIDAD+100 SELECT PRODUCTO,CANTIDAD FROM #TblTemporal

SELECT ' Usando Tablas Temporales ' + cast(DATEDIFF(ms,@HoraInicio,getdate()) as varchar(3))+ ' Milisegundos'

-- 70 MILISEGUNDOS
DROP TABLE #TblTemporal

-- USANDO VARIABLES TABLE

declare @TblTemporal table(Producto varchar(100),Cantidad float)
set @HoraInicio=GETDATE()
INSERT INTO @TblTemporal

SELECT P.PRODUCTNAME AS PRODUCTO,SUM(QUANTITY) AS CANTIDADFROM ORDERS O INNER JOIN [ORDER DETAILS] D ON O.ORDERID=D.ORDERIDINNER JOIN PRODUCTS P ON D.PRODUCTID=P.PRODUCTIDWHERE CONVERT(VARCHAR(8),ORDERDATE,112)>='19960704' AND CONVERT(VARCHAR(8),ORDERDATE,112)<='19980506'GROUP BY P.PRODUCTNAME

UPDATE @TblTemporalSET CANTIDAD=CANTIDAD+100 SELECT PRODUCTO,CANTIDAD FROM @TblTemporal

SELECT ' Usando Variables Table ' + cast(DATEDIFF(ms,@HoraInicio,getdate()) as varchar(3))+ ' Milisegundos'

-- 40 MILISEGUNDOS

-- USANDO CONSULTAS

set @HoraInicio=GETDATE()

SELECT PRODUCTO,CANTIDAD+100 AS CANTIDAD FROM(

SELECT P.PRODUCTNAME AS PRODUCTO,SUM(QUANTITY) AS CANTIDAD FROM ORDERS O INNER JOIN [ORDER DETAILS] D ON O.ORDERID=D.ORDERID INNER JOIN PRODUCTS P ON D.PRODUCTID=P.PRODUCTID WHERE CONVERT(VARCHAR(8),ORDERDATE,112)>='19960704' AND CONVERT(VARCHAR(8),ORDERDATE,112)<='19980506' GROUP BY P.PRODUCTNAME)H

SELECT ' Usando Consulta ' + cast(DATEDIFF(ms,@HoraInicio,getdate()) as varchar(3))+ ' Milisegundos'

-- 40 MILISEGUNDOS


No olvidar que siempre debemos de analizar las dos opciones.
Sin embargo, cuando la cantidad de registros es pequeña se puede optar por el uso de Variables Table.Pero en el caso tener un numero de registros de tamaño considerable se puede optar por Tablas Temporales por tener mayores herramientas.
Gracias por su atencion.

Cualquier aporte sera bien recibido ...

Bienvenida

miércoles, 18 de marzo de 2009

print 'La necesidad de conocimiento es lo que nos hace buscar el conocimiento'