Problemas de indices

Hola Carlo,

El resultado final es el mismo, se reconstruyen los indices y se mejora la
dispersion de datos. Lo novedoso es que este comando permite ejecutar la
reconstrucción a todos los indices de una tabla y no uno a uno como con la
otra instrucción. O ejecutando el DROP y CREATE Index.

Tinoco

"Carlo Sorrel" wrote:

Hola, permiso, Hemilson, tengo una pregunta, es bueno utilizar el comando
dbreindex..???, cual es mejor..???
Gracias.

Atte.,
Carlo Sorrel

"Tinoco" escribió en el mensaje
news:
> Jorge,
>
> Ejecutar la instruccion DROP_EXISTING en un indice Clustered, implica que
> tambien se deben reconstruir los indices Nonclustered.
>
> Para que una consulta funcione bien se debe mejorar el Script de la
consulta
> y si es necesario se debe crear indice(s) para mejorar su desempeño. las
dos
> cosas van directamente relacionadas.
>
> Hermilson Tinoco
>
> "Jorge Costilla" wrote:
>
> > Estimado Hermilson:
> >
> > Desde ya muchisimas gracias por tu respuesta. Ahora, mi pregunta es la
> > siguiente: esta tarea que hice no causa problemas en los indices, no?
Porque
> > las personas que dan soporte a la aplicacion sugieren que son los
indices
> > .Y es muy probable que no sea esoSino algo relacionado como vos
> > decis, a las consultas.
> > "Tinoco" escribió en el mensaje
> > news:
> > > Hola Jorge,
> > >
> > > Mejorar la densidad de un indice, no impica la mejora el performance
de
> > > una
> > > consulta, lo mejor es revisar el plan de ejecución de las consultas
> > > utilizadas para esta tabla y acondicionar los indices acorde a las
> > > necesidades de las mismas.
> > >
> > > Hermilson Tinoco
> > > Colombia
> > >
> > > "Jorge Costilla" wrote:
> > >
> > >> Estimados:
> > >>
> > >> Tengo un inconveniente. Tengo una tabla de casi 1 G la cual tiene un
> > >> indice
> > >> agrupado y 4 no agrupados. He ejecutado el comando DBCC SHOWCOnTIG y
me
> > >> dejo
> > >> como resultado un bajo valor (32%) en Scan Density. Luego de correr
el
> > >> comando CREATE CLUSTERED INDEX [col1] ON tabla1 (col1) WITH
> > >> DROP_EXISTING,
> > >> mejoro el porcentaje a 99 %.
> > >> Ahora, mi pregunta es: que paso con los otros indices no agrupado?
Puede
> > >> que
> > >> se defragmento bien pero que no mejore la performance? Desde ya,
> > >> cualquier
> > >> comentario sera agradecido. Un abrazo.
> > >>
> > >>
> > >>
> > >>
> >
> >
> >
> >

Disculpen muchachos, con todas sus respuestas me anduve enredando un poco,
por lo que entiendo el comando dbreindex seria bueno entonces...???,
pregunto ya que hace bastante tiempo que lo utilizo y me ha dado buenos
resultados, en lo que respecta al tiempo de ejecución y la calidad de la
reconstrucción.
Disculpen pero hoy amaneci un poco duro de entender
Gracias nuevamente.
Saludos.

Atte.,
Carlo Sorrel

"Alejandro Mesa" escribió en el
mensaje news:

Tinoco,

> Ejecutar la instruccion DROP_EXISTING en un indice Clustered, implica

que

> tambien se deben reconstruir los indices Nonclustered.

Esto se debe hacer manualmente, pues los indices nonclustered seran
reconstruidos automaticamente solamente si las llaves del indice clustered
son diferentes. Esa es una de las ventajas de esta opcion.


AMB

"Tinoco" wrote:

> Jorge,
>
> Ejecutar la instruccion DROP_EXISTING en un indice Clustered, implica

que

> tambien se deben reconstruir los indices Nonclustered.
>
> Para que una consulta funcione bien se debe mejorar el Script de la

consulta

> y si es necesario se debe crear indice(s) para mejorar su desempeño. las

dos

> cosas van directamente relacionadas.
>
> Hermilson Tinoco
>
> "Jorge Costilla" wrote:
>
> > Estimado Hermilson:
> >
> > Desde ya muchisimas gracias por tu respuesta. Ahora, mi pregunta es la
> > siguiente: esta tarea que hice no causa problemas en los indices, no?

Porque

> > las personas que dan soporte a la aplicacion sugieren que son los

indices

> > .Y es muy probable que no sea esoSino algo relacionado como

vos

> > decis, a las consultas.
> > "Tinoco" escribió en el mensaje
> > news:
> > > Hola Jorge,
> > >
> > > Mejorar la densidad de un indice, no impica la mejora el performance

