取敢えず、何も指定しないデータベースのパスのみだと

2022/04/28 10:23:07 出走別着度数(2,445) [2022/03] >> Done! ...79.2959801秒
2022/04/28 10:24:26 出走別着度数(1,276) [2022/03] >> Done! ...41.2450401秒

PRAGMA TEMP_STORE = MEMORY;

2022/04/28 10:29:22 出走別着度数(2,445) [2022/03] >> Done! ...80.8131174秒
2022/04/28 10:30:42 出走別着度数(1,276) [2022/03] >> Done! ...41.9937788秒

PRAGMA JOURNAL_MODE = WAL;

2022/04/28 10:34:43 出走別着度数(2,445) [2022/03] >> Done! ...80.604067秒
2022/04/28 10:36:03 出走別着度数(1,276) [2022/03] >> Done! ...41.9658116秒

PRAGMA JOURNAL_MODE = OFF;

SQLite error (5): statement aborts at 1: [PRAGMA JOURNAL_MODE = OFF;] database is locked

PRAGMA JOURNAL_MODE = MEMORY;

SQLite error (5): statement aborts at 1: [PRAGMA JOURNAL_MODE = MEMORY;] database is locked

PRAGMA SYNCHRONOUS = OFF;

2022/04/28 10:46:05 出走別着度数(2,445) [2022/03] >> Done! ...81.065699秒
2022/04/28 10:47:26 出走別着度数(1,276) [2022/03] >> Done! ...42.1620051秒

PRAGMA LOCKING_MODE = EXCLUSIVE;

ちと、JOURNAL_MODE = OFF | MEMORY の場合はVisual Studioの出力タグに延々と上のメッセージが出るので強制終了させてるんですが、これは例外で止まる。しかも、随分と待たされた後にトランザクション開始で起きる^^;

PRAGMA MMAP_SIZE = 30000000000;

2022/04/28 11:01:39 出走別着度数(2,445) [2022/03] >> Done! ...78.8158052秒
2022/04/28 11:02:58 出走別着度数(1,276) [2022/03] >> Done! ...41.0700406秒

PRAGMA CACHE_SIZE = 500;

2022/04/28 11:15:15 出走別着度数(2,445) [2022/03] >> Done! ...80.738003秒
2022/04/28 11:16:36 出走別着度数(1,276) [2022/03] >> Done! ...42.4018137秒

PRAGMA PAGE_SIZE = 32768;

2022/04/28 11:19:52 出走別着度数(2,445) [2022/03] >> Done! ...80.382808秒
2022/04/28 11:21:12 出走別着度数(1,276) [2022/03] >> Done! ...41.6193615秒

個別指定ではどれも誤差レベルなんだけど、MMAP_SIZEだけ若干って感じ。これらをどんな感じで組み合わせると良くなるのか、それともエラーにならないもの全てなのか、database is lockedを解消して効果絶大ってLOCKING_MODE辺りを入れれる様にしなきゃなのかGW使って調べるかなぁorz

そもそも、データベースのパスだけしか指定はしてなかったんですが、あちこちで接続文字列で色々指定するとパフォーマンスが上がるって事で試してるんですがなかなか上手く行きません。

PRAGMA LOCKING_MODE = EXCLUSIVE;

DB Browser for SQLiteではエラー無く実行出来ましたってなるのは確認済みですが、これを指定すると

database is locked

ってなります。これ、

PRAGMA JOURNAL_MODE = MEMORY;

してもなるんだよね^^;データベースがロックされたのを解除するとかの話もいくつか見ましたが、な～んか違うんだよな。

PRAGMA SYNCHRONOUS = OFF;
PRAGMA JOURNAL_MODE = WAL;

の２つでもパフォーマンスが上がるって話も見かけましたが、今回の僕のデータベースには効果無しです。しばらく色々試してみる必要がありそうです。

本日32GBx2枚が届いたので早速PCに組込後、試してみるがメモリ不足は解消されているが速度は全く変わらずでした。OSで64GB認識されているので問題ないとは思うけど、まあ、そのうちにOSのインストールからやり直してみるかもですが、SQLiteの処理が遅いのはもう手詰まりorz 接続文字列も色々と試しましたが変化なし。

