DEV Tips

データベース開発者の方は、Connection, Command, Reader などの Dispose,Close に注意

河端善博 — Tue, 18 Dec 2007 11:52:00 GMT

これは、先日の PASSJ アフタースクールの私のセッションでお話させていただきました。

データベース開発者の方々は、オブジェクトの Dispose (ディスポーズ), Close (クローズ) を確実に行ってください。
忘れた場合、データベースへの接続ができなくなります。

ここ一週間に 2 つのシステムで、この問題を確認しました。
いずれもプログラム経験の十分にある方々によるミスでした。
また、私も先日、DirectoryEntry オブジェクトで同様なミスをしました。

【概要】

　SqlConnection, SqlCommand, SqlDataReader, SqlDataAdapter, DbConnection, DbCommand, DbDataReader, DbDataAdapter などのオブジェクトは、利用終了後、かならず Close または、Dispose メソッドを呼ぶ必要があります。
　Close または、Dispose メソッドを呼び出さない場合、データベースへ接続できないという例外が発生します。
　確実に Close または、Dispose メソッドを呼び出すには、C# の場合 using ステートメント、VB の場合、Using ステートメントの利用をお勧めします。

【詳細】

　まず、各オブジェクトのヘルプにて、メソッドを確認してください。
　Close または、Dispose メソッドがあります。

　次に、呼び出さない場合、どのようになるかを考えます。

　.NET Framework では、利用しなくなったオブジェクトが利用するメモリやリソースは、一定期間ごとに自動的に回収されます。この機構をガベージコレクタといいます。
　逆に、ガベージコレクタが回収するまでは、メモリやリソースを占有したままとなります。

　SqlConneciton などのオブジェクトは、データベースへの接続を行います。
　データベースへの接続は、Close、または Dispose メソッドを呼びだすと解放します。
　逆に、メソッドを呼び出さない場合、カベージコレクタが回収するまで、確保した状態となります。

　.NET Framework は、データベースへの接続を効率的に行うために、コネクションプールという構造を持っています。
　コネクションプールは、データベース接続を解放したときに、実際にデータベースとの接続を切断せず、一定時間、保持しておきます。再度、データベース接続を行うときに、データベース接続文字列が同じであれば、保持している接続を再利用します。
　もし、SqlConnection などのオブジェクトが Close, Dispose されない場合、コネクションプールを使い切ることになります。コネクションプールに保持する接続数は、制限があります。

　このため、Close, Dispose を行わない処理を繰り返した場合、コネクションプールの接続を使い切り、データベース接続ができなくなります。

　データベースへの接続状況は、SQL Server の管理ツールや、sp_who コマンド、パフォーマンスモニタなどで確認することができます。

【推薦】

　確実に Close, Dispose を行うには、C# の using ステートメント、VB の Using ステートメントをお勧めします。

　例:

