Mantenimiento de las bases de datos de Planning Server

En cada instalación de Planning Server, hay una base de datos del sistema de planeación (PPSPlanningSystem) y una base de datos del servicio de planeación (PPSPlanningService).

La base de datos del sistema de planeación contiene los siguientes componentes:

• Datos de seguridad del sistema de planeación

• Datos de la biblioteca de tipos de planeación

• Datos de configuración del nivel de sistema de planeación

• Metadatos del nivel de aplicación de planeación

El tamaño de la base de datos del sistema de planeación y la base de datos del servicio de planeación es pequeño y permanecerá relativamente pequeño.

La base de datos del sistema de planeación y la base de datos del servicio de planeación pueden crearse manualmente o mientras se ejecuta el Administrador de configuración de Planning Server.

Si decide que el Administrador de configuración de Planning Server cree estas dos bases de datos, ambas se colocarán en el grupo de archivos principal con el tamaño de archivo de datos predeterminado establecido en 50 MB y con un crecimiento automático de 50 MB. El tamaño del archivo de registro predeterminado se establecerá en 20 MB, con un crecimiento automático de 20 MB.

Si decide crear estas dos bases de datos manualmente, puede elegir el grupo de archivos y cambiar la configuración predeterminada de tamaño inicial del archivo de base de datos y de registro.

SQL Server 2005 asigna una base de datos a un conjunto de archivos del sistema operativo. La información de los datos y de registro no se mezcla nunca en el mismo archivo, y cada uno de los archivos es utilizado exclusivamente por una base de datos. Para obtener más información sobre los archivos de datos y de registro de la base de datos, consulte SQL Server.

En todas las bases de datos de Planning Server que Planning Server crea automáticamente, el valor predeterminado del tamaño del archivo de datos inicial se establece en 50 MB, con un crecimiento automático por 50 MB.

Para las bases de datos provisionales y de aplicaciones, sugerimos que los administradores de la base de datos de Planning Server del cliente realicen la planeación de la capacidad, y usen los datos de la organización y la directiva de retención de datos para determinar un tamaño razonable para el archivo de datos inicial. Por ejemplo, se puede determinar cuántos modelos esperan incluir en cada sitio de modelos y cuántos sitios de modelos esperan incluir en la aplicación.

Estas son algunas directrices generales para diseñar los archivos de datos y de registro de la base de datos:

• Habilite los archivos de datos y de registro de la base de datos para que puedan crecer automáticamente.

• Asigne tamaños iniciales razonables a los archivos de la base de datos y de registro.

• Establezca un tamaño máximo a los archivos de datos para que no se agote el espacio cuando no disponga de suficiente espacio en disco (especialmente importante si tiene varias bases de datos).

• Establezca un tamaño razonable para el incremento del crecimiento del archivo de datos (preferencias: un incremento fijo menor o igual a 1 GB, a lo que contribuye significativamente la inicialización instantánea de archivos).

• Considere la posibilidad de permitir la inicialización instantánea de los archivos de datos.

• Tenga en cuenta el uso de la tecnología RAID para los archivos de datos y de registro.

• Asigne sólo un archivo de registro.

• Aísle el archivo de registro en una unidad independiente (para obtener un mejor rendimiento, los archivos de registro deben estar en un disco físico independiente, antes que los archivos de datos).

También es importante supervisar el archivo de registro. Puede supervisar el estado del archivo de registro mediante la ejecución de la siguiente consulta:

select * from 
sys.dm_os_performance_counters 
where counter_name like '%Log%'
and instance_name = 'Alpine_Ski_House_AppDB'

Para obtener más información, consulte SQL Server.

Para minimizar el crecimiento automático del archivo de registro, le recomendamos que asigne de forma previa un tamaño adecuado al registro. El tamaño del archivo de registro depende de dos factores: la frecuencia de la copia de seguridad del registro y la actividad del sistema Planning Server.

Aunque la regla general es asignar previamente al archivo de registro un tamaño del 10 o 15 por ciento del archivo de base de datos, el tamaño real del archivo de registro depende de la frecuencia de la copia de seguridad del registro.

Si realiza una copia de seguridad del archivo de registro cada cinco minutos y tiene una actividad normal de Planeación, le recomendamos que asigne el tamaño inicial del archivo de registro de la siguiente manera:

• Base de datos del sistema de planeación: 50 MB

• Base de datos del servicio de planeación: 200 MB

• Base de datos de aplicaciones de planeación: 1 GB

• Base de datos provisional de planeación: 1 GB

