2010-04-30 5 views
0

J'avais hérité de ce SQL Server où nous mettons des données dans une table (appel TableA) sur une base de données (DB-A). Je peux voir la tableA dans une autre base de données sur le même serveur (DB-B) obtient les mêmes données tout de suite.Question de réplication SQL Server

Des idées comment cela est mis en œuvre? J'essaye de voir la trace mais jusqu'ici pas de chance. Quelqu'un a une idée? À ce stade, je ne suis pas sûr si sa réplication. Ceci est une supposition

Répondre

1

Il peut s'agir d'une réplication ou d'un déclencheur sur la table source qui déplace les données.

+0

Le profileur n'a pas réussi à intercepter l'écriture d'un proc stocké dans la base de données A. Le profileur était donc inactif et j'ai vu la mise à jour de la table. Trouvé la cause. Merci pour l'aide – schar

1

Peut-être que c'est une réplication transactionnelle? Vous devriez être en mesure d'aller à la réplication sont et voir s'il y a des abonnés ou des éditeurs. Soit cela ou vous avez des serveurs liés, et les déclencheurs copient les données.

+0

Les deux bases de données sont sur la même machine. Je ne vois pas un déclencheur écrit dans une autre base de données. De toute façon je peux surveiller les écritures à une table particluar? – schar

+0

Vous créez une trace de profileur et la filtrez sur la base de données de destination. Si vous affichez les résultats dans une table, vous pouvez exécuter des requêtes sql sur les résultats pour au moins voir quand les écritures se produisent. Pour la réplication ... quelle version du serveur sql utilisez-vous? Dans 2k5 et au-dessus, il existe un dossier de réplication sous le nœud de serveur. Ouvrez-le et développez tous les nœuds à la recherche de publications ou d'abonnements. – Jeremy

+0

Trouvé qu'une procédure stockée de la base de données A écrivait aussi à la base de données B. Le profileur n'a jamais intercepté cette instruction d'écriture à partir de l'appel de procédure stockée. Merci pour votre suggestion – schar

1

Cela se produit très probablement en utilisant une vue de synonyme ou de base de données croisée. Vérifiez pour voir si la "table" sur l'autre base de données est vraiment une table. S'il s'agit d'une table, ils ont configuré la réplication transactionnelle entre les deux bases de données.

select type_desc from sys.objects where name = 'name_on_database_b' 
+0

Comment puis-je vérifier si elles sont définies en tant que réplication transactionnelle? – schar

+0

Le profileur n'a pas réussi à intercepter l'écriture d'un proc stocké dans la base de données A. Le profileur était donc inactif et j'ai vu la mise à jour de la table. Trouvé la cause. Merci pour l'aide – schar