SQL Server

ストアドプロシージャのパラメータとして配列を渡す (Part 2)

むら — Tue, 08 Jan 2008 21:45:00 GMT

ストアドプロシージャのパラメータとして配列を渡すの続きです。
待ち遠しかったので、実際にSQL Server 2008におけるテーブル型入力パラメータを使ったストアドプロシージャとファンクションを試してみました。

以下は私が試したコードです。
テーブル型で定義した変数を入力として受け取って、そのまま返すストアドプロシージャとファンクションです。
※当たり前ですがSQL Server 2005ではエラーになります。

-- タイプの定義--

CREATE TYPE TableType AS TABLE(code int, [name] nvarchar(256))

-- テストデータの定義--

DECLARE @TestData TableType

INSERT INTO @TestData VALUES (1,'1111')

INSERT INTO @TestData VALUES (2,'2222')

INSERT INTO @TestData VALUES (3,'3333')

-- テーブル型パラメータを入力とするストアドプロシージャ--

CREATE PROCEDURE TestProc(@InputTable TableType READONLY)

BEGIN

SELECT * FROM @InputTable

END

-- ストアドプロシージャ呼び出しの例--

EXECUTE TestProc @TestData

-- テーブル型パラメータを入力とするファンクション--

CREATE FUNCTION TestFunc(@InputTable TableType READONLY)

RETURNS @ReturnTable TABLE(code int, [name] nvarchar(256))

BEGIN

INSERT INTO @ReturnTable SELECT * FROM @InputTable

RETURN

END

-- ファンクション呼び出しの例--

SELECT * FROM TestFunc(@Table)

ポイントは、ストアドプロシージャ定義やファンクション定義の前に書かれたCREATE TYPE宣言です。
この宣言で受け渡すテーブル型を事前に定義し、ストアドプロシージャ定義やファンクション定義でパラメータとして使用する事が出来るようになります。

この新機能のお陰で前回紹介した文字列分割関数が不要になりますね。
また、関数やストアドプロシージャ間で配列を受け渡し出来るので、配列の受け渡しに一時テーブルを使わなくても良くなる事もとても嬉しいですね。

ストアドプロシージャのパラメータとして配列を渡す

むら — Mon, 07 Jan 2008 20:22:00 GMT

あけましておめでとうございます。
今年初のエントリです。今年もどうぞ宜しくお願いします。

次期SQL Server 2008ではストアドプロシージャやファンクションのパラメータにテーブル型を渡す事が出来る様になるらしいのですが、SQL Server 2005ではパラメータとしてテーブル型を渡す事は出来ません。
その結果、ListBoxやCheckBoxListで複数の値を選択してストアドプロシージャにパラメータを渡す際に困る事があります。

その様な場合に私が利用している方法を紹介させて頂きます。（と言っても大した方法ではありません）
私は複数選択した「パラメータを渡す際に一つの文字列に連結し、プロシージャ内でテーブル型に変換する」と言う方法を取っています。
例えば、ListBoxで「A」と「B」を選択した場合、ストアドプロシージャにはパラメータとして「A,B」と言う文字列を渡します。
「A,B」を受け取ったプロシージャは文字列を分割してテーブル型で返却するSplitText関数を呼び出して処理を実行します。

以下はストアドプロシージャの例、およびユーザ定義関数SplitTextのコードです。

-- サンプルのテーブル--

CREATE TABLE [dbo].[TestTable](

[Code] [nvarchar](8) NOT NULL,

[Name] [nvarchar](32) NOT NULL)

-- ストアドプロシージャの例--

CREATE PROCEDURE UP_ProcTest(

@SearchValues nvarchar(max)

)

SELECT

FROM

TestTable

WHERE

Code IN(SELECT * FROM dbo.SplitText(@SearchValues,default,default))

-- ストアドプロシージャ呼び出し例--

UP_ProcTest '1,100'

-- 文字列分割関数--

CREATE FUNCTION SplitText

(

@Texts as nvarchar(max),

@SeparatorChar as char(1) = ',',

@NullText as nvarchar(16) = '<NULL>'

)