de

> > > una
> > > consulta, lo mejor es revisar el plan de ejecución de las consultas
> > > utilizadas para esta tabla y acondicionar los indices acorde a las
> > > necesidades de las mismas.
> > >
> > > Hermilson Tinoco
> > > Colombia
> > >
> > > "Jorge Costilla" wrote:
> > >
> > >> Estimados:
> > >>
> > >> Tengo un inconveniente. Tengo una tabla de casi 1 G la cual tiene

un

> > >> indice
> > >> agrupado y 4 no agrupados. He ejecutado el comando DBCC SHOWCOnTIG

y me

> > >> dejo
> > >> como resultado un bajo valor (32%) en Scan Density. Luego de correr

el

> > >> comando CREATE CLUSTERED INDEX [col1] ON tabla1 (col1) WITH
> > >> DROP_EXISTING,
> > >> mejoro el porcentaje a 99 %.
> > >> Ahora, mi pregunta es: que paso con los otros indices no agrupado?

Puede

> > >> que
> > >> se defragmento bien pero que no mejore la performance? Desde ya,
> > >> cualquier
> > >> comentario sera agradecido. Un abrazo.
> > >>
> > >>
> > >>
> > >>
> >
> >
> >
> >

Carlo,

Este comando es muy util (DBCC DBREINDEX), el unico inconveniente es una
operacion offline, osea nadie debe estar usando la tabla. El punto de Tinoco
(comparto su comentario) es que no solamente reindexando o defragmentando un
indice, la consulta sera mas rapido. Primero se debe leer el plan de
ejecucion, despues, bueno eso depende del plan.


AMB

"Carlo Sorrel" wrote:

Disculpen muchachos, con todas sus respuestas me anduve enredando un poco,
por lo que entiendo el comando dbreindex seria bueno entonces...???,
pregunto ya que hace bastante tiempo que lo utilizo y me ha dado buenos
resultados, en lo que respecta al tiempo de ejecución y la calidad de la
reconstrucción.
Disculpen pero hoy amaneci un poco duro de entender
Gracias nuevamente.
Saludos.

Atte.,
Carlo Sorrel

"Alejandro Mesa" escribió en el
mensaje news:
> Tinoco,
>
> > Ejecutar la instruccion DROP_EXISTING en un indice Clustered, implica
que
> > tambien se deben reconstruir los indices Nonclustered.
>
> Esto se debe hacer manualmente, pues los indices nonclustered seran
> reconstruidos automaticamente solamente si las llaves del indice clustered
> son diferentes. Esa es una de las ventajas de esta opcion.
>
>
> AMB
>
> "Tinoco" wrote:
>
> > Jorge,
> >
> > Ejecutar la instruccion DROP_EXISTING en un indice Clustered, implica
que
> > tambien se deben reconstruir los indices Nonclustered.
> >
> > Para que una consulta funcione bien se debe mejorar el Script de la
consulta
> > y si es necesario se debe crear indice(s) para mejorar su desempeño. las
dos
> > cosas van directamente relacionadas.
> >
> > Hermilson Tinoco
> >
> > "Jorge Costilla" wrote:
> >
> > > Estimado Hermilson:
> > >
> > > Desde ya muchisimas gracias por tu respuesta. Ahora, mi pregunta es la
> > > siguiente: esta tarea que hice no causa problemas en los indices, no?
Porque
> > > las personas que dan soporte a la aplicacion sugieren que son los
indices
> > > .Y es muy probable que no sea esoSino algo relacionado como
vos
> > > decis, a las consultas.
> > > "Tinoco" escribió en el mensaje
> > > news:
> > > > Hola Jorge,
> > > >
> > > > Mejorar la densidad de un indice, no impica la mejora el performance
de
> > > > una
> > > > consulta, lo mejor es revisar el plan de ejecución de las consultas
> > > > utilizadas para esta tabla y acondicionar los indices acorde a las
> > > > necesidades de las mismas.
> > > >
> > > > Hermilson Tinoco
> > > > Colombia
> > > >
> > > > "Jorge Costilla" wrote:
> > > >
> > > >> Estimados:
> > > >>
> > > >> Tengo un inconveniente. Tengo una tabla de casi 1 G la cual tiene
un
> > > >> indice
> > > >> agrupado y 4 no agrupados. He ejecutado el comando DBCC SHOWCOnTIG
y me
> > > >> dejo
> > > >> como resultado un bajo valor (32%) en Scan Density. Luego de correr
el
> > > >> comando CREATE CLUSTERED INDEX [col1] ON tabla1 (col1) WITH
> > > >> DROP_EXISTING,
> > > >> mejoro el porcentaje a 99 %.
> > > >> Ahora, mi pregunta es: que paso con los otros indices no agrupado?
Puede
> > > >> que
> > > >> se defragmento bien pero que no mejore la performance? Desde ya,
> > > >> cualquier
> > > >> comentario sera agradecido. Un abrazo.
> > > >>
> > > >>
> > > >>
> > > >>
> > >
> > >
> > >
> > >

