私の新しいOracleDBAの話し方は意味がありますか
MSSQLボックス用にFCLUNをセットアップする場合、さまざまな種類（クォーラム、MSDTC、TempDB、データ、ログ、バックアップなど）の約8つを超える個別のLUNを提示する必要はほとんどありません。
新しいOracleDBAがあり、彼は最初の新しいサーバーに必要なLUNのリストを私にくれました。38個あります。これは、DBが1つしかない非常に基本的なDBボックス用です。それらはすべてかなり小さい（100GB）LUNであり、LVMタイプの方法でASMを使用して明らかにボルトで固定されています。
これを行うための最良の方法は、私は実際にはOracleの専門家ではありませんが、私には複雑すぎるようです。この問題についてのあなたの考えや経験は何ですか？
私はOracleDBAです。新しいDBAは、多くのOracleDBAのように機能します。
いいえOracleは38個のLUNを必要としません。私はデータファイルを多数のlunに分散させましたが、これらは非常にアクティブで非常に大きいシステム上にあります。 LUNは新しいRAIDグループにマップする必要はありませんよね？したがって、ファイルを別々のルンに置くことは、とにかく何も広げる必要はありません（私はこれの専門家ではありません）。
この種のファイルストライピングが行うのは、DBAの作業を大幅に増やすことだけです。これにより、チームにとっての彼の重要性が増します。多くのOracleDBAは、自分自身をより重要であるように見せようとし、常に物事を設計しすぎています。
データを異なるネットレイドグループ/ルンに分離することは、Oracle固有ではありません。その使用法に基づいています。ファイルを適切に分散するために、DBAはアプリケーションを理解して、何がアクセスされているかを知る必要があります（ところで、アクセスはシリアルであるため、データからインデックスを分離してもパフォーマンスは向上しません...）。彼はアプリケーションを知っていますか？彼はデータベースを調べて、どのオブジェクトが頻繁にアクセスされているかを確認しましたか？何を広げる必要がありますか？一括書き込みと読み取りは何であり、分離する必要があります。
これは、中小規模のデータベースのように聞こえます。活動レベルはどれくらいですか？彼はおそらく知らないでしょう。
一般に、小規模なデータベースでは、パフォーマンスを向上させるためにファイルシステムレベルで多くのことを行う必要はありません。 95％はSQLであり、開発者はループ内で実行するSQLステートメントが多すぎますか。
編集（年後！）：
私はSANのエンジニアと話をすることに時間を費やしており、これを投稿してからSANとLUNの知識をいくらか向上させました。まず、LUNは「論理的」です。個別のRAIDグループ、ディスクなどにマップする必要はありません。これはSANエンジニアによって設定され、DBAには表示されません。ほとんどの人が理解しているIOでSANを分離することにはさらに多くのことがあります。
私は非常に高い活動レベルを持つ非常に大規模なシステムに取り組んでいます。何百ものLUN、RAIDグループなどがあります...ファイルをいたるところに分散しています。 SANエンジニアと協力して、LUNを構成し、それらがSANのさまざまな部分に確実に分散されるようにします。 LUNがOSレベルからどのようにマッピングされているかについては実際にはわかりません。新しいファイルシステムは、SAN上の新しい場所にデータがマップされていることを意味するものではありません。
ASMのストライピングに関するHPの論文に関する限り。 SANを使用する場合、これはまったく意味がありません。ストライピング、ミラーリング、RAIDなどはすべて表面下で行われます。アプリケーションまたはデータベースレベルでは表示されません。 「ストライピング」用にOracleASMを構成することは、SANでは意味がありません。RAID5構成を使用している可能性のある論理ボリューム全体にストライピングするだけだからです（制御コストのために大多数。SANは数百万ドルの投資です）。ファイルシステムが表示されます。これらは、必ずしもSAN内の異なるディスクまたは異なる場所にマップされるとは限りません。
IBMには、アクティビティに基づいてディスクへの書き込み先をSANが決定できる新機能があるようです。ここでの私のポイントは、SANを最適化する人々はスペシャリストであるということです。あなたは彼らと協力する必要があります。 DBAまたはアプリケーション開発者は、何かが拡散しているかどうかを確認することはできません。
私が見たところ、ほとんどの店にはあまり優秀なSANエンジニアがいません。ジュニアレベルの人の仕事になりがちです。良い人のほとんどはコンサルタントになる傾向があります。そのため、多くの場合、製造元によるデフォルトの設定を使用しています。繰り返しになりますが、LUNを追加しても、SANエンジニアが表面下で構成しない限り、データが分散されることはありません。その上、1つのLUNを使用して、それを分散させることができます。優れたSANエンジニアがいない限り、これらすべては無意味です。問題のDBAがSANについて十分に理解しておらず、何も知らないことさえ知っていることは私には明らかです。
99.9％の時間、標準構成で問題ありません。特定のIOボトルネックがない限り、これは不要です。その場合は、SAおよびSANエンジニアと協力して、問題が何であるかを判断する必要があります。多くの場合、SANのレイアウトとは何の関係もありません。繰り返しになりますが、DBAと開発者は、これを理解するための知識はもちろん、その下で何が起こっているのかを確認することもできません。 SANは非常に複雑です。
[〜＃〜] this [〜＃〜] を使用して、彼を頭上で叩いてみることができます。これは、同じ（Stripe And Mirror Everything）アプローチを説明しており、非常にシンプルです。
MSSQLとmySQLを使用しているため、直接的な答えはありません。しかし、私のDBAがクレイジーに聞こえる何かを要求するときはいつでも...そのように。私は彼に、なぜ各ピースが必要なのかを文書化するように要求します。これは2つの目的を果たします。1つは突然心をより正気なものに変え、2つは思考プロセスを確認できるので、システムロジックを必要なものに適用して、それほど簡単ではない代替案を提示できます。 。 SOこの場合、38個のLUNのそれぞれの必要性を正当化するドキュメントを要求します
ASMおよびハードウェアレベルでのストライピングがパフォーマンスに有利である可能性があることを示す研究があります。 HP-Oracleホワイトペーパー これらのパフォーマンスの向上は、ほとんどの場合、期待どおりに聞こえない同時実行性の高い状況で見られます。しかし、あなたのDBAが慣れているものかもしれません。
AIX上のDB2の場合、DBAはデータベースごとに5つのボリュームを取得します。各ボリュームはDBの異なる部分に対応します。 1つはDB用、もう1つはプライマリログ用、1つはアーカイブログ用、一時的なものなどです。これらはボリュームであり、LUNである必要はありません。ストレージの管理方法によって異なります。