• Base de datos de salida de planeación: 400 MB

Puede cambiar estos tamaños según la frecuencia de la copia de seguridad del registro. Por ejemplo, si hace una copia de seguridad del registro cada 10 minutos, deberá ampliar el tamaño del archivo de registro inicial. Si hace una copia de seguridad del archivo de registro cada dos minutos, puede asignar un tamaño de archivo de registro más pequeño.

Además de un tamaño adecuado para el archivo de registro inicial, le recomendamos que establezca el archivo de registro en crecimiento automático con una cantidad fija (no un porcentaje), y que también defina un límite máximo de crecimiento para el registro No establezca un crecimiento sin restricciones.

Minimizar el archivo de registro virtual (VLF) también es importante para el rendimiento de SQL Server. Para obtener más información sobre la forma de llevar a cabo esta tarea, consulte SQL Server.

Es importante que haga una copia de seguridad del archivo de registro con regularidad. En el sistema de producción, se recomienda que programe el equipo que ejecuta SQL Server para que inicie periódicamente las copias de seguridad (por ejemplo, cada 5 o 10 minutos) a fin de evitar la pérdida de datos. Si el modo de recuperación de la base de datos está completo y no ha hecho copias de seguridad del registro durante un largo período de tiempo, éste continuará creciendo hasta que genere un error de “registro lleno".

Hacer copias de seguridad con frecuencia no afecta mucho al sistema, ya que la sobrecarga es mínima. Cuanto más fragmentado esté el archivo de registro, más trabajo requerirá la copia de seguridad. Esta es la razón por la que resulta importante asignar previamente un archivo de registro de tamaño razonable para el sistema; dará como resultado un mejor rendimiento en la copia de seguridad del registro.

Cuando un archivo de registro está lleno, lo único que puede hacer es realizar la copia de seguridad. Al hacer la copia de seguridad, se desactivará el registro inactivo y el archivo de registro se reducirá de tamaño. Realizar una copia de seguridad del registro no borrará los registros activos porque las transacciones aún no están confirmadas.

En un entorno experimental donde no es necesario preocuparse por la pérdida de datos, puede truncar el registro para borrarlo. Sin embargo, sólo debe hacer esto en los sistemas de prototipo, desarrollo o pruebas, donde la pérdida de datos es aceptable.

En los sistemas de producción o experimentales, debe controlar atentamente el archivo de registro (copia de seguridad o truncamiento), pues de lo contrario el archivo de registro crecerá rápidamente y afectará al rendimiento del sistema Planeación.

Ejemplos de secuencias de comandos

En esta sección se ofrecen ejemplos de secuencias de comandos para realizar la copia de seguridad o el truncamiento del registro. Es importante que programe el equipo con SQL Server para que ejecute la siguiente secuencia de comandos. Si está trabajando en un entorno de prueba o prototipo y no desea dedicar tiempo al control de la copia de seguridad o al truncamiento del registro, cambie el modo de recuperación de la base de datos del modo predeterminado Completo al Básico, modificando la página de propiedades de la base de datos de SQL Server Management Studio.

Importante:
El modo simple nunca debe utilizarse en el sistema de producción. Para obtener más información sobre los modelos de recuperación de bases de datos, consulte SQL Server.

-- Truncate Log sample script
-- Use only if you are in testing environment and do not care about DB backup.
BACKUP LOG 'Alpine_Ski_House_AppDB WITH NO_LOG
GO
BACKUP LOG 'Alpine_Ski_House_AppDB WITH TRUNCATE_ONLY
GO

USE 'Alpine_Ski_House_AppDB
GO
EXEC sp_helpfile 
GO
-- get the log file name for this DB

-- now shrink the log file
USE 'Alpine_Ski_House_AppDB
GO
DBCC SHRINKFILE(Alpine_Ski_House_AppDB_log, TRUNCATEONLY)
GO

-- Backup log sample script
-- For any DB that you care about data loss, you should back up DB and the 
-- log, that is the only good way to clear the inactive logs.

-- Create dump devices first
EXEC sp_addumpdevice 'disk', 'ServiceDBData', 
'C:\work\ServiceDBData.bak';
GO

EXEC sp_addumpdevice 'disk', 'ServiceDBLog', 
'C:\work\ServiceDBLog.bak';
GO

-- Back up database and log file
USE PPSPlanningService
GO
BACKUP DATABASE PPSPlanningService TO ServiceDBLog;
GO
BACKUP LOG PPSPlanningService TO ServiceDBLog
GO
DBCC SHRINKFILE(PPSPlanningService_log, TRUNCATEONLY)
GO

