CREATE STATISTICS (Transact-SQL)

Juan Carlos Garcia,

Tratare de contestar lo mas que pueda sin expandir mucho, pues es tema es
bastante extenso.

1) La estadistica esta asociada a 1 tabla y 1 o varios campos de ésta.
Cuantos historiales se deberian crear para mejorar las consultas a esa
tabla?, una por cada indice (simple o compuesto)?

Dejame comentar algo que te ayudara a entender mejor el tema.

Existen varias formas de crear estadisticas.

1 - SQL Server crea automaticamente estadisticas para las columnas que
conforman la llave de un indice.

Existen diferentes valores que se almacenan en las estadisticas, esta el
vector de densidades, el histogram, etc. Puedes ver en los BOL el comando
"dbcc show_statistics" para mas info.

2 - SQL Server crea automaticamente estadisticas de columnas que forman
parte en algun predicado que puede estar en la clausula "where", "having",
"join", etc.

Para que estas estadisticas se creen automaticamente, la opcion a nivel de
base de dato "AUTO_CREATE_STATISTICS" debe estar prendida.

Estas estadisticas se crean para una unica columna, pero pueden haber varias
estadisticas relacionadas con la misma tabla, una por columna que SQL Server
haya decidido crear estadistica.

3 - Las estadisticas se pueden crear manualmente usando la sentencia "create
statistic".

Se pueden crear estadisticas para multi-columnas, al igual que las
estadisticas auto-creadas para las columnas llaves de un indice.

La metadata sobre estadisticas se puede ver en sys.statistics, mientras la
informacion de indices se ve en sys.indexes. Existe una entrada en
sys.statistics por cada indice, pero tambien existen estadisticas para
columnas que no estan en un indice, y que pudieron haberse creado
automaticamente por SQL Server, o manualmente usando "create statistic".

2) Como seria la estadistica para una consulta que incluya varias
tablas con JOIN?. Cada tabla que participe en la consulta deberia
tener una estadistica asociada al campo que establece la relacion?

Las estadisticas estan relacionadas con las columnas de una tabla. Son
estadisticas sobre la distribucion de los valores en una o multiples columnas.

Como te das cuenta, las estadisticas no estan asociadas a una consulta en
especifico, por lo que multiples consultas pueden usar las mismas
estadisticas si estas usan las mismas columnas en algun predicado.

3) Que tan aconsejable es utilizar estas Estadisticas?, Alguien tiene
alguna experiencia que haya experimentado en la implementacion de
estas estadisticas?, como le fue antes y despues, cuales fueron los
resultados que obtuvo.

Las estadisticas son usadas internamente por el optimizador de consultas
para estimar la cardinalidad de un resultado, o la selectividad de una
expresion de comparacion dada. Este calculo permite al optimizador saber
cuanto se consumira en cuanto a CPU, operaciones de lectura / escritura, y
memoria. En base a eso el optimizador escojera que operaciones fisicas usara
para manipular la data que la consulta necesita. Por ejemplo, usar "index
seek" o "index scan" en un determinado indice, etc.

4) Algunos consejos que debamos tener en cuenta para mejorar el
rendimiento de las consultas?

Son muchos como para presentarlos en un simple post.

- Cada tabla de tener una clave primaria.
- Cada tabla debe tener un indice clustered (excepto tablas muy pequenias).
- El indice clustered debe ser estrecho (pocas columnas), preferible en por
columnas que no se modifiquen con frecuencia, y que sean creciente. Que las
columnas se usen con frecuencia para agrupar, ordenar, hacer busquedas de
rango como >, >= between, etc.
- Crear indices para referencias de clave foranea.
- Analizar la posibilidad de usar indices que cubran todas las columnas
referenciadas por una consulta. Esto debe hacerse a discrecion, pues pudieras
terminar por duplicar toda la data de tu tabla.
- Tener en cuenta que los indices ayudan a mejorar el tiempo de respuesta de
las consultas pero a su vez agregan carga cuando se inserta, actualiza y se
borra, pues los indices se deben mantener en sincronizacion con la data de la
tabla.

