Archivage des enregistrements

  • Rversion finale: Zurich
  • Mis à jour 31 juil. 2025
  • 5 minutes de lecture
  • Gérez la croissance de la taille des tables et améliorez les performances des requêtes en archivant les enregistrements.

    Vous pouvez archiver des enregistrements dans des tables principales telles que la table Tâche [task] et des enregistrements dans des tables personnalisées que vous créez sur la règle d’archivage à l’aide des règles d’archivage ServiceNow AI Platform .

    • Pour archiver Base de données de gestion des configurations (CMDB) les enregistrements de CI, utilisez le gestionnaire de CMDB données. Consultez Working with CMDB Data Manager.
    • Pour archiver les e-mails, activez le module d’extension Rétention des e-mails et utilisez les règles d’archivage et de destruction fournies avec le module d’extension. N’utilisez pas la fonctionnalité d’archivage pour créer vos propres règles d’archivage sur la table des e-mails.

    Archiver l’activation

    Lorsque vous activez une règle d’archivage, le système effectue les actions suivantes :

    • Crée la table d’archivage dans la base de données. La table d’archivage porte le même nom que la table primaire avec un préfixe « ar_ ». Par exemple, si vous archivez la table Incident [incident], la table d’archivage est [ar_incident].
    • Stocke une version XML de chaque enregistrement archivé dans la table sys_archive_log. Ce journal d’archivage est la même table pour toutes les règles d’archivage, et vous ne pouvez pas modifier ce comportement. C’est également le seul endroit où le sys_id est stocké avec la valeur d’affichage des champs de référence.
      Par exemple, pour ar_incident <assigned_to>Fred Luddy</assigned_to>, l’enregistrement sys_archive_log est le suivant :
      
      <assigned_to display_value="Fred Luddy">5137153cc611227c000bbd1bd8cd2005</assigned_to>
    • Convertit plusieurs tables jointes en une seule table d’archivage de fichiers plats. La table d’archivage ne se compose plus d’une table de base et de tables étendues.
      Figure 1. Conversion de plusieurs tables jointes en une table d’archivage plate
      Conversion de plusieurs tables jointes en une table d’archivage plate
    • Convertit les valeurs de champ de référence (valeurs définies par les références à des enregistrements dans d’autres tables) en valeurs de chaîne. L’enregistrement d’archive contient la valeur d’affichage du champ de référence au moment de l’archivage.
    • Ajoute un module à la liste des tables d’archivage dans l’application Archivage système . Le nom du module est une combinaison du mot « Archive » et du nom d’affichage de la table archivée. Par exemple, le module d’archivage de la table Pièce jointe [sys_attachments] est Archiver la pièce jointe.
    • Crée une liste de la table d’archivage à l’aide de la vue de liste par défaut.
    • Crée un formulaire pour la table d’archivage à l’aide de la vue de formulaire par défaut. Le formulaire exclut tous les champs de remontée pas à pas tels que l’ID.Email Appelant.

    Valeurs de référence converties en chaînes

    Les données archivées sont stockées sous forme de fichier plat sans champs de référence vers d’autres tables. Le processus d’archivage convertit toutes les références à d’autres tables en valeurs de chaîne.

    Dans le cas d’un champ de référence, la chaîne utilise la valeur d’affichage telle que le nom d’utilisateur de l’appelant. Par exemple, le champ de référence Appelant d’un incident affiche la chaîne Utilisateur ITIL. Si la référence était un ID de document et que la règle d’archivage incluait l’option d’archivage des ID de documents connexes, la chaîne est l’ID de document de l’enregistrement connexe.

    Les modifications ultérieures des valeurs de référence ne sont pas reflétées dans les enregistrements archivés. Par exemple, si vous remplacez le nom d’utilisateur de « John Smith » par « John A. Smith », tous les enregistrements d’incidents actifs affichent automatiquement l’appelant comme « John A. Smith » en raison de la référence entre les tables Incident et Utilisateur. Toutefois, tous les enregistrements d’incidents archivés affichent le nom d’utilisateur qui existait au moment de l’archivage. De même, si vous supprimez un utilisateur du système, les incidents en cours n’affichent plus l’utilisateur supprimé en tant qu’appelant. Toutefois, les incidents archivés affichent toujours la chaîne « John Smith », car cette valeur a été utilisée lors de l’archivage de l’enregistrement.

    Interrogation des données archivées

    Les tables archivées ne sont pas optimisées pour les requêtes ad hoc. Elles ne contiennent que des entrées d’index pour la valeur d’affichage, la date de création et la clé primaire de sys_id.

    Évitez d’effectuer des requêtes à la demande sur une table archivée, comme la recherche de tous les incidents archivés de priorité 1. Au lieu de cela, effectuez uniquement une recherche dans les champs indexés. Par exemple, recherchez des INC100001 d’incident ou des incidents créés à une date spécifique.

    Archiver les tables et les ACL

    Par défaut, les tables d’archivage utilisent les ACL pour la table non archivée du même nom. Par exemple, la table Incident [ar_incident] archivé utilise les ACL définies pour la table Incident [incident] non archivé.

    Vous pouvez gérer explicitement l’accès aux tables d’archivage en créant des ACL pour des tables d’archivage spécifiques et en définissant la glide.security.enable_archive_table_acls propriété sur vrai. Le système suit ensuite l’un des deux chemins suivants :
    1. Si une ou plusieurs ACL actives sont définies pour une table d’archivage, ces ACL contrôlent l’accès à la table d’archivage.
    2. Si aucune ACL n’est définie pour une table d’archivage, le système revient au comportement par défaut et utilise les ACL pour la version non archivée de la table.
    Remarque :
    Les deux chemins s’excluent mutuellement : si les ACL de table d’archivage refusent l’accès, le système ne tente pas de revenir au comportement par défaut.

    L’opération de lecture est la seule opération évaluée et les autres opérations sont empêchées.

    L’interface utilisateur du plan d’exécution connaît cette logique et présente les informations en conséquence. Par exemple, l’ajout de la première ACL à une table d’archivage montre que l’ACL de la table d’archivage « masque » les ACL sur la table non archivée (données d’origine).

    Si vous avez des ACL existantes sur des tables archivées, elles sont ignorées à moins que vous ne définissiez la glide.security.enable_archive_table_acls propriété sur vrai. Ces ACL nouvellement activées peuvent éventuellement entraîner des problèmes d’accès. Pour éviter que cela ne se produise, le système définit la glide.security.enable_archive_table_acls propriété comme suit :
    • Les instances sans la glide.security.enable_archive_table_acls propriété utilisent la valeur par défaut faux
    • Les instances mises à niveau n’installent pas la propriété. La propriété doit être ajoutée manuellement et définie sur vrai pour activer le comportement de l’ACL de la table d’archivage.
    • Les instances zbooted installent la propriété et la définissent sur vrai.

    Définition de la langue des chaînes archivées

    Sur les instances internationalisées, le processus d’archivage utilise la langue de l’utilisateur SYSTEM pour sélectionner les chaînes de valeur d’affichage.

    S’il n’y a pas d’utilisateur SYSTEM, l’instance utilise le paramètre de langue par défaut pour sélectionner les chaînes de valeur d’affichage. Vous pouvez soit créer un utilisateur SYSTEM avec un paramètre de langue spécifique, soit définir la langue par défaut du système pour sélectionner la langue des chaînes archivées.