0

データを使用する他のアプリケーションとの互換性のために使用される MySQL データベースに同期する目的で、UniVerse データベースにアクセスし、その中のすべてのレコードを読み取ります。一部のテーブルは 250,000 レコードを超え、100 列を超えています。サーバーはかなり古く、まだ多くの同時ユーザーが使用しているため、レコードを読み取るのに非常に...長い...時間がかかる場合があります。

例: SSELECT <file> TO 0 を実行して選択リストの読み取りを開始し、各レコードをデータ抽象化タイプに解析して .NET リストに入れます。データベースの使用状況によっては、各レコードの取得に 250 ミリ秒から 3/4 秒かかる場合があります。UniFile.read を使用していなくても、呼び出したときにとにかくすべてのレコード情報をダウンロードすると思うので、抽出のメソッドを削除してもわずかに速度が上がります。

この速度で 250,000 レコードを読み取るのは法外に遅いので、これを高速化する方法を知っている人はいますか? どこかに設定する必要があるオプションはありますか？

4

2 に答える 2

1

本当に SSELECT (ソート済み選択) を使用する必要がありますか? レコード キーでの並べ替えは、追加のパフォーマンス オーバーヘッドを作成します。ソートされた方法で同期する必要がない場合は、単純な SELECT を使用するだけでパフォーマンスが向上します。

これで問題が解決しない場合は、可能であれば、UniVerse システムにログオンしているユーザーがほとんどまたはまったくいないときに、システムの使用率が低いときに同期を自動化して実行してみてください。

それ以外に、エクスポートしているテーブルの一部がサイズ変更を必要としている可能性があります。動的ファイル (自動サイズ変更 - タイプ 30) でない場合は、ディスク上のオーバーフロー スペースに入っている可能性があります。最大のテーブルのサイズを調べ、それらがオーバーフローしているかどうかを確認するには、コマンド ラインで FILE.STAT や HASH.HELP などのコマンドを使用して、詳細情報を取得します。必要な情報を抽出するには、HELP FILE.STAT または HELP HASH.HELP を使用して、これらのコマンドのドキュメントを参照してください。

これらのコマンドでファイルのタイプが 30 であることが示された場合、ファイルはデータベース エンジンによって自動的にサイズ変更されます。ただし、ファイル タイプがタイプ 2 から 18 の場合、HASH.HELP コマンドは、パフォーマンスを向上させるためにテーブル サイズを変更できることを推奨する場合があります。

これが役に立たない場合は、LIST.INDEX TABLENAME ALL を使用してテーブルの有用なインデックスをチェックできます。これを使用すると、選択を高速化できます。

于 2012-06-11T11:45:55.293 に答える
0

ANALYZE-FILE fileName を使用して、ファイルのサイズが正しいことを確認してください。動的でない場合は、オーバーフローが多すぎないことを確認してください。

SSELECT の代わりに SELECT を使用すると、データベースからデータをランダムではなくシーケンシャルに読み取ることになり、大幅に高速になります。

また、各レコードからデータを抽出してリストに入れる方法も調査する必要があります。通常、選択データ区切り文字 254、253、および 252 は外部データベースと互換性がないため、変換する必要があります。これをどのように行うかによって、パフォーマンスに大きな違いが生じる可能性があります。

最初の投稿からは明らかではありませんが、おそらく WRITESEQ がファイル データを出力する最も効率的な方法でしょう。

于 2013-01-15T03:58:27.503 に答える