Actualización de Estadisticas

Alejandro, tenemos Windows 2000 Advanced Server con SQL 2000 Enterprise
Edition, y si, tengo habilitado el AWE en el SQL y el modificador /PAE para
que tome la memoria total. Con respecto a la traza, ya tengo identificado
las consultas y demases mas pesados, pero desgraciadamente, como es una
aplicación comprada (ERP Solomon), no es mucho lo que puedo hacer al
respecto, ni siquiera puedo modificar los índices de las tablas existentes,
ya que según la empresa que nos vendio el producto, la cual es partner de
este producto, no nos recomienda realizar ese tipo de modificaciones, por lo
que estoy tratando de ver las mejoras de performance por otros lados, a
pesar que creo que no es mucho mas lo que voy a ganar.
Te comento que no soy un experto en transact-SQL, pero con el Query Analyzer
y sus opcines de verificar la traza de ejecución, e ido aprendiendo algo.
Con respecto a los libros, te cuento que tengo el SQL Server Performance
Tuning..., y lo he estado leyendo, y se me han aclarado algunas dudas, y me
han surgido otras, por ejemplo, estoy mirando ahora con hambre el tema de
Utilizar Intraprocesos de Windows NT (opción que aparece en la pestaña
procesador junto a la de aumentar la prioridad de SQL en Windows, opción que
tengo habilitada), no termino de entenderla bien, el servidor tiene 2
procesadores Xeon Mp de 2.02 Ghz con 2 MB de cache cada uno, ganaria algo
activando esta opción...??
Gracias nuevamente por tu tiempo y disponibilidad.
Saludos,

Atte.,
Carlo Sorrel

