ドライブvsマウントポイント？

以前のシニアDBAは、会社全体のすべてのSQL Serverのすべてのドライブにマウントポイントを設定しました。新しいシニアDBA は、マウントポイントが私たちの標準を変更したいので怖がっています（主に、経験がないためだと思います）。

多数のインターネット検索の結果に基づいて、マウントポイントを使用しない理由（SQL Server 2000以降）が見つかりません。

このトピックに関するWindows OSの制限を知っている人はいますか？

• 最近、「OSはマウントポイントを認識しない」という主張をよく耳にします。（私たちが使用しているWindows Serverのバージョンに関する私の調査に基づいて、真実ではありません）。

SQL Serverでマウントポイントを使用しない証拠または経験に基づいた理由はありますか？

• ドライブ文字の不足は問題ではないと仮定します。

マウントポイントは、ワークロードの分離に非常に役立つことを理解しています。

マウントポイントは、データファイル、ログファイル、およびtempdbの各ドライブよりも効率的に、さまざまな種類のデータおよびログファイル（システムデータベースファイル、ユーザーデータベースファイル、tempDB）のワークロードを実際に分離/分離するという理解を確認または反論できますか？ ？

マウントポイントのもう一方の端に依存します。マウントがすべて同じ物理ドライブに分散しているすべてのLUNである場合、何のメリットもありません。LUNSが共有された低速のiSCSIチャネル上にある場合は、おそらく利益がありません。LUNSがすべて1つのコントローラーの下にある場合...プレイ中の変数の数を確認できます。誰も答えはありません。

マウントポイントの構成を決定するには、「Boe ProxによるPowerShellを使用したマウントポイントの特定」を参照してください。

SQL Serverはマウントポイントに問題はありません。これらはOSレベルで定義され、SQL Serverは「^1を知りません」それらはマウントされているように見えるドライブと同じボリュームではありません。

ただし、一部の監視ツールは、その最後の文に基づいて悪い情報を提供する場合があります。

たとえば、次のような3つのマウントポイントがある場合

1. C:\SQLData\SQL_Data すべての.MDBファイルが保存されている場所
2. C:\SQLData\SQL_Logs すべての.LDFファイルが保存されている場所
3. C:\SQLData\SQL_Backups すべての.BAKおよび.TRNバックアップファイルが保存されている場所

その後、SQL Serverは問題なく動作します。ただし、ディスクのスペースが不足しているときに警告する何らかのツールを実行すると、その下にマウントされているボリュームではなく C：をチェックする可能性があるため、それらのマウントポイントのディスクスペースが不足していることがわかりません。また、さまざまな "ベストプラクティス"クエリは、SQL Serverが同じディスク上にあるとみなすため、データ、ログ、およびバックアップをすべて同じディスク上に置くべきではないことを示す誤った警告をスローします。これらは偽のフラグであり、無視できます。

ただし、基本的には、サーバー監視にいくつかの追加手順を設定して、C：ドライブに十分なスペースがあり、各マウントポイントにも十分であることを確認する必要があります。

SQL Serverでマウントポイントを使用したとき、私が遭遇した唯一の問題がありました：利用可能な空き領域に関する誤ったデータと、すべてのデータを保持してはならないという誤ったエラーを示すSQL Serverシステムヘルスレポート同じドライブに。これらは誤ったエラーであることがわかっているため、無視するのは簡単です。

¹ SQL Serverにはマウントポイントを認識させるデータがありますが、実際の使用の観点からは、動作に違いはありません。OSが仕様を処理することを信頼して、「機能する」だけです。ローカルドライブとして接続されているiSCSI LUNの詳細を処理するためにOSを信頼するように。

CM_Daytonの回答とSean Gallardyの回答に加えて、マウントポイントでまだ特定されていない問題の1つはセキュリティに関連しています。マウントポイントフォルダーにSQLアクセス許可を設定するためのガイドラインを引用するには：

マウントポイントのルートフォルダーは通常のフォルダーのように見え、フォルダーへのアクセスと同じ方法でアクセスされますが、通常のフォルダーではありません。その結果、マウントポイントのルートフォルダーにアクセス許可を設定すると、通常のフォルダーと同じようにアクセス許可が「親ボリューム」から継承されません。実際、それらはまったく継承されません。これは、マウントされたボリュームは「親ボリューム」の子であるように見えますが、そうではないためです。「親ボリューム」からのパスを介して、マウントされたボリュームにアクセスするだけです。

