Planes de Ejecución...

Si, de hecho estoy haciendo eso, y hasta el momento no he tenido que
actualizar las estadisticas entre semana. Mi problema es lo que comente en
el post inicial, no se que puede estar pasando. El contador Procedure Cache
Pages ha baja a un tercio de lo habitual, el Lazy Writes/sec a aumentado al
doble, el Page Life Expectancy a disminuido a la Mitad, el Page Splits/sec
aumento de 7 a 9 (el promedio), con máximos el dóble de la semana anterior.
No se si estos datos te indican algo...

Atte.,
Carlo
"Alejandro Mesa" escribió en el
mensaje news:

Carlo,

Si la desactivastes, entonces tendras que hacer un analizis de cuanto se
inserta, elimina y actualiza sobre esas tablas para ver si es necesario
actualizar las estadisticas con mas frecuencia y no una vez a la semana.
Microsoft recomienda, que de ser posible, se actualizen diariamente,
incluso
con la opcion "auto update statistics" prendida.


AMB


"Carlo" wrote:

No, la desactive hace un par de meses, ya que la base pesa 350 GB, y me
actualizaba las estadisticas con muestras muy pequeñas que bajaban el
performance.

Atte.,
Carlo
"Alejandro Mesa" escribió en el
mensaje news:
> Carlo,
>
> Esa db tiene encendida la opcion "auto update statistics"?
>
> select databaseproperty('nombre_de_tu_db', 'IsAutoUpdateStatistics')
> go
>
>
> AMB
>
>
> "Carlo" wrote:
>
>> Estimados, alguna idea de adonde guarda SQL los Planes de Ejecución de
>> las
>> consultas...???, estoy revisando algo que no termino de entender, les
>> explico. Tengo mi plan de mantenimiento que se ejecuta todos los días
>> Domingo de cada semana, el cual me reindexa y me actualiza las
>> estadisticas
>> de mis tablas. Pero cuando por alguna razón ese Plan de ejecución no
>> se
>> ejecuta por algún error, la semana que sigue a este error funciona
>> todo
>> ok.
>> El domingo siguiente se ejecuta el Plan de Mantenimiento sin errores,
>> y
>> en
>> la semana se quejan que el "Sistema" anda lento. Despues de otra
>> semana
>> que
>> se ejecute en forma normal, vuelve a su comportamiento normal. Como
>> que
>> algo
>> pierde, y creo que son los Planes de ejecución (CREO). Si alguien
>> tiene
>> otra
>> teoria o me puede explicar este extraño comportamiento se lo
>> agradeceria.
>> 2 Servidores en Cluster con Windows 2003 SP1, SQL Server Enterprise
>> Edition
>> SP3a instalado en Cluster, 12 GB RAM, AWE habilitado, 10,5 Gb de RAM a
>> SQL.
>>
>> Atte.,
>> Carlo
>>
>>
>>

Carlo,

Me pregunto si por casualidad ese mantenimiento incluye encojer la db (dbcc
shrinkdatabase)?


AMB


"Carlo" wrote:

Si, de hecho estoy haciendo eso, y hasta el momento no he tenido que
actualizar las estadisticas entre semana. Mi problema es lo que comente en
el post inicial, no se que puede estar pasando. El contador Procedure Cache
Pages ha baja a un tercio de lo habitual, el Lazy Writes/sec a aumentado al
doble, el Page Life Expectancy a disminuido a la Mitad, el Page Splits/sec
aumento de 7 a 9 (el promedio), con máximos el dóble de la semana anterior.
No se si estos datos te indican algo...