"Alejandro Mesa" escribió en el
mensaje news:
> Carlo,
>
> Que version de windows estas usando?
> Que version de sql server 2000?
>
> Te pregunto esto, por si no tienes seteado ambos (windows y sql server)
para
> usar mas de 2GB de memoria. Otra cosa es si el servidor de sql server es
un
> servidor dedicado, osea, solo se dedica para sql server.
>
> Cuando puedas, crea una traza para guardar las operaciones que se demoran
> mas de un tiempo prederminado, por ejemplo un minuto, y luego analyza que
> tablas estan involucradas, asi como los indices de esas tablas, y si las
> expresiones usadas en la clausula where cimplen el patron necesario para
que
> sql server las reconosca como argumentos de busqueda. Tambien monitorea
los
> counters especificos de memoria para ver si necesitas mas ram. chequea que
> tengas un indice por cada columna(s) que participan en una restriccion de
> clave foranea, pues sql server no lo crea por defecto (por default).
>
> Dejame decirte que el cambio hecho es muy importante, sobre todo si el
nivel
> de actualizacion sobre la bd es alta, ya que raid 5 es muy bueno para
lectura
> pero bajo performance para escritura.
>
> Aprovecha la oportunidad para poner en practica toda esta teoria que a
veces
> se nos queda por eso mismo, por no tener oportunidad de ponerla en
practica.
>
> Mucha suerte,
>
>
> AMB
>
> P.S. Trata de leerte cuanto puedeas desde esta pagina web. Todos sus
> articulos estan dedicadas al mejoramiento del rendimineto de sql server
>
> http://www.sql-server-performance.com/
>
> al final de la pagina encontraras los articulos por categoria. Incluye
tips
> para ambientes clustering.
>
>
>
> "Carlo Sorrel" wrote:
>
> > Si, en realidad estoy en eso fuertemente. Con respecto a lo de las
> > estadisticas, muchas gracias por tus sabios consejos. Te cuento, estoy
> > administrando un SQL en Cluster que tiene una base que actualmente pesa
> > 109GB de pura data, la cual la tengo distribuida en 4 Filegroup's en
> > distintos Raid (raid 1 y raid 10), ademas el Log separado y la tempdb
> > tambien. Esto ha mejorado sustancialmente los tiempos de respuesta de la
> > aplicación (ERP Solomon 5.0 de Microsoft), la cual estaba íntegramente
> > alojada en un Raid 5, tiene 6.5Gb de 7 GB ram disponibles en la maquina
> > asignada al SQL, pero sigo viendo que mas le puedo hacer para que mejore
el
> > rendimiento. Esa es la razón de búsqueda y consultas de ese perfil. Voy
a
> > ver esos libro me mencionas a ver que puedo hacer.
> > Gracias nuevamente y saludos.
> >
> > Atte.,
> > Carlo Sorrel
> >
> > "Alejandro Mesa" escribió en
el
> > mensaje news:
> > > Carlo,
> > >
> > > Veo que estas bastante interesado en la administracion y tuning de sql
> > > server 2000, te aconsejo que te leas este par de libros, te ayudaran
mucho
> > a
> > > entender como funciona sql server por dentro.
> > >
> > > Inside Microsoft SQL Server 2000
> > > by Kalen Delaney
> > >
> > > Microsoft SQL Server 2000(TM) Performance Tuning Technical Reference
> > > by Edward Whalen, Marcilina Garcia
> > >
> > >
> >
http://www.amazon.com/exec/obidos/A...29-8238309
> > >
> > >
> > > AMB
> > >
> > > "Alejandro Mesa" wrote:
> > >
> > > > Carlo,
> > > >
> > > > La opcion "auto update statistics" es una muy buena facilidad
ofrecida
> > por
> > > > sql server, y debe estar prendida excepto en circunstancias
especiales
> > donde
> > > > esta interfiere, disparandose o haciendose en servidores con alta
carga
> > y
> > > > durante espacios de tiempo donde este esta bastante ocupado. Apagar
esta
> > > > utilidad puede traer otros problemas, como que el optimixador escoja
un
> > plan
> > > > no adecuado producto de que las estadisticas de los indices esten
> > > > desactualizadas. Otra cosa, esta utilidad no es perfecta, asi que
> > incorporar
> > > > la actuializacion manual de las estadisticas en el plan de
mantenimiento
> > de
> > > > la bd, no tiene que ver con que esta utilidad este prendida o
apagada,
> > de ser
> > > > posible, deberia hacerse diaria, en todas las tablas y en todas la
bds.
> > > >
> > > > Si tu crees que esta utilidad esta influyendo en el rendimineto de
tu
> > > > servidor, primero deberias hacer una traza para monitorear esto por
lo
> > menos
> > > > durante un dia, o tambien puedes usar con la bandera de traza 8721
(ve
> > dbcc
> > > > traceon / traceoff en los libros en linea), la cual hara hace que
sql
> > server
> > > > escriba en log de errores, cada vez que se corre auto update
statistics.
> > > > Despues de analyzar la carga, entonces podras decidir si vale la
pena o
> > no
> > > > apagar esta facilidad, muy util para la mayoria de los casos. No
creas
> > que
> > > > solo por apagarla, vas a obtener mejores resultados, posiblemente
> > obtengas un
> > > > dolor de cabeza cuando tus queries empizen a tomar mas tiempo de lo
> > comun.
> > > >
> > > > Si en cambio, notas que la actualizacion automatica de las
estadisticas
> > de
> > > > los indices, solamente esta dando problema con un determinado
indice,
> > > > entonces chequea el procedimiento almacenado sp_autostats, en los
libros
> > en
> > > > linea, el cual permite apagar esta utilidad para un indice en
particular
> > y
> > > > usa el commando "update statistics" para actualizar las estadisticas
del
> > > > mismo.
> > > >
> > > > Por ultimo, en cuanto al valor del numero de filas a ser tomadas
como
> > > > muestra, sql server va a asegurarse de que este numero sea el minimo
> > > > necesario si le pasas un valor no aconsejado. Lo optimo seria el
100%
> > pero
> > > > esto se usa solo en casos muy problematicos.
> > > >
> > > > Un ultimo consejo, para tunear o afinar sql server, primero debemos
> > empezar
> > > > por saber si algo esta andando mal, identificar que es, y planificar
> > como
> > > > afinarlo.
> > > >
> > > >
> > > > AMB
> > > >
> > > > "Carlo Sorrel" wrote:
> > > >
> > > > > Estimados, estoy buscando por todos lados mejorar el rendimiento
de mi
> > SQL,
> > > > > y estoy mirando esta opción, "Actualización de Estadisticas
> > > > > Automaticamente", por lo que entiendo, si esta opción
seleccionada, el
> > SQL
> > > > > actualiza en forma automatica las estadisticas, con el
consiguiente
> > consumo
> > > > > de CPU e I/O, por lo que estoy pensando deshabilitar esta opción.
> > Ahora
> > > > > bien, evidentemente no es bueno que las estadisticas queden
> > desactulizadas,
> > > > > por lo que pienso actualizarlas mediante un trabajo agendado,
la
> > > > > consulta es con que porcentaje de muestreo es aconsejable que
realice
> > las
> > > > > actualizaciones, por defecto esto lo deja en 10%, pero es esto
> > > > > aconsejable..???
> > > > > Gracias y Saludos.
> > > > >
> > > > > Atte.,
> > > > > Carlo Sorrel
> > > > >
> > > > >
> > > > >
> >
> >
> >