簡単に言えば、マウントポイントルートフォルダーを使用する場合は、マウントフォルダーに異なる方法でアクセス許可を割り当てる必要があります。通常のフォルダーで行うようにアクセス許可を割り当てる代わりに、ボリュームにアクセス許可を割り当てる必要があります。繰り返しますが、同じ記事から（強調表示はマイクロソフトのものです）：

落とし穴

残念ながら、Windowsエクスプローラーを使用してマウントポイントルートフォルダーのアクセス許可を設定/表示することは可能ですが、マウントポイントルートフォルダーのアクセス許可が有効に見え、「適切な」継承されたアクセス許可を確認できるため、予期しない結果を招く可能性がありますただし、これらはマウントされたボリュームに適用される権限ではありません。

• https://connect.microsoft.com/SQLServer/feedback/details/569895/installation-of-sql-server-2008-r2-on-mount-points-fails

ガイドライン

1. マウントポイントのルートフォルダーにファイルを直接配置しないことをお勧めします。これは、フォルダのアクセス許可を常にチェックする傾向があるため、アクセス許可の管理がはるかに簡単になります。この場合、誤解を招く可能性があります。代わりに、マウントポイントルートフォルダーの下にサブフォルダーを作成し、そのサブフォルダーに適切なアクセス許可を設定します。サブフォルダーは通常のフォルダーであるため、観察して設定するフォルダーのアクセス許可は実際に適用されるアクセス許可です。したがって、前の例を使用して、新しいフォルダーD：\ FolderForVol3 ** SubfolderXYZ **を作成します。ここで、通常と同じように、その新しいSubfolderXYZフォルダーに対してフォルダーのアクセス許可を設定します。
2. マウントポイントのルートフォルダーにアイテムを直接配置する必要がある場合（推奨されるアプローチではありません）、フォルダーのアクセス許可ではなくボリュームのアクセス許可を設定する必要があります。これは、マウントポイントのルートフォルダーのアクセス許可が、マウントされたボリュームに実際に設定されるアクセス許可ではないことを思い出してください（マウントポイントのルートフォルダーは実際のフォルダーではないため）。ボリュームのアクセス許可は次のように設定できます。
   • Start-> run-> diskmgmt.msc（ボリュームのプロパティを表示 http://technet.microsoft.com/en-us/library/cc740097.aspx）
   • ボリューム->プロパティ->セキュリティタブを選択します
3. SQLが使用する新しいフォルダーを追加する場合、SQLアクセスに必要な権限に注意してください。
   • SQL Server 2012以降、アクセス許可は各サービスのサービスごとのSIDに割り当てられます。 http://msdn.microsoft.com/en-us/library/jj219062.aspx
   • Windowsサービスアカウントと権限の構成 http://msdn.microsoft.com/en-us/library/ms143504.aspx

MSが推奨するように、マウントポイントの下のサブフォルダーにすべてを入れ子にしたくない場合、アクセス許可を割り当てるのが最も簡単な方法はcacls.exeユーティリティを使用することです。詳細な手順については、Windows Server 2003のNTFSファイルシステムボリュームのルートディレクトリにアクセス許可を適用できないを参照してください。

まだ完全に解決された問題ではないと思います。この最近の質問である、マウントポイントのアクセス許可に関するSQL Server FCIのインストールの問題は、Windows 2012 with SQL Server 2016でも発生する可能性があることを示しています。

割り当てるセキュリティに応じて、コマンドは異なる場合がありますが、テストは成功の鍵となりますので、ライブマウントポイントに対してコマンドを実行する前にコマンドに精通してください\E。

多数のインターネット検索の結果に基づいて、マウントポイントを使用しない理由（SQL Server 2000以降）が見つかりません。

主な理由は、誰かが彼らと悪い経験をした（または逆に、彼らと経験がなかった）ことであり、彼らを完全に追い払った...永遠に。これは、個人の好みとしても知られています。

今、そこにあるあなたがそれらを使用することができなかったいくつかの理由が。私が考えることができる一番の理由は、サードパーティのドライバーまたはアプリケーション/ツール（フィルタードライバー、ディスク複製など）がそれをサポートしていないことです。これの簡単な例は、特定のクラスターサイズのみで、特定のボリュームで2 TBを超えることができなかった、NTFS以外をサポートしていないブロックレベルのディスク複製ツールです。

