Les écritures forcées entraînent beaucoup d’écritures de fichier base de données disque. Job Watcher est le meilleur moyen de voir cela, en utilisant un exemple suffisamment petit pour capturer le job sur de multiples intervalles. On peut aussi visualiser l’information de job avec Collection Services. Cependant, son intervalle de collecte
Force Write Ratio de la base de données
![Force Write Ratio de la base de données Force Write Ratio de la base de données](https://www.itpro.fr/wp-content/uploads/2016/09/f50ba5da45adf8acf69b4d988607dd83.jpg)
est généralement trop grand pour voir des tendances de traitement plus détaillées et risque de causer une utilisation de CPU supérieure à la normale. Un scan source pour FRCRATIO (force-write ratio) dans les programmes CL de l’application est l’un des meilleurs moyens pour visualiser cette information.
Selon IBM, quand le paramètre FRCRATIO est utilisé sur les commandes de fichier base de données create, change ou override, il vous permet de contrôler quand les changements de la base de données seront écrits en stockage auxiliaire. Le système détermine généralement quand il doit écrire les données modifiées du stockage principal en stockage auxiliaire. Le fait de fermer le fichier (sauf pour un shared close) et d’utiliser l’opération forceend- of-data, force les mises à jour, suppressions et additions restantes en stockage auxiliaire. Si vous journalisez le fichier, le paramètre FRCRATIO devrait être généralement *NONE.
Par le passé, cette assertion était correcte. Aujourd’hui, avec l’avènement du cache d’écriture IOP disque, elle ne l’est plus autant. La déclaration « force les mises à jour, suppressions et additions restantes en stockage auxiliaire » devrait plutôt être « planifie l’écriture en stockage auxiliaire des mises à jour, suppressions et additions restantes ». Avant l’avènement du cache d’écriture disque, une opération d’écriture synchrone garantissait que les données étaient écrites sur disque. Avec le cache d’écriture, les données sont envoyées au sous-système d’I/O disque, lequel généralement réagit presque immédiatement par une indication write-complete, et le job utilisateur peut poursuivre son traitement quoi qu’il advienne. Cependant, les données sont conservées dans le cache d’écriture pendant quelques secondes avant d’être envoyées physiquement vers le bras du disque et sur le disque.
L’opération SLIC Storage Management est la même indépendamment du fonctionnement de la base de données. Les éventuelles différences dépendant des possibilités du soussystème d’I/O disque. Vous pouvez spécifier FRCRATIO avec une commande CRTPF, CHGPF ou OVRDBF. La valeur du paramètre peut être toute valeur entière supérieure ou égale à zéro. Si elle est de zéro, Force Write est désactivé. Si elle est supérieure à zéro, chaque nième écriture (où n est la valeur FRCRATIO) vers un fichier physique de base de données spécifique conduit le système à scanner tout le stockage principal pour y trouver les éventuelles trames de pages changées du fichier. Les pages s’écrivent ensuite sur disque de manière synchrone.
Company aBc a encore d’anciennes applications qui utilisent une valeur FRCRATIO(1). Avec une telle valeur, une opération de scanning et d’écriture de la mémoire du stockage principal se produit à chaque opération d’écriture. Si le système effectue 1 000 transactions par seconde et si chacune d’elles émet une écriture forcée vers le même fichier, beaucoup de temps de CPU est gaspillé à inspecter toutes les trames de pages du stockage principal non nulles (valides).
Force Write était nécessaire pour certaines transactions à l’époque du cache nonwrite : avant que la journalisation ne soit gérée. Mais aujourd’hui, il n’est plus nécessaire d’assurer l’intégrité des données. Quand des changements de base de données sont demandés, ils sont planifiés et envoyés à l’IOP, lequel les envoie vers l’unité.
Téléchargez cette ressource
![Comment lutter contre le Phishing ?](https://www.itpro.fr/wp-content/uploads/2024/07/Special-Report-Eviden-Securite-Phishing-Juillet-2024.png)
Comment lutter contre le Phishing ?
Dans un environnement cyber en constante mutation, le phishing évolue vers des attaques toujours plus sophistiquées combinant IA, automatisation et industrialisation. Une réalité complexe qui exige des mesures de sécurité avancées et repensées au-delà de l’authentification multifacteur. Découvrez les réponses technologiques préconisées par les experts Eviden et les perspectives associées à leur mise en œuvre.