Premièrement, je souhaite dire que j'ai très peu d'expérience avec DB2. Cependant, j'ai été chargé de suivre le problème et la solution à ce problème.
Ceci est une base de données DB2 et nos testeurs disent qu'ils obtiennent:
Le journal des transactions pour la base de données est complet .. sqlcode = -964, sqlstate = 57011, pilote = 4.13.127 Code SQL: -964, SQL State: 57011
J'ai augmenté le nombre de logprimaires à "40". Cependant, il semble que les journaux de transaction soient toujours pleins. J'ai ensuite décidé de "tailler" les journaux de transaction. La procédure que j'ai est de tailler tout avant le journal de transaction actif. Cependant, je ne peux pas déterminer le journal actif:
$ db2 get db config for MyDB | grep -i 'log'
Log retain for recovery status = NO
User exit for logging status = NO
Catalog cache size (4KB) (CATALOGCACHE_SZ) = 278
Log buffer size (4KB) (LOGBUFSZ) = 1997
Log file size (4KB) (LOGFILSIZ) = 1024
Number of primary log files (LOGPRIMARY) = 40
Number of secondary log files (LOGSECOND) = 12
Changed path to log files (NEWLOGPATH) =
Path to log files = /home/db2/db2inst1/db2inst1/NODE0000/SQL00001/LOGSTREAM0000/
Overflow log path (OVERFLOWLOGPATH) =
Mirror log path (MIRRORLOGPATH) =
First active log file =
Block log on disk full (BLK_LOG_DSK_FUL) = NO
Block non logged operations (BLOCKNONLOGGED) = NO
Percent max primary log space by transaction (MAX_LOG) = 0
Num. of active log files for 1 active UOW(NUM_LOG_SPAN) = 0
Percent log file reclaimed before soft chckpt (SOFTMAX) = 520
HADR log write synchronization mode (HADR_SYNCMODE) = NEARSYNC
HADR spool log data limit (4KB) (HADR_SPOOL_LIMIT) = 0
HADR log replay delay (seconds) (HADR_REPLAY_DELAY) = 0
First log archive method (LOGARCHMETH1) = OFF
Archive compression for logarchmeth1 (LOGARCHCOMPR1) = OFF
Options for logarchmeth1 (LOGARCHOPT1) =
Second log archive method (LOGARCHMETH2) = OFF
Archive compression for logarchmeth2 (LOGARCHCOMPR2) = OFF
Options for logarchmeth2 (LOGARCHOPT2) =
Failover log archive path (FAILARCHPATH) =
Number of log archive retries on error (NUMARCHRETRY) = 5
Log archive retry Delay (secs) (ARCHRETRYDELAY) = 20
Log pages during index build (LOGINDEXBUILD) = OFF
Log DDL Statements (LOG_DDL_STMTS) = NO
Log Application Information (LOG_APPL_INFO) = NO
$
Je note que les fichiers journaux de transaction apparaissent dans/home/dB2/dB2Inst1/db2inst1/nœud0000/sql00001/logstream0000 /.
La transaction enregistre-t-elle correctement la configuration? Augmenterait les journaux être la réponse? Ou devrais-je repousser les utilisateurs pour les encourager à faire plus de commettre?
Vous devriez vraiment être lecture manuels , pas "Journaux de taille". Votre base de données est configurée pour la journalisation circulaire, ce qui signifie qu'il n'y a rien à "élaguer". Si les transactions nécessitent parfois des espaces de journalisation supplémentaires, augmentez la valeur de Logsecond. Trop de journaux primaires ralentiront le démarrage de la base de données, car ils sont prévenus. Les journaux secondaires sont alloués selon les besoins, ils resteront dans le répertoire de journal actif jusqu'à ce que la base de données soit redémarrée.
"Les bûches de taille" n'affecteront pas la quantité d'espace de journal actif (à une exception près que je mentionnerai plus tard): il est purement dicté par la somme de logprimary and logsecond, multipliée par logfilsiz. Si vous utilisiez le mode journal d'archive, vous seriez capable de supprimer les fichiers journaux archivés plus anciens pour libérer de l'espace disque, mais la quantité d'espace de journal actif ne changerait pas. Même dans ce cas, vous supprimeriez les journaux créés avant la sauvegarde précédente et non avant le premier fichier journal actif.
Ce n'est que si vos journaux archivés et vos journaux actifs partagent le même système de fichiers (ce qui n'est pas une bonne idée en soi), l'accumulation incontrôlée des bûches archivées peut empêcher la croissance de l'espace journal actif, si nécessaire, à sa taille maximale configurée.