このトピックに関するWindows OSの制限を知っている人はいますか？

いいえ。多くのマウントポイントを作成できます。実際、Windows Server内でかなりの制限に達する前に、デバイスインターフェイスに問題が発生します（17年以上前のバージョンのWindows Serverを使用していない場合...）。

•最近、「OSはマウントポイントを認識しません」という主張をよく耳にします。（私たちが使用しているWindows Serverのバージョンに関する私の調査に基づいて、真実ではありません）。

OSがマウントポイントを認識しなかった場合、マウントポイントをどのように使用できますか？それは意味がありません。

OSがマウントポイントを認識しない場合、なぜそれらを追跡してメタデータをクエリするのですか？また、マウントポイントは、OSがサポートする場合とサポートしない場合があるファイルシステムの構造であることに注意してください。すべてのファイルシステムがマウントポイントをサポートしているわけではありませんが、Windows Serverで最も一般的なファイルシステムはNTFSであり、実際にはマウントポイントをサポートしており、しばらくの間サポートしています。

この偽のアイテムをさらに持ち帰るだけです。Windowsクラスタリングには、クラスター共有ボリューム（CSV）と呼ばれるものがあります。CSVは、ボリュームのマウントポイントを実際に使用します...これは、テクノロジを使用するネイティブアイテムです。私は、これを問題で教育する必要があるとあなたに言った人は誰でも言わなければなりません。

SQL Serverでマウントポイントを使用しない証拠または経験に基づいた理由はありますか？

はい、Windows NT 4を実行しているサーバーが常に1つあります。そこでは使用しないでください。また、サポートされているバージョンのWindows Serverを実行しており、更新プログラムを最新の状態に保ちたい場合もあります。

ただし、上記で説明したように、サポートされていないサードパーティのアイテムや、それらと適切に動作しないサードパーティのアイテムがある場合があります。そのプロバイダーをドロップして、新しいプロバイダーを見つけたと思います。

マウントポイントは、ワークロードの分離に非常に役立つことを理解しています。

マウントポイントは非常に便利です。それらを使用する多くの方法がありますが、最も一般的なのは、Windowsのドライブ文字の制限を回避することです（たとえば、非常に多くあります）。次に最も一般的な使用方法は、管理可能なサイズの小さなドライブ（LUN、仮想ディスク[VMDK、VHDX]など）を使用して、めちゃくちゃで管理が難しいモノリスボリュームからの脱出を支援することです（10TBの範囲でドライブを管理することは本当に問題になります単一のLUN、仮想ディスクなど）。特に、実装が可能な使用量より少ないNTFSの古いバージョンでは...たとえば、Windowsの古いバージョンでは、最大NTFSサイズは2TBでした。

ワークロードの分離は別の優れた用途です。あなたは間違いなく見ることができ、多くの用途があり、それはあなたの個々のユースケースに依存します。また、不適切な使用方法もあります。たとえば、すべてをマウントポイントにする必要があるという包括的なステートメントを作成するなどです。それは、その時点での管理上のオーバーヘッドです。

マウントポイントは、共有アプリケーションを備えたサーバーの場合、または典型的なDZボリュームだけでなくデータをスライスする場合の方法です。

たとえば、1つのアプリケーションデータ、ログ、一時ファイルをすべてe:ドライブにインストールできます。E:/MP_1ビジネスAのデータファイルE:/MP_2、ログE:/mp_3ファイルにビジネスAの一時ファイルなどを含めることができます。次に、F:ドライブのマウントポイントにビジネスBがあります。各マウントポイントには独自のスペースがあります。

OSにはMPの問題はまったくありません。ClustersとAlways Onは、MPに問題はありません。私は、SQLサーバーの大部分がMPにインストールされている非常に有名な銀行で働いていました。DBAがそれらを使用し、概念を理解すると、それを必要とするショップでより簡単なソリューションにそれらを推進します。

MPルートには何もインストールしないことが言及されました。そうです。例としてDのルートに何もインストールしないようなMPルートには何もありません。

Foglight、Guardiam、EMS、PBMなどの監査および監視ソリューションにも、マウントポイントに関する問題はありません。