私の会社は、新しいデータベースサーバー用にSQL Server 2012 DenaliとSQL Server 2008 R2のどちらを購入するかという決定に直面しています。どちらを選ぶかという客観的な理由を探しています。
私たちの要件:
現在、次の理由がわかっています。
SQL Server 2012デナリ
SQL Server 2008 R2
どちらか一方を優先するという技術的な理由を見つけることができないようです。基本的には、成功している実績のあるテクノロジーと、利用可能な最新かつ最高のバージョンを選択することになります。
決定を下す客観的な理由は何ですか?
AlwaysOnとColumnStoreには誰もがワクワクしますが、SQL Server 2012の多くのメリットは、ハイエンドエディションに限定されるものではありません。私はスポークスパーソンのように聞こえたくありませんが、SQL Server 2012についてはたくさんのプレゼンテーションを行いました。あなたに合ったどのエディションでも提供できるものはたくさんあると思います。
Partially Contained Databases これにより、シャックルが少ないサーバーまたは環境間でデータベースを移動できます(つまり、サーバーレベルのログインとサーバー照合の依存関係-将来のバージョンでは、リンクサーバーやエージェントジョブなどの厄介なアイテムを処理します。
Management Studio は、Visual Studioに合わせてはるかに優れたツールになりました。 IntelliSenseの方が優れており、他の多くの機能により編集が簡単になります。もちろん、サーバーに2008 R2をインストールして2012バージョンのSSMSを使用することもできますが、それがライセンスに関してどのように機能するかはわかりません。一部のショップでは、バージョンの混在を望まない(最新のツールをダウンレベルサーバーを管理するためのワークステーション)。まだバグがあった初期の段階で変更についてブログに書いたので、RTMの時点でほとんどまたはすべてが修正されているので、ネガを無視してください。以前のバージョンのSSMSを使用する必要があるとき、私は今身震いしています。
メタデータ拡張機能 を使用すると、オブジェクトの結果セットとアドホッククエリを検査でき、クエリの出力をより適切に形成できます。
カスタムサーバーロール を使用すると、付与/取り消しの代わりに、ロールレベルでユーザーにはるかに細かい権限のセットを定義できます1つずつ、または単に複雑さを考慮してsysadminを提供します。
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()
DATETIMEFROMPARTS
に類似した日付/時刻コンストラクター(例:DateSerial
)PARSE()
/ FORMAT()
-.NETと同様TRY_CONVERT()
/TRY_PARSE()
-NULL
/CONVERT
が失敗した場合はPARSE
を返しますExtended Eventsは、構成/表示用の拡張されたUIを備え、最後に完全にトレース/監査機能をカバーします(はるかに優れた因果関係の追跡を含む)。
多くの新しいDMV 、システムプロシージャ、および診断とパフォーマンスのトラブルシューティングのためのShowPlanの機能強化。 CSSが " The Black Box Recorder "と呼んでいるものも見てください。
Server Core を使用すると、すべてのUIコンポーネントなしで最小限のサーバーで実行できます(表面積が小さいほど、より多くのWindows Updateの対象となるOSの部分が少なくなるため、安全でメンテナンスが軽減されます)。
フルテキスト検索は、重要な基本的なパフォーマンスの強化に加えて、セマンティック検索(キーワードと考えます)とカスタマイズ可能な近接性/ NEARを取得します。
AWEはサポートされなくなりました。つまり、32GBのRAM 4GBを使用することで、ようやく古い32ビットハードウェアをやめる気になります。
以下は、要求に応じた「新しいリリースの最初のバージョンの信頼性の実際の証拠」に関するいくつかの例です。これは完全な分析を意図したものではなく、何を調査したいかについての提案です。
MSDNのWebサイトで、「SQL Server 2008 Service Pack 1で修正される問題のリスト」および「SQL Server 2008 Service Pack 3で修正される問題のリスト」をグーグル検索できます。両方のリストの問題の数と重大度を比較します。 IMOの最初のリストは長く、次のように、1日が台無しになる可能性のあるアイテムが多くなっています。
もう1レベルドリルダウンして、1つのコマンド、MERGEだけを考えてみましょう。 SQL 2008の一部としてリリースされ、いくつかの問題がありました。以下のリンクで説明されています。
そのため、SQL 2008の最初のリリースの時点で、MERGEを使用しないことにしました。私は今、2008 R2でMERGEを頻繁に使用していますが、これは本当に素晴らしい機能だと思います。
編集:これは、最近修正されたSQL 2012の不具合のリストです 。それが役に立てば幸い。
別の編集:MERGEは非常に重要な改善であるため、より詳細な分析のために選択しました。実際、これはOracleに追いつくための主要なステップであり、生産性を向上させます。そのため、MERGEはSQL 2008のリリース時に多く販売されました。しかし、それが最初にリリースされたとき、それは本格的な生産システムで完全に使用する準備ができていなかったし、プレゼンテーション/記事/ブログ投稿などからそれを簡単に知る方法はありませんでした。
同様に、スナップショット分離は機能する素晴らしい新機能ですが、CHECK制約でスカラーUDFを呼び出すことがすべての場合に機能するわけではないため、データの整合性が必要な場合は運用環境で使用しないでください。ただし、両方の新機能は、「SQL xxxxの新機能」のプレゼンテーションや、書籍、記事などで、同様の熱意をもって推奨されました。
新しい機能については、十分に注意する必要があります。それらのすべてが有用/信頼性/パフォーマンスに優れているとは限りません。
ここで言及されていない1つの点は、機能セットとはまったく無関係です。新しいビルドを実行している場合は、データベースのアップグレードをかなり長く延期できるため、移行コストを節約できます。
グリーンフィールドプロジェクトの場合、バグを回避し、発生した場合はベンダーと一緒にバグを発生させる余地があります。そのため、完全に制御されていないプロセスではありません。 SQL Server 2005で最初のデータウェアハウスプロジェクトの1つに携わっていたのは、RTMに移行したときと同じでした。
2008R2の機能セットが望みどおりの動作をする場合は、バグ/回避策のリスクと、アップグレードの必要性を先延ばしにしてアップグレードサイクルを保存することの価値のどちらをとるかが決定されます。
新しく購入する場合の選択は、アップグレードを検討する場合とは大きく異なります。新しいものを購入することは、常に入手可能な最新バージョンを購入するべきだと私は信じています。 2008バージョンは、2012バージョンよりもはるかに早くサポートされなくなります。このバックエンドを長い間使用することになるので、最新のものから新しく開始することをお勧めします。
最初のサービスパックの必要性については、それがわかる前にリリースされます。また、新しい開発を行っているため、何百万ものレコードがあるレガシーデータベースが直面するほどの問題は修正されません。
ここで、新しいサーバーを取得するだけで古いデータベースをそこに配置する場合、問題は何からアップグレードするのですか?データベースが既に2008データベースである場合、同じバージョンを使用することによるリスクは大幅に軽減されます。アップグレードする場合は、ご使用のバージョンから2012に直接アップグレードできるかどうかを確認してください。