Últimos mensajes - Powered by IBM

Palabras claves

Otro debate (mas) sobre los Procedimientos Almacenados

28/04/2008 - 14:00 por Pablo Roca | Informe spam

Siento si el tema es recurrente, pero ahi va:

El siguiente hilo es para proponer un debate (amistoso) sobre los
procedimientos almacenados.

Llegué hace poco a SQL Server 2005 y de lo primero que hice fué empezar a
programar todo o casi todo con procedimientos almacenados. Hasta aquí bien,
en momentos noté que (a ratos) las consultas no iban todo lo bien que
debieran ...

Soy un cliente final, y mi casuistica particular me impone que tenga que
utilizar unas 60 bases de datos. Por lo que uno piensa en buscarse la manera
de sincronizar los procedimientos almacenados entre BBDD, alternativamente
mira uno de poner los SPs en la BBDD master, lo que simplifica la
administración y mantenimiento (hasta cierto punto, porque trabajar en
pruebas contra master es un tanto latazo), pero se me presenta el problema
de que tengo que dar acceso a master a todos los usuarios que utilicen la
aplicación, cosa que no me gusta nada.

Lo que es el modelo de poner todo el acceso a datos dentro de la BBDD, la
verdad que me gusta. Pero despues de leer y comprobar en el post de Eduardo
Quintás

http://geeks.ms/blogs/quintas/archi...nados.aspx

Que los procedimientos almacenados no reutilizan sus planes de ejecución si
se ejecutan en BBDD distintas, eso ya me tiró por el suelo a los SPs. Y me
dió una pista de porque los SP's me iban bien a veces (si consultaba siempre
contra la misma BBDD)

Pegas que le veo a los SPs

- la fundamental es la no reutilización de planes de ejecución entre BBDD
distintas.
- si uno se pone a escribir SPs como si fuera un lenguaje normal de
programación puede caer en el error de hacer esto:

IF condicion1
SELECT uno
ELSE
IF condicion2
SELECT dos
ELSE

hacer grandes bloques de if y consultas SELECT es de las peores cosas que se
pueden hacer con un SP, ya que: los planes de ejecución variaran en funcion
de las condiciones de la consulta, la compilación del plan de ejecución se
hace muy lenta.

En lugar de hacer eso es mucho mas optimo hacer:

IF condicion1
EXEC sp1
ELSE
IF condicion2
EXEC sp2
ELSE

¿Porque? Por la reutilización de planes de ejecución. En este segundo
ejemplo el plan de ejecución del SP principal es siempre el mismo, y el de
cada SP que es llamado tambien. Se evitan tiempos de compilación, cacheo,
...

Ventajas de los SPs

- tener todo el código de acceso centralizado en un único sitio
- facilidad de mantenimiento (incluso en producción)

Bien ante todo esto, estoy empezando a cambiar el chip y pasar mis consultas
a la capa de negocio del lado del servidor (lo que estoy haciendo es una
aplicación SOA) utilizando consultas parametrizadas (ahora decirme que las
consultas parametrizadas no se reutilizan entre BBDD y ya se me lió el
invento :)).

Al hilo de esto.

¿Como trabajar de una manera segura con los SPs en master? ¿Metiendo los SPs
en esquemas personalizados y jugando con los permisos?

Bueno .. cualquier comentario es bienvenido.

Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com

Siga el debate

63 respuestas

Tengo una respuesta

Preguntas similare

Cómo copio más de un archivo sobre otro???

Leer las respuestas

#6 Alejandro Mesa

29/04/2008 - 20:54 | Informe spam

Hola Carlos,

No he dicho lo contrario, pero como Pablo no especifica exactamente donde
reside el procedimiento y desde donde lo ejecuta, entonces no puedo
expandirme sobre el tema. Si una consulta Adhoc se ejecuta desde diferentes
bases, aunque esta referencie una tabla en una misma base, entonces se genera
mas de un plan debido a que parte de las propiedades del plan, y que forma
parte de su clave, es [id] de la base desde donde se ejecuto, pero fijate que
en el caso de un procedimiento esto no sucede. Si el mismo procedimiento
(db.owner.sp_name) se ejecuta desde distintas bases, solo un plan es
generado, si es que las condiciones para su re-uso se cumplen.

Ejemplo:

DBCC FREEPROCCACHE
GO

USE [Northwind]
GO

EXEC Northwind.dbo.[Sales by Year] '19970101', '19981231'
GO

SELECT OrderID, OrderDate, CustomerID
FROM Northwind.dbo.[Orders] AS o
WHERE o.[OrderID] = 10250
GO

USE [Tempdb]
GO

EXEC Northwind.dbo.[Sales by Year] '19970101', '19981231'
GO

SELECT OrderID, OrderDate, CustomerID
FROM Northwind.dbo.[Orders] AS o
WHERE o.[OrderID] = 10250
GO

SELECT *
FROM master.dbo.syscacheobjects
WHERE cacheobjtype = 'Compiled Plan' AND objtype IN ('Prepared', 'Proc')
GO

