Bases de datos compartidas escalables son compatibles con SQL Server 2005

Extended support for SQL Server 2005 ended on April 12, 2016

If you are still running SQL Server 2005, you will no longer receive security updates and technical support. We recommend upgrading to SQL Server 2014 and Azure SQL Database to achieve breakthrough performance, maintain security and compliance, and optimize your data platform infrastructure. Learn more about the options for upgrading from SQL Server 2005 to a supported version here.

IMPORTANTE: Este artículo ha sido traducido por un software de traducción automática de Microsoft (http://support.microsoft.com/gp/mtdetails) en lugar de un traductor humano. Microsoft le ofrece artículos traducidos por un traductor humano y artículos traducidos automáticamente para que tenga acceso en su propio idioma a todos los artículos de nuestra base de conocimientos (Knowledge Base). Sin embargo, los artículos traducidos automáticamente pueden contener errores en el vocabulario, la sintaxis o la gramática, como los que un extranjero podría cometer al hablar el idioma. Microsoft no se hace responsable de cualquier imprecisión, error o daño ocasionado por una mala traducción del contenido o como consecuencia de su utilización por nuestros clientes. Microsoft suele actualizar el software de traducción frecuentemente.

Haga clic aquí para ver el artículo original (en inglés): 910378
INTRODUCCIÓN
Bases de datos compartidas escalables son compatibles con Microsoft SQL Server 2005 y en ediciones posteriores. Este artículo es una vista previa del tema "Escalable base de datos compartida" que ahora se publica como el siguiente tema en los libros en pantalla de SQL Server

Introducción a las bases de datos compartidas escalable
Más información

Bases de datos compartidas escalables

Bases de datos compartidas escalables permiten adjuntar una base de datos de sólo lectura a varias instancias de servidor a través de una red de área de almacenamiento (SAN). Una base de datos es una base de datos de sólo lectura que se genera a partir de una o más bases de datos producción que se usan exclusivamente con fines informativos. Para convertir en una base de datos escalable, una base de datos debe residir en uno o más volúmenes dedicados de sólo lectura. El propósito principal de estos volúmenes de sólo lectura es alojar la base de datos o un conjunto coordinado de bases de datos de informes. Estos volúmenes se denominan volúmenes de informes.

Ventajas

Bases de datos compartidas escalables ofrecen las siguientes ventajas:
  • Usingcommodity servidores para proporcionar escalado de carga de trabajo de creación de informes de bases de datos. Una base de datos escalable es una manera rentable de los puestos de datos sólo para makingread o almacenes de datos disponibles instancesfor de servidor varios informes, tales como ejecutar consultas o mediante servicios de SQL Server 2005Reporting.
  • Proporcionar aislamiento de cargas de trabajo. Cada servidor utiliza su base de datos tempdb , CPU y ownmemory.
  • Garantizar la misma vista de datos de todos los serversif todas las instancias de servidor tienen una configuración idéntica de informes. Por ejemplo, allservers podría utilizar una única intercalación.

    Nota: Si lo desea, puede actualizar la base de datos en un volumen de secondreporting. Para obtener más información, consulte la sección "Maximizar la disponibilidad de la base de datos compartida ascalable".

Restricciones

Las siguientes restricciones existen para una base de datos escalable:
  • La base de datos debe estar en un volumen de sólo lectura.
  • Los archivos de datos pueden tener acceso a través de un SAN.
  • Bases de datos compartidas escalables sólo son compatibles con Microsoft Windows Server 2003 Service Pack 1 (SP1) o una versión posterior de Windows Server 2003.

Ciclo de actualización de una base de datos informes

Cuando se utiliza una base de datos escalable para una base de datos, implica un ciclo de actualización de tres fases:
  • Fase de compilación: el ciclo de actualización de una base de datos comienza con el buildphase. Antes de poder generar una base de datos, el administrador monta el volumen de thereporting en el sistema de producción y facilita la lectura y escritura. Cuando avolume está en un estado de sólo lectura, el volumen puede ser montado en un sistema. Si el volumen está montado en más de un sistema, mightoccur de la corrupción del sistema de archivos. El administrador, a continuación, genera la base de datos con uno de los copymethods de datos proporcionados por SQL Server 2005 para copiar o bases de datos. Después de genera la base de datos, el administrador define el volumen en modo de sólo lectura y thendismounts.
  • Fase de asociación: la fase adjuntar viene después de la fase de compilación. El phasemakes de adjuntar la base de datos disponible como una base de datos escalable. El phasemust adjuntar puede realizar en cada uno de los servidores de informes de forma individual. Para configurar la base de datos thereporting como una base de datos escalable, el administrador monta sólo theread volúmenes informes en un servidor de informes en el SAN. Después de theadministrator se asegura de que cada volumen está establecido en modo de sólo lectura, theadministrator adjunta la base de datos en una instancia de SQL Server. Thereporting base de datos en una instancia de SQL Server también es conocido como una instancia de reportingserver. Ya que cada volumen de información es de sólo lectura, adjuntar la base de datos establece en sólo lectura. En este punto, la base de datos se convierte en ascalable base de datos compartida que se puede tener acceso a los clientes mediante el uso de la reportingserver.

    Nota: Si utiliza un segundo volumen informes cuando se actualiza la base de datos de thereporting, debe elegir entre una actualización sucesiva y actualización asincrónica. Para obtener más información, consulte la sección "Maximizar la disposición de una base de datos escalable".
  • Fase de separación: la tercera fase es la fase de separación. Normalmente, la reportingdatabase con el tiempo se convierte en obsoleto. Para mantener los datos de thereporting actual se debe actualizar la base de datos. La fase de desasociación es el proceso de quitar una base de datos de stalereporting de servicio como una base de datos escalable. Antes de hacer una actualización base de datos disponible en un determinado servidor de informes, debe completarse la fase de separación en ese servidor. Cuando se actualiza un informe databasemust, se debe desasociar desde todas las instancias de servidor. Para iniciar el separar la fase, la base de datos primer detendrá el loadthat de trabajo de consulta viene la base de datos de todas las instancias de servidor. En cada serverinstance, el Administrador de la base de datos obtiene acceso exclusivo a la base de datos y lo desconecta. El Administrador de la base de datos, a continuación, desmonta el sistema de host de cada volumen. Cuando esté terminada la fase de separación, la generación de informes isdisconnected de volumen desde el SAN.
Nota: Para maximizar la disponibilidad de datos de informes, le recomendamos que alternan ciclos de actualización entre dos volúmenes informes como una mejor práctica. Cuando el primer volumen informes aún se monta en los servidores de informes, puede montar el segundo volumen en el servidor de producción y, a continuación, generar una versión actualizada de la base de datos. Para obtener más información, consulte la sección "Maximizar la disponibilidad de una base de datos escalable".

Nota: Cada fase consta de una serie de pasos que se deben realizar por un usuario que tenga derechos de administrador de base de datos. En este artículo, dicho usuario se hará referencia a como el Administrador de la base de datos.

Importante: Para configurar una base de datos escalable, el entorno SAN debe ya funcione correctamente.

Ejemplos de bases de datos compartidas escalables

En ciclos de actualización posterior, puede ser actualizado o reconstruir la base de datos. El mejor método depende de los requerimientos del negocio. Puede utilizar bases de datos compartidas escalables de las dos maneras siguientes:
  • Base de datos del puesto: el uso más simple de una base de datos escalable es un martdatabase de datos. Una base de datos de data mart se extrae periódicamente el contenido del almacén de adata y se usa para informes. Para actualizar la base de datos de data mart, coloque la base de datos y, a continuación, reemplazarlo con una nueva versión.
  • Informes de una base de datos actualizable: cuando se notifica de la base de datos no tiene que se van a transformar de la base de datos de origen, la base de datos puede ser periodicallyupdated. Para actualizar periódicamente la base de datos, cree una copia de seguridad completa de la base de datos de producción y, a continuación, restaurar la copia de seguridad de la base de datos en los volúmenes o reportingvolume.

Asegúrese de que el entorno es correcto para una base de datos escalable

Debe ser una base de datos escalable en un volumen de sólo lectura que se puede acceder a través de un SAN. Los servidores de informes deben ejecutar lo siguiente:
  • Windows Server 2003 SP1 o una versión posterior de Windows Server 2003
  • Un debases de versión posterior Server 2005 o de SQL Server 2005 Enterprise Edition
Compatibilidad, recomendamos que limite sus configuraciones escalables de base de datos compartida con ocho instancias de servidor. Sin embargo, SQL Server 2005 no limita el número de instancias simultáneas que puede tener acceso a una base de datos escalable. Normalmente, cada instancia de servidor se ejecuta en un servidor de informes independiente. Sin embargo, se admite la ejecución de varias instancias de servidor de informes en un servidor de informes.

Configurar el entorno

Para asegurarse de que su entorno es compatible con bases de datos compartidas escalables, le recomendamos que siga estas instrucciones:
  • Asegúrese de que los servidores de informes de una base de datos particularreporting se ejecutan en sistemas operativos idénticos. Cada vez que youupgrade un servidor de informes, actualizar otros servidores informes que sirven la misma base de datos compartida escalable o bases de datos. Por ejemplo, si aplica asoftware actualización o service pack de Windows o de SQL Server 2005 a cualquiera de los servidores de informes, aplicar el mismo software actualización o service pack a todos los servidores de informes.

    Nota: Con frecuencia, puede realizar actualizaciones sucesivas de la reportingservers siempre y cuando se complete la actualización sucesiva de manera oportuna.
  • Bases de datos compartidas escalables se prueban bajo una carga de trabajo concurrentaccess por hasta ocho instancias de servidor de SQL Server 2005 EnterpriseEdition. SQL Server 2005 no impone un límite de instancia. Sin embargo, recomendamos que limite su escalable comparten configuraciones de base de datos a instancias de eightserver para cada base de datos compartida.
  • Si los archivos de datos de la base de datos de producción abarcan multiplevolumes, debe utilizar el mismo número de volúmenes de informes. Por el contrario, dado que la base de datos se establece en modo de sólo lectura, sus archivos de registro pueden co-existwith los archivos de datos en un volumen informes.
  • Para simplificar el proceso de creación o actualización de base de datos de areporting, se recomienda que la ruta de acceso de la base de datos sea la misma que la base de datos de producción. Esto incluye el uso de ambos la misma carta de para de unidad del volumen de generación de informes y la misma ruta de directorio para la base de datos. Por ejemplo, si se encuentra la base de datos de producción en E:\SQLdata, uso E como la carta de unidad del volumen de generación de informes, si es posible. Además, debe utilizar \SQLdata como deldirectorio de la base de datos, si es posible. Sin embargo, una secuencia de comandos eso se ha acabado explícita las rutas de acceso pueden resolver las diferencias. Si el volumen informes utiliza la letra de unidad diferente que el volumen de producción, tendrá que hacer las modificaciones siguientes:
    • Si la base de datos se genera mediante la restauración de una copia de seguridad de la base de datos, la instrucción RESTORE DATABASE debe tener una cláusula WITH MOVE que especifica la ruta completa de los archivos de datos restaurados.
    • Si la base de datos es una copia de la base de datos de producción, la cláusula FOR ATTACH de la instrucción CREATE DATABASE debe enumerar todos los archivos. La cláusula FOR ATTACH también debe especificar la ruta de acceso completa al adjuntar la base de datos. Siempre es una práctica recomendada.

      Nota: Como práctica recomendada, utilice la misma letra de unidad en todos los servidores cuando se monta un volumen de generación de informes en los servidores informes. Esta práctica ayuda a administrar el volumen a través de los diferentes servidores.
  • La base de datos debe estar en un volumen de sólo lectura que puede tener acceso a través del SAN en todos los servidores de informes:
    • Después de montar el volumen informes en un servidor de informes, asegúrese de que el volumen informes se ha montado correctamente y que se pueden tener acceso a los archivos de datos. Para ello, escriba DIR <drive-letter></drive-letter>:\<database-directory></database-directory> en el símbolo del sistema, donde <drive-letter></drive-letter> es la letra asignada al volumen de generación de informes y <database-directory></database-directory> Especifica la ubicación de los archivos de datos de la base de datos en el volumen. Ejecutar esta prueba desde cada servidor de informes para asegurarse de que recibe los resultados de la mismos para todos ellos.
    • Para asegurarse de que la base de datos se establece como de sólo lectura, pruebe a crear un archivo en el volumen. El método más sencillo es intentar copiar o guardar un archivo de texto sin formato en el volumen. El producirá un error porque el volumen es de sólo lectura.

      Nota: Si va a realizar estos pasos manualmente, se recomienda que repita estas pruebas en cada ciclo de actualización cuando vuelva a montar el volumen informes en cada servidor de informes. Si la secuencia de comandos los pasos para mover volúmenes informes de ida y vuelta entre el servidor de producción y los servidores de informes, las pruebas no se requiere cuando se haya asegurado de que las secuencias de comandos funcionan correctamente.

Fase 1: La fase de compilación

Crear o actualizar una base de datos escalable

Una base de datos debe ser creado y actualizar manualmente. Este proceso es la primera fase del ciclo de actualización de una base de datos y se conoce como la fase de construcción. Actualizar una base de datos obsoleto o construir una nueva versión, puede implicar la fase de construcción.

Normalmente, la versión actual de una base de datos con el tiempo se convierte en obsoleta. La base de datos debe actualizarse periódicamente para mantener los datos de informes actualizados.

Completar la fase de creación

Puede actualizar una base de datos informes antiguos mediante la actualización de los datos obsoletos en la base de datos existente o reconstruir la base de datos.

Nota: Para poder actualizar una base de datos existente, debe desasociar la base de datos de cada instancia de reporting server. Además, se debe desmontar el volumen informes de cada servidor de informes. Para obtener más información, consulte la sección "Separar una base de datos escalable".

Para actualizar una base de datos obsoleto, siga estos pasos en el servidor de producción:
  1. Utilice Utilidades de su proveedor de hardware para desenmascarar a los números logicalunit (LUN) que corresponden a los volúmenes de informes. Esta acción hace los volúmenes accesibles para el servidor de producción.
  2. Montar el volumen de generación de informes y, a continuación, marcarlo asread y escritura. Para utilizar la utilidad de línea de comandos de Diskpart para montar el volumen, siga los comandos en el símbolo de ENTRAR:DiskPart
    DISKPART > selectvolume =<drive-number></drive-number>
    DISKPART > assignletter =<drive-letter></drive-letter>
    DISKPART > readonly clara de atributo
    DISKPART > salir

    En este paso,<drive-number></drive-number> es el número del volumen que isassigned por Windows, y <drive-letter></drive-letter> es la carta que se asigna al volumen de generación de informes.
  3. Si va a actualizar una base de datos existente, siga estos pasos:
    1. Adjuntar la base de datos a una instancia del servidor. Normalmente, esto sería la instancia del servidor de producción.
      CREATE DATABASE <database_name> ON <filespec_list>   FOR ATTACH
    2. Establecer la base de datos para acceso de lectura/escritura utilizando la siguiente instrucción de Transact-SQL.
      ALTER DATABASE <database_name> SET READ_WRITE
      Para obtener más información, consulte los libros en pantalla de SQL Server 2005.
  4. Crear la base de datos.

    Para actualizar un reportingdatabase, puede actualizar los datos obsoletos, volver a generar la base de datos o hacer lo más que piensa que es necesario para actualizar los datos. El administratorbuilds de la base de datos utilizando cualquiera de los métodos de copia de datos que son facilitadas por SQL Server 2005 para copiar o bases de datos. Para obtener más información, consulte la sección "Métodos para crear o actualizar una base de datos".

    Nota: En el informe de bases de datos, se recomienda establecer que pageverify a la suma de comprobación, el valor predeterminado. Para configuración de cambiar, utilice ALTER DATABASE.
  5. Establecer la base de datos de sólo lectura mediante la instrucción SQL de la followingTransact.
    ALTER DATABASE <database_name> SET READ_ONLY
  6. Separar la base de datos utilizando el siguiente Transact-SQLstatement.
    sp_detach_db @dbname='<database_name>'
    En este paso, <database_name></database_name> es el nombre de la base de datos.
  7. Marcar el volumen como de sólo lectura y, a continuación, desmonte el volumefrom el servidor de producción. Para utilizar el todismount de la utilidad de línea de comandos de Diskpart el volumen, escriba los comandos siguientes en un símbolo del sistema.
    DiskPartDISKPART> select volume=<drive-number>DISKPART> attribute set readonlyDISKPART> remove
    En este paso, <drive-number></drive-number> es el número de thevolume que se asigna por Windows, y<drive-letter></drive-letter> es la letra que está asignada el volumen informes.
  8. Utilice Utilidades de su proveedor de hardware para enmascarar el thatcorrespond de LUNs a los volúmenes de informes. Esta acción hace que el inaccessibleto de los volúmenes del servidor de producción.
Ahora, la base de datos puede ponerse a disposición como una base de datos escalable. Para obtener más información, consulte la sección "Adjuntar una base de datos escalable".

Métodos para crear o actualizar una base de datos

Nota: Cuando se crea una base de datos, se recomienda que utilice siempre la misma ruta de acceso de la base de datos de producción y las bases de datos informes. Además, se recomienda que utilice la misma letra de unidad a la producción y el reporting de volumen cuando se monta el volumen en los servidores de informes, si es posible.

SQL Server 2005 admite actualmente los siguientes métodos para trasladar datos en una base de datos o para trasladar una base de datos completa:
  • SQL Server Integration Services: puede crear o copiar una base de datos mediante la ejecución de paquetes deSoluciones y mediante la tarea Ejecutar SQL o la Databasetask de transferencia:
    • La tarea Ejecutar SQL ejecuta instrucciones SQL o procedimientos almacenados de un paquete. Cuando se utiliza la tarea de ejecución de SQL, puede crear una base de datos mediante la ejecución de una instrucción CREATE DATABASE. Se puede rellenar la base de datos mediante la copia en una o más tablas o vistas.
    • La tarea de transferencia de base de datos puede copiar una base de datos en la misma instancia de servidor o entre las instancias.

      Nota: También puede crear una base de datos utilizando SQL Server importar y exportar, pero debe copiar al menos una tabla o vista.
  • Backup y restore: puede restaurar una copia de seguridad de una base de datos de producción en volumen de thereporting. Para ello, restaurar y recuperar un volumen informes entra de copia de seguridad de base de datos completa:
    • Si utiliza la misma letra de unidad, monte el volumen de informes en un host diferente y, a continuación, conectarse a una instancia de servidor hay que restaurar la base de datos.
    • Si el volumen informes utiliza una letra de unidad diferente que el volumen de producción, la instrucción RESTORE DATABASE debe tener una cláusula WITH MOVE que especifica la letra de unidad del volumen de generación de informes en la ruta de acceso de la base de datos.
  • Copia de la base de datos de producción en el volumen informes: para poder copiar una base de datos manualmente o utilice el método andAttach de desasociar del Asistente para copiar bases de datos, debe desconectar la base de datos. Después de copiar la base de datos, poner en línea la base de datos. Sin embargo, el Asistente de CopyDatabase ofrece un método alternativo. Base de datos de la copia del método de transferencia de SMO aunque la base de datos permanece en línea. Aunque el Transfermethod SMO es más lento que el método de separar y adjuntar, las transferencia de SMO methodpreserves las conexiones activas con la base de datos.
Para obtener más información acerca de estos métodos de copia de datos, vea los libros en pantalla de SQL Server 2005.

Cuando la base de datos está preparado, debe completar la fase de construcción. Para obtener más información, vea la "fase 1: la fase de creación" sección.

Fase 2: La fase de asociación

Adjuntar una base de datos escalable

Después de generar o actualizar una base de datos de generación de informes y desmontar el volumen informes desde el servidor de producción, un administrador debe disponer de la base de datos como una base de datos escalable. Este proceso se conoce como la fase de asociación.

Completar la fase de asociación

En esta fase, un administrador debe realizar los siguientes pasos:
  1. Uso de utilidades de su proveedor de hardware para desenmascarar el LUNsthat que se correspondan con los volúmenes informes. Esta acción hace que el volumesaccessible a los clientes de cada servidor de informes.
  2. En cada servidor de informes, monte el thatcorresponds de volumen al LUN.

    Nota: Para simplificar el proceso de creación o actualización de un reportingdatabase, se recomienda montar siempre su volumen de generación de informes con la misma letra de unidad como el volumen de producción. Por ejemplo, si la base de datos deproducción está en la unidad E del servidor de producción, la generación de informes shouldalso volumen montar como unidad E en cada servidor de informes, si es posible.

    Para utilizar la utilidad de línea de comandos de Diskpart para montar el volumen, comandos ENTRAR al siguiente en un símbolo del sistema.
    DiskPartDISKPART> select volume=<drive-number>DISKPART> assign letter=<drive-letter>DISKPART> exit
    En este paso, <drive-number></drive-number> es el número de thevolume que se asigna por Windows, y<drive-letter></drive-letter> es la letra que desee usar para el volumen informes en el servidor de informes.

    Nota: El volumen informes debe ser de sólo lectura. Se recomienda que TI se desmonta marcado como de sólo lectura antes el volumen del servidor de producción. Si el volumen no se ha marcado como de sólo lectura, ajustar el volumen para el montaje de sólo lectura cuando el volumen en el primer servidor informes. Para obtener más información, vea "fase 1: la fase de creación" sección.

    Como práctica recomendada, debería de que el volumen es accesible como un volumen de sólo lectura sobre el SANafter monta un volumen informes para cada servidor de informes. Para obtener más información, consulte la sección "Asegúrese de que el entorno es correcto para una base de datos de scalableshared".
  3. Adjuntar la base de datos para el informe orinstances de instancia de servidor en cada servidor de informes. Para obtener más información, consulte en línea de SQL Server 2005Books.
La base de datos está ahora disponible como una base de datos escalable y pueden continuar con las consultas.

La fase 3: La fase de separación

Separar una base de datos compartida escalable

Normalmente, la versión actual de una base de datos informes finalmente quede obsoleta y debe actualizarse para mantener los datos de informes actualizados. El proceso de quitar una base de datos informes antiguos del servicio como una base de datos escalable se conoce como la fase de separación. Esta fase es la tercera y última fase de la actualización de ciclo para una base de datos. Antes de que pueda disponer de una base de datos actualizada en un determinado servidor de informes, debe completarse la fase de separación en ese servidor.

Completar la fase de separación

En esta fase, un administrador debe realizar los pasos siguientes en cada servidor de informes:
  1. Deshabilitar nuevas consultas en la base de datos y, a continuación, permitir que currentqueries se completa correctamente, si es posible.
  2. Separar la base de datos de cada informe utilizando instancia de servidor el sp_detach_db @dbname ='<database_name>'</database_name>comando.

    En este paso,<database_name></database_name> es el nombre de la base de datos. Para obtener más información acerca del comando sp_detach_db , consulte los libros en pantalla de SQL Server 2005.
  3. En cada servidor de informes, desmontar el volumen informes. Para desmontar el volumen mediante el uso de la utilidad de línea de comandos de Diskpart, escriba los comandos siguientes en un símbolo del sistema.
    DiskPartDISKPART> select volume <drive-number>DISKPART> remove
    En este paso, <drive-letter></drive-letter> es la carta que asignado al volumen del informe.
  4. Utilice Utilidades de su proveedor de hardware para enmascarar el thatcorrespond de LUNs a los volúmenes de informes. Esta acción hace que los volúmenes de los clientes de inaccessibleto de cada servidor de informes.

Estrategias alternativas para separar una base de datos informes antiguos

Cuando se reemplaza la versión obsoleta de una base de datos, debe tener en cuenta los requerimientos del negocio para su entorno de creación de informes. Debe evaluar cuál de los siguientes requisitos empresariales tienen prioridad en su entorno:
  • Conservar las transacciones actualmente en ejecución hasta theyfinish.
  • Completar la actualización dentro de una limitedtimeframe.
En función de qué requisito tiene prioridad, puede decidir cómo administrar la fase de separación en cada servidor de informes. Puede administrar la fase de separación de las maneras siguientes:
  • Permitir que las transacciones se termine antes de desconectar el reportingserver: para conservar todas las transacciones en curso, debe iniciar el detachphase deteniendo entrante actividad de E/S en el volumen informes. A continuación, en la instancia del servidor eachreporting, espere para separar la base de datos hasta que finalicen todas las currenttransactions. Cuando se separó la base de datos de todas las instancias de servidor, puede desmontar el volumen informes.
  • Actualizar la base de datos durante un período de tiempo limitado: en este, debe obtener acceso exclusivo a la base de datos en cada serverinstance con una hora de finalización que permite que el período de tiempo. Si cualquier queriesdo no finaliza en ese momento de la rescisión, se detendrá. Los querieswill tienen que esperar hasta después de que se reinicie la actualización. Después de la arestopped de las consultas, puede separar la base de datos de cada instancia de servidor y thendismount el volumen de información de cada servidor de informes.
En este punto, está listo para la siguiente fase de compilación. O bien, si ya ha actualizado la base de datos en otro volumen informes como se recomienda, ahora puede realizar la fase de asociación para el volumen alternativo. Para obtener más información, consulte la sección "Maximizar la disponibilidad de una base de datos escalable".

Maximizar la disponibilidad de una base de datos escalable

Para maximizar la disponibilidad de datos de informes, le recomendamos que alternan ciclos de actualización entre dos volúmenes informes. Cuando el primer volumen informes aún se monta en los servidores de informes, puede montar el segundo volumen en el servidor de producción y generar una versión actualizada de la base de datos.

Si actualiza la base de datos en un segundo volumen de generación de informes, considere las siguientes opciones:
  • Si desea que todas las bases de datos reporting a resultados de returnidentical a los clientes, debe separar la copia antigua de todas las serverinstances antes de asociar la nueva copia a uno de ellos.
  • Si puede tolerar los clientes reciban las instancias de servidor de diferentes resultados diferentes al actualizar la base de datos, canperform una actualización sucesiva de la base de datos. Terminaría ciclo de theupdate en un servidor informes a la vez.

Sincronizada, sensibles al tiempo que las actualizaciones de todos los servidores de informes

En esta sección se describe varias estrategias para actualizar el contenido de una base de datos compartida escalable según los requerimientos del negocio:
  • Deben mantener todos servidores de informes en sincronización.
  • Debe realizar la actualización en un plazo limitado. Este período de tiempo es más importante que conservar realizando transacciones.
Al sincronizar la base de datos en todos los servidores informes, la base de datos no está disponible entre la fase detach para la versión obsoleta de la base de datos y la fase de asociación de la nueva versión.

Para sincronizar el ciclo de actualización en todas las instancias de servidor y el final del ciclo la actualización dentro de un plazo limitado informes, siga estos pasos:
  1. Para mantener el contenido sincronizado, debe finalizar la detachphase en todos los servidores informes antes de cualquiera de los informes servidores se puede actualizada. Si las consultas de larga duración activas en cualquier servidor, debe stopthem.
  2. Después de desmontar el primer volumen de generación de informes de todas las instancias de servidor, puede empezar a actualizar los servidores de informes. En el servidor de eachreporting, montar otro volumen que contenga una versión más actual de la base de datos. Adjuntar esa versión a la serverinstance informes local. Tan pronto como se adjunta la base de datos de una instancia concreta, se puede reiniciar stoppedtransactions en esa instancia.

Actualizaciones sucesivas de servidores de informes

Una actualización sucesiva le permite actualizar la base de datos en un servidor informes cuando un obsoletos en la base de datos de reporting sigue estando temporalmente disponible en otro servidor informes. Durante un tiempo, la versión obsoleta y la versión actualizada de la base de datos están disponibles al mismo tiempo. Dependiendo de los requerimientos de su negocio, puede producirse una actualización sucesiva en un período de tiempo limitado o la actualización sucesiva puede ser relativamente abierta a finalizar las transacciones actuales.

Permitir que las transacciones finalicen antes de la actualización sucesiva

En esta estrategia, una actualización sucesiva permite al administrador de la base de datos de espera para que las transacciones de larga duración para que finalice en un servidor de informes cuando se actualiza la base de datos en otro servidor informes. Esta estrategia aborda los requisitos empresariales siguientes:
  • Los servidores de informes no deben estar sincronizados. Actualización sucesiva de Thispermits entre la base de datos obsoleto y la base de datos de updatedreporting.
  • Tiene un período de tiempo ilimitado para realizar la actualización o la fecha límite es menos importantes que actualmente conserva runningtransactions.
Para realizar este tipo de actualización sucesiva, siga estos pasos en una instancia del servidor a la vez:
  1. Para conservar todas las transacciones en curso, debe empezar desasociar fase deteniendo entrante actividad de E/S en el volumen informes. Consulta de larga ejecución CeBIT retrasa la actualización en una instancia de servidor, espere a que la unión termine antes de desconectar la instancia del servidor.
  2. Una vez haya terminado de todas las transacciones en esta serverinstance, desconecte la base de datos.
  3. Después de desasociar una determinada base de datos de todas las instancias de servidor, adjuntar una versión más reciente de las bases de datos Oraclea informes de esa instancia de servidor.
  4. Para que la instancia del servidor disponible para reportingqueries, adjuntar una copia actualizada de la base de datos.

Finalizar la actualización sucesiva en un tiempo limitado

En esta estrategia, una actualización sucesiva permite al administrador de la base de datos para mantener un servicio ininterrumpido informes permitiendo brevemente la versión obsoleta de la base de datos permanecen disponibles para nuevas consultas en algunos servidores de informes. El servicio no se interrumpe cuando se actualiza la base de datos en otro servidor informes. Esta estrategia aborda los requisitos empresariales siguientes:
  • Los servidores de informes no deben estar sincronizados. Actualización sucesiva de Thispermits entre la base de datos obsoleto y la base de datos de updatedreporting.
  • Debe realizar la actualización en un período de tiempo limitado. Este plazo es más importante que conservar realizando transacciones.
Para realizar este tipo de actualización sucesiva, siga estos pasos en un servidor informes a la vez:
  1. Detener entrante actividad de E/S en el volumen informes y, opcionalmente, espere a que las transacciones cortas para que finalice en un antes de la instancia de servidor separar su base de datos.
  2. Finalizar la fase de separación en ese servidor. Para obtener más información, consulte la sección "Separar una base de datos escalable".
  3. Hacer que la versión actualizada de la generación de informes databaseavailable para consultas de informes. Para obtener más información, consulte la sección "Base de datos escalable ashared de adjuntar".
Esta actualización sucesiva de garantiza que nunca se interrumpe la capacidad global de generación de informes. Esta estrategia le permite soportar transacciones bastante prolongada en algunas de las instancias de servidor durante un tiempo. Sin embargo, dado el período de tiempo limitado para actualizar todos los informes bases de datos, si una consulta de larga ejecución retrasa significativamente la actualización en una instancia del servidor, debe detener dicha consulta. La consulta puede esperar para volver a ejecutar en la misma instancia de servidor después de que se ha actualizado su base de datos o la consulta puede reiniciarse antes en un servidor actualizado.
Referencias
Para descargar los libros en pantalla de SQL Server 2005, visite el siguiente sitio Web del centro de descarga de Microsoft:
SQL Server requiere sistemas de apoyo "entrega garantizada a medios estables", tal como se describe en el programa de revisión de soluciones de almacenamiento de información de Microsoft SQL Server desplaza. FOPara obtener más información acerca de los requisitos de entrada y salidos para el motor de base de datos de SQL Server, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
967576 Requisitos de entrada/salida de motor base de datos de Microsoft SQL Server
SSD kbsql2005addtobol

Propiedades

Id. de artículo: 910378 - Última revisión: 05/12/2015 03:42:00 - Revisión: 1.0

Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2005 Enterprise Edition for Itanium Based Systems, Microsoft SQL Server 2005 Enterprise X64 Edition, Microsoft SQL Server 2008 Developer, Microsoft SQL Server 2008 Enterprise, Microsoft SQL Server 2008 Express, Microsoft SQL Server 2008 Standard

  • kbsql2005engine kbtshoot kbinfo kbmt KB910378 KbMtes
Comentarios