256TB、GPTディスク、できますが、すべきですか？
私はちょうど学びました （ありがとうKevh） Windows上のGPTドライブは256TBを保持できることを
各パーティションのサイズを2TBに制限するMBRとは異なり、GPTの各パーティションは最大2 ^ 64ブロックの長さを保持できます（64ビットを使用しているため）。これは、512バイトブロックの9.44ZBに相当します（1 ZBは10億テラバイトです）。 Microsoft Windowsでは、そのサイズは256TBに制限されています。 ソース
ベストプラクティスに従って、CPUに基づいて複数のデータベースファイルを使用します。小規模なインストールでは、これまで同じMBRドライブにこれらを配置してきました。また、tempdb、データファイル、ログファイル、バックアップ、OSにさまざまなドライブを使用しているため、インスタンスに最低5台のドライブを使用します。
GPTを使用すると、理論的には可能です。 256TBをディスクに置くので、マウントされたディスクが26ドライブ文字の制限を超える時代は過ぎ去ったのかもしれません。 （MBRと26文字のドライブのみの場合、マウントされたドライブを使用せずに52TBに制限されます）
256TB×26文字のドライブ= 6.6ZB
できないからといって、そうすべきだとは限りません...
質問：
SQLインスタンスから256TBのデータファイルを1文字のディスクに配置することを検討する場合、何を考慮する必要がありますか？
短い答え：NO、単一の256 TB NTFSファイルシステムは使用しません。
長い答え： NTFSは、プールされたファイルシステムでも、データセットベースのストレージシステムでもありません。つまり、ボリュームにはファイルシステム全体が含まれます。これは、特定の操作（つまり、chkdsk、vssadmin snapshotなど）はファイルシステム全体に適用されます。
chkdskがほぼ満杯の256 TB NTFSボリュームにかかる時間を想像してみてください。最近のNTFS/chkdskバージョンでは、増え続ける数を修正できると主張できます。オンラインでの問題（ボリュームをアンマウントせずに）、一部の問題では、オフラインスキャンが必要です-その間、ボリュームを使用できません。システムドライブの場合は、OSを起動することすらしません。
または、どのようにvssadmin snapshot createは、単一の小さなファイルを回復するために実行され、SQLデータベースallに大きなパフォーマンスの低下をもたらします。
サイドノート：私が検討する唯一のファイルシステムこのような大容量（WAFLのような「既成の」ものではなく、非常に独占的なものは別として）はZFSです。プールされ、データセットベースで、完全にオンラインですzfs scrub、それはそのような大きな収納スペースに適した設計によるものです。ただし、ZFSを使用しても、これらのサイズでは、複数のプールを作成するオプションを自動的に破棄することはできません。