Maintenance des bases de données Planning Server

Pour chaque installation Planning Server, il existe une base de données système Planning Server (PPSPlanningSystem) et une base de données service Planning Server (PPSPlanningService).

La base de données système Planning Server contient les composants suivants :

• Planification des données de sécurité système

• Planification des données de la bibliothèque de types

• Planification des données de configuration au niveau du système

• Planification des métadonnées au niveau de l'application

La taille des bases de données système et service de Planning Server est petite et reste relativement petite.

La base de données système et la base de données service peuvent être créées soit manuellement soit lors de l'exécution de Gestionnaire de configuration Planning Server.

Si vous choisissez que Gestionnaire de configuration Planning Server se charge de créer ces deux bases de données pour vous, celles-ci sont placées dans le groupe principal de fichiers avec une taille de fichier de données par défaut de 50 Mo, et peuvent s'accroître automatiquement par incrément de 50 Mo. La taille du fichier journal par défaut est de 20 Mo, et il peut s'accroître automatiquement par 20 Mo.

Si vous choisissez de créer manuellement ces deux bases de données, vous pouvez choisir le groupe de fichiers et modifier la valeur par défaut de la taille initiale du fichier journal et de la base de données.

SQL Server 2005 mappe une base de données sur un jeu de fichiers du système d'exploitation. Les informations données et journal ne sont jamais mélangées dans le même fichier, et une base de données n'utilise que des fichiers individuels. Pour plus d'informations sur les fichiers de données et les fichiers journaux des bases de données, consultez SQL Server.

Pour toutes les bases de données Planning Server automatiquement créées par Planning Server, la taille initiale par défaut du fichier de données est définie à 50 Mo, avec accroissement automatique par 50 Mo.

Pour les bases de données d'application et de transit, nous suggérons aux administrateurs de bases de données de nos clients Planning Server de planifier la capacité et d'utiliser les données et la politique de rétention des données de l'entreprise pour déterminer une taille raisonnable pour le fichier de données initial. Par exemple, déterminez combien de modèles vous comptez avoir dans chaque site de modèles, et combien de sites de modèles dans l'application.

Voici quelques instructions d'ordre général pour la conception du fichier de données et du fichier journal de la base de données :

• Choisissez la croissance automatique pour le fichier de données et le fichier journal de la base de données.

• Allouez des tailles initiales raisonnables aux deux fichiers données et journal.

• Définissez une taille maximale pour les fichiers de données afin ne pas manquer de place si vous avez peu d'espace disque (surtout si vous avez plusieurs bases de données).

• Définissez une valeur raisonnable pour l'incrément de croissance du fichier de données (préférences : incrément fixe inférieur ou égal à 1 Go, associé à l'initialisation instantanée du fichier).

• Songez à autoriser l'initialisation instantanée pour les fichiers de données.

• Songez à adopter la technologie RAID pour les fichiers de données et les fichiers journaux.

• N'allouez qu'un seul fichier journal.

• Isolez le fichier journal sur un lecteur distinct (pour de meilleures performances, placez les fichiers journaux sur un disque physique distinct, plutôt que les fichiers de données).

La surveillance du fichier journal est également importante. Vous pouvez surveiller l'état du fichier journal en exécutant la requête suivante :

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

Pour plus d'informations, consultez SQL Server.

Pour limiter la croissance automatique du fichier journal, il vous est recommandé de préallouer une taille appropriée pour le journal. La taille du fichier journal dépend de deux facteurs : la fréquence de la sauvegarde du journal et l'activité du système Planning Server.

Bien que la règle générale soit d'allouer au fichier journal 10 ou 15 pour cent de la taille du fichier de base de données, sa taille réelle dépend la fréquence de sauvegarde du journal.

Si vous sauvegardez votre fichier journal toutes les cinq minutes et si vous avez une activité Planification normale, nous vous recommandons de définir la taille initiale de votre fichier journal de la façon suivante :

• Base de données système Planning Server : 50 Mo

