Discussion :

[vinceroi]

Bonjour,

Tout d'abord désolé si ma question est trivial. Je debute dans l'univers de la Replication.
Notre environment de prod:
1- REP server 15.5 avec RSSD installé sur un ASE 15.5
2- 2 serveurs ASE 15.5 ESD#3
3- 3 dbs repliquées avec la methode MSA (sp_reptostandby 'all' pour les 3 dbs) avec rep definition and subscriptions.
4- Downtime max : 15 mins

Comment puis-je supprimer une colonne d'une table (qui n'est pas une clé primaire ou étrangere) dans un environment repliqué comme décrit au-dessus?
Dans ma compréhension, si je supprime une colonne d'une table, la replication va générer une erreur comme le REP server utilise les noms de colonnes dans la clause WHERE pour répliquer les données sur l'ASE secondaire.
Y-a-t-il une methode simple d'exclure cette colonne de la replication puis la supprimer des 2 serveurs ASE? Y-a-t-il dans le REP server une classe d'erreur correspondant a la situation que je pourrais rendre non critique?
Malheureusement je ne peux pas suspendre la replication, supprimer la colonne sur le secondaire, 'resumer' la replication puis faire un failover de
l'activité sur le secondaire (technique employée quand on fait des upgrade/migration de l'application/db) car la replication va générer des erreurs.

Merci
Vincent

[vinceroi]

Ma question ne semble pas etre très populaire. Peut-etre que c'est un signe pour dire que MSA n'est pas adapté à des changements de schemas, en particulier les suppressions de colonnes.

[mpeppler]

Si - on peut tout à fait la configurer pour repliquer le DDL (comme un warm standby).

Malheureusement je n'ai pas (plus?) l'experience hands-on pour te donner des solutions adaptées spécifiquement à ton probleme.

[vinceroi]

Merci Michael!

1) J'ai commencé par un faire un test simple sur un environnement de test. Supprimer une colonne d'une table sur le primaire pour voir si cela replique.
En lancant "alter table .... drop ", un warning apparait indiquant que l'option 'SELECT INTO' est necessaire pour ca....hum pas une bonne nouvelle sur un environnement repliqué. J'ai donc ouvert un Sybase Case. La réponse est sans appel:
"Alter table drop column is not supported (CR 366077). The reason is that under the covers this kind of alter table will use an SELECT INTO, which is not allowed in at multi-statement transaction either."

2) Concernant mon cas particulier (drop column sur un standby avant de "resumer" la réplication), je crois que 2 cas s'offrent a moi.
- créer un rep def pour cette table ou manque la colonne, cette rep def ayant priorité sur MSA.
- ne pas supprimer la colonne. apres l'upgrade, "resumer" la réplication, quand tout est ok, faire un failover de l'activité sur ce nouveau PRIMARY upgradé, puis supprimer la colonne avant de faire le db dump qui servira a reconstruire le nouveau STANDBY.

Merci