　　using (SqlConnection connection = new SqlConnection("....")
using (SqlCommand command = new SqlCommand("select name from table1", connection))
　　{
　　　connection.Open()
　　}

　プログラムの処理上、using が利用できない場合は、try, finally を利用して例外発生時を含め、必ず Dispose, Close が行われるようにしてください。
　また、ループの中で、Dispose, Close を持つオブジェクトを new する場合は、特にご注意ください。

ご参考になればと思います。

CompareInfo : XP, Vista 比較

河端善博 — Fri, 27 Jul 2007 18:46:00 GMT

System.Globalization.CompareInfo の一覧作成を Windows XP SP2, Windows Vista で行ってみました。

【環境】

Windows XP SP2 日本語版
Windows Vista Ultimate Edition 日本語版

【結果】

CompareInfo 数: XP 237 個、Vista 287 個
変更: 13 個
追加: 50 個

【変更】

　Windows XP SP2 から Vista で Name が変更になった CompareInfo

LCID	XP	Vista
0x65	div	dv
0x42c	az-AZ-Latn	az-Latn-AZ
0x443	uz-UZ-Latn	uz-Latn-UZ
0x465	div-MV	dv-MV
0x46c	ns-ZA	nso-ZA
0x81a	sr-SP-Latn	sr-Latn-CS
0x82c	az-AZ-Cyrl	az-Cyrl-AZ
0x843	uz-UZ-Cyrl	uz-Cyrl-UZ
0xc1a	sr-SP-Cyrl	sr-Cyrl-CS
0x141a	bs-BA-Latn	bs-Latn-BA
0x181a	sr-BA-Latn	sr-Latn-BA
0x1c1a	sr-BA-Cyrl	sr-Cyrl-BA
0x2409	en-CB	en-029

【追加】

LCID	Name
0x417	rm-CH
0x428	tg-Cyrl-TJ
0x42e	hsb-DE
0x442	tk-TM
0x445	bn-IN
0x448	or-IN
0x44c	ml-IN
0x44d	as-IN
0x451	bo-CN
0x453	km-KH
0x454	lo-LA
0x45b	si-LK
0x45d	iu-Cans-CA
0x45e	am-ET
0x461	ne-NP
0x462	fy-NL
0x463	ps-AF
0x464	fil-PH
0x468	ha-Latn-NG
0x46a	yo-NG
0x46d	ba-RU
0x46e	lb-LU
0x46f	kl-GL
0x470	ig-NG
0x478	ii-CN
0x47a	arn-CL
0x47c	moh-CA
0x47e	br-FR
0x480	ug-CN
0x482	oc-FR
0x483	co-FR
0x484	gsw-FR
0x485	sah-RU
0x486	qut-GT
0x487	rw-RW
0x488	wo-SN
0x48c	prs-AF
0x82e	dsb-DE
0x83c	ga-IE
0x845	bn-BD
0x850	mn-Mong-CN
0x85d	iu-Latn-CA
0x85f	tzm-Latn-DZ
0x201a	bs-Cyrl-BA
0x4009	en-IN
0x4409	en-MY
0x4809	en-SG
0x540a	es-US
0x1007f	x-IV_mathan
0x40411	ja-JP_radstr

日本語関連 CompareInfo と、部首画数での並べ替え

河端善博 — Fri, 27 Jul 2007 15:51:00 GMT

Windows Vista から、LCID が追加されています。
まだ、情報不足ですが、とりいそぎ、まとめてみます。

【CompareInfo : ja-JP 関係】

0x411 = ja-JP
0x10411 = ja-JP_unicod
0x40411 = ja-JP_radstr

System.Globalization.CompareInfo クラスで扱える LCID のうち、Name が "ja-JP" で始まるものです。
CompareInfo は、文字列の並べ替え順を定義します。

0x411 (ja-JP) は、従来の ShiftJIS による並べ替えです。
0x10411 (ja-JP_unicod) は、Unicode による並べ替え ?
0x40411 (ja-JP_radstr) は、部首画数順の並べ替えです。Windows XP ではサポートされません。

ja-JP_radstr のradstr は、Radical Stroke の略と思われます。
たとえば、zh-HK_stroke など、_stoke のつく CompareInfo は、4 個あります。

CultureInfo の 0x411, 0x10411, 0x40411 は、CompareInfo プロパティの値以外は、すべて同じ値になります。

Vista の並べ替え順を 0x40411 に設定するには、下記の手順でコントロールパネルから行います。

【並べ替え順の変更方法】

「コントロールパネル」を開きます。
「時計、言語、および地域」を選択します。
「地域と言語のオプション」を選択します。
ボタン「この形式のカスタマイズ」を選択します。
ダイアログが開きます
タブ「並べ替え」を選択します
「並び替えメソッドを選択してください」が表示されます。
メソッドは、「XJIS」と「部首/画数」が選択できます。

上記のメソッドと CompareInfo の対応は次のようになります。

【コントロールパネル　並べ替え順と、CompareInfo】

XJIS = LCID:0x411 (ja-JP)
部首/画数 = LCID:0x40411 (ja-JP_radstr)

変更をすると、すぐに反映されます。
試してみるには、漢字を含む名前のファイルを作成し、エクスプローラなどで並べ替えを実施します。
コマンドプロンプトにて DIR /ON としても並べ替えの変化を確認することができます。

【Excel の並べ替え】

ただし、Excel などの並べ替えには影響ししません。
Excel は、標準では、ふりがなによる並べ替えを行います。
ふりがながない場合は、たぶん XSJIS かと。(不明)

【0x10000, 0x20000, 0x30000, 0x40000】

0x10000: _mathan, _honeb, _technl, _unicod, _modern
0x20000 : _stroke 画数順
0x30000 : _pronun 発音 (pronuncation) 順
0x40000 : _radstr 部首画数順

ja-JP の0x20411, 0x30411 は、ありません。
_radstr をもつ言語は、ja-JP のみです。

とりいぞき、ここまで。
部首画数順とは ? SQL Server 照合順序/Collation との対応は ?
など今後しらべていければと思います。

※今、0 - 0xfffff までの LCID で、GetCompareInfo しているところ...
　たぶん 0x40411 ja-JP_radstr が最後かな

JIS2004 は続くよ ... (岸さんのセッションを聞いて)

河端善博 — Fri, 20 Jul 2007 19:12:00 GMT

昨日、セミナー【PASSJ 向け Windows Server 2008 Beta3 セミナー in 東京】に参加しました。

夕方からの長時間のセミナーで、さらに 1週間前からの告知であったにもかかわらず、80 名弱の方々にご参加いただきました。
また、マイクロソフトの Windows Server チーム、SQL Server チームの方々も来ていただき、最後の Q&A まで丁寧に対応していただけました。
あらためて、担当チームの方々、講師の方々に感謝させていただきたいと思います。

参加された、みなさまいかがでしたでしょうか。ぜひ、アンケートやメーリングリストなどに、気づいたことなど、どんどんご連絡いただければと思います。
実際 18:00-21:30 までの長時間のセミナーで、たぶん、終わった時には、みなさんぐったりではなかったかと。

さて、今回の岸さんのセミナーに感動して、改めて、残りの課題をまとめてみました。

【JIS2004 についての残る課題】

フォントの対応状況の整理
フォントリンクの整理
Office の対応状況の整理
.NET の対応状況の整理
Internet Explorer の対応状況の整理

まず、フォントについて、より詳しい整理は、正しく JIS2004 に対応する上で必須になると思います。
特に、アドビとの関係、各フォントです。
多くのフォントメーカーは、アドビのフォント規格でフォント作成をされているようです。
また、Vista や Office に標準搭載されるフォントについても、整理された情報が必要です。

HGPゴシックM など HG ... は、JIS2004 の字形ではない. U+8FBB が一点シンニョウになる
SimSun の JIS2004 字形版は SimSun-ExtB.
MingLiU の JIS2004 字形版は MingLiU_HKSCS-ExtB
-ExtB は、結合文字も正しく表示 (ト゜ = U+30C8, U+309A)

次に、フォントリンクの動作についても、現状とあるべき姿が必要になると思います。

Arial Unicode MS の U+8FBB は、一転シンニョウ ?
ミッシングフォントが、どのフォントにマップされているのか、わからない

Office については、当然、SQL Server のクライアントとして整理が必要ですよね。

LEN 関数は、補助文字/結合文字を 2 文字とみる
LENB関数は、どうも SJIS に変換してからバイト数を計算している ?

SJIS コードのない文字を LENB でみると、1 (バイト) として表現されます。
たとえば、白将棋の文字 U+2616 は、1 となります。
ト゜(U+30C8, U+309A) の LENB の値は、 ? ... ぜひ、試してみてください。

.NET での対応状況も、もちろん必要ですね。

Internet Explorer での対応状況も、ぜひほしいところです。

JavaScript, VBScript は ?
フォントリンクおかしくない ?

言語での対応は当然として、フォントリンクは、Office など実装が違うのは困りものです。
たとえば、U+21D8C のメイリオは、IE 上で□に表示されます。Excel 2007では表示されているのに。

最後に、優先度の高いお願いを考えてみました。

メイリオと、MS ゴシック/明朝/MS UI Gothic V5.0 の収容フォントは同じにしてほしい。
これを、わける理由が考え付きません。
Adobe の規格とも調整が必要になると思いますが、ここを同じにできれば、フォントの現状の一部は、すっきりすると思います。
つまり、英文系のフォント + 日本語フォント + 中国語フォントというシンプルな形へ。

以上です。
このほかにも、ATOK などの IME, Java, 他の DB連携、収容文字が含まれているかどうかの判定、正規化などの話もありますが、またの機会へ。

SQLCLR のプログラムソースをデータベースに登録したくない場合 : 「配置オプション」-「コードの配置」をオフ

河端善博 — Tue, 03 Jul 2007 12:09:00 GMT

Visual Studio 2005 で SQLCLR を開発し、データベースにアセンブリを配置すると、データベースには、アセンブリだけでなく、C#やVBのプログラムソースコードも配置されます。

プログラムソースコードを配置したくない場合には、次の手順で設定を変更します。

【プログラムソースコードを配置しない設定】

プロジェクトのプロパティの画面を開きます。
タブ「配置」を選択します
項目「構成」を「Release」にします。
項目「配置オプション」-「コードの配置」のチェックをオフにします。
保存します。

設定を変更後、配置しなおすことにより、アセンブリのみデータベースに登録されるようになります。

プログラムソースコードが、データベース上に登録されている様子は、次のクエリーにて確認することができます。

【データベース上のアセンブリ関連のファイル一覧を表示するクエリー】

　select * from sys.assembly_files

列「name」にファイル名が表示されます。「StringSplit.cs」などのプログラムソースコードのファイル名を確認することができます。続いて、ファイルの内容を表示します。

【データベース上のプログラムソースの内容を表示するクエリー】

select convert(xml, content) from sys.assembly_files where name like 'StringSplit.cs'

プログラムのソースコードを完全に表示することができます。
また、SQL Profiler を利用して、Visual Studio 2005 の配置処理の T-SQL を確認することでも、ソースコードがデータベース上に登録されていることを確認することができます。

本番環境など、ソースコードをデータベース上に置いておく必要がない場合は、配置方法にご注意いただければと思います。

なお、この投稿は、Books Online 英語版につけられたコメントを元に、検証し、まとめました。

　項目: Permissions of Fixed Database Roles
　コメント: Be careful with GRANT VIEW DEFINITION and the Visual Studio SQLCLR project type
　著者: ktegels_DevelopMentor

照合順序 SQL_Latin1_General_Pref_CP437_CI_AS など「Pref」　は、遅い

河端善博 — Fri, 29 Jun 2007 16:17:00 GMT

一部の照合順序が、遅いと問題について検証しました。

結果: _Pref_ を含む照合順序をソート対象にした場合、遅い

これは、来月 2007年7月に出版される Kalen さん著、熊澤さん監修の書籍「Inside SQL Server 2005 ストレージエンジン編」の P.15, P.18 に出てくる「大文字優先」「uppercase preference」のパフォーマンス上の問題を検証したものです。

【キーワード】

大文字優先
uppercase preference

　照合順序の属性の一つです。
　ソート時に、小文字よりも、大文字を優先させます。

【_Pref_を含む照合順序】

SQL_AltDiction_Pref_CP850_CI_AS
SQL_Danish_Pref_CP1_CI_AS
SQL_Icelandic_Pref_CP1_CI_AS
SQL_Latin1_General_Pref_CP1_CI_AS
SQL_Latin1_General_Pref_CP437_CI_AS
SQL_Latin1_General_Pref_CP850_CI_AS
SQL_Scandinavian_Pref_CP850_CI_AS
SQL_SwedishPhone_Pref_CP1_CI_AS
SQL_SwedishStd_Pref_CP1_CI_AS

　大文字優先の属性を持つ、照合順序の名前には、「_Pref_」が含まれます。

　select * from ::fn_helpcollations() where name like '%Pref%'
　によって、確認することができます。

　上記のように、SQL照合順序にのみ、Pref 付きは存在します。
　また、かならず、「_CI_AS」が付きます。
　(大文字小文字を区別しない, アクセントを区別する)

【Perf 指定は、char, varchar, text にのみ影響】

　Pref 指定は、Unicode を扱うデータ型には影響しません。
　char, varchar, text など、Unicode ではないデータ型にのみ影響します。

　たとえば、::fn_helpcollations() の出力は次のようになります。

　name:
　　SQL_Latin1_General_Pref_CP437_CI_AS
　description:
　　Latin1-General, case-insensitive, accent-sensitive, kanatype-insensitive, width-insensitive for Unicode Data,
　　SQL Server Sort Order 33 on Code Page 437 for non-Unicode Data

　Unicode Data の場合と、non-Unicode Data の場合で、処理が違っていますね

【遅い、とは】

　select name from t1 order by name

　テーブル t1 の列 name にインデックスが設定されている場合、上記クエリーの実行プランでは「ソート」を行いません。
　インデックスがあるため、列 name は、ソート済みのためです。

　しかし、列 name の照合順序が SQL_Latin1_General_Pref_CP437_CI_AS の場合、実行プランで「ソート」が発生します。
　このために、遅くなります。

【後記】

　Inside SQL Server 2005 ストレージエンジン編を読み進めたところで、この話が出てきました。
　しかし、「大文字優先」というキーワードが何を意味するのか、わかりませんでした。

　Books Online を検索しても、それらしい記事が見つかりません。
　なんとか Kalen さんが、問題視している点を明確にするため、延々とこの問題を調べてしまいました。

　羽田空港での搭乗待ちのときに調べはじめ、関空までの飛行中、関空快速で揺られながら。。
　電車を降りるまでには、検証が終わり、なにより。

　こんなペースで、この本を読んでいたら、読み終わりそうにないなぁ、と思いつつ。

一時テーブルをビューに、ビューを一時テーブルにするチューニング

河端善博 — Wed, 17 Jan 2007 22:18:00 GMT

一時テーブル、ビューをチューニングです。

一時テーブルを利用しているシステムをビューで置き換えて、実行プランや処理時間を計測します。
逆に、ビューを利用しているシステムを一時テーブルに置き換えて、確認します。

SQL Server は多くの実システムの経験が盛り込まれていますので、実際のデータで調査してみると、置換えによってパフォーマンスやシステム負荷が軽減できる場合があります。

■例: 一時テーブルからビューへ変更

一時テーブルが、その後のクエリーから JOIN やサブクエリーで利用される場合

　一時テーブルが、他のクエリーから JOIN などによって参照される場合、一時テーブルに対して適切なインデックスが期待されます。しかし、一時テーブルにインデックスや統計情報の作成は、一定の時間が必要となります。一時テーブルにプライマリキーを設定した場合も同様です。
　これをビューに置き換えた場合、元のテーブルまたはビューに設定してあるインデックスを利用できますので、一時テーブルの作成時間+インデックスの作成時間よりも高速化することが期待できます。
　インデックス付きビューにより、事前に一時テーブルに相当する内容を、インデックスとして作成しておける場合、さらに高速化が期待できます。

■例:ビューから一時テーブルへ変更

カーソルで参照している場合

　ビューを参照する時間が長くなる場合です。カーソルで参照される場合は、カーソルのループ処理の中で、元のテーブルへのロックを最小限にするために、一時テーブルにするほうがいい場合があります。

実際のデータベースで試してみていただければと思います。

実システムにおいて、一時テーブルからビューへ変更することで、20 % 程度の改善を行うことができました。

ビューの中の計算を、計算列,インデックス付きでチューニング

河端善博 — Wed, 17 Jan 2007 21:53:00 GMT

CREATE VIEW [View1]
AS
select RIGHT(string1, 2) as [s]
from Table2

このようなビューをチューニングします。

ビュー内で計算している列がある場合、計算列または、インデックス付きビューにすることによりチューニングすることができます。

いずれの修正方法も、列の値は、クエリー実行時に計算されるのではなく、元のレコードの更新のタイミングで計算されます。さらに、列に適切なインデックスを設定することもできます。

■有効なシナリオ

参照処理に対して、更新処理の少ないテーブル (マスターテーブルなど)
列の計算に時間のかかる場合

修正は、簡単にできます。

計算列の場合、元のテーブルに計算列を追加した後、ビュー内の列の参照先を、作成した計算列にします。なお、SQL Server 2005 の場合、ビューを修正する必要はありません。ビューを修正しなくても、計算式がビューと計算列で同じ場合、実行プランでは計算列が自動的に採用されます。

インデックス付きビューの場合、ビューをスキーマバインディングに設定し、ビューに対してインデックスを設定します。

既存のビューを見直してみるといいですね。

WHERE 句での数値定数のデータ型指定によるチューニング (SQL Server 2000)

河端善博 — Wed, 10 Jan 2007 15:57:00 GMT

SELECT n5
FROM Table3
WHERE n5 = 99999

このようなクエリーのチューニングです。
n5 のデータ型は、numeric(5, 0) です。

SQL Server 2000 で対応が必要です。
SQL Server 2005 では、特に問題なさそうです。

■問題

　インデックススキャンが発生してしまう。

n5 にインデックス IX_Table3_n5 (n5) を作成している場合でも、インデックスシークではなく、スキャンが発生します。

■原因

　数値定数が smallint や int と認識されてしまうため、データ型の変換が発生し、結果としてインデスックススキャンが発生。
　数値定数は、32767 までの場合、smallint, 2147483647 までの場合 int と解釈されます。
　int と認識された場合、numeric(5,0) より値範囲が大きくなるため、スキャンが発生することになります。

■例

-- インデックスシーク
select n5 from Table3 where n5 = 32767

-- インデックススキャン
select n5 from Table3 where n5 = 32768

■対策

　WHERE 句内のnumericデータ型、decimalデータ型と比較する数値定数は、明示的に変換を行ってから使うようにします。

SELECT n5
FROM Table3
WHERE n5 = convert(numeric(5,0), 99999)

特に 32768 ～ 2147483647 にかかる値範囲となる numeric(5,0) ～ numeric(9,0) の場合に対応が必要となります。

なお、numeric(10,0) 以上の場合は、int よりも値範囲が大きいので、データ型の変換は発生しますが、スキャンではなく、シークにより処理されます。

1,000 件のテストデータで、上記の例を評価したところ、約 10 倍の差がありました。

後方一致を計算列とインデックスでチューニング

河端善博 — Wed, 10 Jan 2007 10:56:00 GMT

select string1
from Table2
where string1 like '%A'

このような後方一致のクエリーをチューニングします。

方法は、string1 を事前に逆順にした計算列を作成し、インデックスを作成します。

具体的には、次のようになります

テーブル:Table2

列名データ型/計算式

id int

string1 varchar(50)

stringR reverse(string1)

インデックス

インデックス名列

PK_Table2 id

IX_Table2_stringR_string1 stringR, string1

列名	データ型/計算式
id	int
string1	varchar(50)
stringR	reverse(string1)

インデックス名	列
PK_Table2	id
IX_Table2_stringR_string1	stringR, string1

テーブルには、計算列 stringR を作成し、reverse(string1) を設定します。
関数 reverse は、'abc' を 'cba' のように文字列を逆順にします。

インデックスには、列 stringR を含む IX_Table2_stringR_string1 を定義しています。
このインデックスには、string1 を含めていますが、これはインデックスのみから結果を返すためにいれています。実際のテーブルでは実行プランを見ながら検討してください。

クエリーを次のように変更します。

select string1
from Table2
where stringR like reverse('%A')

計算列 stringR とインデックス IX_Table2_stringR_string1 を設定することにより、後方一致の検索もインデックスシークで行えるようになります。

※この投稿は、下記の記事を見て思いつきました。

ITPro : 基礎から理解するデータベースのしくみ(5)
　SQL 文はどのように実行されるのか (4)
　「インデックスの作りすぎに注意」
　(2006/1/23 布目綾子)