1

少しアドバイスを求めています。

いくつかのローカル プロダクション タスクのために、ローカル Access データベースに移動する必要がある SQL Server テーブルがいくつかあります。「ジョブ」セットアップごとに 1 回、この四半期に 400 ジョブで、12 人のユーザーにわたって...

少し背景:

  1. 現在、配布の問題を回避するために DSN を使用しないアプローチを使用しています

  2. リモート テーブルへの一時的なリンクを作成し、「テーブル作成」クエリを実行してローカル テーブルにデータを入力してから、リモート テーブルを削除できます。期待どおりに動作します。

  3. ここ米国でのパフォーマンスはまずまずです - ~40K レコードで 10 秒から 15 秒です。当社のインド チームは、同じデータセットで 5 ～ 10 分を超えています。彼らのインターネット接続はまともですが、良くはなく、私が制御できない変数です.

  4. より直接的なアプローチで回避できるよりも、MS Access がここでオーバーヘッドを追加しているのかどうか疑問に思っています。

私はさまざまな組み合わせをいじりましたが、明確な改善や成功はありません:

  • Access のパラメーター化されたストアド プロシージャ
  • Access からの SQL パススルー クエリ
  • ADO 対 DAO

提案、または提案する全体的なアプローチはありますか? データを XML として移動するのはどうですか?

注: Access 7、10、13 のユーザーがいます。

ありがとう！

4

2 に答える 2

0

完全に明確ではありませんが、ダンプを実行する MSAccess データベースがローカルにあり、SQL Server データベースがインターネットを介してリモートにある場合、接続の物理的な制限にぶつかることになります。

ODBC ドライバーは、LAN を超えたデータ アクセスに使用するためのものではありません。遅延が大きすぎます。Access がデータを照会すると、ストリームが開かれず、そのブロックがフェッチされ、データがダウンロードされるのを待ってから、別のバッチが要求されます。これは LAN では問題ありませんが、特に米国とインドの間の通信にはおそらく約 200 ミリ秒の遅延があり、通信プロトコルがおしゃべりである場合は非常に急速に加算されるため、多くのことを行うことができないと考えると、長距離では急速に低下します。 、これらすべてが接続の帯域幅の上にあり、LANで得られる帯域幅よりもはるかに低い可能性があります.

より良い解決策は、ダンプをローカルで実行し、結果の Access ファイルを圧縮して圧縮した後に送信することです (たとえば、より良い圧縮のために 7z を使用します)。これにより、数秒で簡単に移動できる非常に小さなファイルが作成される可能性が高くなります。

このプロセスは簡単に自動化できます。最も簡単な方法は、このダンプを毎日自動的に実行し、FTP サーバーまたはダウンロード可能な内部 Web サイトで利用できるようにすることです。

サーバー上で実行されているアプリを介して、Windows 2008 サーバー上の RDP サービスを使用して RemoteApp を介して、または単純に Web サイトまたはシェルを介して、オンデマンドで利用可能にすることもできます。
また、ローカル マシンにインストールされているリモート クライアントの要求をリッスンする SQL Server に単純な Windows サービスを配置することもできます。これは、ダンプを処理してクライアントに送信し、クライアントはそれを解凍して、以前にダウンロードしたデータベースを置き換えます。

確実に自動化するにはある程度の作業が必要になる可能性がありますが、これには多くのソリューションがあります。

最後に、SQL Server から Access へのデータ ダンプを自動化する場合は、自動化された方法で Access を使用しないようにしてください。デバッグが難しく、壊すのは非常に簡単です。代わりに、Access のインストールに依存しないエクスポート ツールを使用してください。

于 2013-08-27T01:46:47.027 に答える
0

Renaud をはじめとする皆様、お時間を割いてご回答いただきありがとうございます。ご指摘のとおり、インターネット全体のパフォーマンスがボトルネックです。データのブロックのフェッチ (vs 連続 DL) は、まさに私が別のアプローチで避けたいと思っていたものです。

または、ワークフローが進化して、米国の User1 がローカル DB で 1 日の作業を完了し、(タイムスタンプに基づいて) 更新のみをサーバーに送信するという、クロックの両側をより有効に活用するようになっています。インドのユーザー 2 も同じ DB のローカル コピーを持っており、1 日の開始時にサーバーから更新されたレコードだけを取得します。そのため、日常的な作業にはかなり効率的です。

主な問題は、現在の「ジョブ」のサーバー (巨大な複数年 DB) からのローカル DB テーブルの最初の DL です - 作業の開始時に一度だけ発生する必要があります (約 1 週間のプロセス) これは作品ですインドが達成するのに 5 ～ 10 分かかります。

現在、DB を FTP 経由で毎日移動しています。これは単一の共有 DB として使用され、一時テーブルのために少し大きいです。毎日の変更だけの新しいタイムスタンプベースのプッシュプルが全体的にプラスになることを望んでいました. と思われますが、初期DLのハードルが残っています。

于 2013-08-27T12:01:42.927 に答える