• Base de données service Planning Server : 200 Mo

• Base de données d'application Planning Server : 1 Go

• Base de données de transit Planning Server : 1 Go

• Base de données sortante Planning Server : 400 Mo

Vous pouvez modifier ces chiffres, selon la fréquence de sauvegarde de votre journal. Par exemple, si vous sauvegardez votre journal toutes les 10 minutes, vous devez augmenter la taille initiale du fichier journal. Si vous sauvegardez votre fichier journal toutes les deux minutes, vous pouvez allouer une plus petite taille au fichier journal.

Outre un taille initiale appropriée pour le fichier journal, nous vous recommandons de définir pour votre fichier journal une croissance automatique en valeur fixe (pas en pourcentage), ainsi qu'une limite de taille autorisée. (Ne définissez pas une taille pour une croissance illimitée.)

Réduire le fichier journal virtuel) (VLF) est également important pour la bonne exécution de SQL Server. Pour plus d'informations sur l'exécution de cette tâche, consultez SQL Server.

Il est important de sauvegarder votre fichier journal régulièrement. Dans votre système de production, il est vous fortement recommandé de planifier l'ordinateur qui exécute SQL Server pour qu'il effectue régulièrement des sauvegardes dans le fichier journal (par exemple toutes les 5 ou 10 minutes) pour éviter les pertes de données. Si votre mode de récupération de base de données est Full et si vous ne sauvegardez pas votre journal pendant un long moment, il continuera à croître jusqu'à ce que vous receviez une erreur de fichier journal plein.

La surcharge sur le système étant minime lorsque vous sauvegardez le journal, des sauvegardes fréquentes ne sont donc pas coûteuses. Plus votre fichier journal est fragmenté, plus coûteuse sera sa sauvegarde. C'est pourquoi il est important de préallouer un fichier journal de taille raisonnable pour votre système ; il en résultera une meilleure exécution de la sauvegarde du journal.

Lorsqu'un fichier journal est plein, la seule chose que vous puissiez faire est de sauvegarder le journal. La sauvegarde du journal effacera le journal inactif et réduira la taille du fichier journal. La sauvegarde du journal n'effacera pas les journaux actifs, parce que leurs transactions ne sont pas encore validées.

Dans un environnement hors production où vous ne craignez pas la perte de données, vous pouvez tronquer le journal pour le nettoyer. Toutefois, ne faites cela qu'avec les systèmes de prototype, de développement ou de test, si la perte de données est acceptable.

Dans les systèmes de production comme hors production, vous devez prendre soin du fichier journal (par sauvegarde ou troncature) ; sinon, sa croissance rapide affectera les performances de votre système Planification.

Exemples de scripts

Cette section inclut des exemples de scripts pour l'exécution de sauvegardes ou de troncatures du journal. Il est important de planifier l'exécution du script suivant sur l'ordinateur qui exécute SQL Server. Si vous travaillez dans un environnement de test ou de prototype et si vous ne voulez pas passer votre temps à gérer ce problème de sauvegarde ou de troncature, remplacez le mode de récupération de la base de données (Full par défaut) par le mode Simple, en modifiant la page de propriétés de la base de données dans SQL Server Management Studio.

Important :
Le mode Simple ne doit jamais être utilisé dans le système de production. Pour plus d'informations sur les modèles de récupération des bases de données, consultez 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

Important :

Vous devez soit tronquer le journal dans un système hors production, soit configurer l'ordinateur qui exécute SQL Server pour qu'il sauvegarde régulièrement le journal afin de réduire sa taille, pour améliorer les performances et éviter toute perte de données. Si vous laissez vos fichiers journaux devenir trop volumineux, les performances de Planning Server seront affectées de manière significative. Ce fichier journal croissant finira à la longue par occuper une place considérable sur votre disque.