En este sitio encontraras algunos articulos que pueden ayudarte a entender
mejor este tema.

Puedes comentar en este grupo sobre cualquier duda, pues hay muchos usuarios
que pueden ayudarte.


AMB





"Juan Carlos Garcia (Medellín-Col)" wrote:

Hola Grupo.

Soy nuevo en este grupo.

Haciendo algunas pruebas de la herramienta de optimizacion SQL Server
vemos la recomendacion de utilizar el Create Statistics para mejorar
el rendimiento. Estuvimos viendo la ayuda pero tenemos muchas
inquietudes al respecto y quiero solicitar su amable ayuda para que
nos colaboren a entender mejor esta herramienta que parece ser una
buena solucion.

Lo que entendimos es que con este comando se puede crear 1 o varias
estadisticas en un historial para medir rendimiento y SQL Server
constantemente la esta analizando y actualizando internamente, el
motor de BD utiliza la de mejor rendimiento automaticamente al momento
de que se realice una consulta sobre la tabla que esta asociada a la
estadistica.

Preguntas:

1) La estadistica esta asociada a 1 tabla y 1 o varios campos de ésta.
Cuantos historiales se deberian crear para mejorar las consultas a esa
tabla?, una por cada indice (simple o compuesto)?

2) Como seria la estadistica para una consulta que incluya varias
tablas con JOIN?. Cada tabla que participe en la consulta deberia
tener una estadistica asociada al campo que establece la relacion?

3) Porque el motor de optimizacion de SQL Server, hace las
recomendaciones a nivel de tablas y no a nivel de las consultas que
ésta herramienta analiza, cuando uno ejecuta esta herramienta lo hace
sobre una traza hecha con el PROFILER, en ésta estan las Sentencias
SQL (Select, Insert, Update), porque entonces las recomendaciones no
las hace sobre estas sentencias y en cambio las hace sobre las tablas
indivualmente?

3) Que tan aconsejable es utilizar estas Estadisticas?, Alguien tiene
alguna experiencia que haya experimentado en la implementacion de
estas estadisticas?, como le fue antes y despues, cuales fueron los
resultados que obtuvo.

4) Algunos consejos que debamos tener en cuenta para mejorar el
rendimiento de las consultas?

Mil gracias

Juan Carlos Garcia




.

No adjunte la direccion del sitio mencionado.

http://www.helpdna.net/sqlserver_rendimiento.htm

Este sitio es de Salvador Ramos, quien es MVP de SQL Server y el cual ha
recopilado varios articulos relacionados con el rendimiento de consultas.


AMB



"Alejandro Mesa" wrote:

Juan Carlos Garcia,

Tratare de contestar lo mas que pueda sin expandir mucho, pues es tema es
bastante extenso.

> 1) La estadistica esta asociada a 1 tabla y 1 o varios campos de ésta.
> Cuantos historiales se deberian crear para mejorar las consultas a esa
> tabla?, una por cada indice (simple o compuesto)?

Dejame comentar algo que te ayudara a entender mejor el tema.

Existen varias formas de crear estadisticas.

1 - SQL Server crea automaticamente estadisticas para las columnas que
conforman la llave de un indice.

Existen diferentes valores que se almacenan en las estadisticas, esta el
vector de densidades, el histogram, etc. Puedes ver en los BOL el comando
"dbcc show_statistics" para mas info.

2 - SQL Server crea automaticamente estadisticas de columnas que forman
parte en algun predicado que puede estar en la clausula "where", "having",
"join", etc.

Para que estas estadisticas se creen automaticamente, la opcion a nivel de
base de dato "AUTO_CREATE_STATISTICS" debe estar prendida.

Estas estadisticas se crean para una unica columna, pero pueden haber varias
estadisticas relacionadas con la misma tabla, una por columna que SQL Server
haya decidido crear estadistica.

3 - Las estadisticas se pueden crear manualmente usando la sentencia "create
statistic".

Se pueden crear estadisticas para multi-columnas, al igual que las
estadisticas auto-creadas para las columnas llaves de un indice.

