ドライブ対マウントポイント？
以前の上級DBAは、会社全体のすべてのSQL Serverのすべてのドライブにマウントポイントを設定しました。新しいシニアDBA マウントポイントに恐怖を感じる 私たちの基準を変更したい（主に、彼はそれらの経験がないためだと思います）。
多数のインターネット検索の結果に基づいて、マウントポイントを使用しない理由（SQL Server 2000以降）を見つけることができません。
このトピックに関するWindows OSの制限を知っている人はいますか？
- 最近、「OSがマウントポイントを認識しない」という主張をよく耳にします。 （私が使用しているWindows Serverのバージョンに関する私の調査に基づくと、正しくありません）。
SQL Serverでマウントポイントを使用しない証拠または経験に基づく理由はありますか？
- ドライブ文字の不足は問題ではないと仮定します。
マウントポイントがワークロードの分離に非常に役立つことは私の理解です。
マウントポイントが実際にさまざまなタイプのデータとログファイル（システムデータベースファイル、ユーザーデータベースファイル、tempDB）のワークロードを、データファイル、ログファイル、tempdbの各ドライブよりも効率的に分離/分離するという私の理解を誰もが確認または否定できますか？
マウントポイントの反対側に何があるかによって異なります。マウントがすべて同じ物理ドライブにまたがるLUNSである場合、メリットはありません。 LUNがすべて共有された低速のiSCSIチャネル上にある場合、おそらく効果はありません。すべてのLUNが1つのコントローラーの下にある場合は、いくつの変数が機能しているかがわかります。答えは1つではありません。
マウントポイントの構成を確認するには、Boe Proxによる PowerShellを使用したマウントポイントの検索 を参照してください。
SQL Serverはマウントポイントに問題はありません。これらはOSレベルで定義されており、SQL Serverは「わからない」1「それらは、マウントされているように見えるドライブと同じボリュームではありません。
ただし、一部の監視ツールは、最後の文に基づいて悪い情報を提供する場合があります。
たとえば、次のような3つのマウントポイントがある場合
C:\SQLData\SQL_Dataすべての.MDBファイルが保存されている場所C:\SQLData\SQL_Logsすべての.LDFファイルが保存されている場所C:\SQLData\SQL_Backupsすべての.BAKおよび.TRNバックアップファイルが保存される場所
その後、SQL Serverは問題なく動作します。ただし、ディスクの空き容量が少ないときに警告するツールを実行すると、C：がチェックされ、その下のマウントされたボリュームはチェックされない可能性があるため、いつこれらのマウントポイントのディスク領域が不足しています。また、さまざまな「ベストプラクティス」クエリは、SQL Serverが同じディスク上にあると見なしているため、データ、ログ、バックアップをすべて同じディスク上に置くべきではないという誤った警告をスローします。 これらは偽のフラグであり、無視できます。
ただし、基本的にはサーバー監視でいくつかの追加手順を設定して、C：ドライブに十分なスペースがあり、各マウントポイントにも十分であることを確認します。
SQL Serverでマウントポイントを使用した回数、これは私が遭遇した唯一の問題です：利用可能な空き領域に関する誤ったデータを提供するSQL Serverシステムヘルスレポート、およびすべてのデータを保持するべきではないという誤ったエラー同じドライブ上。あなたはそれらが誤ったエラーであることを知っているので、それらは無視するのに十分簡単です。
1 SQL Serverにはマウントポイントを認識させるデータがありますが、実用上の観点からは動作に違いはありません。 OSを信頼して詳細を処理することで、「機能するだけ」です。 OSを信頼して、ローカルドライブとして接続されているiSCSI LUNの詳細を処理するように。
多数のインターネット検索の結果に基づいて、マウントポイントを使用しない理由（SQL Server 2000以降）を見つけることができません。
主な理由は、誰かが彼らとの悪い経験をしていて（または逆に、彼らとの経験がなかった）、彼らを完全に乗り越えてしまったことです...永遠に。これは、個人の好みとしても知られています。
今、それらを使用できなかったいくつかの理由があります。考えられる一番の理由は、サードパーティのドライバーまたはアプリケーション/ツール（フィルタードライバー、ディスクレプリケーションなど）がサポートしていないことです。この簡単な例は、特定のクラスターサイズのみでNTFS以外をサポートせず、特定のボリュームに対して2 TB>を超えることができなかったブロックレベルのディスクレプリケーションツールです。
このトピックに関するWindows OSの制限を知っている人はいますか？
いいえ、多数のマウントポイントを作成できます。実際、Windows Serverの内部でかなりの制限に達する前に、一般的にデバイスインターフェイスに問題があります（17年以上前のバージョンのWindows Serverを使用していない場合...）。
•最近、「OSがマウントポイントを認識しない」という主張をよく耳にします。 （私が使用しているWindows Serverのバージョンに関する私の調査に基づくと、正しくありません）。
OSがマウントポイントを認識しない場合、どのようにしてマウントポイントを使用できますか？それだけでは意味がありません。
OSがマウントポイントを認識しない場合、なぜ それらを追跡し、それらのメタデータをクエリする ？また、マウントポイントは、OSがサポートする場合とサポートしない場合があるファイルシステムの構成要素であることに注意してください。すべてのファイルシステムがマウントポイントをサポートしているとは限りませんが、Windows Serverで最も一般的なファイルシステムは 実際にはマウントポイントをサポートしているNTFS であり、しばらくの間使用できます。
この偽りのアイテムを持ち帰るためだけに。 Windowsクラスタリングには、実際にボリュームのマウントポイントを使用するクラスター共有ボリューム（CSV）と呼ばれるものがあります...これは、テクノロジーを使用したネイティブアイテムです。私は、あなたがこれを問題で教育する必要があるとあなたに言った人は誰でも言わなければなりません。
SQL Serverでマウントポイントを使用しない証拠または経験に基づく理由はありますか？
はい、Windows NT 4を実行しているサーバーは常に存在します。そこでは使用しないでください。また、サポートされているバージョンのWindows Serverを実行していて、最新の状態を維持していることを確認することもできます。
ただし、上記で説明したように、サポートされていない、または適切に動作しないサードパーティのアイテムがある場合があります。そのプロバイダーをドロップして、新しいプロバイダーを見つけると思います。
マウントポイントがワークロードの分離に非常に役立つことは私の理解です。
マウントポイントは非常に便利です。それらを使用するには多くの方法がありますが、最も一般的なのは、Windowsのドライブ文字の制限を回避することです（例：非常に多くあります）。次の最も一般的な使用法は、管理しやすいサイズの小さいドライブ（LUN、仮想ディスク[VMDK、VHDX]と考える）を使用して、めちゃくちゃ大きくてめったに管理できないモノリスボリュームを回避するのに役立ちます（10TBの範囲でドライブを管理することは実際に問題になります）。単一のLUN、仮想ディスクなど）。特に、実装が可能な使用量よりも少ないNTFSの古いバージョンでは...たとえば、古いバージョンのWindowsでは、最大NTFSサイズは2TBでした。
ワークロードの分離は、もう1つの優れた用途です。あなたは間違いなく見ることができます、多くの用途があり、それはあなたの個々のユースケースに依存します。それを使用する不適切な方法もあります...すべてがマウントポイントである必要があるという包括的なステートメントの作成など。これは、その時点での管理上のオーバーヘッドに過ぎません。
CM_Daytonの answer およびSean Gallardyの answer に加えて、マウントポイントでまだ特定されていない問題の1つはセキュリティに関連しています。引用するには マウントポイントフォルダにSQLアクセス許可を設定するためのガイドライン ：
マウントポイントのルートフォルダーは通常のフォルダーのように見え、フォルダーへのアクセスと同じ方法でアクセスされますが、通常のフォルダーではありません。その結果、マウントポイントのルートフォルダーにアクセス許可を設定した場合、アクセス許可は通常のフォルダーのように「親ボリューム」から継承されません。実際、それらはまったく継承されません。これは、マウントされたボリュームは「親ボリューム」の子であるように見えますが、そうではないためです。 「親ボリューム」からのパスを介して、マウントされたボリュームにアクセスするだけです。
簡単に言うと、マウントポイントのルートフォルダーを利用する場合は、マウントフォルダーへのアクセス許可を別の方法で割り当てる必要があります。通常のフォルダーで行うようにアクセス許可を割り当てる代わりに、ボリュームにアクセス許可を割り当てる必要があります。繰り返しますが、同じ記事から（強調表示はMicrosoftのものです）：
Gotchas
残念ながら、Windowsエクスプローラーを介してマウントポイントのルートフォルダーのアクセス許可を設定/表示することは引き続き可能です。マウントポイントのルートフォルダーのアクセス許可は有効に見え、「適切な」継承されたアクセス許可が表示されるため、予期しない結果が生じる可能性がありますただし、これらはマウントされたボリュームに適用される権限ではありません。
ガイドライン
- マウントポイントのルートフォルダーにファイルを直接配置しないことをお勧めします。これにより、フォルダーのアクセス許可を常に確認する傾向があるため、アクセス許可の管理がはるかに簡単になります。 代わりに、マウントポイントのルートフォルダーの下にサブフォルダーを作成し、そのサブフォルダーに適切なアクセス許可を設定します。サブフォルダーは通常のフォルダーであるため、監視および設定するフォルダーのアクセス許可は、実際に適用されるアクセス許可です。したがって、前の例を使用して、新しいフォルダーを作成する必要があります：D：\ FolderForVol3 ** SubfolderXYZ **。次に、通常のように、その新しいSubfolderXYZフォルダーに対してフォルダーのアクセス許可を設定します。
- mount-point root folderにアイテムを直接配置する必要がある場合（推奨する方法ではありません）、フォルダーのアクセス許可ではなく、ボリュームのアクセス許可を設定する必要があります。これは、マウントポイントのルートフォルダーのアクセス許可が、マウントされたボリュームに実際に設定されるアクセス許可ではないことを思い出してください（マウントポイントのルートフォルダーは実際のフォルダーではないため）。ボリュームの権限は次のように設定できます。
- Start-> run-> diskmgmt.msc（ボリュームのプロパティを表示 http://technet.Microsoft.com/en-us/library/cc740097.aspx ）
- ボリューム->プロパティ->セキュリティタブを選択します。
- 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のインストール は、SQL Server 2016がインストールされたWindows 2012でも引き続き発生する可能性があることを示しています。
割り当てるセキュリティによってコマンドは異なりますが、テストが成功の鍵となるため、\Eフラグのような単純なものを忘れるとすぐにセキュリティが失われる可能性があるため、ライブマウントポイントに対してコマンドを実行する前に、コマンドをよく理解してください。
マウントポイントは、アプリケーションを共有するサーバーの場合や、一般的なD-Zボリュームだけでなく、他のデータをスライスする場合にも使用できます。
たとえば、1つのアプリケーションデータ、ログ、一時ファイルをすべてe:ドライブにインストールできます。 E:/MP_1にはビジネスAのデータファイルを含めることができ、E:/MP_2にはログファイルを含めることができますE:/mp_3にはビジネスAの一時ファイルを含めることができます。次に、F:ドライブのマウントポイントにビジネスBがあります。各マウントポイントには独自のスペースがあります。
OSはMPに関してはまったく問題ありません。クラスターとAlways Onには、MPに関する問題はありません。 SQLサーバーの大部分がMPにインストールされている非常に有名な銀行で働いていました。 DBAがそれらを使用して概念を理解すると、それを必要とするショップでのより簡単なソリューションにそれらを推進します。
MP rootには何もインストールしないと述べました。そうです。MP rootには何もインストールしないのと同じように、rootには何もインストールしません。例としてD。
Foglight、Guardiam、EMS、およびPBMなどの監査および監視ソリューションでも、マウントポイントに問題はありません。