Atte.,
Carlo
"Alejandro Mesa" escribió en el
mensaje news:
> Carlo,
>
> Si la desactivastes, entonces tendras que hacer un analizis de cuanto se
> inserta, elimina y actualiza sobre esas tablas para ver si es necesario
> actualizar las estadisticas con mas frecuencia y no una vez a la semana.
> Microsoft recomienda, que de ser posible, se actualizen diariamente,
> incluso
> con la opcion "auto update statistics" prendida.
>
>
> AMB
>
>
> "Carlo" wrote:
>
>> No, la desactive hace un par de meses, ya que la base pesa 350 GB, y me
>> actualizaba las estadisticas con muestras muy pequeñas que bajaban el
>> performance.
>>
>> Atte.,
>> Carlo
>> "Alejandro Mesa" escribió en el
>> mensaje news:
>> > Carlo,
>> >
>> > Esa db tiene encendida la opcion "auto update statistics"?
>> >
>> > select databaseproperty('nombre_de_tu_db', 'IsAutoUpdateStatistics')
>> > go
>> >
>> >
>> > AMB
>> >
>> >
>> > "Carlo" wrote:
>> >
>> >> Estimados, alguna idea de adonde guarda SQL los Planes de Ejecución de
>> >> las
>> >> consultas...???, estoy revisando algo que no termino de entender, les
>> >> explico. Tengo mi plan de mantenimiento que se ejecuta todos los días
>> >> Domingo de cada semana, el cual me reindexa y me actualiza las
>> >> estadisticas
>> >> de mis tablas. Pero cuando por alguna razón ese Plan de ejecución no
>> >> se
>> >> ejecuta por algún error, la semana que sigue a este error funciona
>> >> todo
>> >> ok.
>> >> El domingo siguiente se ejecuta el Plan de Mantenimiento sin errores,
>> >> y
>> >> en
>> >> la semana se quejan que el "Sistema" anda lento. Despues de otra
>> >> semana
>> >> que
>> >> se ejecute en forma normal, vuelve a su comportamiento normal. Como
>> >> que
>> >> algo
>> >> pierde, y creo que son los Planes de ejecución (CREO). Si alguien
>> >> tiene
>> >> otra
>> >> teoria o me puede explicar este extraño comportamiento se lo
>> >> agradeceria.
>> >> 2 Servidores en Cluster con Windows 2003 SP1, SQL Server Enterprise
>> >> Edition
>> >> SP3a instalado en Cluster, 12 GB RAM, AWE habilitado, 10,5 Gb de RAM a
>> >> SQL.
>> >>
>> >> Atte.,
>> >> Carlo
>> >>
>> >>
>> >>
>>
>>
>>

No, no incluye esa actividad. Dejo el Log de transacciones con el tamaño en
forma fija.

Atte.,
Carlo
"Alejandro Mesa" escribió en el
mensaje news:

Carlo,

Me pregunto si por casualidad ese mantenimiento incluye encojer la db
(dbcc
shrinkdatabase)?


AMB


"Carlo" wrote:

Si, de hecho estoy haciendo eso, y hasta el momento no he tenido que
actualizar las estadisticas entre semana. Mi problema es lo que comente
en
el post inicial, no se que puede estar pasando. El contador Procedure
Cache
Pages ha baja a un tercio de lo habitual, el Lazy Writes/sec a aumentado
al
doble, el Page Life Expectancy a disminuido a la Mitad, el Page
Splits/sec
aumento de 7 a 9 (el promedio), con máximos el dóble de la semana
anterior.
No se si estos datos te indican algo...

