Restaurer et supprimer la récupération

  • Rversion finale: Xanadu
  • Mis à jour 1 août 2024
  • 4 minutes de lecture

    • Les contextes de restauration vous permettent de restaurer certaines actions telles que la mise à niveau d’un correctif, l’activation d’un module d’extension et les exécutions de script en arrière-plan, et récupérer les suppressions d’enregistrements et tous les changements associés.

    Les fonctionnalités de restauration et de suppression sont disponibles sur les instances qui utilisent des bases de données MySQL et MariaDB. Les instances qui utilisent des bases de données Oracle prennent uniquement en charge la restauration. Les instances qui utilisent SQL Server ne prennent pas en charge la restauration ou la suppression de la récupération.
    Tableau 1. Restaurer et supprimer la prise en charge de la base de données de récupération
    Type de base de données Restaurer Supprimer la récupération
    MySQL yes yes
    MariaDB yes yes
    Oracle yes no

    Module Enregistrements supprimés

    Ce module fonctionne sur les enregistrements dans des tables auditées. La récupération des enregistrements supprimés en cascade doit être effectuée dans les sept jours suivant la suppression de l’enregistrement. Au bout de sept jours, seuls les enregistrements de données et les références sur les tables ayant fait l’objet d’un audit des suppressions peuvent être récupérés, ce qui équivaut aux mêmes fonctionnalités que les versions précédentes.

    Pour trouver ce module, accédez à Définition du système > Enregistrements supprimés.

    Supprimer le module de récupération

    Ce module fonctionne pour tout enregistrement supprimé. Cette récupération doit être effectuée dans les sept jours suivant la suppression de l’enregistrement.

    Pour trouver ce module, accédez à Restauration et reprise > Supprimer la détection.

    Module Historique des exécutions de script

    Ce module fonctionne sur les scripts exécutés à l’aide du module Scripts - Arrière-plan . Cet historique ne comprend que sept jours d’exécutions de scripts.

    Pour trouver ce module, accédez à Restauration et reprise > Historique des exécutions de script.

    Contextes de restauration

    Les contextes de restauration contiennent tout ce qui est nécessaire pour restaurer une mise à niveau logicielle ou l’activation d’un module d’extension. Il s’agit notamment des enregistrements supprimés, des mises à jour de correctifs, des exécutions de scripts en arrière-plan, des actions de base de données et des activations de plug-ins. Un contexte de restauration est créé pour chaque mise à niveau de correctif au sein d’une famille et chaque activation de module d’extension, à condition que le module d’extension prenne en charge les contextes de restauration.

    Pour utiliser les contextes de restauration, activez les modules d’extension Restaurer les enregistrements supprimés (com.snc.undelete) et Supprimer la récupération (com.glide.delete_recovery).

    Les restaurations sont généralement effectuées sur des instances de pré-production où les fonctionnalités doivent être restaurées avant de pouvoir trouver la cause première d’un problème dans la mise à niveau. La restauration supprime des données, ce qui peut souvent rendre difficile, voire impossible, la découverte du problème qui a rendu la restauration nécessaire.

    Un contexte de restauration est créé lorsque :
    • GlideRecord.delete() ou GlideRecord.deleteMultiple() suppriment des enregistrements.
    • Il y a une mise à niveau du correctif.
    • Vous activez un module d’extension qui prend en charge les contextes de restauration.
    • Un script s’exécute à l’aide du module Scripts - Arrière-plan et la restauration a été activée en cochant la case Enregistrer pour restaurer ? .

    Les restaurations n’ont pas d’impact sur les autres activités de la base de données. Si une activité de base de données modifie un enregistrement qui fait partie d’un contexte de restauration, la restauration n’affecte pas cet enregistrement.

    Étant donné que les contextes de restauration contiennent une quantité importante de données, ils sont supprimés au bout de 10 jours. Par conséquent, les restaurations doivent avoir lieu dans les 10 jours suivant la dernière mise à niveau ou activation du module d’extension. Si vous avez besoin de conserver un contexte de restauration pendant plus de 10 jours, vous pouvez le faire en ajoutant une propriété système. Consultez Propriétés de contexte de restauration.

    Remarque :
    Ne pas restaurer un contexte de restauration avant d’avoir vérifié avec Service et assistance client. Une restauration supprime des données et peut supprimer la preuve du problème de mise à niveau ou d’activation, empêchant ainsi le débogage du problème.

    Pour trouver ce module, accédez à Restauration et reprise > Contextes de restauration.

    si l’une des opérations suivantes se produit pendant une restauration, un contexte de restauration n’est pas créé :

    • Les tables ou les colonnes sont supprimées du schéma.
      Remarque :
      Les baisses d’index sont acceptables.
    • Une table est tronquée.
    • Une table ou une colonne est renommée.
    • Un parent d’une colonne est changé ou promu.
    • Un type de colonne change.
    • La largeur d’une colonne est réduite.
    Le processus de restauration activé Now Support effectue les opérations suivantes :
    • Met à jour le WAR signalé vers la version restaurée et le WAR affecté reste défini sur la version antérieure à la restauration.
    • Définit la propriété glide.war.no_upgrade sur l’instance sur la version antérieure à la restauration.
    • Affiche le message suivant : « La guerre souhaitée correspond à la guerre inversée spécifiée par la propriété [glide.war.no_upgrade]. Le script de mise à niveau ne s’exécutera PAS ».
    • Passe l’état à Expiré et la restauration purge toutes les données stockées.