Archivage des enregistrements

Rversion finale: Xanadu

Mis à jour 1 août 2024

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 les enregistrements dans des tables principales telles que la table Tâche [task] et les enregistrements dans les tables personnalisées que vous créez à l’aide des règles d’archivage Now Platform .

Pour archiver Base de données de gestion des configurations (CMDB) les enregistrements CI, utilisez le Gestionnaire de CMDB données. Consultez Working with CMDB Data Manager.
Pour archiver les e-mails, activez le module d’extension Conservation 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.

Activation de l’archive

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ù les sys_id sont stockées 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 à fichier plat. 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
Convertit les valeurs de champ de référence (valeurs définies par des 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 System Archiving . 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 Pièce jointe d’archivage.
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 ID.Email de l’appelant.

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

Les données archivées sont stockées sous la forme d’un fichier plat sans champs de référence à 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 futures 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 « 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 contiennent uniquement 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 rechercher tous les incidents archivés de priorité 1. Au lieu de cela, effectuez une recherche uniquement 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 de 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ée.

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 alors l’un des deux chemins suivants :

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.
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 d’autres opérations sont empêchées.

L’interface utilisateur du plan d’exécution est consciente de 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 table d’archivage « masque » les ACL sur la table non archivée (données d’origine).

Si vous avez des ACL existantes sur les 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 ACL de la table d’archivage.
Les instances Zbooted installent la propriété et la définissent sur true.

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 système 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.