6

最近、SQL Server 2005 から SQL Server 2008 (R2、SP1) にアップグレードしました。このアップグレードにはいくつかのパブリケーションが含まれており、すべてのテーブルは「後で勝つ」原則に基づくデフォルトのコンフリクト リゾルバーでパブリッシュされています。そのスマート ネームは「Microsoft SQL Server DATETIME (Later Wins) Conflict Resolver」で、対応する dll ファイルは ssrmax.dll です。

ご存知のように、競合リゾルバーを使用してテーブルを発行すると、このテーブルを使用する以降のすべての発行で同じ競合リゾルバーを使用する必要があります。当然のことですが、以前に公開されたテーブルを新しいパブリケーションに追加し、このテーブルに使用する競合リゾルバーとまったく同じものを指定すると、エラー メッセージが表示されます。

use [myDb]
exec sp_addmergearticle 
    @publication = N'myDb_Pub', 
    @article = N'Tbl_blablabla', 
    @source_owner = N'dbo', 
    @source_object = N'Tbl_blablabla', 
    @type = N'table', 
    @description = N'', 
    @creation_script = N'', 
    @pre_creation_cmd = N'drop', 
    @schema_option = 0x000000000C034FD1, 
    @identityrangemanagementoption = N'none', 
    @destination_owner = N'dbo', 
    @force_reinit_subscription = 1, 
    @column_tracking = N'false', 
    @article_resolver = N'Microsoft SQL Server DATETIME (Later Wins) Conflict Resolver', 
    @subset_filterclause = N'', 
    @resolver_info = N'ddmaj', 
    @vertical_partition = N'false', 
    @verify_resolver_signature = 0, 
    @allow_interactive_resolver = N'false', 
    @fast_multicol_updateproc = N'true', 
    @check_permissions = 0, 
    @subscriber_upload_options = 0, 
    @delete_tracking = N'true', 
    @compensate_for_errors = N'false', 
    @stream_blob_columns = N'false', 
    @partition_options = 0
GO

そして、これは私たちが得るエラーです:

The article '...' already exists in another publication with a different article resolver.

同じ競合リゾルバーがマシンによって「同じ競合リゾルバー」と見なされない理由を理解しようとすることで、レジストリに同じ名前で異なるバージョンの 2 つの競合リゾルバーがあることがわかりました。

2005年版:

  • ファイルssrmax.dll、
  • バージョン 2005.90.4035.0、
  • cls_id D604B4B5-686B-4304-9613-C4F82B527B10

2008年版:

  • ファイルssrmax.dll、
  • バージョン 2009.100.2500.0、
  • cls_id 77209412-47CF-49AF-A347-DCF7EE481277

そして、2008年のサーバーが2番目のサーバーを「利用可能なカスタムリゾルバー」と見なしていることを確認しました（sp_enumcustomresolversを実行してこれを取得しました）。問題は、両方の参照がレジストリで利用できることです。そのため、古い出版物は 2005 年版を参照しているのに対し、新しい出版物は 2008 年版を参照しようとしていると思いますが、これは実際には以前のものとは異なります。

問題は、どうすればこれら 2 つのバージョンのうちの 1 つだけをサーバーに考慮させることができるかということです。これは (もちろん) 既存の出版物を削除して再作成する必要がありません (これにより、次の 2 週間、私たちの生活は地獄に変わります)。

4

2 に答える 2

0

ありがとう、サブスクライバーの記事にサーバー上で意味をなさないCLSIDがある再発行者に似たようなものがありましたが（Regeditで調べました）、記事をパブリケーションに追加しようとすると上記のエラーが発生しました。

取得しようとしていた clisd を使用して、購読記事の sysMergeArticles テーブルの resolver_clsid フィールドを更新しました

{

declare @resolver_clsid  nvarchar(50)

 exec sys.sp_lookupcustomresolver N'Microsoft SQL Server DATETIME (Earlier Wins) Conflict Resolver', @resolver_clsid OUTPUT


 select @resolver_clsid 

}

その後、記事を追加できます

于 2015-12-02T17:55:38.653 に答える
0

ええと..誰も答えを得ませんでした。しかし、私は（ついに）それを手に入れたと思います。何を推測します...それはメタモデルのどこかにあります（いつものように）！

  • アイテムをサブスクリプションに追加するとき、ストアド プロシージャによって使用される新しい競合リゾルバー参照は、[distribution].[MSmerge_articleresolver] テーブルから取得されます。
  • ただし、既存のサブスクリプションの場合、以前のコンフリクト リゾルバーの参照は、公開データベースのシステム テーブル、つまり [sysmergearticles]、[sysmergeextendedarticlesview]、および [sysmergepartitioninfoview] に格納されます。

そのため、パブリッシング データベース メタモデルに従って、パブリケーションが 2005 競合リゾルバーを参照する、SQLSERVER 2005 で最初にパブリッシュされたアイテムがあります。反対側では、マシンは同じアイテムを新しい出版物に追加しようとしますが、今回は配布データベースで利用可能な競合リゾルバーへのデフォルトの参照を使用しますが、これは実際には 2005 のものとは異なります....

これを説明するために、次のことを確認できます。

USE distribution
go
SELECT article_resolver, resolver_clsid
  FROM [MSmerge_articleresolver] WHERE article_resolver like '%Later Wins%'
  GO

それで、

USE myPublicationDatabase
go
SELECT article_resolver, resolver_clsid
  FROM [sysmergearticles] WHERE article_resolver like '%Later Wins%'
  GO
 SELECT article_resolver, resolver_clsid
  FROM [sysmergeextendedarticlesview] WHERE article_resolver like '%Later Wins%'
  GO
 SELECT article_resolver, resolver_clsid
  FROM [sysmergepartitioninfoview] WHERE article_resolver like '%Later Wins%'
  GO

したがって、ディストリビューション データベースの参照または出版データベースの参照のいずれかを更新する必要があるようです。やるだけやってみよう！

于 2012-06-20T14:20:06.213 に答える