中央競馬の予想や購入したもののメモなどを書いて行こうかと。まあ、個人的なメモ的なブログです。
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
昨日行ったフルセットアップは結局金曜日の夜は修正のみで一旦終了し、土曜日の朝から追加修正して開始。終わったのは日付回って今日午前0時過ぎでした。14時間43分とか掛かってまして、やはり62ギガバイトとかの巨大なDBファイルとなりました。追加のアップデートデータも入れ込んだ後に最適化すると、ギリ60ギガバイト切りました(笑) で、追加作業してたんですが、ある表示をするのに数分とか掛かる事が分かりました。最初は何かハングでもするミスコーディングでもしたのかと思い、一旦PCから離れて戻ると表示はされてたんですが、これでは使い物にならない様な^^; DB最適化もアプリ固まる状態で3時間強だったかな。
どう考えても、この巨大DBファイルは現実的ではないよな~っと。で、分割する事にします。4分割綺麗に15ギガバイトずつにはならないとは思うが、4分割してみようかと。エンティティ定義を大きなテーブルを別々のコンテキストにすれば良いだけだと信じて、作業してみます。分割後に再度フルセットアップして、その時間。最適化の時間。で、問題の表示時間等がどの程度短縮されるか楽しみに作業進めてみます^^
追記 2022/2/6 22:10
簡単には4分割出来ないと判断して、取敢えず3分割に。大きくなりそうなテーブル3つを別コンテキストにするんですが、2つは関連があるので、この2つを別コンテキスト、更に巨大になっていると思われる1つのテーブルを別コンテキストという感じにして、プロジェクト内に3つのコンテキストが存在する事になりました。
ここで、今まで同様にAdd-Migration xxxとUpdate-Databaseをしようとするが
More than one DbContext was found. Specify which one to use. Use the '-Context' parameter for PowerShell commands and the '--context' parameter for dotnet commands.
とか言われて処理されない^^; グーグル先生に確認すると
Add-Migration xxx -Context context1
Update-Database -Context context1
Add-Migration xxx -Context context2
Update-Database -Context context2
って感じでオプションパラメーターで指定する必要がある事が分かった。今回はもう1回の計3セットする必要があった訳だが、それを済ませてフルセットアップ開始してみた。フルセットアップは時短されないとすると明日の昼過ぎに終わるかな^^;
追記 2022/2/7 9:22
今もフルセットアップ中なんですが、エクスプローラでDBサイズ確認すると既にメインDBは45ギガバイトorz 余りダイエット出来てない様です。これでは期待薄なので、一応終了までは今回の結果確定用に続け、午後終了後に当初の計画通り4分割処理してみようかと。これすればメインDBのダイエットはもう少し効果あるんじゃないかと思うので、それから効果確認してみようかと思います。
追記 2022/2/7 12:37
やっとフルセットアップ完了。14時間19分で、24分程度短縮された^^; 最適化前にメインDBは58ギガバイトと少しスリムになりましたが、まあ、確かに分けたコンテキストは3ギガバイトと1ギガバイトで3ギガバイトの方が単一テーブルなので、確かに巨大テーブルで分離したのは良かったのかもですが、効果自体は期待出来ないかも。なので、分割作業進めてみる。
追記 2022/2/7 13:50
分割作業は結局6分割まで進めてみた。これで実用的じゃなかったらっとか考えたくもないが、分割後のフルセットアップ開始はしたので、明日の明け方に終わるのかな~^^; 分割ダイエットによるセットアップ時間の短縮はそれ程期待は出来ないとは思う。例の1テーブルで3ギガバイトなコンテキストは1年分のデータ登録に40分程度掛かる感じなのは把握した。これ、確か2004年頃から提供されているので、ここまで18年分とかある訳で、これだけでも12時間掛かる計算ですorz ってか、逆に言えば、これ見捨てれば2時間程度で終わるのか^^ 今回の作業終わったら、しばらくこのモンスター除外して諸々進めるのか吉かな。
追記 2022/2/8 14:30
今日早朝にセットアップが終わってたんですが、痛恨のポカミスorz コンテキスト移動してるのに古いままのアクセスしようとしてのエラーで終了とか。まあ、本当の終わりの部分だったので14時間24分とかだった模様で分割での時短はもう無い感じですかね。問題の修正も終えて朝再トライ掛けようとするがエラーが出るとか...データ提供元がメンテに入ってたので、強制的に休憩w その間にも出来る修正はしてみました。しかし、こんなメンテも本来なら一般ユーザーの影響が少ない夜中に行う感じなのに普通に昼間に行う辺りが、親方日の丸ってな感じなのがね~^^;
まあ、分割は大体成功してる感じで、予想通り巨大なテーブルは頻繁にアクセスするテーブルとは分離出来、まあ、その分離した側が50ギガバイト超えとか^^; 今回はフルセットアップ中にエラーが出での終了だったので、全DB削除してますので、サーバーメンテ終了したら、テスト的なセットアップして動作確認後に今晩再度フルセットアップして寝る感じになるのかなぁっと。
前々から文字列として提供されたデータを数値化する際にエラーになるものがあり、対処はしてきたつもりでしたが、日付データとしてタイトル通りの"0000/00/00"は確かに存在しない日付としてエラーになる。日付データとして提供してるんなら、何らかの意味のある日付にして欲しい所ですが、具体的な日付が無い場合の対処として、プログラム組んでいると、最小値とか最大値にしたり、逃げ方は色々あるかとは思いますが、今回のこのゼロのオンパレードも考え方としては有かもしれませんが、マイクロソフトのDateTime.ParseではNGです。で、このエラートラップが必要になりました。
他の型の文字列→数値にはそれなりに関数作ってエラートラップしたものにしてましたが、日付型も新たに作り対応する事にしました。DateTime.MinValueがエラー時には適用される様にしてみました。
ってな訳で、フルセットアップを中断して再スタートしたので、明日の朝8時過ぎに終わるのかな~っと。これ、前回のフルセットアップでも見掛けたエラーだったんですが、諸々やってたら出なくてスルーしてたので、まあ、怪我の功名的な感じかも^^;
昨年末から続く身体的な問題。2週間程前にやっと退院したと思ったんですが、先週末に仕事中に腹部にまた異変があり、週明け月曜日に病院に行くと、昨年末の右鼠径ヘルニアよりも若干下になる右大腿ヘルニアとの診断で、水曜日に再手術となり、まあ、本日無事に退院して来ました^^;
入院前から始めていた新たな機能の処理などを巡り、データベース設計時点で不要かと思われた項目が必要だと判断しました。これ、大規模な開発とかで、データベース設計への変更が有った場合、単にエンティティの修正してUpdate-Databaseすれば、データベース自体には、今回の場合だと項目の追加になったので、それが反映されるのかな?ちと軽い気持ちで試す気になれなく、まあ、仮にデータベースに項目が追加されたとしても、その追加された項目だけを反映させるコーディングもしなきゃと思うと無駄に思えたので、60ギガバイトのDBファイルを潔く削除してデータのフルセットアップを開始しました。14、5時間なので明日の朝方には終わっている筈かな。
今後の開発進めていくのにも、今回の様な根本的な変更が無いとも言えないけど、まあ、無い様に進める方向で考える様にしなきゃとは思う。提供元からのデータ保存用のDBなので、アプリ側での個別データは別のデータベースを使う方向にすれば問題ないかな~っと安易に開発進めるんだけど、数人で行うプロジェクトとかではそうは行かないとは思うけど、自分一人でやってる事だから頭の中で上手く整理しながらやろうかと^^
C#だろうとVBだろうと、まあ、そもそもSQLは素人レベルだけど、なんとなくだけど、ここまで40年以上プログラミングしてたりすると、ある程度予測が出来たりしてイメージして、それをLINQ的に書いてみたりしてるんですが、LINQにはクエリ式とメソッド式があるんだと。で、最初はクエリ式で
var races = from i in db.RaceInfo
orderby i.year descending, i.month descending, i.day descending
select i;
って感じで書いてたんですが、メソッド式で
var races = db.RaceInfo
.OrderByDescending(i => i.year)
.OrderByDescending(i => i.month)
.OrderByDescending(i => i.day)
.ToArray();
にしてみたんですが、上手くソートされない。よくよく調べると、
var races = db.RaceInfo
.OrderByDescending(i => i.year)
.ThenByDescending(i => i.month)
.ThenByDescending(i => i.day)
.ToArray();
としなければならない事が分かった。LINQには更にLINQ to EntitiesとLINQ to Objectがあるんだと。で、更に今回の用途では読込のみで更新なんかはしないので
var races = db.RaceInfo
.OrderByDescending(i => i.year)
.ThenByDescending(i => i.month)
.ThenByDescending(i => i.day)
.AsNoTracking()
.ToArray();
としてやると、かなりスピードアップしました。これするには、今回のプロジェクトではusing Microsoft.EntityFrameworkCore;の追加が必要でした。自分の使っているEntityFrameworkの参照を有効にする必要があるって事の様です。
今週月曜日に人生初の大腸カメラの予約をしてたんですが、病院の指示通りに前日日曜日には3食指定の食事をし、下剤を服用して就寝し、決められた時間に病院の指定場所に入り、2時間掛けてニフレック2リットルを飲みきってまあ、実際には空腹でハイペースで飲んでしまい1時間半程度でしたが^^; 腸内のモノを出し切り、順番待ち。思いの外待たされ、ようやく自分の番が回ってきて検査が始まり眠りにつく。
で、検査終了で起こされ、「大きなのと小さなポリープが有ったので取りました。1週間程入院になります。」と、突然の宣告orz 会社にその旨連絡し、迎えに来る予定の妻には入院になったのでスマホの充電器だけはお願いした。火曜日夜までは点滴のみの寂しい入院生活。先月に続く入院だし、節約しやきゃだが大部屋の空きが無く個室に。初日は8,000円と案内されるが翌朝ここは12,000円の部屋だけど案内ミスなので8,000円でいいですって今度は本当の8,000円の個室に。違いはトイレにシャワーがついているか否かでした。3日目水曜日には大部屋っといっても、前回入院時は4人部屋でしたが2人部屋。ここまでの個室で夜間も夜な夜なゲームしたり、テレビもスマホで"どこでもディーガ"アプリで音出して視聴したりとなかなか有意義に過ごせただけに移動に躊躇したけど、節約は必要なので我慢。しかも、水曜日午後には1週間程度と言われてたのに、担当医師が来て「明日退院する?」って言われ、逆に「大丈夫ですか?」と確認すると「まあ、心配だったら明後日金曜日に退院にしようか」って事で本日無事に退院して来ました。67,620円となりました。この内、16,000円は個室代なので本来5万円程度だった様です。
で、本題ですが、入院少し前に気が付いたんですが、Preview版から正規のVisual Studio 2022 Version 17.0.5にしてからだと思うんですが、C#のバージョンが10になっているのに気が付き、実はマイクロソフトのラウンチイベ以降に諸々知った情報でPreviewの段階でも試してたんですが、結果的にはNG(コンパイルエラー)だったんですが、C#お決まりの、namespace xxx {}の括りが、先頭にnamespace xxx;で済み、インデントが1つ減らせる的なのを再度試しました。
Previewでこの言語バージョンがどうだったか今更確認は出来ませんが、仕様通りにコンパイルも通りインデントを1段減らす事が出来ました。