La metadata sobre estadisticas se puede ver en sys.statistics, mientras la
informacion de indices se ve en sys.indexes. Existe una entrada en
sys.statistics por cada indice, pero tambien existen estadisticas para
columnas que no estan en un indice, y que pudieron haberse creado
automaticamente por SQL Server, o manualmente usando "create statistic".

> 2) Como seria la estadistica para una consulta que incluya varias
> tablas con JOIN?. Cada tabla que participe en la consulta deberia
> tener una estadistica asociada al campo que establece la relacion?

Las estadisticas estan relacionadas con las columnas de una tabla. Son
estadisticas sobre la distribucion de los valores en una o multiples columnas.

Como te das cuenta, las estadisticas no estan asociadas a una consulta en
especifico, por lo que multiples consultas pueden usar las mismas
estadisticas si estas usan las mismas columnas en algun predicado.

> 3) Que tan aconsejable es utilizar estas Estadisticas?, Alguien tiene
> alguna experiencia que haya experimentado en la implementacion de
> estas estadisticas?, como le fue antes y despues, cuales fueron los
> resultados que obtuvo.

Las estadisticas son usadas internamente por el optimizador de consultas
para estimar la cardinalidad de un resultado, o la selectividad de una
expresion de comparacion dada. Este calculo permite al optimizador saber
cuanto se consumira en cuanto a CPU, operaciones de lectura / escritura, y
memoria. En base a eso el optimizador escojera que operaciones fisicas usara
para manipular la data que la consulta necesita. Por ejemplo, usar "index
seek" o "index scan" en un determinado indice, etc.

> 4) Algunos consejos que debamos tener en cuenta para mejorar el
> rendimiento de las consultas?

Son muchos como para presentarlos en un simple post.

- Cada tabla de tener una clave primaria.
- Cada tabla debe tener un indice clustered (excepto tablas muy pequenias).
- El indice clustered debe ser estrecho (pocas columnas), preferible en por
columnas que no se modifiquen con frecuencia, y que sean creciente. Que las
columnas se usen con frecuencia para agrupar, ordenar, hacer busquedas de
rango como >, >= between, etc.
- Crear indices para referencias de clave foranea.
- Analizar la posibilidad de usar indices que cubran todas las columnas
referenciadas por una consulta. Esto debe hacerse a discrecion, pues pudieras
terminar por duplicar toda la data de tu tabla.
- Tener en cuenta que los indices ayudan a mejorar el tiempo de respuesta de
las consultas pero a su vez agregan carga cuando se inserta, actualiza y se
borra, pues los indices se deben mantener en sincronizacion con la data de la
tabla.

En este sitio encontraras algunos articulos que pueden ayudarte a entender
mejor este tema.

Puedes comentar en este grupo sobre cualquier duda, pues hay muchos usuarios
que pueden ayudarte.


AMB





"Juan Carlos Garcia (Medellín-Col)" wrote:

> Hola Grupo.
>
> Soy nuevo en este grupo.
>
> Haciendo algunas pruebas de la herramienta de optimizacion SQL Server
> vemos la recomendacion de utilizar el Create Statistics para mejorar
> el rendimiento. Estuvimos viendo la ayuda pero tenemos muchas
> inquietudes al respecto y quiero solicitar su amable ayuda para que
> nos colaboren a entender mejor esta herramienta que parece ser una
> buena solucion.
>
> Lo que entendimos es que con este comando se puede crear 1 o varias
> estadisticas en un historial para medir rendimiento y SQL Server
> constantemente la esta analizando y actualizando internamente, el
> motor de BD utiliza la de mejor rendimiento automaticamente al momento
> de que se realice una consulta sobre la tabla que esta asociada a la
> estadistica.
>
> Preguntas:
>
> 1) La estadistica esta asociada a 1 tabla y 1 o varios campos de ésta.
> Cuantos historiales se deberian crear para mejorar las consultas a esa
> tabla?, una por cada indice (simple o compuesto)?
>
> 2) Como seria la estadistica para una consulta que incluya varias
> tablas con JOIN?. Cada tabla que participe en la consulta deberia
> tener una estadistica asociada al campo que establece la relacion?
>
> 3) Porque el motor de optimizacion de SQL Server, hace las
> recomendaciones a nivel de tablas y no a nivel de las consultas que
> ésta herramienta analiza, cuando uno ejecuta esta herramienta lo hace
> sobre una traza hecha con el PROFILER, en ésta estan las Sentencias
> SQL (Select, Insert, Update), porque entonces las recomendaciones no
> las hace sobre estas sentencias y en cambio las hace sobre las tablas
> indivualmente?
>
> 3) Que tan aconsejable es utilizar estas Estadisticas?, Alguien tiene
> alguna experiencia que haya experimentado en la implementacion de
> estas estadisticas?, como le fue antes y despues, cuales fueron los
> resultados que obtuvo.
>
> 4) Algunos consejos que debamos tener en cuenta para mejorar el
> rendimiento de las consultas?
>
> Mil gracias
>
> Juan Carlos Garcia
>
>
>
>
> .
>

