サーバーのアップグレードプロジェクトに関するDBAとのミーティング-一般的な懸念事項

私はネットワーク/ Windowsの管理者であり、SQLサーバーのアップグレードプロジェクトの監督を任されています。DBAと会って、アップグレードに関する彼らのニーズ/要望について話し合う必要があります。完全に盲目になりたくないので、まず皆さんにお聞きしたいと思いました。SQL Server 2008からSQL Server 2008 R2に移行しており、可能であればWindows Server 2008 R2に移行する予定です。DBAとして、このようなアップグレードについてどのような懸念がありますか？同時に見たいことはありますか？

システムの性質に関する情報（質問についての私のコメントを参照）またはアップグレードする理由がないと、具体的または簡潔なアドバイスを提供することは困難です。

開始点として、新しいサーバを構築するための優れたチェックリストの多くがあり、ブレントOzarとジョナサンKehayiasは 2つの良い例です。これらのガイドの多くの推奨事項から、強調する価値のある項目がいくつかあります。これらは、私が最も頻繁に設定ミスに遭遇するものです。

• ストレージ-パーティションアラインメントを確認します。ただし、通常は手動のパーティションアラインメントは必要ないため（非標準/エキゾチックなSANは別として）、これはW2K8 +の場合はそれほど問題にはなりません。データドライブの場合、デフォルトの4kbではなく、64kブロックサイズでフォーマットします。a）サーバーXとサーバーYを比較するための基準があり、b）このサーバー機能にある程度の自信があるように、SQLIOテストの基本セットを実行します。

• ウイルス対策-MDF、NDF、LDFファイルがウイルス対策スキャナーから除外されていることを確認します。これらは、ビジーなシステムで混乱を引き起こす可能性があります。それが起こる前に修正してください。

• モデルデータベース-モデルデータベースに加えられた変更は、作成したすべてのユーザーデータベースに反映されます。モデルのサイズと成長率を、環境/システムに適した値に設定します。他のガイドの代わりに、SIMPLEリカバリー（誰かがログバックアップの構成を忘れた場合）、2048MBのデータファイル、1024MBの拡張、1024MBのログファイル、512MBの拡張（JKのチェックリストによる）。

ビジネスクリティカルであると見なされ、厳しいSLAの対象となるサーバー/システム/アプリケーションの場合は、より悪いものを計画します。これらを使用すると、ビジネスまたはユーザーの観点から見ると、アップグレードがダウングレードにならないことができる限り100％近く確認する必要があります。そのレベルの信頼を得るためには、さらにいくつかテストし、テストし、テストする必要があります。

大規模なシステムでは、最適化のためにハック/回避策/ヒントが必要なクエリが1つまたは2つあります。いくつかは故意であり、当時の最良のアドバイスに基づいており、他は忘れられていた緊急修正です。これらは、クエリオプティマイザーの調整と改善の結果、アップグレード時に予期せず動作を変更するクエリです。それらを見つける唯一の方法は、新しいキットで実行することです。

私が好むアプローチは、RMLツールを使用したワークロードのキャプチャと再生です。SQL CATからRMLをまさにこの目的で使用するための優れたガイド、RMLユーティリティ9.0を使用したMicrosoft SQL ServerのPrecision Performanceがあります。

SQL 2008からSQL 2008 R2は大きなスイッチではありませんが、Windows 2003からWindows 2008に移行する場合は、ホストベースのファイアウォールに対応する必要があります。他に気にする必要のある問題は、エージェントジョブ、master / msdb / modelの権限、サーバー間でのログインの移行、バックアップを新しいサーバーに復元するか、インプレースアップグレードするか、互換性モードなどです。