Archive for the ‘SQL Server’ Category
SQL Server の初期設定の照合順序 (Japanese_CI_AS / SQL_Latin1_General_CP1_CI_AS) で、Unicode 文字を操作する場合に気を付けておきたいとこ
SQL Server / SQL Database を使用しており設定を初期状態で使用していると、インスタンス / データベースの照合順序は、
- Japanese_CI_AS : 日本語環境のデフォルト
- SQL_Latin1_General_CP1_CI_AS : 英語環境のデフォルト
のいずれかを使用しているケースが多いのではないでしょうか？
これらの照合順序は列レベルの照合順序の初期設定として、引き継がれますので列の比較をする際の挙動にも影響をしてきます。
照合順序については、次のドキュメントの内容を確認することになります。
- 改行されていないスクリプトを確認したい場合はこちら
SQL Server では Unicode の文字の比較を考慮する際には、照合順序の次のような内容を意識する必要があるのではないでしょうか。
- サポートされる Unicode のバージョン
- Unicode コードポイント
- 比較時の重み
SQL Server では、nchar / nvarchar / char (UTF-8 サポートあり) / varchar (UTF-8 サポート) を使用することで、Unicode の文字列を格納することができ、どの照合順序を使用していてもこれらのデータ型を使用している場合は、次のようなエンコードで文字を格納することができます。
- nchar / nvarchar : UCS-2 / UTF-16
- char (UTF-8 サポートあり) / varchar (UTF-8 サポートあり) : UTF-8
ただし、格納と文字の比較は別であり、照合順序の設定によって「格納はできても想定した比較結果にならない」ということがあります。
日本語圏で考えた場合、
- 新しい Unicode のバージョンで追加された文字
- サロゲートペア
- 異体字
というような設定が関係し、「新しい Unicode のバージョンで追加された文字」については、「基本多言語面 (BMP)」である「000000 – 00FFFF」に追加されることもありますので、BMP の範囲の文字についても、照合順序の設定によっては正しく比較されないことがあります。
Unicode の情報については、https://home.unicode.org/ から確認することができ、Unicode のバージョンや、文字のコードポイントを確認する場合には、次の情報を使用するとよいのではないでしょうか。
- Unicode® Code Charts Help and Links
- Unicode Character Code Charts
- https://www.fileformat.info/info/unicode/char/search.htm
SQL Server は文字の格納については、Unicode をサポートしたデータ型を使用していれば、柔軟にデータを登録することができますが、データの比較 については、照合順序の設定が大きく影響してきます。
本投稿では、以前のバージョンの照合順序となる BIN / Unicode は使用しない前提で記載していますので、バイナリ照合順序といえば BIN2 となり、Unicode サポートの照合順序といえば、照合順序名に Unicode がついていないものを前提としています。
SQLBits 2022 で Azure SQL のアップデートの発表がありました
ロンドンで開催されている SQLBits 2022 というイベントで MS のセッションで Azure SQL のアップデートの発表が行われたようです。
発表内容については、Azure SQL News Update | Data Exposed Live @SQLBits 2022 で動画が公開されています。
機能追加としては、SQL Managed Instance の MI Link が Public Preview になったことが大きいかと思います。
同時期には、次のような記事も公開されていますのでこれらの情報も確認してみるとよいかと思います。
- Azure SQL News Update: March 2022
- Azure SQL—General availability updates for early March 2022
- Azure SQL—Public preview updates for early March 2022
SQLBits のキーノートとして実施された Level Up with Azure Data については、SQLBits の Youtube に公開されています。
このセッションの中で、SQL Server 2022 の Public Preview についても触れられ、2022 年の 1Q の終わりまでに、公開が行われる計画となるようです。
以下のブログの記事もとても参考になりますので、こちらも確認しておくとよいのではないでしょうか。
Azure SQL Managed Instance の リンク機能 (MI Link) で SQL Server 2019 とデータ同期を実施してみる
SQLBits 2022 でアナウンスがありましたが、SQL Server から Azure SQL Managed Instance （MI) とデータ同期をするための機能となる、Azue Managed Instance のリンク機能 (Link feature for Azure SQL Managed Instance / Managed Instance Link) が Public Preview となりました。
SQL Server 2022 と同時にこの機能のアナウンスも行われていたのですが、当初は Limited Preview となり限定されたプレビューでの公開となりました。(アナウンス時の情報は、Managed Instance link – connecting SQL Server to Azure reimagined となります)
今回、Public Preview となり、任意の環境で検証ができるようになりましたので、情報をまとめておきたいと思います。
追記
Tech Community でもアナウンスが行われました。
SQL Server のロール設定によるロック競合 / デッドロックについての情報
SQL Server のロール設定をした際のロック競合とデッドロックについての調査をしていた際に見つけた情報として、次のようなものがありました。
- SQL Server Deadlock on subresource PERMISSIONS when sp_executesql with #temptables
- High volume of deadlocks with Vault in Sql server
どちらも同一の情報がベースとなっており、HashiCorp の Vault と SQL Server の組み合わせた場合のデッドロックの発生となるようですが、情報としてはとても興味深い内容となっていました。
SQL Server 2022 で廃止となる機能の一部がアナウンスされました
The path forward for SQL Server analytics で発表されましたが、SQL Server 2022 で SQL Server 2019 までで実装されていた機能の一部の廃止 (Retirement) がアナウンスされています。
Today, we are announcing changes to SQL Server analytics which includes:
- Customer feedback
- Retirement of SQL Server 2019 Big Data Clusters
- Retirement of PolyBase scale-out groups
- Path forward
統計情報を使用した非パーティションテーブルのエクスポートデータの分割
SQL Server のデータをエクスポートする場合、大規模データをエクスポートする場合はいくつかのデータに分割してエクスポートを行うことで、
- ファイル当たりのエクスポートデータのサイズ調整
- データに問題があった場合の再抽出
- データの並列ローディング
というようなメリットがあるのではないでしょうか？
PolyBase のような機能では、パーティションテーブルに対してのアクセスについては、パーティション単位にスレッドを分散させてデータアクセスを行っており、何らかの論理空間で分割が行われている場合は、「パーティション単位でデータをエクスポートする」というように、複数のエクスポートデータを容易に生成することができます。
それでは「非パーティションテーブル」ではどのような方法を使用することで、エクスポートデータを分割することができるでしょうか？
以前投稿した、Database Migration Assistant (DMA) で SQL Server から SQL Database へのデータ移行方法について にも関連する内容となるのですが、非パーティションテーブルを複数のエクスポートデータに分割したい場合、「統計情報を使用する」というアプローチをとることができますので、本投稿で紹介させていただきます。
タイトルには、「非パーティションテーブル」と書きましたが「パーティションテーブル」でも使用できます。(パーティションと統計情報のヒストグラムを組み合わせるとさらに細かな単位でデータを分割できるかと)
メモリプレッシャーによる SQL Server の AppDomain のアンロード
先日、SQL Server と AppDomain という投稿をしました。
SQL Server では、ユーザー定義の CLR を使用していなくても、
- 空間データ型 (geography / geometry)
- 階層データ型 (hierarchyid)
- FORMAT 関数
等を使用した場合、CLR による実装が行われているため、CLR がロードされ AppDomain (アプリケーション ドメイン) が生成されていることについて触れました。
前回の投稿では「ロード」部分が主内容となっていましたが、本投稿では「アンロード」部分について触れてみたいと思います。
SQL Server と AppDomain
SQL Server と AppDomain の関係について整理する必要があったので、情報を遺しておきたいと思います。
SQL Server は通常の使用を行っていても、一部の機能では、CLR (.NET 共通言語ランタイム) が使用されており、AppDomain が生成されている可能性があります。
統計情報を更新してリコンパイルを誘発させるテストを実施する場合の注意点
SQL Server ではクエリのリコンパイルが発生する条件としては次のようなものがあります。
パラメータースニッフィング等で、実行プランが大多数のクエリで効率が悪くなってしまった場合の補正として、「統計情報を更新」することでリコンパイルを誘発させることがあるのではないでしょうか。
実稼働環境であれば、統計情報の更新を行うことでリコンパイルを誘発させるということを実施するのは、それほど難しくない気がしますが、負荷がかかっていない検証環境のようなものを使用して、検証を実施しようとすると、統計情報を更新してもリコンパイルが発生しないとう状態になることがあります。
これについては、2018 年の段階で Does Updating Statistics Cause a Recompile if No Data Has Changed? で解説が行われていますが、投稿を書いている時点の最新のバージョンである、SQL Server 2019 CU15 でも同様な状態になるのかと思って確認していた際の内容を遺しておきたいと思います。