Modèle des exceptions dans la base RSSD et suppression efficace des exceptions Sybase Replication Server

Logo

Introduction

La suppression des exceptions rencontrées par Replication Server peut s’avérer être une opération très délicate et dangereuse. En fonction du volume des commandes SQL contenues dans une exception, la procédure stockée rs_delexception qui permet de supprimer une exception dans la base ASE RSSD (Replication Server System Database) peut engendrer une saturation du journal des transactions de la base RSSD.

Lorsque le journal des transactions RSSD est saturé par l’exécution de la procédure stockée rs_delexception, le système de réplication est indisponible.

Cet article propose de comprendre le modèle des exceptions dans la base RSSD de Sybase Replication Server ainsi que le stockage des exceptions dans les tables rs_% et donne une méthodologie et un script pour supprimer efficacement les exceptions trop volumineuses en nombre de commandes SQL et qui peuvent saturer le journal des transactions, mais aussi pour supprimer efficacement et massivement des centaines de petites exceptions.

Le contexte du schéma de réplication de l’article est le suivant :

contexte réplication image

La suppression massive des exceptions dans une base RSSD Adaptive Server Enterprise est disponible dans le guide pratique Sybase Replication Server - §2 : Sybase Replication Server - Guide pratique, aide-mémoire

Les exceptions dans Replication Server

Retrouver la base RSSD associée à Replication Server (admin rssd_name)

Pour retrouver rapidement la base RSSD associée à un serveur Replication Server, deux options possibles :

  • Utiliser la commande système admin rssd_name dans Replication Server.
  • Consulter le fichier de configuration de Replication Server qui stocke la localisation de la base RSSD.

Exemple avec la commande admin rssd_name : 

admin rssd_name
DEC_D1_REP> admin rssd_name

RSSD Dataserver    RSSD Database
---------------    ------------------
RSD_D1_ASE         DEC_D1_REP_RSSD

Exemple avec le fichier de configuration Replication Server :

Dans le contexte de cet article, le fichier de configuration de Replication Server DEC_D1_REP.cfg est stocké dans le répertoire /Software/sybase/dba/DEC_D1_REP/cfg. Les informations au sujet de la base RSSD sont données avec les paramètres RSSD_% dans ce fichier de configuration

DEC_D1_REP.cfg
…
RSSD_server=RSD_D1_ASE
RSSD_database=DEC_D1_REP_RSSD
…

Écrire les exceptions dans la base RSSD (sysadmin log_first_tran)

Lorsqu’une exception est rencontrée par Sybase Replication Server vers une destination pour une transaction, le message de cette exception (attempt to insert duplicate key, etc.) est consigné dans le fichier de log de Replication Server et le process distributeur (DSI) vers la destination est alors suspendu.

Exemple d’exception dans le fichier de log de Replication Server :

E. 2009/09/10 16:49:11. ERROR #1028 DSI EXEC(112(1) DEC_T5_ASE.idee) - dsiqmint.c
(3042)
        Message from server: Message: 1204, State 2, Severity 17 -- 'ASE has run
out of LOCKS. Re-run your command when there are fewer active users, or contact a
 user with System Administrator (SA) role to reconfigure ASE with more LOCKS.
'.
H. 2009/09/10 16:49:11. THREAD FATAL ERROR #5049 DSI EXEC(112(1) DEC_T5_ASE.idee)
 - dsiqmint.c(3049)
        The DSI thread for database 'DEC_T5_ASE.idee' is being shutdown. DSI rece
ived data server error #1204 which is mapped to STOP_REPLICATION. See logged data
 server errors for more information. The data server error was caused by output c
ommand #1 mapped from input command #50009 of the failed transaction.
I. 2009/09/10 16:49:11. The DSI thread for database 'DEC_T5_ASE.idee' is shutdown

La commande admin who_is_down lancée dans Replication Server montre effectivement que le process distributeur (DSI) est dans l’état suspendu (suspended).

admin who_is_down
DEC_D1_REP > admin who_is_down