Importante:

Debe truncar el registro en un sistema experimental o configurar el equipo que ejecuta SQL Server para que realice la copia de seguridad del registro de forma periódica y borre el tamaño del archivo de registro, a fin de obtener un mejor rendimiento y evitar la pérdida de datos. Si deja que los archivos de registro alcancen un tamaño demasiado grande, el rendimiento de Planning Server se verá afectado de forma significativa. Con el transcurso del tiempo, el archivo de registro en crecimiento llegará a consumir una enorme cantidad de espacio en disco.

El tamaño de TempDB puede afectar al rendimiento del sistema. Por ejemplo, si el tamaño definido para TempDB es demasiado pequeño, cada vez que reinicie el servicio de SQL Server (MSSQLServer) es posible que parte de la carga de procesamiento del sistema deba dedicarse al crecimiento automático de la base de datos, hasta llegar al tamaño necesario para que admita la carga de trabajo. Puede evitar esta sobrecarga si aumenta el tamaño de TempDB.

Estas son algunas recomendaciones generales para la ubicación física y las opciones de la base de datos que se establecen para TempDB:

• Permita que TempDB pueda expandirse automáticamente según sea necesario.

• Establezca el tamaño original de los archivos TempDB en un tamaño razonable para evitar que los archivos se expandan automáticamente cuando necesiten más espacio. Si TempDB se expande con demasiada frecuencia, el rendimiento puede verse afectado.

• Establezca el porcentaje de incremento de crecimiento de archivos en un tamaño razonable para evitar que los archivos TempDB crezcan con valores demasiado pequeños. Si el crecimiento del archivo es demasiado pequeño, en comparación con la cantidad de datos que se escriben en TempDB, es posible que la base de datos tenga que expandirse constantemente. Esto afectará al rendimiento.

• Ponga TempDB en un subsistema rápido de entrada y salida para garantizar un buen rendimiento. Divida TempDB entre varios discos para obtener un mejor rendimiento. Ponga TempDB en discos diferentes a los que usan las bases de datos de usuarios. Para obtener más información acerca de cómo mover TempDB a una nueva ubicación, consulte SQL Server.

Cuando se reinicia SQL Server, el tamaño de TempDB vuelve al tamaño configurado inicialmente y crece de acuerdo con las necesidades. Esto puede dar lugar a la fragmentación de TempDB y puede ocasionar una sobrecarga. Es algo que puede afectar al rendimiento de la carga de trabajo. Se recomienda que asigne previamente un tamaño adecuado a TempDB.

Dado que las bases de datos de Planning Server utilizan el "aislamiento confirmado de lectura" mediante la característica de control de versiones de fila, se debe establecer para TempDB un tamaño razonablemente grande para obtener un buen rendimiento. Establezca el tamaño inicial de TempDB en 500 MB como mínimo. Establezca el tamaño inicial de TempDB en 1 GB para obtener un rendimiento incluso mejor.

Es importante supervisar el espacio libre en TempDB. Para obtener más información, consulte SQL Server.

Debe agrupar objetos y archivos de base de datos en grupos de archivos para fines de administración y asignación.

La base de datos del sistema de planeación y la base de datos del servicio de planeación pueden crearse durante la instalación de Planning Server, o los clientes pueden configurarlas manualmente antes de instalar el software Planning Server. Si deja que Administrador de configuración de Planning Server cree estas dos bases de datos, no tendrá la opción de especificar un grupo de archivos. Estas dos bases de datos tienen un tamaño relativamente pequeño y la necesidad de utilizar para ellas un grupo de archivos es mínima.

La base de datos de aplicaciones de planeación se crea durante el proceso de creación de aplicaciones. Cuando se crean bases de datos de aplicaciones, se tienen dos opciones. Los clientes pueden especificar la opción de Ejecución manual en la interfaz de usuario Crear aplicación de Consola de administración de planeación, de forma que los administradores de la base de datos puedan personalizar CREATE DATABASE/CREATE TABLE durante el proceso de creación de la aplicación. En concreto, los administradores de la base de datos pueden agregar la información del grupo de archivos al crear la base de datos de aplicación. Una vez que se generan las secuencias de comandos de SQL Server en el proceso de creación de aplicaciones, los administradores de la base de datos pueden editar CreateAppDB.sql y TypeLibMasterSchema.SQL, y agregar la información del grupo de archivos a estas secuencias de comandos antes de que las ejecuten manualmente.

Para obtener más información acerca de los grupos de archivos, consulte SQL Server.