Mi empresa se está moviendo a SQL Server 2008 R2. Tenemos una tabla con toneladas de archivo de los datos. La mayoría de las consultas que utiliza esta tabla se emplea el valor de DateTime en la declaración. Por ejemplo:

Consulta 1

SELECT COUNT(*) 
FROM TableA 
WHERE 
     CreatedDate > '1/5/2010' 
     and CreatedDate < '6/20/2010'  

Estoy haciendo la suposición de que las particiones se crean en CreatedDate y cada partición se extiende a través de múltiples unidades, tenemos 8 CPUs, y hay 500 millones de registros en la base de datos que se distribuye uniformemente a través de las fechas de 1/1/2008 a 2/24/2011 (38 particiones). Estos datos también podrían ser asignados a los trimestres de un año o en otro tiempo de duración, pero que permite mantener la hipótesis de meses.

En este caso me gustaría creer que el 8 de CPU sería utilizado, y sólo el 6 particiones consultar para las fechas entre el 1/5/2010 y 6/20/2010.

Ahora lo que si me encontré con la siguiente consulta y mis suposiciones son los mismos que los anteriores.

Consulta 2

SELECT COUNT(*) 
FROM TableA 
WHERE State = 'Colorado'

Preguntas?

1. Va a todas las particiones se pueden consultar? Sí

2. Todos 8 Cpu se utiliza para ejecutar la consulta? Sí

3. Se desempeño mejor que consultar una tabla que no es partitoned? Sí

4. Hay algo que me falta?

5. ¿Cómo sería la Partición de Índice de ayuda?

Respondo las primeras 3 preguntas anteriores, la base de mis limitados conocimientos de SQL Server 2008 Tabla con Particiones & Paralelismo. Pero si mis respuestas son incorrectas, puede usted proporcionar retroalimentación por qué estoy incorrecta.

De recursos:

BarDev

  • Parece como DBA preguntas como esta mejor se adapten a Serverfault (o tenemos un DBA sitio ahora?)… Pero no estoy seguro.
  • Voy a ir a Serverfault y averiguar.
  • Basado en las respuestas, nuestra tabla tiene Clusterd Índice y otros índices en columnas como Estado. Traté de mantener el puesto de tan pequeño como sea posible sin entrar en todos los detalles del servidor, base de datos y configuraciones de la tabla. Tal vez yo también debería haber identificado estos supuestos. Supongamos que el servidor, dabases y objetos de objeto sigue las mejores prácticas de Microsoft.