ちと、出来る範囲のシェイプアップはしてみるつもりなのと、根本的にシンプルなループで回せる事と沢山の引数連れた飛び回りを減らしてみるしかないかな～っと。現在は取り込んでいるデータをステータスバーに表示してるんですが、試しに表示無しにすると８１秒が７６秒とか５秒短縮されてましたが、これは対価として７６秒間ひたすらプログレスバーが伸びるの見るだけなんですよね。まあ、1か月分のデータ取込で７秒程度短縮されると８４秒/年で、１８年だと２５分の短縮なのは大きいとみるべきなのか。９時間が８時間半ちょいは十分とみるのか本当に微妙です。まあでも、そんな感じでシェイプアップ進めるしかないですね。

追記 2022.4.27
64GB積んだ状態でもメモリリソース不足は出ました。

PRAGMA MMAP_SIZE = 30000000000;

が原因だと思うけど、これ単純に30GBって事なのかな?う～ん、わからないorz

SQLiteの接続文字列で色々やってたんですが、一向に早くならなくて半ば諦めムードだったんですが、昨夜のフルセットアップでVisual Studioへの出力にふと目をやると

SQLite error (6154): os_win.c:46881: (8) winMapfile2(E:CS ProjectKSDKSD_DB.db) - このコマンドを処理するにはメモリ リソースが足りません。

と山の様にメッセージが出てる事に気が付く。今まではSQLiteConnectionStringBuilderの設定で色々と試してたんですがコネクションオープン後に地味に１つ１つPRAGMA叩く事に変更してたんです。

            using (SQLiteCommand cmd = con.CreateCommand())
            {
                cmd.CommandText = "PRAGMA JOURNAL_MODE = WAL;";
                cmd.ExecuteNonQuery();
                cmd.CommandText = "PRAGMA SYNCHRONOUS = OFF;";
                cmd.ExecuteNonQuery();
                cmd.CommandText = "PRAGMA TEMP_STORE = MEMORY;";
                cmd.ExecuteNonQuery();
                cmd.CommandText = "PRAGMA MMAP_SIZE = 30000000000;";
                cmd.ExecuteNonQuery();
            }

で、出力されてたのが今回のエラーなんです。そもそも、今のPCは3年前位に組んでるんですが、見積もりしてもらった時には16GBx2枚でしたが、いざ購入って日に在庫切れorz お盆休み利用しての購入で入荷待つ気にはなれず8GBx2枚で妥協したのが今となって仇になった感じです。

まあ、これは仕方ないと朝から16GBx2枚を検討し探してみるとまあ1万5千円前後な感じで、仕方ないかな～っと眺めながら、数か月前にもメモリ増やそうかな～って探してた時にコロナの影響からの半導体不足で買い時じゃないな～って諦めてた時にも確か3万円以上での記憶があったんですが、Amazonにてタイムセールで32GBx2枚が3万円以下を発見!!! 大分予算オーバーだけど、明日届くって事で即決して発注しちゃいました。

Team DDR4 2666Mhz PC4-21300 32GBx2枚（64GBkit） デスクトップ用メモリ Elite Plus シリーズ 日本国内無期限保証 正規品

データベースのノウハウ不足は否めません。日々勉強になる事が沢山あります。今回はデータベースの基本操作の登録・更新・削除で新しい機能っていうのか方法がある事を知りました。

これまでSQLite3では基本INSERTは高速で更新とか遅いって話は知っていて、該当データの存在チェックはせずに登録処理をtryで失敗時にcatchして更新かけるコーディングしてたんですが、INSERT INTO ～ ON CONFLICT() DO UPDATE ～ってまあ、コーディングしてた事をSQL文記述で行う変更をしました。これ、このUPDATE側のSETでは、INSERT側で指定したパラメータをそのまま使うEXCLUDED使う事で、今までINSERTするのにパラメータ用意して、更新時にもパラメータ用意と2度しなければならなかったのも1回で済むってのもありがたい。

前回書き込み時に触れた接続文字列は直接指定する事で効いてるかは不明だが、エラーにはなってないので、フルセットアップに再挑戦中。ただ、これ自体では然程スピードが改善されてる感じは部分テストしてみた時にはなかった。少しでも改善されていれば、日付変わる前にフルセットアップが終わると嬉しいかも。

追記 2022.4.17
まだバグが残ってたので修正してフルセットアップやり直しですorz