Les stratégies ahlt et cnt déterminent ce qui se passe lorsque la file d'attente de l'audit est pleine et ne peut plus accepter d'événements.
Les stratégies –cnt et –ahlt sont indépendantes et associées. La combinaison de ces stratégies a les effets suivants :
-ahlt +cnt est la stratégie adoptée par défaut. Cette valeur par défaut permet le traitement d'un événement soumis à un audit même si l'événement ne peut pas être journalisé.
La stratégie -ahlt indique que si un enregistrement d'audit d'un événement asynchrone ne peut pas être placé dans la file d'attente d'audit du noyau, le système comptabilise les événements et poursuit le traitement. Dans la zone globale, le compteur as_dropped enregistre le nombre correspondant.
La stratégie +cnt indique que si un événement synchrone survient et ne peut pas être placé dans la file d'attente d'audit du noyau, le système comptabilise l'événement et poursuit le traitement. Le compteur as_dropped de la zone enregistre le nombre correspondant.
La configuration -ahlt +cnt est généralement utilisée sur les sites où le traitement doit se poursuivre, même si celui-ci peut entraîner une perte d'enregistrements d'audit. Les champs auditstatdrop indiquent le nombre d'enregistrements d'audit supprimés dans une zone.
La stratégie +ahlt -cnt indique que le traitement s'arrête lorsqu'un événement asynchrone ne peut pas être ajouté à la file d'attente d'audit du noyau.
La stratégie +ahlt indique que si un enregistrement d'audit d'un événement asynchrone ne peut pas être placé dans la file d'attente d'audit du noyau, toutes les opérations de traitement sont arrêtées. Le système panique. L'événement asynchrone ne sera pas dans la file d'attente de l'audit et doit être récupéré à partir de pointeurs sur la pile des appels.
La stratégie -cnt indique que, si un événement synchrone ne peut pas être placé dans la file d'attente d'audit du noyau, le thread tentant de fournir l'événement sera bloqué. Le thread est placé dans une file d'attente de mise en veille jusqu'à ce que de l'espace d'audit devienne disponible. Aucun compte n'est conservé. Des programmes peuvent sembler bloqués jusqu'à ce que de l'espace d'audit devienne disponible.
La configuration +ahlt -cnt est généralement utilisée dans les sites où un enregistrement de chaque événement d'audit est prioritaire sur la disponibilité du système. Le champ auditstat wblk indique à combien de reprises des threads ont été bloqués.
Toutefois, si un événement asynchrone se produit, le système va paniquer, entraînant une interruption de service. La file d'attente du noyau des événements d'audit peut être restaurée manuellement partir d'un vidage mémoire enregistré. L'événement asynchrone ne sera pas dans la file d'attente de l'audit et doit être récupéré à partir de pointeurs sur la pile des appels.
La stratégie -ahlt -cnt indique que si un événement asynchrone ne peut pas être placé dans la file d'attente d'audit du noyau, l'événement sera comptabilisé et le traitement poursuivi. Lorsqu'un événement synchrone ne peut pas être placé dans la file d'attente d'audit du noyau, le thread tentant de fournir l'événement sera bloqué. Le thread est placé dans une file d'attente de mise en veille jusqu'à ce que de l'espace d'audit devienne disponible. Aucun compte n'est conservé. Des programmes peuvent sembler bloqués jusqu'à ce que de l'espace d'audit devienne disponible.
La configuration -ahlt -cnt est généralement utilisée dans les sites où l'enregistrement de tous les événements d'audit synchrones est prioritaire sur la perte potentielle d'enregistrements d'audit asynchrones. Le champ auditstat wblk indique à combien de reprises des threads ont été bloqués.
La stratégie +ahlt +cnt indique que si un événement asynchrone ne peut pas être placé dans la file d'attente d'audit du noyau, le système panique. Si un événement asynchrone ne peut pas être placé dans la file d'attente d'audit du noyau, le système comptabilise l'événement et poursuit le traitement.