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 :
La suppression massive des exceptions dans une base RSSD Adaptive Server Enterprise est disponible dans le guide pratique Sybase Replication Server - §2 : Guide pratique et astuces Sybase Replication Server »
Pour retrouver rapidement la base RSSD associée à un serveur Replication Server, deux options possibles :
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 est stocké dans le répertoire /Software/sybase/dba/DEC_D1_REP/cfg/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
cat DEC_D1_REP.cfg
... RSSD_server=RSD_D1_ASE RSSD_database=DEC_D1_REP_RSSD ...
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
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 :
rs_helpexception [XactID [,v]]
Sans argument, rs_helpexception liste très sommairement la liste des exceptions :
RSD_D1_ASE.DEC_D1_REP_RSSD.1> rs_helpexception RSD_D1_ASE.DEC_D1_REP_RSSD.2> 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.1> rs_helpexception 113 RSD_D1_ASE.DEC_D1_REP_RSSD.2> 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.1> rs_helpexception 113,v RSD_D1_ASE.DEC_D1_REP_RSSD.2> 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
La procédure stockée rs_delexception dans la base RSSD supprime une exception à partir de son numéro (Xact ID) :
rs_delexception XactID
RSD_D1_ASE.DEC_D1_REP_RSSD.1> rs_delexception 112 RSD_D1_ASE.DEC_D1_REP_RSSD.2> 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.1> rs_delpexception RSD_D1_ASE.DEC_D1_REP_RSSD.2> 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}'
4 tables rs_% dans la base RSSD stockent les exceptions :
Une transaction XactID dans les exceptions Replication Server est toujours identifiée par une valeur binaire de type binary(8).
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.
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 |
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 chapines (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;
|
La table rs_exceptslast dans le modèle des exceptions de la base RSSD est indépendante des tables rs_exceptshdr, rs_exceptscmd et 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 permet de rendre 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.
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.
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 taillé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" »
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.
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 :
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.
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.
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
Le système de réplication est remis en route avec la commande resume log transfer de Replication Server : voir §3 Procédure de mise en veille (mode quiesced) de Sybase Replication Server pour en savoir plus sur la suppression du mode veille.
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
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 dans le paragraphe 5-2-2- 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 retournés :
| 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 N |
| 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 et est imminente
| Version | Date | Commentaires |
|---|---|---|
| 1.0 | 11/2009 | Version initiale |
SQLPAC : Procédure de mise en veille (mode quiesced) de Sybase Replication Server
SQLPAC :
Extraction et exploitation des exceptions Replication Server
SQLPAC : Guide
pratique et astuces Sybase Replication Server
RS 15 BOL :
rs_helpexception
RS 15 BOL :
rs_delexception
RS 15 BOL :
admin rssd_name
RS 15 BOL :
admin who_is_down
RS 15 BOL :
sysadmin log_first_tran
RS 15 BOL :
resume connection
RS 15 BOL :
rs_systext
RS 15 BOL :
rs_exceptscmd
RS 15 BOL :
rs_exceptshdr
RS 15 BOL :
rs_exceptslast