RETURNS @Table TABLE([Text] varchar(max))

BEGIN

DECLARE @Cnt int;

DECLARE @NextChar nvarchar(1);

DECLARE @SaveText nvarchar(max);

SELECT @Cnt = 1, @NextChar = '', @SaveText = '';

WHILE @Cnt <= LEN(@Texts)

BEGIN

SET @NextChar = SUBSTRING(@Texts, @Cnt, 1);

IF @NextChar = @SeparatorChar

BEGIN

IF @SaveText = @NullText SELECT @SaveText = null;

INSERT INTO @Table VALUES(@SaveText);

SELECT @SaveText = '';

END

IF @NextChar <> @SeparatorChar

SELECT @SaveText = @SaveText + SUBSTRING(@Texts, @Cnt, 1);

SET @Cnt = @Cnt + 1;

END

IF @SaveText = @NullText SELECT @SaveText = null;

INSERT INTO @Table VALUES(@SaveText);

RETURN

END

※ SplitText関数のパラメータ規定値を使用するために呼び出し側ストアドプロシージャではパラメータに「Default」を指定します。
※ SplitText関数は規定ではカンマを区切り文字として使用しています。（呼び出し時の第二パラメータにて変更可能）
※ SplitText関数に「<NULL>」と言う文字列を渡すとnull値を返します。（呼び出し時の第三パラメータにて変更可能）

ちなみにSplitTextと同様の関数のコードは海外のサイトでも色々と紹介されていますので、それらを参考にしてよりスマートなコードを目指しても良いかも知れません。
文字列を連結する代わりにXMLを使っても面白いかもしれませんね。

Visual Studio 2005のTableAdapterとSQLのIDENTITY

むら — Tue, 14 Aug 2007 18:24:00 GMT

SQL ServerのID生成について前回纏めさせて頂きました。その際、黒龍さんからVisual Studio のTableAdapterがSCOPE_IDENTITYを利用するSQL文を生成している事を教えて頂きました。
また前回はIDの取得について様々な方法を紹介しておきながら、OUTPUT句について一切触れておりませんでした。
そこで、TableAdapterとOUTPUT句を絡めて纏めてみたいと思います。
（OUTPUT句については以前中さんが纏めていらっしゃいましたので、こちらもご参考になさって下さい。SQL Server 2005のOUTPUT句は最高）

OUTPUT句

OUTPUT句はSQL Server 2005から追加された機能で、INSERT、UPDATE、DELETEの各ステートメントにより影響を受ける行の情報を返す事が出来る構文です。
OUTPUT句の中ではINSERTEDやDELETEDプレフィックスを使用することが出来ます。例えばUPDATEステートメントの場合、更新前の行にアクセスする時はDELETED、更新後の行にアクセスする時はINSERTEDプレフィックスを使用します。
IDENTITYプロパティにより生成されたIDを取得したい場合、INSERTEDプレフィックスを利用することで容易にIDを取得出来ます。

INSERT INTO TestTable ([name]) OUTPUT INSERTED.ID VALUES('name')

TableAdapterが生成するSQL文

Visual Studio 2005でSQL ServerデータベースにアクセスするTableAdapterを作成する場合、「TableAdapter構成ウィザード」を使います。
このウィザードでIDENTITYプロパティを設定したテーブルに対するINSERTコマンドを生成すると、次のようなSQLコマンドが生成されます。

INSERT INTO [dbo].[TestTable] ([name]) VALUES (@name);
SELECT id, name FROM TestTable WHERE (id = SCOPE_IDENTITY());

つまり、テーブルに行を挿入した後、主キー(IDENTITY列)で検索しています。

OUTPUT句を利用した場合のコスト比較

次にOUTPUT句を利用する場合とSCOPE_IDENTITY()を利用する場合とでコストの違いを実験してみます。
この実験ではVisual Studio 2005のテーブルアダプタが生成するSCOPE_IDNEITYを利用したステートメントとOUTPUT句を比較します。
（実験で使用したテーブルは前回のネタで使用したものを使いまわしています。）

