C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[13]: Adapter.Fill実行1回目が遅い [1]


(過去ログ 172 を表示中)
掲示板トップ C# と VB.NET 入門 新規作成 利用方法/規約 トピック表示 ランキング 記事検索 過去ログ

[トピック内 24 記事 (21 - 24 表示)]　 << 0 | 1 >>

■99166 / inTopicNo.21) 　Re[11]: Adapter.Fill実行1回目が遅い
  ▼■
□投稿者/ 大谷刑部 (174回)-(2022/02/14(Mon) 13:30:51)
■No99147 (ど さん) に返信
> テーブルのデータを空っぽにしても結果は同じです。Indexも張っています。
>
> C以外にも、Dドライブ直下、D:\testフォルダ、ネットワークフォルダなど全部試しましたが結果は１回目が
> 遅く２回目以降は速いです。これらのファイルは絶対パスで指定います。
>
> ちなみに.Net Frameworkのバージョンは4.7.2になります。
>
> OleDbConnection nwindConn = new OleDbConnection(connectionString="Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C\:test\mydb.accdb");
>
> nwindConn.Open();
> OleDbConnection nwindTransaction = nwindConn.BeginTransaction(IsolationLevel.ReadCommitted);
>
> OleDbCommand selectCMD = new OleDbCommand("SELECT CustomerID, CompanyName FROM Customers", nwindConn);

上記のコードの通りだとするとwhere句がないのでインデックスはほぼ関係ないと思います。
OracleとかSQLserverでヒント句にインデックスを指定すれば強制的にインデックスを使用させるのは可能ですが、
全件取得であれば、オプティマイザが全表検索を選択することはあり得るので。
ましてやAccessなら、ヒント句は確かなかったと思うので、(主キー以外の)インデックスを張ってもほぼ無意味です。

ちなみに実運用上通常何件くらいですか？
ゼロ件でも遅いとあるので件数の問題ではないかもしれませんが、
取得する項目がIDと名称だけだとすると、如何にAccessと言えども数千、数万程度で結合もしてない単純なselect文でそんなに時間が要することは考えにくいです。
引用返信 編集キー/
■99171 / inTopicNo.22) 　Re[12]: Adapter.Fill実行1回目が遅い
▲▼■
□投稿者/ 古谷 (31回)-(2022/02/15(Tue) 11:02:38)
こういう場合正当なやり方としてはプロファイラで何に時間がかかってるか調べるのがいんでしょうけどね
CPUがブリブリ動いてるのかIO待ちで時間がかかってるのか調べるプロファイラがきっとどこかにあるはず
引用返信 編集キー/
■99172 / inTopicNo.23) 　Re[12]: Adapter.Fill実行1回目が遅い
▲▼■
□投稿者/ 魔界の仮面弁士 (3294回)-(2022/02/15(Tue) 12:11:29)
■No99149 (魔界の仮面弁士) に追記
>>コードをはしおってしまって申し訳ないです。
>>OleDbConnection nwindConn = new OleDbConnection(connectionString="Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C\:test\mydb.accdb");
> これ、そもそも構文エラーになりません?
「C:\test」じゃなくて「C\:test」になっているし、
そもそも @"〜\mydb.accdb" や "〜\\mydb.accdb" ではなく "〜\mydb.accdb" はエラーになるはず。

引数で connectionString への代入を同時に行っているのも不自然すぎます。

>> OleDbConnection nwindTransaction = nwindConn.BeginTransaction(IsolationLevel.ReadCommitted);
> パスだけでなく、トランザクション処理もなんだか不自然…。
右辺が返すオブジェクトは OleDbTransaction 型なのに、
左辺に用意された変数は OleDbConnection 型な点がちぐはぐ。

No99148 で古谷さんが指摘された点もありますし、何よりも
selectCMD の Transaction プロパティが設定されていないので、
これを実行しているというのであれば、下記のエラーになっているはず。
|
| System.InvalidOperationException:
| 　ExecuteReader は、コマンドに割り当てられた接続が保留状態であるローカルの
| 　トランザクションにあるとき、トランザクション オブジェクトを持つコマンドが必要です。
| 　コマンドの Transaction プロパティがまだ初期化されていません。
|

結局のところ、「掲示板で質問している内容」と「実際に試しているコード」の内容が
乖離しているので、第三者が検証しようがありません。

＜実際に動作する最低限のソースコード＞と
＜現象を発生させてしまう検証用の .accdb ファイル＞を提示できませんか?



あとは、ACE / Jet Red の制御の及ばない【外部要因】の可能性もあります。
よく挙げられるのは LAN のトラフィック、同一マシンで同時に実行されている他のプロセス、ディスクの断片化など。

.mdb や .accdb において、クエリーの最適化やレジストリ設定の調整での影響を測る場合には、
　(1) ISAMSTATS
　(2) showplan.out
によるログ解析が使われることがあります。
http://hanatyan.sakura.ne.jp/logbbs/wforum.cgi?no=5649&reno=5647&oya=5447&mode=msgview
https://social.msdn.microsoft.com/Forums/office/en-US/b786a029-fa8c-4556-a40c-e749ba73499e/jetshowplan-in-access2013

前者は、ディスクの入出力、ロック、キャッシュなどの状況を調べためのもの、
後者は、コストベースのクエリー最適化プランのコンパイルログ。

【外部要因】の影響を受けて処理時間が異なる場合でも、読み取りや書き込みの回数は
一般的に同じになるので、プログラムの影響なのか、環境の問題なのかを比較するための指針となります。


ただ現状は、初回のみ遅いという事象であることから、外部要因というよりは、
何か別の見落としがあるような予感がしています。

たとえば、初回接続と 2 回目以降で時間が変わってしまうという事から、
二回目以降の検証時に、同じ .accdb への既存接続が残留していたりはしないでしょうか。
(初回接続を切断しきれていなかったとか、Access やその他のデータツールで同時に開いていたりとか)
引用返信 編集キー/
■99173 / inTopicNo.24) 　Re[13]: Adapter.Fill実行1回目が遅い
▲▼■
□投稿者/ くま (162回)-(2022/02/15(Tue) 18:14:56)
一応だけど
Accessのファイルが2GB超えてないですよね？
あと最適化はされていますか？
引用返信 編集キー/

＜前の20件
トピック内ページ移動 / << 0 | 1 >>

このトピックに書きこむ

過去ログには書き込み不可

管理者用

- Child Tree -