plan de ejecucion de procedimiento sobre vista

.asi hasta varios meses (cada tabla tiene una constraint en "fecha" para
que los datos no puedan estar fuera de ese mes)

Hola a todos,

Tengo un conjunto de operaciones particionado por meses en varias tablas

create table OperacionesEnero(id int,codigo int,fecha datetime)
create table OperacionesFebrero(id int,codigo int,fecha datetime)
.asi hasta varios meses (cada tabla tiene una constraint en "fecha" para
que los datos no puedan estar fuera de ese mes)

Y una vista que unifica estas tablas
create view VistaUnificada
as
select id,codigo,fecha from OperacionesEnero union all
select id,codigo,fecha from OperacionesEnero..

Se que no es el mejor diseño, pero es como esta y cambiarlo nos es ahora
mismo imposible.

El caso es que cuando ejecuto una consulta, por ejemplo
select * from VistaUnificada where fecha='20060615',el plan de consulta
muestra que solo se busca en la tabla de Junio.Pero cuendo hago un
procedimiento como:select * from VistaUnificada where fecha=@fecha y lo
ejecuto, el plan de consulta muestra que se busca en todas las tablas.En la
practica,con el parametro tarda tambien muchisimo mas.
Entiendo que esto sera debido a que el servidor tiene que crear un plan de
ejecucion generico, ya que no sabe que contendra el parametro.


Mi pregunta es,hay alguna manera de salvar esto y hacer que solo busque en
la tabla necesaria? el procedimiento no se usa demasiado, asi que no me
importa que se recompile muchas veces.Yo he pensado en sql dinamico,pero me
parece un poco chapucero.
Otra pregunta:Las tablas de operaciones mensuales son muy utilizadas en mi
sistema.Cuando ejecuto una select normal sobre la vista,si la consulta es
pesada se generan un monton de bloqueos en la bbdd.Sabeis a que puede ser
debido?

Gracias por todo y perdonar que no ponga los scripts pero no tengo acceso
ahora mismo al servidor.Espero haber sido claro, cualquier ayuda la
agradecere.

Un saludo.

Silverius,

1 - Que version de SQL Server usas?

2 - Basado en el comentario que esta a continuacion, sabes si la columna
[fecha] forma parte de la clave primaria de cada tabla?. Pudieras postear

definicion de la clave primaria?

> .asi hasta varios meses (cada tabla tiene una constraint en "fecha"

> que los datos no puedan estar fuera de ese mes)


AMB

"Silverius" wrote:

> Hola a todos,
>
> Tengo un conjunto de operaciones particionado por meses en varias tablas
>
> create table OperacionesEnero(id int,codigo int,fecha datetime)
> create table OperacionesFebrero(id int,codigo int,fecha datetime)
> .asi hasta varios meses (cada tabla tiene una constraint en "fecha"

> que los datos no puedan estar fuera de ese mes)
>
> Y una vista que unifica estas tablas
> create view VistaUnificada
> as
> select id,codigo,fecha from OperacionesEnero union all
> select id,codigo,fecha from OperacionesEnero..
>
> Se que no es el mejor diseño, pero es como esta y cambiarlo nos es ahora
> mismo imposible.
>
> El caso es que cuando ejecuto una consulta, por ejemplo
> select * from VistaUnificada where fecha='20060615',el plan de consulta
> muestra que solo se busca en la tabla de Junio.Pero cuendo hago un
> procedimiento como:select * from VistaUnificada where fecha=@fecha y lo
> ejecuto, el plan de consulta muestra que se busca en todas las tablas.En

> practica,con el parametro tarda tambien muchisimo mas.
> Entiendo que esto sera debido a que el servidor tiene que crear un plan

> ejecucion generico, ya que no sabe que contendra el parametro.
>
>
> Mi pregunta es,hay alguna manera de salvar esto y hacer que solo busque

> la tabla necesaria? el procedimiento no se usa demasiado, asi que no me
> importa que se recompile muchas veces.Yo he pensado en sql dinamico,pero