Spid Name       State                Info                                    
---- ---------- -------------------- ----------------------------------------
     DSI EXEC   Suspended            118(1) DEC_T5_ASE.idee                  
     DSI        Suspended            118 DEC_T5_ASE.idee

Le message dans le fichier de log de Replication Server ne donne pas toujours la raison détaillée de l’exception levée et notamment l’ordre ou les ordres SQL en échec. Seule la commande système Replication Server sysadmin log_first_tran permet de demander à Replication Server d’écrire l’exception dans sa base RSSD pour pouvoir visualiser l’ordre ou les ordres SQL associé(s) à l’exception.

sysadmin log_first_tran, dataserver, database
DEC_D1_REP > sysadmin log_first_tran, DEC_T5_ASE, idee

The first transaction for database 'DEC_T5_ASE.idee' has been logged into the exceptions log

Visualiser la liste et le détail des exceptions (rs_helpexception)

La procédure stockée rs_helpexception dans la base RSSD permet de visualiser la liste des exceptions stockées ou le détail d’une exception stockée :

execute rs_helpexception [XactID [,v]]

Sans argument, rs_helpexception liste très sommairement la liste des exceptions :

RSD_D1_ASE.DEC_D1_REP_RSSD> execute rs_helpexception
RSD_D1_ASE.DEC_D1_REP_RSSD> go

         Summary of Logged Transactions on 'DEC_D1_REP'
 
              Total # of Logged Transactions = 2       
 
 Xact ID     Org Site        Org User Org Date    Dest Site       # Recs/Xact
 ----------- --------------- -------- ----------- --------------- -----------
         112 DEC_T1_ASE.idee ideemgr  Sep 10 2009 DEC_T5_ASE.idee           3
         113 DEC_T1_ASE.idee ideemgr  Sep 10 2009 DEC_T5_ASE.idee      314420

        For detailed information on a logged xact., type 'rs_helpexception {Xact ID}'