Atte.,
Carlo
"Alejandro Mesa" escribió en el
mensaje news:
> Carlo,
>
> Si la desactivastes, entonces tendras que hacer un analizis de cuanto
> se
> inserta, elimina y actualiza sobre esas tablas para ver si es necesario
> actualizar las estadisticas con mas frecuencia y no una vez a la
> semana.
> Microsoft recomienda, que de ser posible, se actualizen diariamente,
> incluso
> con la opcion "auto update statistics" prendida.
>
>
> AMB
>
>
> "Carlo" wrote:
>
>> No, la desactive hace un par de meses, ya que la base pesa 350 GB, y
>> me
>> actualizaba las estadisticas con muestras muy pequeñas que bajaban el
>> performance.
>>
>> Atte.,
>> Carlo
>> "Alejandro Mesa" escribió en
>> el
>> mensaje news:
>> > Carlo,
>> >
>> > Esa db tiene encendida la opcion "auto update statistics"?
>> >
>> > select databaseproperty('nombre_de_tu_db', 'IsAutoUpdateStatistics')
>> > go
>> >
>> >
>> > AMB
>> >
>> >
>> > "Carlo" wrote:
>> >
>> >> Estimados, alguna idea de adonde guarda SQL los Planes de Ejecución
>> >> de
>> >> las
>> >> consultas...???, estoy revisando algo que no termino de entender,
>> >> les
>> >> explico. Tengo mi plan de mantenimiento que se ejecuta todos los
>> >> días
>> >> Domingo de cada semana, el cual me reindexa y me actualiza las
>> >> estadisticas
>> >> de mis tablas. Pero cuando por alguna razón ese Plan de ejecución
>> >> no
>> >> se
>> >> ejecuta por algún error, la semana que sigue a este error funciona
>> >> todo
>> >> ok.
>> >> El domingo siguiente se ejecuta el Plan de Mantenimiento sin
>> >> errores,
>> >> y
>> >> en
>> >> la semana se quejan que el "Sistema" anda lento. Despues de otra
>> >> semana
>> >> que
>> >> se ejecute en forma normal, vuelve a su comportamiento normal. Como
>> >> que
>> >> algo
>> >> pierde, y creo que son los Planes de ejecución (CREO). Si alguien
>> >> tiene
>> >> otra
>> >> teoria o me puede explicar este extraño comportamiento se lo
>> >> agradeceria.
>> >> 2 Servidores en Cluster con Windows 2003 SP1, SQL Server Enterprise
>> >> Edition
>> >> SP3a instalado en Cluster, 12 GB RAM, AWE habilitado, 10,5 Gb de
>> >> RAM a
>> >> SQL.
>> >>
>> >> Atte.,
>> >> Carlo
>> >>
>> >>
>> >>
>>
>>
>>

En vez de usar el Plan de Mantenimiento, implementa los jobs
manualmente, es decir, prepara un query que reindexe las tablas, para
que cuando falle, sea preciso en cual sentencia falla. Cuando falla el
Plan de Mantenimiento el History no te dice mucho al respecto..
Tambien ten en cuenta que el FIll Factor no puede ser el mismo para
todas las tablas (las maestras se llenan de forma diferente de las de
movimiento, etc.)

Juan Carlos Mendoza
Callao - Peru

En el post <#,
DIJO .

Si, de hecho estoy haciendo eso, y hasta el momento no he tenido que
actualizar las estadisticas entre semana. Mi problema es lo que comente en
el post inicial, no se que puede estar pasando. El contador Procedure Cache
Pages ha baja a un tercio de lo habitual, el Lazy Writes/sec a aumentado al
doble, el Page Life Expectancy a disminuido a la Mitad, el Page Splits/sec
aumento de 7 a 9 (el promedio), con máximos el dóble de la semana anterior.
No se si estos datos te indican algo...

Tu problema principal creo que es un problema llamado localidad de
referencia.

Cuando actualiza las estadisticas y reindexa debe llevar a memoria las
paginas que lee eso hace descargar las paginas que no se usan que estan
en memoria y ademas disminuye el contador del procedure cache porque los
planes se vuelven obsoletos y los descarga de memoria ya que los debe
reemplazar.

Seguramente los usuarios usan mas frecuentemente una parte de la base de
datos y por lo tanto la ven mas lenta ya que el servidor debe recargar
todo en memoria dejando los mas frecuente con mayor espectativa de vida
y mas tiempo en memoria. Prueba reiniciar el servicio si puedes sin
lanzar las estadisticas ni el reindex y verifica si se produce el mismo
fenomeno. No deberia ser tan severo pero es probable que veas que a lo
largo del tiempo el servidor va mejorando los tiempos de respuesta.

En cuanto al Lazy Writes/sec se me ocurre que hasta que mejora y aprende
acerca de la nueva localidad de referencia aumenta la descarga de los
buffers porque no tiene memoria para el "working set" o sea lo mas usado
y como consecuencia aumenta este contador. Esto ademas, coincide
perfectamente con la caida del Page Life Expectancy.

En cuanto al aumento de los Page Splits/sec creo que no se esta
seleccionando de forma adecuada el FILL FACTOR para los indices de
algunas de las tablas por lo que seria conveniente estudiar la
fragmentacion producida a lo largo del tiempo, y determinar la mejor
estrategia de reindexado.




Saludos
Ing. Jose Mariano Alvarez


(Cambia los ceros por O y saca lo que sobra)


IMPORTANTE

Por favor traten de indicar la versión de SQL y Service Pack.
La inclusión de (CREATE, INSERTS, etc.) para poder reproducir el
problema también ayuda.