Borrado extremadamente lento

Vuelvo a molestar otra vez, es que estoy un poco pez en el asunto.
¿El índice debe ser agrupado o no agrupado y con qué factor de relleno?

Gracias de nuevo.

Jesús.



"Salvador Ramos" escribió:

> Hola,
>
> Deberías añadir un índice a cada tabla por los campos que formen la clave
> externa (en tu caso por los dos). Las repercusiones en cuanto a los
> insert/update/delete sobre estas tablas no son significativas en absoluto,
> mientras que la mejora del rendimiento de tus consultas si que va a ser
> notable.
>
> Un saludo
> Salvador Ramos
> Murcia - España
>
> [Microsoft MVP SQL Server]
> www.helpdna.net (información sobre SQL Server y .NET)
>
>
> "Jesús" escribió en el mensaje
> news:
> > Gracias por la respuesta.
> > Otra pregunta a raíz de vuestros consejos. ¿El índice lo debería crear por
> > los dos campos o dos índices uno por cada campo?. ¿Cómo repercute el
> > añadir
> > esos índices en los SELECT, INSERT y UPDATES de esas tablas?
> >
> > De nuevo gracias por anticipado
> >
> >
> > "Jesús" escribió:
> >
> >> Hola:
> >> Necesito un poco de ayuda. Trato de explicar la situación. Tengo una
> >> tabla TA con su clave primaria compuesta de un sólo campo A y una tabla
> >> TB
> >> con su clave primaria compuesta de un sólo campo B. Con estas dos tablas
> >> implemento una relación muchos a muchos en una tabla TAB con clave
> >> primaria
> >> en los campos A y B que a su vez son clave ajena de las tablas TA y TB
> >> respectivamente. Además tengo 15 tablas con los campos A y B formando
> >> clave
> >> ajena contra la tabla TAB. Hasta aquí nada del otro mundo.
> >> Mi problema viene al intentar borrar registros de la tabla TAB de la
> >> forma "delete from TAB where A=@valor" ya que tarda una eternidad. El
> >> problema es evidentemente la integridad referencial ya que si antes del
> >> borrado deshabilito las relaciones de todas la tablas con la tabla TAB
> >> entonces el borrado es casi inmediato. Esto no es solución ya que en el
> >> periodo que están deshabilitadas las relaciones podrían entrar datos
> >> incoherentes. LA tabla TAB tiene 5 millones y medio de registros y las
> >> otras
> >> 15 tienen un media de casi el millón de registros.
> >> Por favor, ¿me podéis echar una mano para poder resolver esto? No sé
> >> por donde tratar de buscar la solución.
> >> Gracias de antemano y perdón por el tostón de explicación pero creo
> >> que
> >> era necesario.
> >>
> >> Jesús Corbí.
>
>
>

Jesús,

Esa pregunta solo la puedes constestar tu, porque eres quien conoces el
negocio, el tipo de queries que usas contra las tablas, la distribucion de
valores en esas llaves, etc. Por lo pronto prueba con nonclustered y con el
fillfactor que tiene el server por default y que puedes ver usando el
procedimineto sp_configure.


AMB

"Jesús" wrote:

> Vuelvo a molestar otra vez, es que estoy un poco pez en el asunto.
> ¿El índice debe ser agrupado o no agrupado y con qué factor de relleno?
>
> Gracias de nuevo.
>
> Jesús.
>
>
>
> "Salvador Ramos" escribió:
>
> > Hola,
> >
> > Deberías añadir un índice a cada tabla por los campos que formen la clave
> > externa (en tu caso por los dos). Las repercusiones en cuanto a los
> > insert/update/delete sobre estas tablas no son significativas en absoluto,
> > mientras que la mejora del rendimiento de tus consultas si que va a ser
> > notable.
> >
> > Un saludo
> > Salvador Ramos
> > Murcia - España
> >
> > [Microsoft MVP SQL Server]
> > www.helpdna.net (información sobre SQL Server y .NET)
> >
> >
> > "Jesús" escribió en el mensaje
> > news:
> > > Gracias por la respuesta.
> > > Otra pregunta a raíz de vuestros consejos. ¿El índice lo debería crear por
> > > los dos campos o dos índices uno por cada campo?. ¿Cómo repercute el
> > > añadir
> > > esos índices en los SELECT, INSERT y UPDATES de esas tablas?
> > >
> > > De nuevo gracias por anticipado
> > >
> > >
> > > "Jesús" escribió:
> > >
> > >> Hola:
> > >> Necesito un poco de ayuda. Trato de explicar la situación. Tengo una
> > >> tabla TA con su clave primaria compuesta de un sólo campo A y una tabla
> > >> TB
> > >> con su clave primaria compuesta de un sólo campo B. Con estas dos tablas
> > >> implemento una relación muchos a muchos en una tabla TAB con clave
> > >> primaria
> > >> en los campos A y B que a su vez son clave ajena de las tablas TA y TB
> > >> respectivamente. Además tengo 15 tablas con los campos A y B formando
> > >> clave
> > >> ajena contra la tabla TAB. Hasta aquí nada del otro mundo.
> > >> Mi problema viene al intentar borrar registros de la tabla TAB de la
> > >> forma "delete from TAB where A=@valor" ya que tarda una eternidad. El
> > >> problema es evidentemente la integridad referencial ya que si antes del
> > >> borrado deshabilito las relaciones de todas la tablas con la tabla TAB
> > >> entonces el borrado es casi inmediato. Esto no es solución ya que en el
> > >> periodo que están deshabilitadas las relaciones podrían entrar datos
> > >> incoherentes. LA tabla TAB tiene 5 millones y medio de registros y las
> > >> otras
> > >> 15 tienen un media de casi el millón de registros.
> > >> Por favor, ¿me podéis echar una mano para poder resolver esto? No sé
> > >> por donde tratar de buscar la solución.
> > >> Gracias de antemano y perdón por el tostón de explicación pero creo
> > >> que
> > >> era necesario.
> > >>
> > >> Jesús Corbí.
> >
> >
> >

Gracias de nuevo, sólo quería saber en qué medida afecta el hecho de
elegir
un factor de relleno u otro y rellenear o no el índice. Algo así cómo "a
mayor factor de relleno mejoran los SELECT y empeoran los INSERT" si es
que
tiene algo que ver.
Independientemente de esto, vuestra ayuda hata el momento resulta muy
valiosa.

Saludos

Jesús

"Alejandro Mesa" escribió:

Jesús,

Esa pregunta solo la puedes constestar tu, porque eres quien conoces el
negocio, el tipo de queries que usas contra las tablas, la distribucion
de
valores en esas llaves, etc. Por lo pronto prueba con nonclustered y con
el
fillfactor que tiene el server por default y que puedes ver usando el
procedimineto sp_configure.


AMB

"Jesús" wrote:

> Vuelvo a molestar otra vez, es que estoy un poco pez en el asunto.
> ¿El índice debe ser agrupado o no agrupado y con qué factor de relleno?
>
> Gracias de nuevo.
>
> Jesús.
>
>
>
> "Salvador Ramos" escribió:
>
> > Hola,
> >
> > Deberías añadir un índice a cada tabla por los campos que formen la
> > clave
> > externa (en tu caso por los dos). Las repercusiones en cuanto a los
> > insert/update/delete sobre estas tablas no son significativas en
> > absoluto,
> > mientras que la mejora del rendimiento de tus consultas si que va a
> > ser
> > notable.
> >
> > Un saludo
> > Salvador Ramos
> > Murcia - España
> >
> > [Microsoft MVP SQL Server]
> > www.helpdna.net (información sobre SQL Server y .NET)
> >
> >
> > "Jesús" escribió en el mensaje
> > news:
> > > Gracias por la respuesta.
> > > Otra pregunta a raíz de vuestros consejos. ¿El índice lo debería
> > > crear por
> > > los dos campos o dos índices uno por cada campo?. ¿Cómo repercute
> > > el
> > > añadir
> > > esos índices en los SELECT, INSERT y UPDATES de esas tablas?
> > >
> > > De nuevo gracias por anticipado
> > >
> > >
> > > "Jesús" escribió:
> > >
> > >> Hola:
> > >> Necesito un poco de ayuda. Trato de explicar la situación.
> > >> Tengo una
> > >> tabla TA con su clave primaria compuesta de un sólo campo A y una
> > >> tabla
> > >> TB
> > >> con su clave primaria compuesta de un sólo campo B. Con estas dos
> > >> tablas
> > >> implemento una relación muchos a muchos en una tabla TAB con clave
> > >> primaria
> > >> en los campos A y B que a su vez son clave ajena de las tablas TA
> > >> y TB
> > >> respectivamente. Además tengo 15 tablas con los campos A y B
> > >> formando
> > >> clave
> > >> ajena contra la tabla TAB. Hasta aquí nada del otro mundo.
> > >> Mi problema viene al intentar borrar registros de la tabla
> > >> TAB de la
> > >> forma "delete from TAB where A=@valor" ya que tarda una eternidad.
> > >> El
> > >> problema es evidentemente la integridad referencial ya que si
> > >> antes del
> > >> borrado deshabilito las relaciones de todas la tablas con la tabla
> > >> TAB
> > >> entonces el borrado es casi inmediato. Esto no es solución ya que
> > >> en el
> > >> periodo que están deshabilitadas las relaciones podrían entrar
> > >> datos
> > >> incoherentes. LA tabla TAB tiene 5 millones y medio de registros y
> > >> las
> > >> otras
> > >> 15 tienen un media de casi el millón de registros.
> > >> Por favor, ¿me podéis echar una mano para poder resolver
> > >> esto? No sé
> > >> por donde tratar de buscar la solución.
> > >> Gracias de antemano y perdón por el tostón de explicación
> > >> pero creo
> > >> que
> > >> era necesario.
> > >>
> > >> Jesús Corbí.
> >
> >
> >

