Exemple : Estimation de taille de journal d'archivage et de journal actif avec des sauvegardes intégrales de base de données
Le serveur IBM Storage Protect supprime les fichiers inutiles du journal d'archivage uniquement lorsqu'une sauvegarde intégrale de la base de données se produit. Par conséquent, lorsque vous estimez l'espace requis pour le journal d'archivage, vous devez également prendre en compte la fréquence des sauvegardes intégrales de base de données.
Par exemple, si une sauvegarde intégrale de base de données a lieu une fois par semaine, l'espace de journal d'archivage doit pouvoir contenir les informations dans le journal d'archivage durant toute une semaine.
La différence de taille de journal d'archivage pour des sauvegardes de base de données intégrales et quotidiennes est indiquée dans l'exemple du tableau suivant.
| Elément | Valeurs de l'exemple | Description |
|---|---|---|
| Nombre maximal de noeuds client pouvant à tout moment et simultanément sauvegarder, archiver ou migrer des fichiers | 300 | Nombre de noeuds client sauvegardant, archivant ou migrant des fichiers toutes les nuits. |
| Fichiers stockés lors de chaque transaction | 4096 | La valeur par défaut de l'option de serveur TXNGROUPMAX est 4096. |
| Espace de journal requis pour chaque fichier | 3453 octets | 3053 octets pour chaque fichier plus 200 octets pour
chaque pool de stockage de copie. La valeur de 3053 octets pour chaque fichier d'une transaction représente les octets de journal nécessaires lors de la sauvegarde de fichiers à partir d'un client Windows dont les noms de fichier sont compris entre 12 et 120 octets. Elle dépend des résultats des tests exécutés en laboratoire. Pour ces tests, des clients ont exécuté des opérations de sauvegarde sur un pool de stockage de disque à accès aléatoire (DISK). Les pools DISK nécessitent de plus d'espace journal que des pools de stockage à accès séquentiel. Prévoyez une valeur supérieure à 3053 octets si les noms de fichiers des données en cours de stockage dépassent 12 à 120 octets. |
| Journal actif : taille recommandée | 20 Go 1 | Utilisez le calcul suivant pour déterminer la taille du journal actif. Un Go est égal à 1 073 741 824 octets.
Augmentez ce nombre de la taille de départ conseillée de 16 Go :
|
| Journal d'archivage : taille recommandée avec une sauvegarde intégrale de base de données quotidienne | 60 Go 1 | Pour pouvoir stocker
des journaux d'archivage sur trois cycles de sauvegarde, multipliez
l'estimation du journal actif par 3 afin d'évaluer les exigences totales du journal d'archivage :
Augmentez ce nombre de la taille de départ conseillée de 48 Go :
|
| Journal d'archivage : taille recommandée avec une sauvegarde de base de données complète hebdomadaire | 132 Go 1 | Pour pouvoir stocker
des journaux d'archivage sur trois cycles de sauvegarde de base de données serveur, multipliez
l'estimation du journal actif par 3 afin d'évaluer les exigences totales du journal d'archivage. Multipliez le résultat par le nombre de jours entre deux sauvegardes complètes de base de données :
Augmentez ce nombre de la taille de départ conseillée de 48 Go :
|
| 1 Les valeurs de l'exemple présentées dans ce tableau
sont uniquement utilisées pour illustrer comment calculer les tailles des journaux actifs et des journaux d'archivage. Dans un environnement de production n'utilisant pas le dédoublonnage, la taille minimale conseillée est de 16 Go pour un journal actif. La taille de départ conseillée pour un journal d'archivage dans un environnement de production n'utilisant pas le dédoublonnage est de 48 Go. Si vous remplacez des valeurs de votre environnement et que les résultats sont supérieurs à 16 Go et 48 Go, utilisez vos résultats pour ajuster la taille des journaux actifs et d'archivage. Surveillez vos journaux et ajustez leur taille si nécessaire. |
||