2008 R2よりもSQL Server 2012を好む客観的なビジネス上の理由は何ですか？

私の会社は、新しいデータベースサーバー用にSQL Server 2012 DenaliとSQL Server 2008 R2のどちらを購入するかの決定に直面しています。客観的な理由を探して、どちらかを選択します。

私たちの要件：

• Standardエディション（経済的理由およびエンタープライズ機能の必要性の欠如のため）
• OLTPワークロード（つまり、新しいウィンドウ関数と列ストアインデックスは不要です）
• 10〜100 GBのデータベースサイズ
• ビジネスインテリジェンス機能は必要ありません。リレーショナルエンジンのみが必要です
• 同期データベースミラーリング

現在、次の理由がわかっています。

SQL Server 2012デナリ

• 利用可能な最新バージョン

SQL Server 2008 R2

• 実績のある技術

どちらか一方を好むという技術的な理由はあまりないようです。基本的に、成功している実績のあるテクノロジーと、利用可能な最新かつ最高のバージョンを選択することになります。

決定を下す客観的な理由は何ですか？

AlwaysOnとColumnStoreには誰もが興奮していますが、SQL Server 2012の利点の多くはハイエンドエディションに限定されません。私はスポークスマンのように聞こえたくありませんが、SQL Server 2012で多くのプレゼンテーションを行ってきました。あなたに合ったエディションで提供できるものはたくさんあると思います。

• いくつかの少ないシャックルでサーバーまたは環境間でデータベースを移動できる部分的に含まれるデータベース（つまり、サーバーレベルのログインとサーバー照合順序の依存関係-将来のバージョンでは、リンクサーバーやエージェントジョブなどの厄介なアイテムを処理します）。

• Management Studioは、Visual Studioと連携してより優れたツールになりました。IntelliSenseの方が優れており、他の多くの機能により編集が容易になります。もちろん、サーバーに2008 R2をインストールして2012バージョンのSSMSを使用することもできますが、それがライセンス面でどのように機能するかわかりません。また、一部のショップでは混合バージョンが必要ではありません（最新のツールはダウンレベルサーバーを管理するための私のワークステーション）。バグがまだあった初期の段階で変更についてブログに書いたので、RTMの時点でほとんどまたはすべてが修正されているので、マイナスを無視してください。SSMSの以前のバージョンを使用しなければならないとき、私は身震いします。

• メタデータの機能強化により、オブジェクトおよびアドホッククエリの結果セットを検査できるようになり、クエリの出力をより適切に整形できるようになりました。

• カスタムサーバーロールを使用すると、ユーザーに1つずつ付与/取り消ししたり、複雑さを与えてシステム管理者に付与したりする代わりに、ロールレベルでより詳細な権限のセットを定義できます。

• FileTableを使用すると、ドキュメントのテーブルのようにフォルダーを管理できますが、コンテンツを外部から制御できます（T-SQLでこれを実行できることを想像してください。cmdまたはPowerShellでそれがどれほど難しいか想像してくださいUPDATE C:\Docs\*.* SET ReadOnly = 1 WHERE Author = 'Bob' AND Created < '20100101';）。 FileStreamはWinFSに適合し、起動するための使いやすさが得られます。

• T-SQLの機能強化により、以前のバージョンでは苦労した多くのことができます。

  • THROW （再レイズと考えてください）
  • OFFSET/FETCH（より単純なANSI標準ページング）
  • SEQUENCE （Oracleのような集中IDENTITYメカニズム）
  • ウィンドウ化/フレーミングの強化（ここでは、実行中の合計のパフォーマンスなど、さまざまなもの）
  • IIF()/ CHOOSE()/ CONCAT()/EOMONTH()
  • VB DATETIMEFROMPARTSと同様の日付/時刻コンストラクター（例）DateSerial
  • PARSE()/ FORMAT()-自分の.NET対応のような
  • TRY_CONVERT()/ TRY_PARSE()- / 失敗したNULL場合に戻るCONVERTPARSE

• 拡張イベントには、構成/表示用の拡張UIがあり、最終的にトレース/監査機能を完全にカバーします（より優れた因果関係追跡を含む）。

• 診断とパフォーマンスのトラブルシューティングのための多くの新しいDMV、システム手順、ShowPlanの機能強化。また、CSSが「ブラックボックスレコーダー」と呼んでいるものも見てください。

• Server Coreを使用すると、すべてのUIコンポーネントを使用せずに最小限のサーバーで実行できます（表面積が小さいほど、Windows Updateの対象となるOSの部分が少なくなるため、安全性が高まり、メンテナンスが軽減されます）。

• 全文検索では、セマンティック検索（キーワードを考える）およびカスタマイズ可能な近接/ NEARだけでなく、重要な基礎となるパフォーマンスの強化が行われます。