Si las consultas que realizas son principalmente de lectura, puedes ajustar
el factor de relleno incluso a menor del 10%. Sino, es mejor que lo
mantengas o incluso puede llegar a interesar subirlo. El factor de relleno
involucra el espacio libre que se deja en las páginas de la BBDD para ser
utilizados por registros después de un INSERT, o UPDATE. Si la BBDD tiene
que depositar un registro en una página que está llena, se produce una
rotura de página, es decir, se necesita crear una página adicional y
distribuir los registros entre ambas páginas. Esto puede llegar a conllevar
un rebalanceo en el Arbol (las páginas suelen formar un Arbol B). Si sufres
muchas inserciones y modificaciones y tienes las páginas llenas, una gran
cantidad de roturas de páginas puede afectar considerablemente al
rendimiento de tu servicio debido al aumento de consumo en IOs del sistema.
Suele ser también bueno, crearse Planes de Mantenimiento.

Saludos,
Guillermo Roldán


"Jesús" escribió en el mensaje
news:
> Gracias de nuevo, sólo quería saber en qué medida afecta el hecho de
> elegir
> un factor de relleno u otro y rellenear o no el índice. Algo así cómo "a
> mayor factor de relleno mejoran los SELECT y empeoran los INSERT" si es
> que
> tiene algo que ver.
> Independientemente de esto, vuestra ayuda hata el momento resulta muy
> valiosa.
>
> Saludos
>
> Jesús
>
> "Alejandro Mesa" escribió:
>
>> Jesús,
>>
>> Esa pregunta solo la puedes constestar tu, porque eres quien conoces el
>> negocio, el tipo de queries que usas contra las tablas, la distribucion
>> de
>> valores en esas llaves, etc. Por lo pronto prueba con nonclustered y con
>> el
>> fillfactor que tiene el server por default y que puedes ver usando el
>> procedimineto sp_configure.
>>
>>
>> AMB
>>
>> "Jesús" wrote:
>>
>> > Vuelvo a molestar otra vez, es que estoy un poco pez en el asunto.
>> > ¿El índice debe ser agrupado o no agrupado y con qué factor de relleno?
>> >
>> > Gracias de nuevo.
>> >
>> > Jesús.
>> >
>> >
>> >
>> > "Salvador Ramos" escribió:
>> >
>> > > Hola,
>> > >
>> > > Deberías añadir un índice a cada tabla por los campos que formen la
>> > > clave
>> > > externa (en tu caso por los dos). Las repercusiones en cuanto a los
>> > > insert/update/delete sobre estas tablas no son significativas en
>> > > absoluto,
>> > > mientras que la mejora del rendimiento de tus consultas si que va a
>> > > ser
>> > > notable.
>> > >
>> > > Un saludo
>> > > Salvador Ramos
>> > > Murcia - España
>> > >
>> > > [Microsoft MVP SQL Server]
>> > > www.helpdna.net (información sobre SQL Server y .NET)
>> > >
>> > >
>> > > "Jesús" escribió en el mensaje
>> > > news:
>> > > > Gracias por la respuesta.
>> > > > Otra pregunta a raíz de vuestros consejos. ¿El índice lo debería
>> > > > crear por
>> > > > los dos campos o dos índices uno por cada campo?. ¿Cómo repercute
>> > > > el
>> > > > añadir
>> > > > esos índices en los SELECT, INSERT y UPDATES de esas tablas?
>> > > >
>> > > > De nuevo gracias por anticipado
>> > > >
>> > > >
>> > > > "Jesús" escribió:
>> > > >
>> > > >> Hola:
>> > > >> Necesito un poco de ayuda. Trato de explicar la situación.
>> > > >> Tengo una
>> > > >> tabla TA con su clave primaria compuesta de un sólo campo A y una
>> > > >> tabla
>> > > >> TB
>> > > >> con su clave primaria compuesta de un sólo campo B. Con estas dos
>> > > >> tablas
>> > > >> implemento una relación muchos a muchos en una tabla TAB con clave
>> > > >> primaria
>> > > >> en los campos A y B que a su vez son clave ajena de las tablas TA
>> > > >> y TB
>> > > >> respectivamente. Además tengo 15 tablas con los campos A y B
>> > > >> formando
>> > > >> clave
>> > > >> ajena contra la tabla TAB. Hasta aquí nada del otro mundo.
>> > > >> Mi problema viene al intentar borrar registros de la tabla
>> > > >> TAB de la
>> > > >> forma "delete from TAB where A=@valor" ya que tarda una eternidad.
>> > > >> El
>> > > >> problema es evidentemente la integridad referencial ya que si
>> > > >> antes del
>> > > >> borrado deshabilito las relaciones de todas la tablas con la tabla
>> > > >> TAB
>> > > >> entonces el borrado es casi inmediato. Esto no es solución ya que
>> > > >> en el
>> > > >> periodo que están deshabilitadas las relaciones podrían entrar
>> > > >> datos
>> > > >> incoherentes. LA tabla TAB tiene 5 millones y medio de registros y
>> > > >> las
>> > > >> otras
>> > > >> 15 tienen un media de casi el millón de registros.
>> > > >> Por favor, ¿me podéis echar una mano para poder resolver
>> > > >> esto? No sé
>> > > >> por donde tratar de buscar la solución.
>> > > >> Gracias de antemano y perdón por el tostón de explicación
>> > > >> pero creo
>> > > >> que
>> > > >> era necesario.
>> > > >>
>> > > >> Jesús Corbí.
>> > >
>> > >
>> > >

