2

現在のデータベースの「スナップショット」を取得し、新しい主キーを使用して同じデータベースに複製する必要があります。

問題のスキーマは約 10 個のテーブルで構成されていますが、一部のテーブルには、複製が必要な数十万から 100 万のレコードが含まれる可能性があります。

ここでのオプションは何ですか?

残念ながら、SPROC を作成するには、操作の全期間にわたって問題のデータベース行を (同時実行のために) ロックする必要があり、これは他のユーザーにとって非常に迷惑です。sqlserver が許可する最大限の範囲で最適化できると仮定すると、そのような操作にはどれくらいの時間がかかりますか? これだけ挿入するのに 30 秒から 1 分かかりますか? 同じテーブルを個別に使用している他のアカウントの下に他のユーザーがいるため、テーブル全体をロックして一括挿入を行うことができません。

期待されるパフォーマンスに応じて、現在のデータベースを xml ファイルにダンプし、バックグラウンドで暇なときにこの xml ファイルからデータベースを非同期的に複製することもできます。これの明らかな利点は、db が xml ダンプの実行にかかる時間だけロックされ、挿入をバックグラウンドで実行できることです。

優れた DBA が「複製」操作を最初から最後まで 10 秒以内に実行できる場合、xmldump/webservice ソリューションの複雑さに見合う価値はないでしょう。しかし、それが失われた原因であり、数百万行を挿入する可能性があり、時間内に膨れ上がる可能性がある場合は、xml アプローチからすぐに開始したいと思います。

それとも、完全に優れたアプローチがあるのでしょうか??

あなたが提供できる洞察に感謝します。

4

2 に答える 2

1

データベースをバックアップしてから、サーバー上で新しいデータベースとして復元することをお勧めします。その新しい DB をソースとして使用できます。私は絶対にxmlダンプのアイデアに反対することをお勧めします..

于 2009-11-18T22:22:50.840 に答える
0

まったく同じテーブルにある必要がありますか? これらすべてのレコードが入る一連の「スナップショット」テーブルを作成できます。次のように、単一の挿入と選択のみが必要です。

insert into snapshots_source1 (user,col1, col2, ..., colN) 
select 'john', col1, col2, ..., colN from source1

等々。

snapshots_*「新しい PK」を作成し、必要に応じて古いものも保存できる IDENTITY 列を作成できます。

これには (ほとんど) ロックの問題がなく、見た目もかなり良くなっています。

コードを変更する必要がありますが、必要に応じてスナップショット テーブルを指すようにアプリを作成するのは難しくありません。

これにより、クリーニングとメンテナンスの問題も軽減されます

---8<------8<------8<---outdated answer---8<---8<------8<------8<------8<---

ライブ バックアップを取り、コピー先のクローンでデータ操作 (キーの変更) を行ってみませんか?

さて、一般的に、新しい主キーのアイデアを使用したこのスナップショットは疑わしいように思えます。レプリカが必要な場合は、ログ配布とクラスター サービスが必要です。データのコピーで「新しいアプリ インスタンス」を生成する必要がある場合は、バックアップ/復元/操作プロセスで十分です。

DBがどれだけ占有するかはわかりませんが、ディスクサブシステムの速度にもよりますが、約10秒で2000万行（800MB？）をバックアップできます...

于 2009-11-18T22:26:16.507 に答える