Crear vistas distribuidas con particiones

Para poder implementar una vista con particiones, primero debe realizar una partición horizontal de la tabla. Si diseña un esquema de partición, debe tener claro qué datos pertenecen a cada tabla miembro. La tabla original se reemplaza con varias tablas miembro más pequeñas. Cada tabla miembro tiene el mismo número de columnas que la tabla original, y cada columna tiene los mismos atributos (como tipos de datos, tamaño e intercalación) que la columna correspondiente de la tabla original. Si va a crear una vista dividida distribuida, cada tabla miembro estará en un servidor miembro diferente. Para obtener la mayor transparencia de ubicación, es conveniente que el nombre de las bases de datos miembro sea el mismo en cada servidor miembro, aunque no ello no es obligatorio. Por ejemplo: Server1.CustomerDB, Server2.CustomerDB, Server3.CustomerDB.

Crear tablas miembro

Diseñe las tablas miembro de manera que cada tabla almacene una rebanada horizontal de la tabla original basada en un intervalo de valores de clave. Los intervalos se basan en los valores de datos de una columna de partición. El intervalo de valores de cada tabla miembro se exige mediante una restricción CHECK de la columna de partición; los intervalos no se pueden superponer. Por ejemplo, no puede haber una tabla con un intervalo de 1 a 200000 y otra con un intervalo de 150000 a 300000, ya que no quedaría claro qué tabla contiene los valores que van de 150000 a 200000.

Por ejemplo, imagine que está creando particiones de una tabla Customer en tres tablas. La restricción CHECK de estas tablas es:

-- On Server1:
CREATE TABLE Customers_33
  (CustomerID   INTEGER PRIMARY KEY
                CHECK (CustomerID BETWEEN 1 AND 32999),
  ... -- Additional column definitions)

-- On Server2:
CREATE TABLE Customers_66
  (CustomerID   INTEGER PRIMARY KEY
                CHECK (CustomerID BETWEEN 33000 AND 65999),
  ... -- Additional column definitions)

-- On Server3:
CREATE TABLE Customers_99
  (CustomerID   INTEGER PRIMARY KEY
                CHECK (CustomerID BETWEEN 66000 AND 99999),
  ... -- Additional column definitions)

Definir vistas distribuidas con particiones

Después de crear las tablas miembro, defina una vista distribuida con particiones en cada servidor miembro, con el mismo nombre para cada vista. Esto permite que las consultas que hacen referencia al nombre de vista distribuida con particiones se ejecuten en los servidores miembro. El sistema funciona como si hubiera una copia de la tabla original en cada servidor miembro, aunque cada servidor sólo tiene una tabla miembro y una vista dividida distribuida. La aplicación detecta la ubicación de los datos.

Puede generar las vistas distribuidas con particiones mediante las siguientes tareas:

  • Agregando definiciones de servidor vinculado a cada servidor miembro que contenga la información de conexión necesaria para ejecutar consultas distribuidas en los demás servidores miembro. Esto proporciona a la vista distribuida con particiones el acceso a los datos de los demás servidores miembro.

  • Estableciendo la opción lazy schema validation, mediante sp_serveroption, para cada definición de servidor vinculado que se utilice en las vistas distribuidas con particiones. Esto optimiza el rendimiento al garantizar que el procesador de consultas no solicitará metadatos para ninguna de las tablas vinculadas hasta que se necesiten los datos de la tabla miembro remota.

  • Crea una vista distribuida con particiones en cada servidor miembro. Las vistas utilizan las instrucciones SELECT distribuidas para obtener acceso a los datos de los servidores miembro vinculados y mezclan las filas distribuidas con las filas de la tabla miembro local.

Para crear vistas distribuidas con particiones en el ejemplo anterior, debe hacer lo siguiente:

  • Agregar una definición de servidor vinculado denominada Server2 con la información de conexión de Server2, y una definición de servidor vinculado denominada Server3 para tener acceso a Server3.

  • Crear la siguiente vista distribuida con particiones:

    CREATE VIEW Customers AS
       SELECT * FROM CompanyDatabase.TableOwner.Customers_33
    UNION ALL
       SELECT * FROM Server2.CompanyDatabase.TableOwner.Customers_66
    UNION ALL
       SELECT * FROM Server3.CompanyDatabase.TableOwner.Customers_99
    
  • Realizar los mismos pasos en Server2 y Server3.

Reglas de tablas