La taille de TempDB peut affecter les performances de votre système. Par exemple, si la taille définie pour TempDB est trop petite, chaque fois que vous redémarrez le service SQL Server (MSSQLSERVER), votre système risque de devoir consacrer une partie de sa charge de travail à l'agrandissement automatique de cette base de données jusqu'à la taille nécessaire pour pouvoir prendre en charge votre travail. Vous pouvez éviter cette surcharge en augmentant la taille de TempDB.

Recommandations générales pour les options d'emplacement physique et de base de données définies pour TempDB :

• Autorisez TempDB à croître automatiquement selon les besoins.

• Définissez une taille d'origine raisonnable pour les fichiers TempDB afin d'éviter le déclenchement de l'expansion automatique lorsque plus d'espace sera requis. Si l'expansion de TempDB se déclenche trop souvent, les performances peuvent être affectées.

• Définissez un pourcentage raisonnable pour l'incrément de croissance des fichiers, pour que chaque expansion des fichiers TempDB soit de taille suffisante. Si l'expansion des fichiers est trop faible pour le volume de données en cours d'écriture dans TempDB, la base de données devra se développer en permanence. Ceci affectera les performances.

• Placez TempDB sur un sous-système d'entrée/sortie rapide, pour garantir de bonnes performances. Répartissez TempDB sur plusieurs disques pour obtenir de meilleures performances. Placez TempDB sur des disques différents de ceux des bases de données utilisateur. Pour plus d'informations sur le déplacement de TempDB vers un nouvel emplacement, consultez SQL Server.

Lorsque SQL Server redémarre, TempDB reprend la taille initialement configurée et s'accroît selon les besoins. Cela peut entraîner la fragmentation de TempDB et peut provoquer une surcharge. Cela peut influer sur les performances de votre charge de travail. Il vous est recommandé de préallouer à TempDB une taille appropriée.

Les bases de données Planning Server utilisant l'« isolation validée en lecture » à l'aide de la fonctionnalité de contrôle de version des lignes, la taille de TempDB doit être suffisante pour de meilleures performances. Définissez pour TempDB une taille initiale d'au moins 500 Mo pour de meilleures performances. Et pour des performances meilleures encore, définissez la taille initiale de TempDB à 1 Go.

Il est important de surveiller l'espace disponible dans TempDB. Pour plus d'informations, consultez SQL Server.

Vous devez regrouper les objets de base de données et les fichiers dans des groupes de fichiers à des fins d'allocation et d'administration.

Les bases de données système et service de Planning Server peuvent être créées lors de l'installation de Planning Server, ou être configurées manuellement par nos clients avant l'installation du logiciel Planning Server. Si vous laissez Gestionnaire de configuration Planning Server créer ces deux bases de données pour vous, vous n'aurez pas la possibilité de spécifier un groupe de fichiers pour elles. Ces deux bases de données étant de taille relativement faible, la nécessité d'utiliser pour elles un groupe de fichiers est minime.

La base de données d'application de Planning Server est créée au cours du processus de création de l'application. Il existe deux options de création de bases de données d'application. Les clients peuvent spécifier l'option Exécution manuelle dans l'interface utilisateur Créer l'application de Console Administration de planification afin que les administrateurs de base de données puissent personnaliser CREATE DATABASE/CREATE TABLE dans le processus de création de l'application. Plus précisément, les administrateurs de base de données peuvent ajouter des informations de groupe de fichiers lorsqu'ils créent la base de données d'application. Une fois les scripts SQL Server générés dans le processus de création de l'application, les administrateurs de base de données peuvent modifier CreateAppDB.sql et TypeLibMasterSchema.sql et ajouter les informations de groupe de fichiers dans ces scripts avant de les exécuter.

Remarque :
Vous pouvez créer des groupes de fichiers à partir de CREATE DATABASE ou ALTER DATABASE. Vous pouvez spécifier un groupe de fichiers pour les tables à partir de CREATE TABLE. Lorsque vous créez de nouveaux groupes de fichiers, veillez à ajouter les fichiers à vos nouveaux groupes de fichiers avant qu'ils ne soient utilisés.

Pour plus d'informations sur les groupes de fichiers, consultez SQL Server.