-- パターンA (VS2005テーブルアダプタ)
INSERT INTO [dbo].[TestTable] ([name]) VALUES ('name');
SELECT id, name FROM TestTable WHERE (id = SCOPE_IDENTITY());

-- パターンB (OUTPUT句)
INSERT INTO TestTable ([name]) OUTPUT INSERTED.* VALUES('name');

両パターンのSQL文を実行した実行プランを下の図に示しますが、この結果から次の事柄が分かります。

INSERTのコストはパターンA・B共に違いがない
SCOPE_IDENTITY()を取得するコストは殆ど掛からない
Clustered Index Seekが発生している分だけパターンAにハンデがある

従い、「一行だけ挿入してその結果を取得する」と言う前提においてはOUTPUT句に軍配が上がります。（この結果は中さんの記事と同じですね）

ただし、OUTPUT句とSCOPE_IDENTITYは特性が違う事も念頭に置いておく必要が有ります。
と言うのも、一行だけ挿入する場合は双方共に挿入されたIDを返しますが、複数行挿入した場合はOUTPUT句では「挿入された全てのIDを返す」のに対してSCOPE_IDENTITYでは「挿入された最後のIDを返す」からです。

Visual Studio 2008のテーブルアダプタ構成ウィザード

Beta2で確認した所、残念ながらVisual Studio 2008のテーブルアダプタ構成ウィザードもSCOPE_IDENTITYでSELECTする構文を生成していました。
この辺りはSQL Serverの下位互換も考慮した結果なのかも知れませんが。

SQL Server によるIDの生成

むら — Tue, 07 Aug 2007 15:39:00 GMT

インスパイア元はtatsumihrさんのBlogです。
最近感動したこと
このエントリを元にけろさんと話をしていたら、流れで「SQL ServerのIdentityについて纏めなさい」と命ぜられてしまいました。
ですので、また自分なりに纏めてみたいと思います。

IDENTITYプロパティ

SQL Serverに一意のIDを生成させる方法として、列にIDENTITYプロパティを指定する方法があります。
IDENTITYプロパティには次の特徴があります。

ひとつのテーブルのひとつの列にしか指定できません。
指定する列のデータ型はint型、bigint型、smallint型、tinyint型、decimal型、numeric型に限ります。
（設定により変更可能ですが）基本的に値のセットは出来ません。

IDENTITYを指定した列に値を挿入したい場合は、IDENTITY_INSERTプロパティをONに設定します。
この設定は同一セッション内でのみ有効です。

新しく付与されたIDの取得方法

IDENTITYプロパティにより新しく生成されたIDを取得する方法には次の３つの手段があります。

@@IDENTITY
SCOPE_IDENTITY
IDENT_CURRENT

いずれも、生成されたIDを取得すると言う意味では同様のものではありますが、それぞれに特徴があります。

@@IDENTITYはそれを指定したセッション内の任意のスコープにて最後に生成されたIDを返します。
SCOPE_IDENTITYはそれを指定したスコープ内およびセッション内で最後に生成されたIDを返します。
IDENT_CURRENTは任意のスコープ、任意のセッションにおいて特定テーブルに対して最後に生成されたIDを返します。

一見すると同じものを返す様に見えますが、「テーブルに新しく行を追加した結果、生成されたIDを取得したい」場合には注意が必要です。
例えば、@@IDENTITYは任意のスコープ（モジュールやストアドプロシージャなどの単位）で生成されたIDを返すので、トリガによりIDENTITYプロパティを指定したテーブルへの挿入をしていた場合には、トリガにより生成されたIDを返してしまいます。

また、IDENT_CURRENTはテーブルを限定しますがセッションを限定しないので、対象テーブルを更新するトランザクションが同時実行された場合に意図しないIDを返す恐れがあります。さらにスコープを限定しないので、トリガにより自身のテーブルに列を挿入する場合にも意図しないIDを返す恐れもあります。

