SQL Server Express Edition

11月ですね。
たまにはSEぽいことも書きましょうか。

1.SQL Server Express Edition
先日、現地のDBが溢れました。
領域フル、これ以上１行も書けないって状況です。

環境は、Windows Server 2003 上にIISのWebサーバ、
そのアクセスログをSQL Serverに保存しています。

問題だったのは、SQL ServerがExpress Editionであり、
DB領域の上限が4GBという制限があることでした。

MSの製品概要には以下の記述があります。
スケーラビリティとパフォーマンス
サポートしている CPU は 1 つだけですが任意のサーバーにインストールできます。
アドレス指定可能な RAM は 1 GB です。
4 GB のデータベース サイズ(★)
参考：Microsoft SQL Server 2005 Express Edition データシート

最後の1文、「4 GB のデータベース サイズ」ということは、
「それを超えると拡張しませんよ」ってことです。

痛たたたた…。
それを現地で、しかも運用開始後
1年以上経過してから気付くってのも間抜けですね。

適切なログローテートの仕組みさえ備えていれば、
通常は起こりえないことです。

仕方ないので、300万件を超える現地テーブルに対し、
CSV形式でデータを保存した後、TRUNCATEを投げました。
初めての経験です、現地DBにTRUNCATE…。
それがどれほど恐ろしいことか…。
(参考：ユーザーの伝票明細テーブルを間違ってTRUNCATEした。 ROLLBACKも効かない。:アルファルファモザイク - ２ちゃんねるスレッドまとめブログ)

運用計画はしっかり立てましょう。

--
2.LIKEと=の挙動差異
これも現地で気付いたことです。

次のSQLの違いについてです。
1)SELECT * FROM hoge WHERE ID = 'A'
2)SELECT * FROM hoge WHERE ID LIKE 'A'
2)はワイルドカードの無いパターン検索です。
どちらもIDが「A」というデータを検索するSQLに見えます。

が、結果が異なりました。

環境は、Windows Server 2003 上の
SQL Serve Enterprise Editionです。

検索結果ですが、以下のようになります。
1)「A」、「 A」、「A 」、「 A」…
2)「A」のみ

不思議ですが、1)のSQLは複数の結果を返します。
1)の場合、「A」の前後に空白が存在するデータも
検索結果に入ってしまっています。

SQLサーバでは、"="は
「前後の空白をTRIMして検索する」らしいです。

猫目が物を知らなかっただけですが、
そもそも同じ検索処理で異なるSQLを書いてはいけない、
ということですね。

え、結末？
直しましたよ、その場でストアドプロシージャを。
ｺｿｰﾘと、ね。