Las tablas miembro se definen en la cláusula FROM de cada instrucción SELECT de la definición de vista. Cada tabla miembro debe seguir las reglas siguientes:

  • No se puede hacer referencia a las tablas miembro de la vista más de una vez.

  • Las tablas miembro no pueden tener índices en ninguna columna calculada.

  • Las tablas miembro deben tener todas las restricciones PRIMARY KEY en el mismo número de columnas.

  • Las tablas miembro deben tener el mismo valor de relleno ANSI. Para obtener más información acerca del modo de establecer el valor de relleno ANSI, vea SET ANSI_PADDING.

Reglas de columnas

Las columnas se definen en la lista de selección de cada instrucción SELECT de la definición de vista. Cada columna debe seguir las reglas siguientes:

  • Todas las columnas de cada tabla miembro deben estar incluidas en la lista de selección. SELECT * FROM <member table> es una sintaxis aceptable.

  • No se puede hacer referencia a las columnas de la lista de selección más de una vez.

  • Las columnas de la lista de selección deben estar en la misma posición ordinal.

  • Las columnas de la lista de selección de cada instrucción SELECT deben ser del mismo tipo. Esto incluye el tipo de datos, la precisión, la escala y la intercalación. Por ejemplo, la siguiente definición de vista es errónea porque el tipo de datos de la primera columna de ambas instrucciones SELECT no coincide:

    CREATE VIEW NonUpdatable
    AS
    SELECT IntPrimaryKey, IntPartNmbr
    FROM FirstTable
      UNION ALL
    SELECT NumericPrimaryKey, IntPartNmbr
    FROM SecondTable
    

Reglas de columnas de partición

Sólo una columna puede usarse para las particiones y debe estar en cada tabla miembro. Las restricciones CHECK identifican los datos disponibles en cada tabla miembro. Se aplican las siguientes reglas adicionales:

  • Los intervalos de clave de las restricciones CHECK de cada tabla no pueden superponerse a los intervalos de ninguna otra tabla. Cualquier valor específico de la columna de partición deben asignarse a una sola tabla. Las restricciones CHECK sólo pueden utilizar estos operadores: BETWEEN, IN, AND, OR, <, <=, >, >=, =.

  • La columna de partición no puede ser una columna de identidad, predeterminada o timestamp.

  • La columna de partición debe tener la misma posición ordinal en la lista de selección de todas las instrucciones SELECT de la vista. Por ejemplo, la columna de partición siempre es la primera columna de cada lista de selección, o la segunda columna de cada lista de selección, etc.

  • Las columnas de partición no permiten valores nulos.

  • Las columnas de partición deben ser parte de la clave principal de la tabla.

  • La columna de partición no puede ser una columna calculada.

  • Debe haber sólo una restricción en la columna de partición. Si hay más de una restricción, SQL Server las omite todas y no las tiene en cuenta al determinar si la vista tiene particiones.

  • No hay restricciones en la posibilidad de actualización de la columna de partición.

Una columna de partición que cumpla todas estas reglas admitirá todas las optimizaciones compatibles con el optimizador de consultas. Para obtener más información, vea Resolver vistas con particiones distribuidas.

Reglas generales

[!NOTA]

Las siguientes condiciones no se aplican a las vistas con particiones locales creadas en el mismo servidor. Esta característica se incluye por compatibilidad con versiones anteriores.

A continuación se indican algunas reglas adicionales que se deben tener en cuenta:

  • Una vista distribuida con particiones no se puede formar mediante los operadores EXCEPT o INTERSECT.

  • Se iniciará una transacción distribuida para garantizar la atomicidad en todos los nodos a los que afecta la actualización.

  • El valor de la opción XACT_ABORT SET debe ser ON.

  • Las columnas smallmoney y smalldatetime de tablas remotas se asignan como money y datetime respectivamente. Por tanto, las columnas correspondientes de las tablas locales también deberían ser money y datetime.

  • Ningún servidor vinculado puede ser un servidor vinculado en bucle de retorno. Se trata de un servidor vinculado que apunta a la misma instancia de SQL Server.

Una vista que haga referencia a tablas con particiones y que no cumpla todas estas reglas se puede actualizar si hay un desencadenador INSTEAD OF en la vista. Sin embargo, si la vista utiliza un desencadenador INSTEAD OF, el optimizador de consultas no siempre es capaz de generar planes de ejecución para dicha vista que sean tan eficaces como los planes para una vista con particiones que cumpla con todas las reglas.