Dans l’exemple ci-dessus, la transaction 113 en échec en date du 10 septembre 2009 contient 314420 commandes SQL (# Recs/Xact).

En appelant la procédure rs_helpexception avec le numéro d’exception, le détail de la transaction en échec est donné avec le site d’origine, le site de destination, l’utilisateur, la date et l’heure de la transaction validée (Commit Date), etc.

RSD_D1_ASE.DEC_D1_REP_RSSD> execute rs_helpexception 113
RSD_D1_ASE.DEC_D1_REP_RSSD> go

        Detailed Summary of Logged Transaction # 113      on 'DEC_D1_REP'
 
 Origin Site                    Origin User     Org. Commit Date  #Cmds in Xact
 ------------------------------ --------------- ----------------- -------------
 DEC_T1_ASE.idee                ideemgr         Sep 10 2009  3:56        314420

 Dest. Site                     Dest. User      Date Logged      
 ------------------------------ --------------- -----------------
 DEC_T5_ASE.idee                idee_maint      Sep 11 2009  4:47
 
This transaction was logged by the 'sysadmin log_first_tran' command.

En donnant en plus l’argument v (verbose) en plus du numéro de l’exception, le détail des commandes SQL dans la transaction en échec est affiché. 

RSD_D1_ASE.DEC_D1_REP_RSSD> execute rs_helpexception 113,v
RSD_D1_ASE.DEC_D1_REP_RSSD> go

...
 A0126 05iso_1distribute 2 ~"!,3 1 applied ~!6INSTRUMENT_idee_dect1.~!*rs_update  yielding min_before ~$)INST_NUM=~%'623819, ~$-INST_EXT_COD=~",L_SO433BF8F after ~$-INST_EXT_COD=NULL                                                                          
 update INSTRUMENT set INST_EXT_COD=NULL  where INST_NUM=623819                                                                                                                                                                                                 
 A0126 05iso_1distribute 2 ~"!,3 1 applied ~!6INSTRUMENT_idee_dect1.~!*rs_update  yielding min_before ~$)INST_NUM=~%'623820, ~$-INST_EXT_COD=~"*SO433BF83 after ~$-INST_EXT_COD=NULL                                                                            
 update INSTRUMENT set INST_EXT_COD=NULL  where INST_NUM=623820                                                                                                                                                                                                 
 A0126 05iso_1distribute 2 ~"!,3 1 applied ~!6INSTRUMENT_idee_dect1.~!*rs_update  yielding min_before ~$)INST_NUM=~%'623821, ~$-INST_EXT_COD=~"*SO433BF84 after ~$-INST_EXT_COD=NULL                                                                            
 update INSTRUMENT set INST_EXT_COD=NULL  where INST_NUM=623821

Supprimer les exceptions (rs_delexception)

La procédure stockée rs_delexception dans la base RSSD supprime une exception à partir de son numéro (Xact ID) :

exec rs_delexception XactID
RSD_D1_ASE.DEC_D1_REP_RSSD> execute rs_delexception 112
RSD_D1_ASE.DEC_D1_REP_RSSD> go

 Deleting 3         commands in logged transaction # 112      on 'DEC_D1_REP'
 
         Logged transaction # 112      successfully deleted. Truncate RSSD transaction log if necessary.
 
(return status = 0)

Une seule exception à la fois peut être supprimée avec la procédure rs_delexception, ce qui peut être très rébarbatif lorsqu’il y a une centaine d’exceptions à supprimer. Le script donné plus loin permet d’automatiser la suppression massive des exceptions.

Sans paramètre XactID, la liste des exceptions est retournée comme avec la procédure rs_helpexception avec la consigne de préciser XactID.

RSD_D1_ASE.DEC_D1_REP_RSSD> execute rs_delpexception
RSD_D1_ASE.DEC_D1_REP_RSSD> go

         Summary of Logged Transactions on 'DEC_D1_REP'
 
              Total # of Logged Transactions = 2       
 
 Xact ID     Org Site        Org User Org Date    Dest Site       # Recs/Xact
 ----------- --------------- -------- ----------- --------------- -----------
         112 DEC_T1_ASE.idee ideemgr  Sep 10 2009 DEC_T5_ASE.idee           3
         113 DEC_T1_ASE.idee ideemgr  Sep 10 2009 DEC_T5_ASE.idee      314420

         To delete a specific logged xact., type 'rs_delexception {Xact ID}'

Le modèle des exceptions dans Replication Server

Les tables rs_% de la base RSSD impliquées dans le stockage des exceptions

4 tables rs_% dans la base RSSD stockent les exceptions :

  • rs_exceptscmd
  • rs_exceptshdr
  • rs_exceptslast
  • rs_systext
contexte réplication image

Une transaction XactID dans les exceptions Replication Server est toujours identifiée par une valeur binaire de type binary(8).

Correspondance entre le numéro d’exception (XactID) et sys_trans_id

Les colonnes sys_trans_id sont de type binary(8). Les types binary stockent des données semblables aux données hexadécimales, données constituées d’un préfixe "0x" suivi d’une chaîne de chiffres et des lettres.

Ces chaînes sont interprétées différemment selon les plates-formes (little endian/big endian). Par exemple, la chaîne "0x0000100" représente 65536 sur des machines considérant l’octet 0 comme le plus significatif et 256 sur des machines le considérant comme le moins significatif.

Pour déterminer si l’octet 0 est le plus ou le moins significatif :

RSD_D1_ASE.DEC_D1_REP_RSSD> select convert(int,0x0000100)

256

Dans le contexte de cet article, il s’agit de plateformes SPARC Solaris 9 64 bits, l’octet 0 est le moins significatif.

La requête exemple ci-dessous, en fonction de la signification de l’octet 0 sur la plateforme, permet de traduire les valeurs des colonnes sys_trans_id dans les tables rs_exceptshdr et rs_exceptscmd en identifiant d’exception XactId :

if (convert(int, 0x0000100) = 65536)
begin
 select
   "Xact ID" = convert(int, reverse(substring(sys_trans_id, 5, 8)))
 from rs_exceptshdr
end
else
begin
 select
  "Xact ID" = convert(int, substring(sys_trans_id, 5, 8))
 from rs_exceptshdr
end

 Xact ID    
 -----------
         113

Dans la suite de cet article, seule la commande convert(int, substring(sys_trans_id, 5, 8)) est exécutée pour retrouver XactID. Le code est à adapter en fonction de la plateforme utilisée.

rs_exceptshdr, informations générales sur les exceptions

La table rs_exceptshdr stocke les informations générales d’une transaction en échec (site d’origine, site de destination…). Une transaction en échec est identifiée de manière unique par son identifiant système de transaction sys_trans_id :

select "XactID" = convert(int, substring(sys_trans_id, 5, 8)) ,
       orig_site, 
       orig_db,
       orig_time, 
       error_site,
       error_db , 
       log_time, 
       log_reason
  from rs_exceptshdr
go

XactID orig_site   orig_db  orig_time           error_site  error_db  log_time             log_reason
------ ----------  -------  ------------------- ----------  --------  -------------------  ----------       
113    DEC_T1_ASE  idee     Sep 10 2009 3:56PM  DEC_T5_ASE  idee      Sep 11 2009  4:47PM  D

La colonne log_reason dans la table rs_exceptshdr explique l’action qui a enregistré l’exception dans la base RSSD (sysadmin log_first_tran, resume connection…).

log_reason Raison de l’enregistrement de l’exception
O Transaction automatiquement enregistrée car orpheline dans la queue du DSI
E Transaction qui a généré une erreur sur la cible et qui est associée à l’option LOG ou RETRY_LOG
S Transaction automatiquement enregistrée car écartée avec une commande resume connection avec l’option skip transaction
D Transaction enregistrée avec la commande sysadmin log_first_tran

rs_exceptscmd et rs_systext : textes SQL et commandes source et de sortie (source command, output command)

Les textes SQL d’une exception sont stockés dans la colonne textval varchar(255) de la table rs_systext.

La table rs_systext ne contient pas la colonne sys_trans_id pour retrouver directement l’identifiant XactID. Il faut réaliser une jointure entre la colonne parentid de la table rs_systext et la colonne cmd_id de la table rs_exceptscmd, table qui contient la colonne sys_trans_id.

select top 6 "XactID" = convert(int, substring(sys_trans_id, 5, 8)),
        src_cmd_line,
        cmd_type,
        texttype,
        sequence,
        textval
from rs_systext, rs_exceptscmd
where cmd_id = parentid

 XactID      src_cmd_line cmd_type texttype sequence textval        
 ----------- ------------ -------- -------- -------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
         113            1 S        C               1 A0126 05iso_1distribute 1 ~";Sep 10 2009  3:56:46:880PM,2 ~"!,3 1 begin transaction ~"%_upd npw ~"(ideemgr
         113            1 L        C               1 begin transaction                                              
         113            2 S        C               1 A0126 05iso_1distribute 2 ~"!,3 1 applied ~!6INSTRUMENT_idee_dect1.~!*rs_update  yielding min_before ~$)INST_NUM=~%#10, ~$-INST_EXT_COD=~"*250010000 after ~$-INST_EXT_COD=NULL
         113            2 L        C               1 update INSTRUMENT set INST_EXT_COD=NULL  where INST_NUM=10
         113            3 S        C               1 A0126 05iso_1distribute 2 ~"!,3 1 applied ~!6INSTRUMENT_idee_dect1.~!*rs_update  yielding min_before ~$)INST_NUM=~%#11, ~$-INST_EXT_COD=~"*260350000 after ~$-INST_EXT_COD=NULL
         113            3 L        C               1 update INSTRUMENT set INST_EXT_COD=NULL  where INST_NUM=11

Les types de commande cmd_type dans la table rs_exceptscmd peuvent avoir trois valeurs possibles :

cmd_type
S Commande source : texte de la transaction envoyé par l’agent de réplication et reçu par Replication Server.
L Commande de sortie : texte de la transaction préparée par Replication Server pour la base de données cible à partir des fonctions chaînes (function strings).
RPC Commande de sortie RPC (Remote procedure call).

Lorsqu’un texte SQL dépasse la capacité de la colonne textval dans la table rs_systext, une nouvelle entrée est créée dans la table rs_systext avec un numéro pour la colonne sequence incrémenté.

Dans la table rs_systext, la colonne texttype est toujours à C. Il ne faut surtout pas manipuler les lignes pour lesquelles texttype est définie à O ou S.

texttype
C Commande SQL pour une exception.
S Modèle d’entrée d’une chaîne fonction (function string).
O Modèle de sortie d’une chaîne fonction (function string). Exemple : 
select texttype, textval from rs_systext where type='O'

--  -----------------------------------------
O   use ?rs_destination_db!sys_raw?;
    set transactional messaging FULL;

rs_exceptslast

La table rs_exceptslast dans le modèle des exceptions de la base RSSD est indépendante des tables rs_exceptshdr, rs_exceptscmdet rs_systext.

La table rs_exceptslast stocke notamment les particularités de la dernière transaction pour laquelle l’option "skip tran" a été utilisée avec une commande resume connection to DATASERVER.BASECIBLE. L’option skip tran doit être utilisée à bon escient.

Une jointure entre la table rs_exceptslast et la table rs_databases rend compréhensible les données :

select
(select dsname + "."+ dbname  from rs_databases
        where dbid=a.error_db and dbname is not null) "DatabaseCible",
(select dsname from rs_databases
        where dbid=a.origin and dbname is not null) "DataserverSource",
(select dsname+ "."+ dbname from rs_databases
        where dbid=a.lorigin and dbname is not null) "LogicalSource",
origin_time,
log_time,
status
from rs_exceptslast a

DatabaseCible    DataserverSource LogicalSource       origin_time         log_time            status
---------------- ---------------- ------------------- ------------------  ------------------- ------
DEC_T5_ASE.idee  DEC_T1_ASE       L_DEC_T1_ASE.l_idee Dec 23 2009  2:27PM Dec 23 2009  2:28PM      0

Dans l’exemple ci-dessus, une transaction a été écartée ave l’option skip tran de la commande resume connection to DEC_T5_ASE.idee.

La colonne status de la table rs_exceptslast est très importante, car elle permet de détecter les éventuelles pertes de transactions dans les files (loss transactions in queues). La colonne status peut prendre 3 valeurs possibles :

status
0 Valide : aucune transaction pour la base origine.
1 Pertes détectées (losses) : il faut déterminer dans ce cas si des transactions ont été perdues pour la base origine.
2 Rejet des messages après des pertes détectées. Des transactions ont été probablement perdues pour la base origine.

Les transactions écartées avec l’option skip tran ne sont pas considérées comme perdues car elles sont enregistrées dans la base RSSD, c’est pourquoi la colonne status est à 0 dans ce cas de figure.

En revanche, lorsque la colonne status vaut 1 ou 2, le cas est gravissime car il faut envisager une éventuelle corruption dans les files (ou queues) du moteur Replication Server.

Requêtes utiles d’extraction des commandes SQL des exceptions

Extraction du nombre de commandes SQL dans une exception

La colonne src_cmd_line dans la table rs_exceptscmd donne le nombre de commandes SQL pour une exception XActID donnée en recherchant la valeur maximale :

declare @xactid int
select @xactid=113

select max(src_cmd_line)
from   rs_exceptscmd exc
where
(case (select convert(int, 0x0000100))
  when 65536 then convert(int, reverse(substring(sys_trans_id, 5, 8)))
  else convert(int, substring(sys_trans_id, 5, 8))
  end
 ) = @xactid
group by sys_trans_id

 -----------
      314420

Le nombre de commandes SQL dans une exception est un critère important pour décider d’utiliser ou non la procédure stockée rs_delexception afin de ne pas saturer le journal des transactions de la base RSSD.

Extraction des commandes SQL d’une exception

Pour extraire les requêtes SQL d’une exception, il suffit donc d’interroger la colonne rs_systext pour la transaction XActId associée à l’exception :

declare @xactid int
select @xactid = 113 
select
 textval
from rs_systext, rs_exceptscmd
where cmd_id = parentid
and texttype='C'
and cmd_type='L'
and (case (select convert(int, 0x0000100))
  when 65536 then convert(int, reverse(substring(sys_trans_id, 5, 8)))
  else convert(int, substring(sys_trans_id, 5, 8))
  end
 ) = @xactid
order by src_cmd_line,sequence

La requête ci-dessus fonctionne très bien lorsqu’aucune commande SQL dans la transaction ne dépasse la longueur de la colonne textval qui est dimensionnée à varchar(255). Dans le cas d’une commande SQL dépassant les 255 caractères, un saut de ligne coupe la commande SQL.

Pour aller plus loin au sujet de l’extraction des commandes SQL d’une exception dans un fichier exploitable, consulter l’article : Extraction et exploitation des exceptions Replication Server

Supprimer efficacement les exceptions dans Replication Server

Problème pouvant survenir lors de la suppression des exceptions (transaction log almost full)

Lors de la suppression des exceptions avec rs_delexception, lorsque le nombre de commandes SQL à supprimer dans l’exception est trop volumineux, la taille du journal des transactions de la base RSSD peut s’avérer être insuffisante. Une saturation du journal se produit alors :

Server Message: Number 7415, Severity 10 Line 1:
The transaction log in database DEC_D1_REP_RSSD is almost full.
Your transaction is being suspended until space is made available in the log.

Dans ce cas de figure, le système de réplication devient indisponible si le journal des transactions de la base RSSD est saturé !

La saturation provient des commandes delete sur les tables rs_systext et rs_exceptscmd dans la procédure rs_delexception :

delete  rs_systext
from    rs_exceptscmd exc,
        rs_exceptshdr exh,
        rs_systext sys
where   exc.sys_trans_id = exh.sys_trans_id
and     exc.cmd_id = sys.parentid
and     sys.texttype = "C"
and     exh.sys_trans_id  =  @systran

...

delete  rs_exceptscmd
where   sys_trans_id  =  @systran

Ce cas peut également se présenter lorsque de multiples appels de la commande rs_delexception sont réalisés pour supprimer de nombreuses petites exceptions, multiples appels réalisés sans vider le journal des transactions avec la commande dump tran <RSSD Database Name> with truncate_only à chaque appel. Le journal de la base RSSD a le temps d’être saturé avant que le process système Checkpoint Sleeper ne puisse vider le journal régulièrement.

Suppression massive des exceptions volumineuses

Lorsqu’un doute existe sur la capacité du journal des transactions d’une base RSSD à supporter la suppression d’une exception volumineuse en nombre de commandes SQL, et afin de ne pas étendre le journal des transactions à des tailles délirantes, une méthode efficace permet de supprimer massivement les exceptions. Cette méthode n’est pas supportée et suppose 2 pré-requis très importants :

  • La base RSSD n’est pas répliquée. Si la base RSSD est répliquée, il faut s’assurer que les commandes truncate table soient répliquées.
  • Le système de réplication est mis en mode veille ou "quiesced" pendant la suppression massive des exceptions.

Dans le contexte de cet article, la base RSSD n’est pas répliquée.

Il est possible de d’effectuer cette manipulation sans mettre Replication Server en mode veille, cependant le risque n’est pas nul si une exception survient pendant l’opération.

Mise en mode veille ou "quiesced" du système de réplication (admin quiesce_check)

Afin de ne pas surcharger cet article, la procédure de mise en veille d’un moteur Replication Server n’est pas décrite ici : voir Procédure de mise en veille (mode quiesced) de Sybase Replication Server pour en savoir plus.

La commande admin quiesce_check permet de vérifier la mise en veille du système de réplication

admin quiesce_check
DEC_D1_REP > admin quiesce_check

La réponse de mise en veille effective doit être : Replication Server <RS_Name> is quiesced. Dans le cas contraire, un message indique la raison.

Suppression massive des exceptions

Une fois le système de réplication en mode "quiesced" (ainsi aucune exception ne peut survenir), les tables rs_exceptslast, rs_exceptshdr et rs_exceptscmd sont vidées sans journalisation avec la commande truncate table :

use DEC_D1_REP_RSSD
go
truncate table rs_exceptshdr
go
truncate table rs_exceptscmd
go
truncate table rs_exceptslast
go

Pour vider la table rs_systext avec la commande truncate table, les lignes pour lesquelles texttype ne valent pas C sont tout d’abord sauvegardées dans une table temporaire ayant la même structure que la table rs_systext. Ces lignes sauvegardées sont réinjectées dans la table rs_systext une fois la troncature réalisée.

use DEC_D1_REP_RSSD
go
select * into #rs_systext from rs_systext where texttype != 'C'
go
truncate table rs_systext
go
insert into rs_systext select * from #rs_systext
go

Remise en route du système de réplication (resume log transfer)

Le système de réplication est remis en route avec la commande resume log transfer de Replication Server : voir Procédure de mise en veille (mode quiesced) de Sybase Replication Server pour en savoir plus sur la suppression du mode veille.

Suppression efficace d’un nombre élevé de petites exceptions

La procédure stockée rs_delexception est parfaitement adaptée pour supprimer efficacement un nombre très élevé de petites exceptions. Toutefois les multiples appels de la procédure rs_delexception peuvent également saturer le journal des transactions de la base RSSD si le process Checkpoint Sleeper n’a pas le temps de vider le journal régulièrement durant les appels de la procédure rs_delexception.

Pour pallier à ce problème, chaque exécution de la procédure rs_delexception est accompagnée d’une troncature du journal de la base RSSD : la méthode est violente mais permet d’éviter tout risque d’indisponibilité pour le système de réplication.

Dans le script shell ci-dessous en guise d’exemple, $EXCEPTSID est la liste des exceptions détectées à supprimer :

for iexcept in $EXCEPTSID
do
        isql -U${SYB_USER} -S${REPSERVER} -D$[RSSD_DBNAME} -o ${LOG_FILE} EOF |grep -v '^Password
:'
        ${SYB_PASSWD}
        rs_delexception $iexcept
        go
        dump tran $[RSSD_DBNAME} with truncate_only
        go
        EOF
done

Script rsdelexceptions.ksh

Le script rsdelexceptions.ksh supprime massivement les exceptions dans une base RSSD :

%> rsdelexceptions.ksh <RepServer> <Mode N(default)|F> [<Seuil (1000)>]

Le deuxième paramètre du script est le mode de suppression : N (par défaut) ou F

Mode
N Mode de suppression normal. La procédure rs_delexception est appliquée pour chaque exception avec troncature du journal des transactions de la base RSSD après chaque appel. Par défaut, toutes les exceptions contenant plus de 1000 commandes SQL sont écartées en mode normal : le troisième paramètre applicable uniquement en mode normal permet d’augmenter ce seuil de 1000 commandes SQL. Le seuil est augmenté en fonction du dimensionnement du journal des transactions de la base RSSD.
F Mode de suppression forcée. Les tables rs_exceptshdr, rs_exceptslast, rs_exceptscmd et rs_systext sont vidées selon la procédure décrite précédemment (Suppression massive des exceptions). Durant la suppression massive des exceptions, le moteur de réplication est mis en veille (mode quiesced).

Voici quelques exemples d’appel :

%> rsdelexceptions.ksh DEC_D1_REP F
%> rsdelexceptions.ksh DEC_D1_REP N
%> rsdelexceptions.ksh DEC_D1_REP N 5000

Les codes retour suivants sont :

0 Suppression des exceptions réussie 
%> rsdelexceptions.ksh DEC_D1_REP F
1 Suppression des exceptions réussie, mais des exceptions ont été écartées, le seuil du nombre de commandes SQL ayant été atteint pour une ou plusieurs exceptions à supprimer. 
%> rsdelexceptions.ksh DEC_D1_REP N
2 La mise en mode veille du moteur de réplication est en échec (mode quiesced). 
%> rsdelexceptions.ksh DEC_D1_REP F
3 Erreur de syntaxe dans l’appel du programme. 
%> rsdelexceptions.ksh DEC_D1_REP Z
Usage : rs_delexceptions.ksh REPSERVER Mode(N|F) [Threshold (default 1000)]

La publication du script rsdelexceptions.ksh n’est pas encore réalisée.