Borrado extremadamente lento

Perdón por el mensaje anterior vacío. Se me fue el dedo...
Si lo he entendido bien, lo malo de esto es que se tenga que crear una
página nueva al hacer una inserción, pero supongo que tampoco será muy
eficiente tener muchas páginas pero bastante vacías cada una. Tanto las
inserciones como las consultas están bastante equilibradas en estas
tablas,
¿me lleva esto a pensar que una solución salomónica de un factor del 50%
es
adecuado o no tiene nada que ver?

Gracias otra vez.

Jesús.

"Guillermo Roldán" escribió:

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