> parece un poco chapucero.
> Otra pregunta:Las tablas de operaciones mensuales son muy utilizadas en

> sistema.Cuando ejecuto una select normal sobre la vista,si la consulta

> pesada se generan un monton de bloqueos en la bbdd.Sabeis a que puede

> debido?
>
> Gracias por todo y perdonar que no ponga los scripts pero no tengo

> ahora mismo al servidor.Espero haber sido claro, cualquier ayuda la
> agradecere.
>
> Un saludo.
>
>
>
>

Usamos Sql Server 2000 y no,no forma parte de la clave primaria.
La clave primaria es un simple autonumerico.

Gracias Alejandro,
Usamos Sql Server 2000 y no,no forma parte de la clave primaria.
La clave primaria es un simple autonumerico.


"Alejandro Mesa" escribió en el
mensaje news:
> Silverius,
>
> 1 - Que version de SQL Server usas?
>
> 2 - Basado en el comentario que esta a continuacion, sabes si la columna
> [fecha] forma parte de la clave primaria de cada tabla?. Pudieras postear
la
> definicion de la clave primaria?
>
> > .asi hasta varios meses (cada tabla tiene una constraint en "fecha"
para
> > que los datos no puedan estar fuera de ese mes)
>
>
> AMB
>
> "Silverius" wrote:
>
> > Hola a todos,
> >
> > Tengo un conjunto de operaciones particionado por meses en varias tablas
> >
> > create table OperacionesEnero(id int,codigo int,fecha datetime)
> > create table OperacionesFebrero(id int,codigo int,fecha datetime)
> > .asi hasta varios meses (cada tabla tiene una constraint en "fecha"
para
> > que los datos no puedan estar fuera de ese mes)
> >
> > Y una vista que unifica estas tablas
> > create view VistaUnificada
> > as
> > select id,codigo,fecha from OperacionesEnero union all
> > select id,codigo,fecha from OperacionesEnero..
> >
> > Se que no es el mejor diseño, pero es como esta y cambiarlo nos es ahora
> > mismo imposible.
> >
> > El caso es que cuando ejecuto una consulta, por ejemplo
> > select * from VistaUnificada where fecha='20060615',el plan de consulta
> > muestra que solo se busca en la tabla de Junio.Pero cuendo hago un
> > procedimiento como:select * from VistaUnificada where fecha=@fecha y lo
> > ejecuto, el plan de consulta muestra que se busca en todas las tablas.En
la
> > practica,con el parametro tarda tambien muchisimo mas.
> > Entiendo que esto sera debido a que el servidor tiene que crear un plan
de
> > ejecucion generico, ya que no sabe que contendra el parametro.
> >
> >
> > Mi pregunta es,hay alguna manera de salvar esto y hacer que solo busque
en
> > la tabla necesaria? el procedimiento no se usa demasiado, asi que no me
> > importa que se recompile muchas veces.Yo he pensado en sql dinamico,pero
me
> > parece un poco chapucero.
> > Otra pregunta:Las tablas de operaciones mensuales son muy utilizadas en
mi
> > sistema.Cuando ejecuto una select normal sobre la vista,si la consulta
es
> > pesada se generan un monton de bloqueos en la bbdd.Sabeis a que puede
ser
> > debido?
> >
> > Gracias por todo y perdonar que no ponga los scripts pero no tengo
acceso
> > ahora mismo al servidor.Espero haber sido claro, cualquier ayuda la
> > agradecere.
> >
> > Un saludo.
> >
> >
> >
> >

Silverius,

> Usamos Sql Server 2000 y no,no forma parte de la clave primaria.
> La clave primaria es un simple autonumerico.

Entonces chequea los libros en linea, pues uno de los requisitos es que

columnas por la que se particiona la data, forme parte de la clave

de la tabla.

En el siguiente articulo, pon especial atencion en "Partitioning Column
Rules".

Creating a Partitioned View

AMB

"Silverius" wrote:

> Gracias Alejandro,
> Usamos Sql Server 2000 y no,no forma parte de la clave primaria.
> La clave primaria es un simple autonumerico.
>
>
> "Alejandro Mesa" escribió en

> mensaje news:
> > Silverius,
> >
> > 1 - Que version de SQL Server usas?
> >
> > 2 - Basado en el comentario que esta a continuacion, sabes si la

> > [fecha] forma parte de la clave primaria de cada tabla?. Pudieras

> la
> > definicion de la clave primaria?
> >
> > > .asi hasta varios meses (cada tabla tiene una constraint en

> para
> > > que los datos no puedan estar fuera de ese mes)
> >
> >
> > AMB
> >
> > "Silverius" wrote:
> >
> > > Hola a todos,
> > >
> > > Tengo un conjunto de operaciones particionado por meses en varias

> > >
> > > create table OperacionesEnero(id int,codigo int,fecha datetime)
> > > create table OperacionesFebrero(id int,codigo int,fecha datetime)
> > > .asi hasta varios meses (cada tabla tiene una constraint en

> para
> > > que los datos no puedan estar fuera de ese mes)
> > >
> > > Y una vista que unifica estas tablas
> > > create view VistaUnificada
> > > as
> > > select id,codigo,fecha from OperacionesEnero union all
> > > select id,codigo,fecha from OperacionesEnero..
> > >
> > > Se que no es el mejor diseño, pero es como esta y cambiarlo nos es

> > > mismo imposible.
> > >
> > > El caso es que cuando ejecuto una consulta, por ejemplo
> > > select * from VistaUnificada where fecha='20060615',el plan de

> > > muestra que solo se busca en la tabla de Junio.Pero cuendo hago un
> > > procedimiento como:select * from VistaUnificada where fecha=@fecha y

> > > ejecuto, el plan de consulta muestra que se busca en todas las

> la
> > > practica,con el parametro tarda tambien muchisimo mas.
> > > Entiendo que esto sera debido a que el servidor tiene que crear un

> de
> > > ejecucion generico, ya que no sabe que contendra el parametro.
> > >
> > >
> > > Mi pregunta es,hay alguna manera de salvar esto y hacer que solo

> en
> > > la tabla necesaria? el procedimiento no se usa demasiado, asi que no

> > > importa que se recompile muchas veces.Yo he pensado en sql

> me
> > > parece un poco chapucero.
> > > Otra pregunta:Las tablas de operaciones mensuales son muy utilizadas

> mi
> > > sistema.Cuando ejecuto una select normal sobre la vista,si la

> es
> > > pesada se generan un monton de bloqueos en la bbdd.Sabeis a que

> ser
> > > debido?
> > >
> > > Gracias por todo y perdonar que no ponga los scripts pero no tengo
> acceso
> > > ahora mismo al servidor.Espero haber sido claro, cualquier ayuda la
> > > agradecere.
> > >
> > > Un saludo.
> > >
> > >
> > >
> > >
>
>
>

Aunque hicieramos lo que indicas seguiriamos teniendo el problema ya que el
asunto aqui es que sql server no sabe a priori que parametro entrara y crea
un plan de ejecucion generico.

"Entonces chequea los libros en linea, pues uno de los requisitos es que las
columnas por la que se particiona la data, forme parte de la clave primaria
de la tabla"
Lo nuestro nos una vista particionada Alejandro.Seguramente se pueda hacer
asi,pero no es nuestro caso.La primary key es como digo un autonumerico
porque nos interesa mas asi,ya que estas tablas se usan mucho y la consulta
por la que yo pregunto se ejecuta muy poco en comparacion con otras.Si
tenemos una constraint para impedir que los datos de esta columna se
solapen.
Tenemos ademas la vista montada sobre las tablas, y esta funciona
perfectamente menos en el tema que te indico del parametro.Aunque hicieramos
lo que indicas seguiriamos teniendo el problema ya que el asunto aqui es que
sql server no sabe a priori que parametro entrara y crea un plan de
ejecucion generico.

Gracias de todas formas y un saludo.

