Restaurer et supprimer la récupération

  • Rversion finale: Yokohama
  • Mis à jour 30 janv. 2025
  • 4 minutes de lecture

    • Avec les contextes de restauration, vous pouvez restaurer certaines actions telles qu’une mise à niveau de correctif, l’activation de module d’extension et l’exécution de scripts en arrière-plan, et vous pouvez récupérer les suppressions d’enregistrements et tous les changements associés.

    Les fonctionnalités de restauration et de récupération 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 d’enregistrements supprimés

    Ce module fonctionne sur les enregistrements 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. Après sept jours, seuls les enregistrements de données et les références sur les tables qui auditent les suppressions peuvent être récupérés, ce qui représente la même fonctionnalité que les versions précédentes.

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

    Supprimer un 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 rechercher ce module, accédez à Restauration et reprise > Supprimer la détection.

    Module Historique des exécutions de scripts

    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 rechercher 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. Elles comprennent les enregistrements supprimés, les mises à jour de correctifs, les exécutions de scripts Scripts - Arrière-plan, les actions de base de données et les activations de modules d’extension. Un contexte de restauration est créé pour chaque mise à niveau de correctif au sein d’une famille et pour chaque activation de module d’extension, à condition que le module d’extension prenne en charge les contextes de restauration.

    Pour utiliser des 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 les instances de pré-production où les fonctionnalités doivent être restaurées avant que vous puissiez 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 Enregistrement pour la restauration ? .

    Les restaurations n’ont pas d’impact sur les autres activités de 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, les contextes de restauration 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 devez 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 du contexte de restauration.

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

    Pour rechercher 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.
    • Une colonne est reparentée ou promue.
    • Un type de colonne change.
    • La largeur d’une colonne est réduite.
    Le processus de restauration effectue Now Support 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 est défini sur la version antérieure à la restauration.
    • Affiche le message « La guerre souhaitée correspond à la guerre annulée spécifiée par la propriété [glide.war.no_upgrade]. Le script de mise à niveau ne s’exécutera PAS ».
    • Change l’état sur Expiré et la restauration purge toutes les données stockées.