Mise en place de la Réplication : erreur dans la log [Résolu]

[tibal]

Bonjour,

Après avoir cassé une réplication, je m'attaque à sa remise en place. Voici les étapes effectuées :
1 - Création d'un utilisateur de maintenance sur les 2 ASE (sce et stdby)
2 - Installation de la procedure stockée rs_install_primary.sql (sauf dbcc settrunc et sp_setreplicate) sur les 2 ASE (sce et stdby)
3 - enable rep agent threads
4 - Création de la connexion logique sur le RS
5 - Création de la connexion de la database sce
6 - Création du login dans le RS
7 - Configuration du Rep Agent

sp_config_rep_agent "<syb_src_db>", "enable",...
sp_config_rep_agent "<syb_src_db>", "send warm standby xacts", true
sp_setreplicate rs_marker,"true"
sp_setreplicate rs_update_lastcommit,"true"
sp_start_rep_agent "<syb_src_db>"

8 - Marquer la database pour la replication

sp_reptostandby "<syb_src_db>","all"

9 - Création de la connexion de la database stdby
10 - Dump de la base

Dans le log du RS, voici le message d'erreur qui arrive :
E. 2009/02/19 16:47:13. ERROR #1028 CREATE(DataServer_stdby.Ma_Base) - /dsiexec.c(392)
Message from server: Message: 10330, State 1, Severity 14 -- 'EXECUTE permission denied on object rs_marker, database cd_but001, owner dbo
E. 2009/02/19 16:47:13. ERROR #5051 CREATE(DataServer_stdby.Ma_Base) - /dsiexec.c(409)
Received errors from database 'DataServer_Prod.Ma_Base'. See logged ct-lib and data server messages for more information.

Durant tout le déroulement, aucune erreur n'est apparu. Je pense que cela pourrai éventuellement venir de

Code :

sp_setreplicate rs_marker,"true"

,vu le message d'erreur, mais aucune erreur n'est apparue.

Merci pour votre aide.

[mpeppler]

Personellement j'utilise simplement rs_init pour initialiser les env. de repli - c'est plus simple :-)

Mais dans ce cas précis - le problème est que le maintenance user n'a pas le droit d'exécuter la proc rs_marker - donc il manque un grant execute dans la base source (et probablement dans la destination aussi)

Michael

[tibal]

Merci Michael.

Existe t'il une SP qui affiche les membres d'un rôle, comme sp_helprolemember de MS SQL Server, mais qui ne fonctionne pas sur ASE 12_5. Je souhaite comparer ce qui existe sur une autre base en Warm Standby en terme de rôle pour l'utilisateur de maintenance et l'appliquer sur les deux bases sur lesquelles je travaille.

Merci.

[mpeppler]

Non, pas vraiment.

Il y a sp_displaylogin, qui va donner les roles d'un login.

Par contre, un select sur master..sysloginroles et master..syssrvroles devrait donner la liste des roles par login.

Et inversement, sp_helprotect pour voir les grants sur un objets.

Michael

[mpeppler]

Euh - je dis des bêtises...

Regardes sp_displayroles 'login_name'...

Michael

[tibal]

J'ai lance la sp_displayroles "user" sur les 2 ASE.
J'ai bien le rôle replication_role sur chaque utilisateur de maintenance.
Par contre concernant le rôle "rs_marker", il se trouve dans la base RSSD du serveur de Réplication. Je ne pense pas qu'on puisse affecter ce rôle aux utilisateurs de maintenance, étant donné que ces derniers sont situés sur des ASE (donc serveurs différents).
Je continue de chercher mais suis preneur de toutes les solutions.

[tibal]

Lorsque je passe par "rs_ini", j'obtiens le message d'erreur suivant lors de l'ajout de la standby à la réplication :

Unable to execute query 'exec sp_config_rep_agent "Ma_base", enable,"rsc_XX","rsc_XX_ra", "rsc_XX_ra_ps"' against server 'Mon_DataServer_De_Secour'.

???

[mpeppler]

Il faut lire le reste de la log pour voir pourquoi cela ne marche pas!

(permissions, etc.)

Michael

[DBRep]

Unable to execute query 'exec sp_config_rep_agent "Ma_base", enable,"rsc_XX","rsc_XX_ra", "rsc_XX_ra_ps"' against server 'Mon_DataServer_De_Secour'.

Effectivement, il faudrait avoir/voir le fichier de log de "rs_init", mais je soupconne fortement que ce soit du au fait que le RepAgent ai deja ete configure precedement (voir point 7 du premier post).