• AWEはサポートされなくなりました。つまり、32 GBのRAMを搭載したx86上のSQL Serverインスタンスは4 GBしか使用できなくなります。したがって、最終的に古い32ビットハードウェアを使用する意欲があります。

以下は、「新しいリリースの最初のバージョンでの信頼性に対する賛成または反対の実際の証拠」に関するごく一部の例です。これは完全な分析を目的としたものではなく、研究対象の提案です。

MSDNのWebサイトで、「SQL Server 2008 Service Pack 1で修正された問題のリスト」および「SQL Server 2008 Service Pack 3で修正された問題のリスト」をグーグル検索できます。両方のリストで問題の数と重大度を比較します。IMOの最初のリストはより長く、次のような、私の一日を台無しにする可能性のあるアイテムがより多くあります。

• Windows VistaまたはWindows Server 2008を実行しているクライアントコンピューターでSQL Serverの名前付きインスタンスに接続するとエラーメッセージが表示される
• ログリーダーエージェントを実行してトランザクションをレプリケートすると、ログリーダーエージェントは一部のトランザクションをスキップします
• SQL Server 2008で外部結合操作を伴うクエリを実行するとエラーメッセージが表示される
• SQL Server 2008で作成されたクラスター化インデックスがないテーブルで更新または削除操作を実行すると、エラーメッセージが表示される
• SQL Server 2008で複数の接続でクエリを同時に実行すると、パラメーターとRECOMPILEオプションを使用するクエリが誤った結果を返す

もう1つのレベルをドリルダウンして、1つのコマンド、MERGEだけを考えてみましょう。SQL 2008の一部としてリリースされ、次のリンクで説明されているいくつかの問題があります。

• 興味深いMERGEバグ、
• SQL Server 2008 RTM MERGEのバグと修正、
• 外部キー制約は、非クラスタ化インデックスに作成されMERGEのバグ（2008RTM） 、
• INSERTは/使用し、濾過したインデックスをDELETE MERGE文のバグ、
• MERGEクエリプランでは、FKおよびCHECK制約違反が許可されます。
• 参照整合性バイパスMERGE文、
• パラメータ化されたDELETEおよびMERGEは、外部キー制約違反を許可します。

そのため、SQL 2008の最初のリリースの時点で、MERGEを使用しないことにしました。私は現在、2008 R2でMERGEを多く使用していますが、これは本当に素晴らしい機能だと思います。

編集： ここに、最近修正されたSQL 2012の欠陥のリストがあります。それが役に立てば幸い。

別の編集： MERGEは非常に重要な改善であるため、より詳細な分析のためにMERGEを選択しました。実際、これはOracleに追いつくための重要なステップであり、生産性を向上させます。そのため、MERGEはSQL 2008のリリース時に多く販売されています。しかし、最初のリリース時には本格的な本番システムで使用する準備が完全に整っていなかったため、プレゼンテーション/記事/ブログ投稿などから簡単に知る方法はありませんでした。

同様に、スナップショットアイソレーションは機能する素晴らしい新機能ですが、CHECK制約でスカラーUDFを呼び出すことはすべての場合に機能するわけではないため、データの整合性が必要な場合は本番環境で使用しないでください。ただし、両方の新機能は、「SQL xxxxの新機能」プレゼンテーション、書籍、記事などで、同様の熱意で推奨されました。

私たちは新機能に非常に注意する必要があります-それらのすべてが役に立つ/信頼できる/性能があるとは限りません。

ここで言及されていない点の1つは、機能セットとは完全に無関係です。新しいビルドを行う場合は、データベースのアップグレードをかなり長く延期できます。これにより、移行コストを節約できます。

グリーンフィールドプロジェクトの場合、バグを回避し、バグが見つかった場合はベンダーに報告するための息抜きがあります。そのため、完全に制御されていないプロセスではありません。私はSQL Server 2005の最初のデータウェアハウスプロジェクトの1つに参加しましたが、それがRTMに移行したので、私たちはそれをやめました。

2008R2の機能セットが希望どおりに機能する場合は、バグ/回避策のリスクと、アップグレードの必要性を延期してアップグレードサイクルを節約することの価値を決定します。

新しく購入するときの選択肢は、アップグレードを検討しているときとは大きく異なります。新しいものを購入することは、あなたが入手できる最新バージョンを常に購入すべきだという私の信念です。2008バージョンは、2012バージョンよりもはるかに早くサポートされなくなります。このバックエンドを長期間使用するため、最新のものから始めてください。

最初のサービスパックの必要性については、知らないうちに公開されます。新しい開発を行っているため、修正される問題は、数百万のレコードを持つレガシーデータベースほど影響はありません。

今、新しいサーバーを取得するだけで古いデータベースを配置する場合、質問は何からアップグレードするのでしょうか？データベースがすでに2008データベースである場合、同じバージョンを使用するリスクは大幅に低くなります。アップグレードする場合は、バージョンから2012に直接アップグレードできるかどうかを確認してください。