3 Comentarios

  1. 1

    Particionado puede aumentar el rendimiento-he visto muchas veces. La razón de partición se desarrolló fue y es el rendimiento, especialmente para las inserciones. Aquí está un ejemplo del mundo real:

    Tengo varias tablas en una SAN con una gran ole tocando la bocina disco como lo que podemos decir. El SAN administradores de insistir en que el SAN sabe todo por lo que no será optimizar la distribución de los datos. ¿Cómo puede una partición posiblemente ayudar? Hecho: se hizo y hace.

    Nos particiones varias tablas utilizando el mismo esquema (FileID%de 200) con 200 particiones TODOS en la primaria. Qué uso tendría que ser si la única razón para tener un esquema de particionamiento es de «intercambio»? Ninguno, pero el propósito de la partición es el rendimiento. Usted ve, cada una de esas particiones tiene su propio esquema de paginación. Puedo escribir los datos a todos ellos a la vez y no hay ninguna posibilidad de un interbloqueo. Las páginas no puede ser bloqueado debido a que cada proceso tiene un IDENTIFICADOR único que equivale a una partición. 200 particiones de mayor rendimiento 2000x (hecho) y interbloqueos cayó de 7500 por hora de 3 a 4 por día. Esto por la sencilla razón de que en la página de la extensión de bloqueo siempre se produce con grandes cantidades de datos y un alto volumen de sistema OLTP y bloqueos de página son la causa de los interbloqueos. Creación de particiones, incluso en el mismo volumen y archivo de grupo, los lugares a los datos con particiones en diferentes páginas y la extensión de bloqueo no tiene ningún efecto ya que los procesos que no están tratando de acceder a las mismas páginas.

    El beneficio está ahí, pero no tan grande, para la selección de datos. Pero normalmente el esquema de particionamiento sería desarrollado con el propósito de la base de datos en la mente. Estoy apostando a Remus desarrollado su esquema, con una carga incremental (tales como las cargas diarias) en lugar de procesamiento transaccional en mente. Ahora bien, si uno fueron con frecuencia la selección de filas con el bloqueo (read committed), a continuación, interbloqueos podría resultar si los procesos intento de acceder a la misma página de forma simultánea.

    Pero Remus es correcto-en su ejemplo, no veo ningún beneficio, de hecho, puede haber algunos costos en la búsqueda de las filas a través de las diferentes particiones.

  2. 6

    Particiones es nunca una opción para mejorar el rendimiento. El mejor que te puede pasar es tener a la par del rendimiento con la tabla con particiones. Generalmente se obtiene una regresión que aumenta con el número de particiones. Para el rendimiento que usted necesita índices, no particiones. Las particiones son para la gestión de datos de operaciones: ETL, archivo, etc. Algunos afirman que la partición de eliminación es posible mejorar el rendimiento, pero para nada de la partición de eliminación puede dar la colocación de la clave de índice inicial en la misma columna como la columna de partición dará resultados mucho mejores.

    Va a todas las particiones se pueden consultar?

    Que consulta necesita un índice en State. De lo contrario, es una exploración de la tabla, y explorar toda la tabla. Un examen de la tabla a través de una tabla con particiones es siempre más lento que un análisis sobre el mismo tamaño de la tabla con particiones. El índice puede ser alineado en el mismo esquema de partición, pero la principal clave debe ser State.

    Todos 8 Cpu se utiliza para ejecutar la consulta?

    Paralelismo no tiene nada que ver con las particiones, a pesar de la falsa idea común de lo contrario. Ambos con y sin particiones rango de análisis se pueden utilizar en paralelo un operador, será el Optimizador de Consultas decisión.

    Se desempeño mejor que consultar una tabla que no es
    particiones?

    No

    Cómo sería la Partición de Índice de ayuda?

    Un índice será de ayuda. Si el índice tiene que estar alineado, entonces debe de ser dividida. Un índice sin particiones será más rápido que un particiones, pero el índice de alineación requisito para activar/desactivar operaciones no pueden ser eludidas.

    Si usted está buscando en la partición, debe ser porque se necesita hacer rápido interruptor de interruptor de salida de las operaciones para eliminar datos antiguos pasado de retención período de la póliza, o algo similar. Por rendimiento, es necesario buscar en los índices, no en la partición.

    • Puede ayudar al rendimiento, porque se puede localizar particiones en discos separados. Esto permite de e/S de ancho de banda para aumentar la = mejor rendimiento. Aparte de que hay un montón de «opinión» en el que no estoy de acuerdo con menos respaldadas con hechos. msdn.microsoft.com/en-us/library/ms177411.aspx
    • sin particiones de tablas pueden ser ubicados en los grupos de archivos que contiene varios archivos (propagación a través de Lun/discos) que impulsará el aumento de la IO ancho de banda mejores de la partición.
    • Estoy totalmente de aggree con Richard . Nuestra base de datos está en una san, y varios Lun están disponibles. Remus, ¿puedes ver el video que estaba en el original post? Se trata de mejorar el rendimiento con la Tabla de Partición.
    • Todo lo que he leído, y hablando con Microsoft consultores menciona el uso de Tablas de Partición y difundir las particiones a través de múltiples discos o Lun.
    • Partición tiene su función y es insustituible para escenarios específicos. Sin embargo, ese papel es no rendimiento.
    • en el video en tu post Eric Hanson habla sobre las mejoras realizadas a las consultas que toque varias particiones. La mejora de él menciona que va a mejorar el rendimiento cuando se compara con otra consulta que toque varias particiones en SQL Server 2005. Esto no implica que la consulta se comporta mejor que una consulta que se ejecuta en un de una sola tabla con particiones. El mensaje de que el vídeo no es para nada de particiones mejora el rendimiento’, es ‘hemos hecho mejoras a la partición, de modo que ahora no es tan malo como lo fue’.
    • Tenga cuidado al usar la palabra «nunca». Puede ayudar al rendimiento no sólo porque puede implicar varios discos y las consultas pueden mejor aprovechar los núcleos de la CPU, sino también porque facilita el bloqueo en el nivel de la partición en lugar de toda la tabla de nivel.

  3. 1

    la primera pregunta que tengo es si la tabla tiene un índice agrupado en ella. si no, usted querrá tener uno.

    Además, tendrá un índice de cobertura para sus consultas. Los Índices De Cobertura

    Si usted tiene una gran cantidad de datos históricos usted puede mirar en un proceso de archivado para ayudar a acelerar sus aplicaciones oltp.

Dejar respuesta

Please enter your comment!
Please enter your name here