Il faudrait supprimer la config precedement faite :

Code , arret du RAT, au cas ou ... :

sp_stop_rep_agent <syb_src_db>[, "nowait"]

Code , puis suppression de la config precedente :

sp_config_rep_agent <syb_src_db>, "disable"

puis relancer la creation de la connection avec "rs_init" ...


DBRep

[tibal]

Bonjour,

Je vous joint mon fichier de log.

Merci pour votre aide.

[Roller]

rs_init configure automatiquement le rep agent.
Il faut donc que celui ci soit désactivé (suivre la procédure donnée par dbrep) avant de le lancer

[DBRep]

Envoyé par tibal

Je vous joint mon fichier de log.

Désolé pour le délai.

D'après la log du "rs_init", la raison de l'échec doit être la suivante :

Code :

1
2
3
2009/02/27 15:44:20 WARNING: "Active database or logical connection to
                    L_DS_PROD.L_BASE_001 does not exist or is not controlled
                    by this site"

2 possibilités :

1) Soit le nom de la connexion Logique spécifiée n'est pas bonne : L_DS_PROD.L_BASE_001

2) soit, vous essayez de créer la connexion Standby sur un autre RepServer.
ceci n'est pas permis pour la création d'une Warm/Standby classique (il faut que les 2 connexions soit gérer par le même RepServer)

Si vous tenez absolument à avoir 2 RepServer, il faut utiliser la fonctionnalité MSA, dans ce cas, il faut créer la 1ère connexion Primaire classique sur le premier RepServer, la 2ème connexion Replicate classique sur le deuxième RepServer (avec une route du 1er au 2ème) et ensuite définir une Database Replication Definition (sur le 1er RS) et sa Subscription (sur le 2e RS).


DBRep

[tibal]

Merci BDRep, je contrôle tout ça dès demain et vous tiens au courant du résultat.
Existe t'il de la doc (en français) sur la réplication 12_6 avec des exemples et exercices ?

[tibal]

Bonsoir,
Après maintes tentatives de configuration de la réplication à l'aide du binaire RS_INIT, tout c'est déroulé sans erreurs. Ensuite, j'ai fait un Dump de la base primaire, un load sur la base répliquée, puis résumé la connexion. Mais le hic c'est que lorsque je créé une table sur la base primaire, elle n'est pas créée sur la base répliquée ??
Je ne pense pas être très loin de la vérité, mais que me manque t'il, alors même que plus aucune erreur ne se produit lors de la config.
Encore merci pour votre aide.

[tibal]

Ca y est, ça fonctionne enfin. Pour y parvenir j'ai du octroyé au maintenance_user des droits sur les objets de les bases primaire et répliquée. Par contre, lorsque je créé une table dans la base primaire, cela bloque de nouveau la réplication car les maintenance_user des bases primaire et répliquée n'ont aucun droit sur la table nouvellement créée.
Comment peux t'on contourner ce problème et faire en sorte que les maintenance_user des bases primaire et répliquée aient les droits nécessaires sur tout objet créé dans la base primaire ?
Merci pour votre aide.

[mpeppler]

Une solution: aliaser le user de maintenace à "dbo":

Code :

1
2
3
4
5
6
7
 
USE ma_db
go
sp_dropuser 'user_de_maintenance'
go
sp_addalias 'user_de_maintenance', dbo
go

Maintanent le user de maintenance a les mêmes droits que dbo, et peu donc créer des tables, etc.

Michael

[DBRep]

Envoyé par tibal

Mais le hic c'est que lorsque je créé une table sur la base primaire, elle n'est pas créée sur la base répliquée ??

Pour ça il faut activer la réplication des DDL avec :

Code :

1
2
3
4
USE <myactivedb>
go
sp_reptostandby <myactivedb>, 'all'
go

Pour les droits d'accès aux objets pour l'utilisateur de maintenance, effectivement, "alliasser" l'utilisateur de maintenant à DBO est une solution.

Sinon, lors de la création de la table, pensez à donner des droits, cela doit aussi être répliqué :

Code :

1
2
3
4
create table <mytable> bla bla bla
go
grant all on mytable to <mymaintuser>
go

(cela impose d'avoir les mêmes utilisateurs de maintenance pour l'ACTIVE et la STANDBY, ou du moins que l'utilisateur de maintenance de la STANDBY existe aussi dans l'ACTIVE, ce qui fait qu'"alliasser" l'utilisateur de maintenant à DBO pour être moins contraignant...)


bonne journée
DBRep

[tibal]

Merci à tous pour votre aide.
A bientôt pour un nouveau sujet.