Conceptos de tablas e índices con particiones
La partición facilita el uso de tablas e índices grandes, ya que permite administrar y tener acceso a subconjuntos de datos de forma rápida y eficaz, a la vez que mantiene la integridad de la recopilación de datos. Si se utilizan las particiones, una operación como la carga de datos desde un sistema OLTP a un sistema OLAP tarda solo unos segundos, en lugar de los minutos y las horas que tardaba en versiones anteriores de SQL Server. Las operaciones de mantenimiento que se realizan en los subconjuntos de datos también se realizan de forma más eficaz porque estas operaciones solo afectan a los datos necesarios, en lugar de a toda la tabla.
Nota
Las tablas e índices con particiones únicamente están disponibles en las ediciones Enterprise, Developer y Evaluation de SQL Server.
Los datos de tablas e índices con particiones se dividen en unidades que pueden propagarse por más de un grupo de archivos de la base de datos. Los datos se dividen en sentido horizontal, de forma que los grupos de filas se asignan a particiones individuales. La tabla o el índice se tratarán como una sola entidad lógica cuando se realicen consultas o actualizaciones en los datos. Las particiones de un índice o una tabla deben encontrarse en la misma base de datos.
Las tablas y los índices con particiones admiten todas las propiedades y características asociadas con el diseño y la consulta de tablas e índices estándar, incluidas las restricciones, los valores predeterminados, los valores de identidad y marca de tiempo, así como los desencadenadores. Por tanto, si desea implementar una vista con particiones local en un servidor, puede interesarle implementar en su lugar una tabla con particiones.
La decisión acerca del uso de las particiones depende básicamente del tamaño actual o futuro de la tabla, la forma en que se utiliza y el rendimiento que presenta en las consultas de usuario y las operaciones de mantenimiento.
Por regla general, puede resultar adecuado crear particiones de una tabla grande si se cumplen las dos condiciones siguientes:
La tabla contiene, o se espera que contenga, muchos datos que se utilizan de formas diferentes.
Las consultas o las actualizaciones en la tabla no presentan el rendimiento que se esperaba o los costos de mantenimiento superan los períodos de mantenimiento predefinidos.
Por ejemplo, si los datos del mes actual se utilizan principalmente en operaciones INSERT, UPDATE DELETE, y MERGE, mientras que los meses anteriores se usaban en consultas SELECT, la administración de la tabla sería más fácil si se crearan particiones por mes. La ventaja puede ser especialmente importante si las operaciones de mantenimiento periódicas solo afectan a un subconjunto de los datos. Si la tabla no dispone de particiones, estas operaciones pueden consumir muchos recursos en un conjunto de datos completo. Con las particiones, las operaciones de mantenimiento como las regeneraciones de índice y las desfragmentaciones se pueden realizar en los datos de solo escritura de un único mes; por ejemplo, mientras que los datos de solo lectura siguen disponibles para el acceso en línea.
Para ampliar este ejemplo, supongamos que desea mover los datos de solo lectura de un mes de esta tabla a una tabla de almacenamiento de datos para su análisis. Con las particiones, se pueden separar rápidamente los subconjuntos de datos en áreas de ensayo para el mantenimiento sin conexión y posteriormente agregarlos como particiones a tablas con particiones existentes, siempre que dichas tablas se encuentren en la misma instancia de base de datos. Las operaciones de este tipo pueden tardar segundos, en lugar de los minutos o las horas que tardaban en versiones anteriores.
La creación de particiones en una tabla o un índice puede mejorar el rendimiento de las consultas si las particiones se diseñan correctamente, basándose en los tipos de consultas que se ejecutan con más frecuencia y en la configuración del hardware. Para obtener más información, vea Diseñar particiones para mejorar el rendimiento de las consultas.
La creación de particiones suele usarse junto con la replicación de SQL Server. El uso de particiones puede permitirle optimizar el rendimiento de la replicación transaccional y la replicación de mezcla reduciendo de forma efectiva la cantidad de datos y metadatos que el sistema de replicación tiene que administrar. La replicación admite un máximo de 1024 particiones por cada tabla. Para obtener más información, vea Replicar tablas e índices con particiones.
Para consultar un ejemplo sobre la forma de aplicar una solución de particiones en una base de datos real, dispone de un escenario de partición que puede implementar en la base de datos de ejemplo AdventureWorks2008R2. Este escenario se explica en Crear particiones en la base de datos de ejemplo AdventureWorks2008R2.
Arquitectura de las particiones
En SQL Server, se considera que todas las tablas e índices de una base de datos disponen de particiones, incluso si se componen de una sola partición. Básicamente, las particiones conforman la unidad básica de organización en la arquitectura física de tablas e índices. Esto significa que la arquitectura lógica y física de las tablas y los índices compuestos por varias particiones es igual a la de tablas e índices con una única partición. Para obtener más información, vea Organización de tablas e índices.