SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
以前、SQL Server のクエリオプティマイザを学習する際に確認するドキュメント という投稿を書きました。
SQL Server のクエリオプティマイザを学習するためには、上記の投稿で触れている技術情報に加えて、SQL Server ディスク ベース テーブルに対するクエリ処理 の以下の図を意識する必要があります。
SQL Server のクエリ実行時の実行プランの生成については、
というような流れとなります。
「2.」の Algebrizer が論理操作 (論理ツリー) を出力する部分については、公開されている情報が少ないのですが、「3.」のクエリオプティマイザの動作については、様々な情報が公開されています。
本投稿ではどのような情報が公開されているのかについてまとめておきたいと思います。
SQL Server でデータのエクスポート / インポートを行う場合、bcp ユーティリティ を使用しますが、ネイティブ型 (-n オプション) を使用したファイルをインポートしようとした際に、特定の条件下でエクスポートされたデータをインポートすることができず、理由を理解するのに時間がかかりました…。
その時の調査内容を残しておきたいと思います。
Power BI Premium / Power BI Embedded のワークスペースでは、XMLA エンドポイントを使用して、ワークスペースの操作を行うことができます。
XMLA は、XML for Analysis の略となり、Analysis Services の操作を行う際に使用されているプロトコルとなります。
XMLA エンドポイントを使用することで、SSAS を操作するためのツールを使用して、Power BI の操作を行うことができるようになり、
等の作業を行うことができるようになります。
他にも データセットの更新 に書かれているような、データセットの内容の更新時に次のようなメリットがあります。
XMLA エンドポイントにより、SSMS、PowerShell による自動化、Azure Automation、TOM を使用する Azure Functions を使用した、きめ細かい更新機能を実現するための広範なシナリオが可能になります。 たとえば、すべての履歴データを再読み込みしなくても、特定の増分更新履歴パーティションを更新できます。
Power BI サービスで更新を構成するのと異なり、XMLA エンドポイントを介した更新操作は、1 日 48 回の更新に制限されず、スケジュールされた更新のタイムアウトも課されません。
XMLA エンドポイントを使用したデータ更新のメリットについては、データセットの増分更新とリアルタイム データ にも記載があります。
先日、XMLA エンドポイントを使用した Power BI の操作方法を調査する機会があったのですが、その際に調べた内容を遺していなかったので、本投稿でまとめておきたいと思います。
Azure Purview では、Azure Purview で Google BigQuery プロジェクトに接続して管理する (プレビュー) で解説が行われているように、Google BigQuery 上のデータセットについても、Purview のスキャン対象とすることができます。
BigQuery のスキャンについては、セルフホステッド統合ランタイム (SHIR) 経由で実施する必要があるため、PaaS だけでは完結がしないのですが、SHIR をインストールした環境に、BigQuery 用の JDBC ドライバーを設定することで、BigQuery のスキャンが可能となります。
BigQuery ではデータセット単位に、データセットを配置する場所 (Location) を指定する必要があり、データセットのロケーション で解説が行われています。
以下のデータセットであれば US に配置されていることになります。
今年になってドキュメントに追記が行われたようなのですが、Purview で BigQuery をスキャンする場合、現時点では BigQuery のデータセットのロケーションについては、US が設定されている必要があり、それ以外のロケーションに設定されているデータセットについては、Purview でスキャンすることができません。
現在 Purview は、米国の複数地域の場所にある Google BigQuery データセットのスキャンのみをサポートしています。 指定されたデータセットが us-east1 や EU などの別の場所にある場合、スキャンは完了しますが、資産は Purview に表示されません。
BigQuery は東京 (asia-northeast1) にデータセットを作成することができるのですが、残念ながら、現時点では、東京に作成されたデータセットは、Purview で認識することができないという状況になっています。(データセットが見つからないというような状態となります)
昨年、この動作について、SR で確認をしていて、その中でドキュメントへの追記の検討や、データセットのロケーションを指定できる or 全ロケーションを対象とするような改善要望の提案なども、ご対応いただいていたので、もしかしたらそのうち改善がされるかもしれません。
現時点では、US 以外のロケーションにあるデータセットについては、US にコピーを行わないと Purview のスキャン対象とすることはできないようです。
先日、How to learn SQL Server という SQL Server の勉強の仕方についてのセッションを担当させていただきました。
その際のセッション資料を How to learn SQL Server として PDF を公開させていただきました。
SQL Server の勉強をする際の参考になれば幸いです。
SQL Server のインストールを行うと、SQL Server VSS Writer (SQLWriter) サービスが合わせてインストールされ、Windows OS の Windows VSS インフラストラクチャと連携して、データベースのバックアップを行うことができます。
SQL Server 標準の BACKUP DATABASE を使用している場合は、VSS Writer との連携は意識しませんが、それ以外の方法、OS のバックアップ (Windows Server バックアップ) や、バックアップソフトのようなものを使用した場合は、SQL Server VSS Writer が透過的に使用されていることもあります。(SQL Server VSS Writer を使用したバックアップについては、BACKUP ステートメントを WITH SNAPSHOT オプションで実行しているケースがあり、厳密には BACKUP ステートメントと関連性はありますが)
この SQL Server の VSS Writer について確認する必要が出た場合、どのような技術情報が公開されているのかをまとめておきたいと思います。
Azure Arc Enabled SQL Server (Azure Arc 対応サーバーでの SQL Server) の操作方法について、ドキュメントを見てもわかりづらいところがいくつかあったので、本投稿で操作方法をまとめておきたいと思います。
私の環境では、サブスクリプション単位で、Microsoft Defender for Cloud を有効にせず、Log Analytics ワークスペース単位で有効にしているということもあるので、その辺も操作の複雑性に起因しているかもしれません。
今回の環境は Windows 版の SQL Server を対象としています。
SQL Server の特定の待機を意図的に誘発させたり、特定のスレッドを一時的にフリーズさせて挙動を確認させる際に windbg を使用することがあるのですが、windbg で SQL Server を操作する際「WAITFOR DELAY」を題材にしてみると、操作方法を理解するのに役に立つ気がしたので、操作の流れをまとめておこうと思います。
本投稿は、windbg の導入の基本的な操作の把握や、SQL Server に関連するパブリックシンボルの設定については完了している前提となっており、それ以降の操作を記載しています。
あけましておめでとうございます。2022 年最初の投稿ですね。
今年は SQL Server のクエリオプティマイザ周りのスキルを延ばそうと思っているのですが、その中で、どのようなドキュメントを最初に確認したほうが良いのかを軽くまとめてみました。
SQL Server のクエリ実行についてはざっくりと書くと、
というようなステップが踏まれると思いますが、これらのクエリ実行の流れの動作を把握するために一読しておいたほうが良いドキュメントを箇条書きでまとめたものとなります。