Si las consultas que realizas son principalmente de lectura, puedes ajustar
el factor de relleno incluso a menor del 10%. Sino, es mejor que lo
mantengas o incluso puede llegar a interesar subirlo. El factor de relleno
involucra el espacio libre que se deja en las páginas de la BBDD para ser
utilizados por registros después de un INSERT, o UPDATE. Si la BBDD tiene
que depositar un registro en una página que está llena, se produce una
rotura de página, es decir, se necesita crear una página adicional y
distribuir los registros entre ambas páginas. Esto puede llegar a conllevar
un rebalanceo en el Arbol (las páginas suelen formar un Arbol B). Si sufres
muchas inserciones y modificaciones y tienes las páginas llenas, una gran
cantidad de roturas de páginas puede afectar considerablemente al
rendimiento de tu servicio debido al aumento de consumo en IOs del sistema.
Suele ser también bueno, crearse Planes de Mantenimiento.

Saludos,
Guillermo Roldán


"Jesús" escribió en el mensaje
news:
> Gracias de nuevo, sólo quería saber en qué medida afecta el hecho de
> elegir
> un factor de relleno u otro y rellenear o no el índice. Algo así cómo "a
> mayor factor de relleno mejoran los SELECT y empeoran los INSERT" si es
> que
> tiene algo que ver.
> Independientemente de esto, vuestra ayuda hata el momento resulta muy
> valiosa.
>
> Saludos
>
> Jesús
>
> "Alejandro Mesa" escribió:
>
>> Jesús,
>>
>> Esa pregunta solo la puedes constestar tu, porque eres quien conoces el
>> negocio, el tipo de queries que usas contra las tablas, la distribucion
>> de
>> valores en esas llaves, etc. Por lo pronto prueba con nonclustered y con
>> el
>> fillfactor que tiene el server por default y que puedes ver usando el
>> procedimineto sp_configure.
>>
>>
>> AMB
>>
>> "Jesús" wrote:
>>
>> > Vuelvo a molestar otra vez, es que estoy un poco pez en el asunto.
>> > ¿El índice debe ser agrupado o no agrupado y con qué factor de relleno?
>> >
>> > Gracias de nuevo.
>> >
>> > Jesús.
>> >
>> >
>> >
>> > "Salvador Ramos" escribió:
>> >
>> > > Hola,
>> > >
>> > > Deberías añadir un índice a cada tabla por los campos que formen la
>> > > clave
>> > > externa (en tu caso por los dos). Las repercusiones en cuanto a los
>> > > insert/update/delete sobre estas tablas no son significativas en
>> > > absoluto,
>> > > mientras que la mejora del rendimiento de tus consultas si que va a
>> > > ser
>> > > notable.
>> > >
>> > > Un saludo
>> > > Salvador Ramos
>> > > Murcia - España
>> > >
>> > > [Microsoft MVP SQL Server]
>> > > www.helpdna.net (información sobre SQL Server y .NET)
>> > >
>> > >
>> > > "Jesús" escribió en el mensaje
>> > > news:
>> > > > Gracias por la respuesta.
>> > > > Otra pregunta a raíz de vuestros consejos. ¿El índice lo debería
>> > > > crear por
>> > > > los dos campos o dos índices uno por cada campo?. ¿Cómo repercute
>> > > > el
>> > > > añadir
>> > > > esos índices en los SELECT, INSERT y UPDATES de esas tablas?
>> > > >
>> > > > De nuevo gracias por anticipado
>> > > >
>> > > >
>> > > > "Jesús" escribió:
>> > > >
>> > > >> Hola:
>> > > >> Necesito un poco de ayuda. Trato de explicar la situación.
>> > > >> Tengo una
>> > > >> tabla TA con su clave primaria compuesta de un sólo campo A y una
>> > > >> tabla
>> > > >> TB
>> > > >> con su clave primaria compuesta de un sólo campo B. Con estas dos
>> > > >> tablas
>> > > >> implemento una relación muchos a muchos en una tabla TAB con clave
>> > > >> primaria
>> > > >> en los campos A y B que a su vez son clave ajena de las tablas TA
>> > > >> y TB
>> > > >> respectivamente. Además tengo 15 tablas con los campos A y B
>> > > >> formando
>> > > >> clave
>> > > >> ajena contra la tabla TAB. Hasta aquí nada del otro mundo.
>> > > >> Mi problema viene al intentar borrar registros de la tabla
>> > > >> TAB de la
>> > > >> forma "delete from TAB where A=@valor" ya que tarda una eternidad.
>> > > >> El
>> > > >> problema es evidentemente la integridad referencial ya que si
>> > > >> antes del
>> > > >> borrado deshabilito las relaciones de todas la tablas con la tabla
>> > > >> TAB
>> > > >> entonces el borrado es casi inmediato. Esto no es solución ya que
>> > > >> en el
>> > > >> periodo que están deshabilitadas las relaciones podrían entrar
>> > > >> datos
>> > > >> incoherentes. LA tabla TAB tiene 5 millones y medio de registros y
>> > > >> las
>> > > >> otras
>> > > >> 15 tienen un media de casi el millón de registros.
>> > > >> Por favor, ¿me podéis echar una mano para poder resolver
>> > > >> esto? No sé
>> > > >> por donde tratar de buscar la solución.
>> > > >> Gracias de antemano y perdón por el tostón de explicación
>> > > >> pero creo
>> > > >> que
>> > > >> era necesario.
>> > > >>
>> > > >> Jesús Corbí.
>> > >
>> > >
>> > >