0

データベースが少し乱雑な状況になっています。

私たちのメインのバックオフィス システムは、ローカル データを使用して Visual Fox Pro で作成されています (はい、知っています!)。

ウェブサイトのデータを効果的に扱うために、定期的にデータを SQL データベースにエクスポートすることを選択しました。ただし、これを行うプロセスでは、基本的に毎回テーブルがクリアされ、再挿入が行われます。

これは、2 つの SQL データベースがあることを意味します。1 つは FoxPro エクスポート プロセスが書き込むデータベースで、もう 1 つは Web サイトが読み取るデータベースです。

この質問は、ある SQL データベースから別の SQL データベースへの変換に関するものです (SqlFoxProData -> SqlWebData)。

特定のテーブル (メイン アプリケーション テーブルの 1 つ) については、このプロセス中にさまざまなデータ変換が行われるため、自己結合を使用した簡単な UPDATE、INSERT、および DELETE ステートメントではなく、代わりにカーソルを使用する必要があります ( !)

これは何ヶ月もうまく機能していますが、現在、更新が行われているときにパフォーマンスの問題が発生し始めています (これは日中に定期的に発生する可能性があります)。

基本的に、SqlFoxProData.ImportantTable から SqlWebData.ImportantTable を更新しているときに、ライブ Web サイトで接続タイムアウト/デッドロック/その他の問題が発生することがあります。

クエリの最適化、キャッシュなどに懸命に取り組んできましたが、データを更新するための別の戦略を探しているところまで来ました。

頭に浮かんだ 1 つのアイデアは、ImportantTable の 2 つのコピー (A と B) を用意し、どのテーブルが現在「アクティブ」であるかという概念を持ち、非アクティブなテーブルを更新してから、現在のアクティビティ テーブルを切り替えることです。

つまり、ImportantTableB を更新している間に、ImportantTableA から Web サイトを読み取り、その後、ImportantTableB から読み取るように Web サイトを切り替えます。

質問は、これは実現可能であり、良い考えですか? 私は以前にそのようなことをしたことがありますが、最適化/インデックス作成などに必ずしも良いとは確信していません.

任意の提案を歓迎します。これが厄介な状況であることはわかっています...長期的な目標は、FoxPro アプリケーションが SQL を指すようにすることです。

(役立つ場合は、SQL 2005 を使用しています)

データは常に少し古くなっているため、インスタンスではデータの一貫性は特に重要ではないことを付け加えておきます。

4

5 に答える 5

2

この猫の皮を剥ぐ方法はたくさんあります。

最初にロックの問題に取り組みます。私が CURSORS を使用することは非常にまれであり、パフォーマンスとロック動作を改善することで、多くの問題が解決される可能性があると思います。

2 つの別々のステージング テーブルを使用することで解決できると思います。1 つは SQL での FoxPro エクスポート用で、もう 1 つは SQL で最終的な形式に変換されたものです。次に、sp_rename を使用して本番用のファイナルをスワップするか、単純に 3 つの INSERT/UPDATE/DELETE トランザクションを使用してファイナル テーブルから本番用のすべての変更を適用します。いずれにせよ、そこにはいくつかのロックが発生しますが、どのくらいの大きさについて話しているのでしょうか?

于 2009-01-27T14:50:29.637 に答える
1

Web サイト用に 1 つのデータベースを維持し、他の SQL データベース テーブルからそのテーブルにレプリケートするだけでよいはずです。

これは、Web サイト自体からデータを更新しないことを前提としています。

于 2009-01-27T13:39:25.863 に答える
1

「特定のテーブル (メイン アプリケーション テーブルの 1 つ) については、このプロセス中にさまざまなデータ変換が行われるため、自己結合を使用した簡単な UPDATE、INSERT、および DELETE ステートメントではなく、代わりにカーソルを使用する必要があります (私は知る！）"

カーソルを使用して挿入、更新、または削除を実行する必要があるケースは考えられません。カーソルの選択を記述できる場合は、それを挿入、更新、または削除に変換できます。これらのステートメントで他のテーブルに結合し、条件付き処理に case ステートメントを使用できます。set ベースの方法でこれを行うのに時間をかけると、問題が解決する場合があります。

移動するデータが大量にある場合に考慮すべきことの 1 つです。必要なデータのビューを時折作成し、2 つのテーブルを作成します。1 つはアクティブで、もう 1 つはデータがロードされるテーブルです。データのロードが終了したら、プロセスの一部として、ビューが使用するテーブルをロードを終了したテーブルに切り替える単純なコマンドを実行します。そうすれば、ユーザーはせいぜい数秒しかダウンしません。読み込み中にデータにアクセスしようとするロックの問題は発生しません。

SSIS を使用してデータを移動することも検討してください。

于 2009-01-27T16:15:17.983 に答える
0

上記のErnieへの回答に基づいて、データベースを複製する方法を尋ねました。これは、SQL2005でのレプリケーションに関するMicrosoftのハウツーです。

ただし、レプリケーションとその方法について質問している場合は、SQLサーバーの経験が少し少ないことを示しています。そうは言っても、物事を台無しにするのはかなり簡単です。私はすべて経験から学ぶことができますが、これがミッションクリティカルなデータである場合は、DBAを雇うか、少なくとも＃$ @＃$をテストする方がよいでしょう。実際に実装する前に、これから％。

于 2009-01-27T14:57:11.587 に答える
0

更新を「クリアして再挿入」するのではなく、よりアトミックにするオプションはありますか? Visual Fox Pro はトリガーをサポートしていると思いますよね? キー テーブルについて、更新/挿入/削除にトリガーを追加して、変更されたレコードの ID を取得し、それらのレコードだけを移動 (または削除) できますか?

または、すべての変更をオフライン データベースに書き込み、SQL Server のレプリケーションに同期を任せてみませんか?

[申し訳ありませんが、十分な評判があれば、これはコメントでした!]

于 2009-01-27T13:49:52.440 に答える