Si chequeas el resultado, veras que se generan dos planes (diferente valor
de dbid) para la consulta Adhoc, la cual es simple y SQL Server la auto
parametriza, no asi para el procedimiento, para el cual solo se genera un
unico plan, ya que el valor de [dbid] para un procedimiento es el [id] de la
base donde este reside.

Yo lei el articulo al que Pablo hace referencia y no estoy de acuerdo con lo
que dice el autor acerca de que "las consultas adhoc y prepared si reusan los
planes aunque se ejecuten en diferente base de datos.".

Espero Pablo exponga algo mas sobre el tema.

AMB

"Carlos M. Calvelo" wrote:

Hola Alejandro, Hola Pablo,

On 29 apr, 04:03, Alejandro Mesa
wrote:
> Pablo Roca,
>
> > Lo que es el modelo de poner todo el acceso a datos dentro de la BBDD, la
> > verdad que me gusta. Pero despues de leer y comprobar en el post de Eduardo
> > Quintás
>
> >http://geeks.ms/blogs/quintas/archi...lanes-d...
>
> > Que los procedimientos almacenados no reutilizan sus planes de ejecución si
> > se ejecutan en BBDD distintas, eso ya me tiró por el suelo a los SPs. Y me
> > dió una pista de porque los SP's me iban bien a veces (si consultaba siempre
> > contra la misma BBDD)
>
> Pudieras ser mas explicito, por favor?
>
> Las consultas adhoc y las consultas parametrizadas (sp_executesql) tampoco
> reusan un plan de ejecucion si estas se ejecutan desde diferentes base de
> datos.
>
> Una de las propiedades de un plan en el cache, y que es parte de su clave
> (clave que identifica al plan), es [dbid]. Su valor es el [id] de la base de
> datos donde reside el procedimiento, o la base de datos desde donde se
> ejecuto el query adhoc o consulta parametrizada. Si el valor de [dbid]
> cambia, para un query adhoc o consulta parametrizada, entonces se genera un
> nuevo plan.
>

Lo caul es totalmente lógico.
Imaginémonos dos bases de datos con la estructura lógica totalmente
igual, pero a nivel físico la una optimizada para actividades tipo
OLTP y la otra para actividades tipo OLAP.
Pues una tendrá pocos índices por ejemplo y la otra muchos; el mismo
procedimiento puede estár implementado con algoritmos distintos, etc,
etc.
Entonces... claro que el plan de ejecución depende de la base de
datos,
porque depende de los datos, estadísticas, y mecanismos a nivel
físico
como los índices y distintas implementaciones del mismo procedimiento.

Si Pablo me permite, y muy amistosamente, tengo la impresión de que
está confundiendo SGBD con base de datos.

Saludos,
Carlos

Responder a este mensaje

#7 Carlos M. Calvelo

29/04/2008 - 21:07 | Informe spam

Hola Alejandro,

On 29 apr, 20:54, Alejandro Mesa
wrote:

Hola Carlos,

No he dicho lo contrario, ...

Alejando, por si existe confunsión, yo te estaba dando la razón.
Y explicando a mi manera por qué creo que tiene que ser así,
como tu has explicado.

Leeré mas detenidamente tus ejemplos.

Saludos,
Carlos

Responder a este mensaje

#8 Carlos M. Calvelo

29/04/2008 - 21:09 | Informe spam

Alejando, ...

Y dale! Pues ya no es la primera vez que me pasa
esto con tu nombre eh!! :)

Saludos

Responder a este mensaje

#9 Alejandro Mesa

29/04/2008 - 21:34 | Informe spam

Carlos M. Calvelo,

Con tal de que no escribas Alejandra :-))

La explicación que distes me parecio muy logica y razonable. Uno de los
factores mas importantes para escojer el plan final es las estadisticas que
se tengan sobre los objetos que se referencian, y estas son propia de cada
base de datos donde se alojan, asi que que usar un mismo plan para
distribuciones diferentes no tiene mucha razon de ser, eso creo.

De todas maneras me gustaria ver si Pablo a tenido otra experiencia que
demuestre lo contrario.

AMB

"Carlos M. Calvelo" wrote:

>
> Alejando, ...

Y dale! Pues ya no es la primera vez que me pasa
esto con tu nombre eh!! :)

Saludos

Responder a este mensaje

#10 Carlos M. Calvelo

29/04/2008 - 22:01 | Informe spam

Hola Alejandro,

On 29 apr, 21:34, Alejandro Mesa
wrote:

Carlos M. Calvelo,

Con tal de que no escribas Alejandra :-))

:-) Disculpa de todas formas.

La explicación que distes me parecio muy logica y razonable. Uno de los
factores mas importantes para escojer el plan final es las estadisticas que
se tengan sobre los objetos que se referencian,

Y por tanto, indirectamente, de los objetos mismos (los datos).
Otros factores son también la presencia/ausencia de
mecanismos físicos, como índices.

y estas son propia de cada
base de datos donde se alojan, asi que que usar un mismo plan para
distribuciones diferentes no tiene mucha razon de ser, eso creo.

Exacto!

Saludos,
Carlos

Responder a este mensaje

Ads by Google

Hacer una preguntaSiguiente

Tengo una respuesta

1 2 3 4 5 6 7 8 9

Busqueda sugerida