仕事の備忘録

IT系技術とか、カスタマーサービスとか

第12回 SQL Server 2019勉強会(1st Anniversary) に参加してきた　その１

Microsoft SQL Server

本日SQL Serverの勉強会に参加してきた。

sqlserver.connpass.com

5月にde:code 2018に参加して以来の外部での勉強会となった。その間に仕事で初めてOffice365とPower BI とAzureを使い、最低限のレベルは確保できたがまだまだだと思った次第である。とりあえず最初から【初級者、中級者向け】SQL ServerのAzure移行のいろいろ　までに参加することができた。参加した部分だけではあるが、ブログ書くまでが勉強会なので書く。

【初級者向け】SQL Serverのクエリ実行プランとパフォーマンス -SQL Serverエンジン、インディクスの基礎

今回は初心者向けに基礎テーマを行うとのことでクエリ実行プランの動作を詳細説明。そこでの一言が印象的であった。

SQLは書き方次第で本当にDBの動きを良くも悪くもする。最近どうしてもテーブルを複数結合するためにパフォーマンスが悪くなる仕様があり、1週間ほど悩んでお客様に相談したところ「あれ？数分もかからないはずだけど」という返答を頂いた。弊社親会社もグループ各社もシステム以外のほとんどの方がSQLをかける会社である。SQLをお願いしていただいたら大量のSUM関数をマクロで生み出していて、テーブル結合をせず実施していた。自分の思い込みの設計が誤っていたのだ。その時のことをこの言葉で思い出した。とにかくクエリ実行プランとその内部動作を知るとSQLをもっと早くできるので、勉強しておくべきだと思う。リソース増強より安くて手軽だ。

しかしこの辺りすっかり忘れており、MCP資格を2005の時に取得したのだがやり直しだなと思った次第。

【中級者、上級者向け】SQL Server 2019 最新情報 ReCap

Microsoft MVP - Data Platform Ozawaさんに聞くSQL Serverの質問会

私のブログに何度も出てくるムッシュ小澤さんによるSQL Server 2019情報、および質問会。小澤さんはMSの毎月実施しているSQL Server セミナーや、MSの大規模イベントでも解説されている国内で一番有名なSQL Server技術者である。過去ブログでは以下で発表者側として参加されている。 

testedquality-tech.hatenadiary.jp

testedquality-tech.hatenadiary.jp

testedquality-tech.hatenadiary.jp

今回は2019の解説であったが、プレゼン資料が配布されないとのことで写真OKだったものの私のカメラは性能が良くないので、ツイートでメモした。また解説資料が多いので質問を早めに終わらせようと、先にSQL Serverの質問会を行うことになった。

 msdbはSQL Serverのシステム用DBと呼ばれるもの。DBをSQL Server Integation Service をつかって移行作業をする場合、作成したスクリプトにはコンピューター名が含まれている。移行先ではコンピューター名変わることが一般的だと思うが、その場合コンピューター名が作成したスクリプトに直書きされているので、これを書き換える必要があるとのこと。スクリプトは平文となるので、手作業修正ができる。msdbの移行部分に埋まっているということなんですね。

 SQL Serverの新規作成時、デフォルトではDBファイルとログファイルの2種を1ファイルずつ(mdb,ldb）2ファイル作成できる。しかしDBファイルとログファイルを2つ以上指定することも可能だ。この新規作成時についての質問。

ファイルグループについては公式のドキュメントに記載がある。

データベース ファイルとファイル グループ | Microsoft Docs

昔から分割機能はあり、処理速度向上に役立つという記載もあるのだが、実際に運用していた際の自分の検討だと、バックアップの復旧を考えると分割によるリスク増大を許容できず見送った。せめてトランザクションログと別ディレクトリにするなどで、I/Oの効率UPを図るのがよさげだ。また、データサイズが大きいことを質問者の方が気にされていたが大きいからと言って圧縮だけは避けたほうがよいとのこと。理由が明確でなるほど！と思った。実際に私も仕事でストレージが不足して圧縮をしたときがあり、速度低下がユーザーの体感レベルで下がり問題になったことがあるので、みにつつまされた。

 トランザクションログもそうだがSQL Serverの物理ファイルは、一度大きくなるとレコードやテーブルを削除してもファイルサイズはそのままである。トランザクションログも同様。なのでトランザクションログのファイルサイズが大きい場合には、まず本当に中身が入っているのかを確認したほうがよい。統計情報でも見れるが、私は楽をするためデフォルトのレポートで見ていた。割合が円グラフで出てきて、他の人にもわかりやすい。　そのうえで中身がある場合、切り捨てが発生してない理由が何かあるはずで、それはシステムとログの状況を調べるしかない。ストレージを大きくするのをオンラインのままはできないので、業務が停止できない状況でログがむやみに増大するのは運用が厳しいだろう。

ということで質問がある程度落ち着いたところで2019の技術解説が始まった。

こちらも面白かったのだが、もう眠いので明日続きを書く。