従い、「テーブルに新しく行を追加した結果、生成されたIDを取得したい」と言う要件に対する解決策としてはSCOPE_IDENTITYを使うことが最善と言えます。
SCOPE_IDENTITYを取得する際は、SELECT SCOPE_IDENTITY で取得できます。

IDの生成にnewid関数を利用する方法

一意の値をSQL Serverに生成させる方法として、他にnewid関数を利用する方法もあります。
newid関数は、uniqueidentifier型の一意な値（GUID）を生成する関数です。
このnewid関数をuniqueidentifier型の列の規定値にすると、値が指定されなかった場合に新しいGUIDを生成してくれます。
データ型も違いますのでIDENTITYプロパティとはまったく異なるものですが、一意の値を生成すると言う目的に対しては有効です。
IDの生成にnewidを使用する場合の特徴は次の通りです。

newid関数自体はひとつのテーブルの複数の列で指定可能です。
規定値にnewidを指定できる列のデータ型はuniqueidentifier型です。
newidを規定値に指定していても、値のセットは可能です。

IDの生成にnewid関数を利用する事の利点と欠点

newidを規定値に指定していてもデフォルトで値の挿入が可能です。
しかもIDENTITY列と異なり、プログラム側からSystem.Guid.NewGuid()メソッドで挿入するIDを生成できるので、SCOPE_IDENTITY等を利用して事後にIDを取得する必要はありません。
もちろん、欠点もあります。
業務要件により「挿入された順序の把握が必要な場合」には、何らかの別項目が必要となります。
また、Guid.NewGuidで生成されたIDは理論上2^128分の1の確立で重複しますので、この確立が無視できない場合は相応の重複チェックが必要となります。

最後に

けろさん、こんな感じで纏めてみましたが如何でしょうか。
そうそう、もう宿題はご勘弁頂きたく...

SQL Server 2005のメモリについて(AWEの有効化)

むら — Thu, 19 Jul 2007 12:28:00 GMT

先日、私が担当しているシステムに一時的に処理が集中し、レスポンスが非常に悪くなる現象が発生しました。結論としてはSQL Server 2005の〔AWEを使用してメモリを割り当てる〕オプションを有効にすることで事態は沈静化したのですが、折角なのでレポートします。（画像中のサーバー名は塗潰しまたは置換しています。）

システムの構成は以下の通りです。
・ASP.NET 2.0
・SQL Server 2005 SP2
・同一サーバー内にDatabaseとWEBアプリケーションが稼働
・サーバーのOSはWindows Server 2003 Standard SP2（32bit）
・サーバーのCPUはXeon 3.0GHz×２、メモリ4GB

この時ハードコピーを取り忘れてしまったのですが、SQL Server内には大量の待ちプロセスが発生していました。また、その時のパフォーマンスモニタのレポートは以下の通りです。

レポートを見てわかるように、SQL Serverに割り当てられたメモリは約1.5GBです。

しかしながら、タスクマネージャで確認すると利用可能メモリは1GB以上残っていました。（これもMemory : Available Bytesのカウンタをとっておけば良かったのですが…）

そもそもサーバーのリソースが足りないと言う議論は置いておいて、AWEの使用を有効にすることでよりメモリを有効に使えるのではないかと考えました。（AWEとはAddress Windowing Extensionsの略で、大容量物理メモリサポート機能の名称です。）
そこで、SQL Serverのオブジェクトエクスプローラからデータベースエンジンのプロパティを開き、メモリ設定の〔AWEを使用してメモリを割り当てる(U)〕をチェックしました。

設定変更後、SQL ServerのTotal Server Memoryは約2.4GBとなりサーバーのメモリが多く割り当てられた事が分ります。

また、サーバーの利用可能メモリの量も約250MBまで減少しました。

この設定変更後、SQL Serverに滞留していた多くのプロセスが処理され、サーバーのレスポンスも次第に回復しました。

いずれにせよ、OSを含めハードウェアの増強を検討しなければ… orz

参考URL:
http://technet.microsoft.com/ja-jp/library/ms190673.aspx
http://www.atmarkit.co.jp/fdb/rensai/drk02/drk02_1.html