Muchas gracias Alejandro por tus respuestas, fueron muy claras y
seguro me aclaro mis dudas.



Juan Carlos Garcia





On 11 mar, 13:03, Alejandro Mesa
wrote:

No adjunte la direccion del sitio mencionado.

http://www.helpdna.net/sqlserver_rendimiento.htm

Este sitio es de Salvador Ramos, quien es MVP de SQL Server y el cual ha
recopilado varios articulos relacionados con el rendimiento de consultas.

AMB



"Alejandro Mesa" wrote:
> Juan Carlos Garcia,

> Tratare de contestar lo mas que pueda sin expandir mucho, pues es tema es
> bastante extenso.

> > 1) La estadistica esta asociada a 1 tabla y 1 o varios campos de ésta.
> > Cuantos historiales se deberian crear para mejorar las consultas a esa
> > tabla?, una por cada indice (simple o compuesto)?

> Dejame comentar algo que te ayudara a entender mejor el tema.

> Existen varias formas de crear estadisticas.

> 1 - SQL Server crea automaticamente estadisticas para las columnas que
> conforman la llave de un indice.

> Existen diferentes valores que se almacenan en las estadisticas, esta el
> vector de densidades, el histogram, etc. Puedes ver en los BOL el comando
> "dbcc show_statistics" para mas info.

> 2 - SQL Server crea automaticamente estadisticas de columnas que forman
> parte en algun predicado que puede estar en la clausula "where", "having",
> "join", etc.

> Para que estas estadisticas se creen automaticamente, la opcion a nivel de
> base de dato "AUTO_CREATE_STATISTICS" debe estar prendida.

> Estas estadisticas se crean para una unica columna, pero pueden haber varias
> estadisticas relacionadas con la misma tabla, una por columna que SQL Server
> haya decidido crear estadistica.

> 3 - Las estadisticas se pueden crear manualmente usando la sentencia "create
> statistic".

> Se pueden crear estadisticas para multi-columnas, al igual que las
> estadisticas auto-creadas para las columnas llaves de un indice.

> La metadata sobre estadisticas se puede ver en sys.statistics, mientras la
> informacion de indices se ve en sys.indexes. Existe una entrada en
> sys.statistics por cada indice, pero tambien existen estadisticas para
> columnas que no estan en un indice, y que pudieron haberse creado
> automaticamente por SQL Server, o manualmente usando "create statistic".

> > 2) Como seria la estadistica para una consulta que incluya varias
> > tablas con JOIN?. Cada tabla que participe en la consulta deberia
> > tener una estadistica asociada al campo que establece la relacion?

> Las estadisticas estan relacionadas con las columnas de una tabla. Son
> estadisticas sobre la distribucion de los valores en una o multiples columnas.

> Como te das cuenta, las estadisticas no estan asociadas a una consulta en
> especifico, por lo que multiples consultas pueden usar las mismas
> estadisticas si estas usan las mismas columnas en algun predicado.

> > 3) Que tan aconsejable es utilizar estas Estadisticas?, Alguien tiene
> > alguna experiencia que haya experimentado en la implementacion de
> > estas estadisticas?, como le fue antes y despues, cuales fueron los
> > resultados que obtuvo.

