plan de ejecucion de procedimiento sobre vista

Silverius,

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.

Lamento no coincidir contigo en este punto. Para eso mismo son las vistas
particionadas, para evitar que sql server tenga que buscar el valor en
todas
las tablas que conforman la vista e ir directamente a buscar en la tabla
cuya
particion se adecua con el valor a buscar.


AMB


"Silverius" wrote:

"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.
> > > >
> > > >
> > > >
> > > >
> >
> >
> >

Silverius,

> Aunque hicieramos lo que indicas seguiriamos teniendo el problema ya que

> asunto aqui es que sql server no sabe a priori que parametro entrara y

> un plan de ejecucion generico.

Lamento no coincidir contigo en este punto. Para eso mismo son las vistas
particionadas, para evitar que sql server tenga que buscar el valor en

las tablas que conforman la vista e ir directamente a buscar en la tabla

particion se adecua con el valor a buscar.


AMB


"Silverius" wrote:

>
> "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"
> Lo nuestro nos una vista particionada Alejandro.Seguramente se pueda

> 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

> 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

> lo que indicas seguiriamos teniendo el problema ya que el asunto aqui es

> 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

> 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

> 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

> > Rules".
> >
> > Creating a Partitioned View
> >
>

> _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ó

> 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

> tablas
> > > > >
> > > > > create table OperacionesEnero(id int,codigo int,fecha datetime)
> > > > > create table OperacionesFebrero(id int,codigo int,fecha

> > > > > .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

> 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

> > > > > procedimiento como:select * from VistaUnificada where

> 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

> 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

> 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

> 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

> > > acceso
> > > > > ahora mismo al servidor.Espero haber sido claro, cualquier ayuda

> > > > > agradecere.
> > > > >
> > > > > Un saludo.
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
>
>
>