Si, eso es verdad..., sólo lo puedo correr fuera de horario, y
desgracidamente no puedo modificar las estructuras de las tablas (lo que
mas quisiera yo es poder mejorar eso), pero es un ERP, y no me permiten
hacer modificaciones porque el proveedor no sabe "que puede suceder",
increible no...??
Gracias y saludos.

Atte.,
Carlo Sorrel
Chile.

"Alejandro Mesa" escribió en el
mensaje news:

Carlo,

Este comando es muy util (DBCC DBREINDEX), el unico inconveniente es una
operacion offline, osea nadie debe estar usando la tabla. El punto de

Tinoco

(comparto su comentario) es que no solamente reindexando o defragmentando

un

indice, la consulta sera mas rapido. Primero se debe leer el plan de
ejecucion, despues, bueno eso depende del plan.


AMB

"Carlo Sorrel" wrote:

> Disculpen muchachos, con todas sus respuestas me anduve enredando un

poco,

> por lo que entiendo el comando dbreindex seria bueno entonces...???,
> pregunto ya que hace bastante tiempo que lo utilizo y me ha dado buenos
> resultados, en lo que respecta al tiempo de ejecución y la calidad de la
> reconstrucción.
> Disculpen pero hoy amaneci un poco duro de entender
> Gracias nuevamente.
> Saludos.
>
> Atte.,
> Carlo Sorrel
>
> "Alejandro Mesa" escribió en

el

> mensaje news:
> > Tinoco,
> >
> > > Ejecutar la instruccion DROP_EXISTING en un indice Clustered,

implica

> que
> > > tambien se deben reconstruir los indices Nonclustered.
> >
> > Esto se debe hacer manualmente, pues los indices nonclustered seran
> > reconstruidos automaticamente solamente si las llaves del indice

clustered

> > son diferentes. Esa es una de las ventajas de esta opcion.
> >
> >
> > AMB
> >
> > "Tinoco" wrote:
> >
> > > Jorge,
> > >
> > > Ejecutar la instruccion DROP_EXISTING en un indice Clustered,

implica

> que
> > > tambien se deben reconstruir los indices Nonclustered.
> > >
> > > Para que una consulta funcione bien se debe mejorar el Script de la
> consulta
> > > y si es necesario se debe crear indice(s) para mejorar su desempeño.

las

> dos
> > > cosas van directamente relacionadas.
> > >
> > > Hermilson Tinoco
> > >
> > > "Jorge Costilla" wrote:
> > >
> > > > Estimado Hermilson:
> > > >
> > > > Desde ya muchisimas gracias por tu respuesta. Ahora, mi pregunta

es la

> > > > siguiente: esta tarea que hice no causa problemas en los indices,

no?

> Porque
> > > > las personas que dan soporte a la aplicacion sugieren que son los
> indices
> > > > .Y es muy probable que no sea esoSino algo relacionado

como

> vos
> > > > decis, a las consultas.
> > > > "Tinoco" escribió en el mensaje
> > > > news:
> > > > > Hola Jorge,
> > > > >
> > > > > Mejorar la densidad de un indice, no impica la mejora el

performance

> de
> > > > > una
> > > > > consulta, lo mejor es revisar el plan de ejecución de las

consultas

> > > > > utilizadas para esta tabla y acondicionar los indices acorde a

las

> > > > > necesidades de las mismas.
> > > > >
> > > > > Hermilson Tinoco
> > > > > Colombia
> > > > >
> > > > > "Jorge Costilla" wrote:
> > > > >
> > > > >> Estimados:
> > > > >>
> > > > >> Tengo un inconveniente. Tengo una tabla de casi 1 G la cual

tiene

> un
> > > > >> indice
> > > > >> agrupado y 4 no agrupados. He ejecutado el comando DBCC

SHOWCOnTIG

> y me
> > > > >> dejo
> > > > >> como resultado un bajo valor (32%) en Scan Density. Luego de

correr

> el
> > > > >> comando CREATE CLUSTERED INDEX [col1] ON tabla1 (col1) WITH
> > > > >> DROP_EXISTING,
> > > > >> mejoro el porcentaje a 99 %.
> > > > >> Ahora, mi pregunta es: que paso con los otros indices no

agrupado?

> Puede
> > > > >> que
> > > > >> se defragmento bien pero que no mejore la performance? Desde

ya,

> > > > >> cualquier
> > > > >> comentario sera agradecido. Un abrazo.
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > >
> > > >
> > > >
> > > >
>
>
>