CLR 統合 - 概要

適用対象:SQL ServerAzure SQL Managed Instance

共通言語ランタイム (CLR) は、Microsoft .NET Framework の中核であり、すべての .NET Framework コードの実行環境を提供します。 CLR の内部で実行されるコードはマネージド コードと呼ばれます。 CLR は、ジャストインタイム (JIT) コンパイル、メモリの割り当てと管理、タイプ セーフの設定、例外処理、スレッド管理、セキュリティなど、プログラムの実行に必要なさまざまな機能やサービスを備えています。 詳細については、.NET Framework SDK を参照してください。

Microsoft SQL Server にホストされる CLR (CLR 統合と呼ばれる) を利用することで、ストアド プロシージャ、トリガー、ユーザー定義関数、ユーザー定義型、およびユーザー定義集計をマネージド コードで作成できます。 マネージド コードは実行前にネイティブ コードにコンパイルされるため、状況によっては、パフォーマンスが大幅に向上します。

マネージド コードでは、アセンブリが特定の操作を実行できないように、CAS (コード アクセス セキュリティ) が使用されます。 SQL Server は、CAS を使用して、マネージド コードをセキュリティ保護し、オペレーティング システムやデータベース サーバーへの侵害を防止します。

CLR 統合機能の利点

Transact-SQL は、データに直接アクセスしたり、データベースを直接操作することを主眼に設計されています。 Transact-SQL はデータへのアクセスやデータの管理に優れていますが、いわゆる本格的なプログラミング言語ではありません。 たとえば、Transact- SQL では、配列、コレクション、for-each ループ、ビット シフト、およびクラスはサポートされません。 これらの構造の一部は Transact-SQL でもシミュレートできますが、マネージド コードでは、これらの構造に対するサポートが統合されています。 シナリオによっては、この特性が、特定のデータベースの機能をマネージド コードに実装するかどうかの決め手となることがあります。

Microsoft Visual Basic .NET および Microsoft Visual C# は、カプセル化、継承、多態性など、オブジェクト指向の機能を備えています。 関連のあるコードは、簡単にクラスや名前空間に編成することができます。 大量のサーバー コードを使用している場合も、この機能により、コードの編成と管理を簡略化できます。

マネージド コードは、Transact-SQL より計算や複雑な実行ロジックに適しており、文字列処理や正規表現など、多くの複雑な作業を幅広くサポートしています。 .NET Framework ライブラリの機能を使用すると、数千もの事前にビルドされたクラスやルーチンにアクセスすることができます。 このようなクラスやルーチンには、任意のストアド プロシージャ、トリガー、またはユーザー定義関数から簡単にアクセスできます。 BCL (基本クラス ライブラリ) には、文字列操作、高度な算術演算、ファイル アクセス、暗号化などの機能を提供するクラスがあります。

注意

これらのクラスの多くは、SQL Server の CLR コード内から使用できますが、サーバー側での使用が適していないクラス (ウィンドウ関連のクラスなど) にはアクセスできません。 詳細については、「サポートされている.NET Framework ライブラリ」を参照してください。

マネージド コードの利点の 1 つはタイプ セーフであることです。つまり、コードから各データ型へのアクセスは、正しく定義された許容される方法に限られます。 CLR は、マネージド コードが実行される前に、そのコードが安全であることを確認します。 たとえば、事前に書き込まれていないメモリからの読み取りが行われないように、コードがチェックされます。 また、CLR は、コードからアンマネージ メモリの操作が行われないようにする際にも役立ちます。

CLR 統合を使用すると、パフォーマンスが向上する可能性が高くなります。 詳細については、「 CLR 統合のパフォーマンス」を参照してください。

警告

CLR では、セキュリティ境界としてサポートされなくなった、.NET Framework のコード アクセス セキュリティ (CAS) が使用されます。 PERMISSION_SET = SAFE で作成された CLR アセンブリが、外部のシステム リソースにアクセスし、非管理対象コードを呼び出し、sysadmin 特権を取得できる場合があります。 SQL Server 2017 (14.x) 以降、CLR アセンブリのセキュリティを強化するために clr strict security という sp_configure オプションが導入されました。 clr strict security は既定で有効になり、SAFE および EXTERNAL_ACCESS アセンブリを UNSAFE とマークされている場合と同様に扱います。 clr strict security オプションは、旧バージョンとの互換性のために無効にできますが、これは推奨されません。 Microsoft では、master データベースで UNSAFE ASSEMBLY アクセス許可が付与されている対応するログインを含む証明書または非対称キーで、すべてのアセンブリに署名することをお勧めします。 詳しくは、「CLR の厳密なセキュリティ」をご覧ください。

Transact-SQL とマネージド コードの選択

ストアド プロシージャ、トリガー、およびユーザー定義関数を記述する際には、従来の Transact-SQL を使用するか、または Visual Basic .NET や Visual C# などの .NET Framework 言語を使用するかを判断する必要があります。 データ アクセスに使用する手続き型のロジックが、コード中にない場合や非常に少ない場合は、Transact-SQL を使用します。 複雑なロジックで CPU を集中的に使用する関数やプロシージャ、または .NET Framework の BCL を使用する場合は、マネージド コードを使用します。

サーバー側での実行とクライアント側での実行の選択

Transact-SQL またはマネージド コードのどちらを使用するかの選択を左右するもう 1 つの要因は、サーバー コンピューターまたはクライアント コンピューターのどちらにコードを配置するかです。 Transact-SQL とマネージド コードの両方をサーバーで実行できます。 サーバー側でコードを実行すると、コードとデータが近くにあるため、サーバーの処理能力を活用できます。 逆に、データベース サーバーでプロセッサを集中的に使用するタスクを実行することが好ましくない場合もあります。 現在、多くのクライアント コンピューターは高性能なので、できるだけ多くのコードをクライアント側で実行して、この処理能力を活用することもできます。 マネージド コードはクライアント コンピューターで実行できますが、Transact-SQL はクライアント コンピューターでは実行できません。

拡張ストアド プロシージャとマネージド コードの選択

Transact-SQL ストアド プロシージャでは実行不可能な機能を実行するために、拡張ストアド プロシージャを構築できます。 ただし、拡張ストアド プロシージャは SQL Server プロセスの整合性を損ねる可能性があります。一方、タイプ セーフかどうかの検証が行われるマネージド コードは、SQL Server プロセスの整合性を損ねる可能性がありません。 さらに、メモリ管理、スレッドおよびファイバーのスケジューリング、および同期サービスは、CLR のマネージド コードと SQL Server との間の方がより密接に統合されています。 CLR 統合を使用すると、拡張ストアド プロシージャを使用するよりも安全に、Transact-SQL では記述できないタスクを実行するのに必要なストアド プロシージャを記述することができます。 CLR 統合と拡張ストアド プロシージャの詳細については、「 CLR 統合のパフォーマンス」を参照してください。

参照

.NET Framework のインストール
CLR 統合のアーキテクチャ
CLR データベース オブジェクトからのデータ アクセス
CLR 統合の概要