> Las estadisticas son usadas internamente por el optimizador de consultas
> para estimar la cardinalidad de un resultado, o la selectividad de una
> expresion de comparacion dada. Este calculo permite al optimizador saber
> cuanto se consumira en cuanto a CPU, operaciones de lectura / escritura, y
> memoria. En base a eso el optimizador escojera que operaciones fisicas usara
> para manipular la data que la consulta necesita. Por ejemplo, usar "index
> seek" o "index scan" en un determinado indice, etc.

> > 4) Algunos consejos que debamos tener en cuenta para mejorar el
> > rendimiento de las consultas?

> Son muchos como para presentarlos en un simple post.

> - Cada tabla de tener una clave primaria.
> - Cada tabla debe tener un indice clustered (excepto tablas muy pequenias).
> - El indice clustered debe ser estrecho (pocas columnas), preferible en por
> columnas que no se modifiquen con frecuencia, y que sean creciente. Que las
> columnas se usen con frecuencia para agrupar, ordenar, hacer busquedas de
> rango como >, >= between, etc.
> - Crear indices para referencias de clave foranea.
> - Analizar la posibilidad de usar indices que cubran todas las columnas
> referenciadas por una consulta. Esto debe hacerse a discrecion, pues pudieras
> terminar por duplicar toda la data de tu tabla.
> - Tener en cuenta que los indices ayudan a mejorar el tiempo de respuesta de
> las consultas pero a su vez agregan carga cuando se inserta, actualiza y se
> borra, pues los indices se deben mantener en sincronizacion con la data de la
> tabla.

> En este sitio encontraras algunos articulos que pueden ayudarte a entender
> mejor este tema.

> Puedes comentar en este grupo sobre cualquier duda, pues hay muchos usuarios
> que pueden ayudarte.

> AMB

> "Juan Carlos Garcia (Medellín-Col)" wrote:

> > Hola Grupo.

> > Soy nuevo en este grupo.

> > Haciendo algunas pruebas de la herramienta de optimizacion SQL Server
> > vemos la recomendacion de utilizar el Create Statistics para mejorar
> > el rendimiento. Estuvimos viendo la ayuda pero tenemos muchas
> > inquietudes al respecto y quiero solicitar su amable ayuda para que
> > nos colaboren a entender mejor esta herramienta que parece ser una
> > buena solucion.

> > Lo que entendimos es que con este comando se puede crear 1 o varias
> > estadisticas en un historial para medir rendimiento y SQL Server
> > constantemente la esta analizando y actualizando internamente, el
> > motor de BD utiliza la de mejor rendimiento automaticamente al momento
> > de que se realice una consulta sobre la tabla que esta asociada a la
> > estadistica.

> > Preguntas:

> > 1) La estadistica esta asociada a 1 tabla y 1 o varios campos de ésta.
> > Cuantos historiales se deberian crear para mejorar las consultas a esa
> > tabla?, una por cada indice (simple o compuesto)?

> > 2) Como seria la estadistica para una consulta que incluya varias
> > tablas con JOIN?. Cada tabla que participe en la consulta deberia
> > tener una estadistica asociada al campo que establece la relacion?

> > 3) Porque el motor de optimizacion de SQL Server, hace las
> > recomendaciones a nivel de tablas y no a nivel de las consultas que
> > ésta herramienta analiza, cuando uno ejecuta esta herramienta lo hace
> > sobre una traza hecha con el PROFILER, en ésta estan las Sentencias
> > SQL (Select, Insert, Update), porque entonces las recomendaciones no
> > las hace sobre estas sentencias y en cambio las hace sobre las tablas
> > indivualmente?

> > 3) Que tan aconsejable es utilizar estas Estadisticas?, Alguien tiene
> > alguna experiencia que haya experimentado en la implementacion de
> > estas estadisticas?, como le fue antes y despues, cuales fueron los
> > resultados que obtuvo.

> > 4) Algunos consejos que debamos tener en cuenta para mejorar el
> > rendimiento de las consultas?

> > Mil gracias

> > Juan Carlos Garcia

> > .- Ocultar texto de la cita -

- Mostrar texto de la cita -