"Alejandro Mesa" escribió en el
mensaje news:
> Silverius,
>
> > Usamos Sql Server 2000 y no,no forma parte de la clave primaria.
> > La clave primaria es un simple autonumerico.
>
> Entonces chequea los libros en linea, pues uno de los requisitos es que
las
> columnas por la que se particiona la data, forme parte de la clave
primaria
> de la tabla.
>
> En el siguiente articulo, pon especial atencion en "Partitioning Column
> Rules".
>
> Creating a Partitioned View
>
http://msdn.microsoft.com/library/d...reatedb/cm
_8_des_06_17zr.asp
>
>
> AMB
>
> "Silverius" wrote:
>
> > Gracias Alejandro,
> > Usamos Sql Server 2000 y no,no forma parte de la clave primaria.
> > La clave primaria es un simple autonumerico.
> >
> >
> > "Alejandro Mesa" escribió en
el
> > mensaje news:
> > > Silverius,
> > >
> > > 1 - Que version de SQL Server usas?
> > >
> > > 2 - Basado en el comentario que esta a continuacion, sabes si la
columna
> > > [fecha] forma parte de la clave primaria de cada tabla?. Pudieras
postear
> > la
> > > definicion de la clave primaria?
> > >
> > > > .asi hasta varios meses (cada tabla tiene una constraint en
"fecha"
> > para
> > > > que los datos no puedan estar fuera de ese mes)
> > >
> > >
> > > AMB
> > >
> > > "Silverius" wrote:
> > >
> > > > Hola a todos,
> > > >
> > > > Tengo un conjunto de operaciones particionado por meses en varias
tablas
> > > >
> > > > create table OperacionesEnero(id int,codigo int,fecha datetime)
> > > > create table OperacionesFebrero(id int,codigo int,fecha datetime)
> > > > .asi hasta varios meses (cada tabla tiene una constraint en
"fecha"
> > para
> > > > que los datos no puedan estar fuera de ese mes)
> > > >
> > > > Y una vista que unifica estas tablas
> > > > create view VistaUnificada
> > > > as
> > > > select id,codigo,fecha from OperacionesEnero union all
> > > > select id,codigo,fecha from OperacionesEnero..
> > > >
> > > > Se que no es el mejor diseño, pero es como esta y cambiarlo nos es
ahora
> > > > mismo imposible.
> > > >
> > > > El caso es que cuando ejecuto una consulta, por ejemplo
> > > > select * from VistaUnificada where fecha='20060615',el plan de
consulta
> > > > muestra que solo se busca en la tabla de Junio.Pero cuendo hago un
> > > > procedimiento como:select * from VistaUnificada where fecha=@fecha y
lo
> > > > ejecuto, el plan de consulta muestra que se busca en todas las
tablas.En
> > la
> > > > practica,con el parametro tarda tambien muchisimo mas.
> > > > Entiendo que esto sera debido a que el servidor tiene que crear un
plan
> > de
> > > > ejecucion generico, ya que no sabe que contendra el parametro.
> > > >
> > > >
> > > > Mi pregunta es,hay alguna manera de salvar esto y hacer que solo
busque
> > en
> > > > la tabla necesaria? el procedimiento no se usa demasiado, asi que no
me
> > > > importa que se recompile muchas veces.Yo he pensado en sql
dinamico,pero
> > me
> > > > parece un poco chapucero.
> > > > Otra pregunta:Las tablas de operaciones mensuales son muy utilizadas
en
> > mi
> > > > sistema.Cuando ejecuto una select normal sobre la vista,si la
consulta
> > es
> > > > pesada se generan un monton de bloqueos en la bbdd.Sabeis a que
puede
> > ser
> > > > debido?
> > > >
> > > > Gracias por todo y perdonar que no ponga los scripts pero no tengo
> > acceso
> > > > ahora mismo al servidor.Espero haber sido claro, cualquier ayuda la
> > > > agradecere.
> > > >
> > > > Un saludo.
> > > >
> > > >
> > > >
> > > >
> >
> >
> >