Oracleデータベースにデータ記憶域用の複数の表領域が必要ですか？

Question

私のチームは、Oracleデータベースを管理しています。 200GBのサイズ。すべてのデータ（表、索引など）は、単一のUSERS表領域内に存在します。これは悪い考えですか？複数の表領域を持つことにどのようなメリットがあり、どのような状況でデータベースにさらに何かを追加したいのですか？

ありがとうございます！ データベースのデータ

を割り当て、特定の領域クォータのために

コントロールディスク容量の割り当て：

Answer 1

私の偏見（これは主に個人的な好みです）は、追加の表領域を作成することに魅力的な利点がない場合、単一の表領域でより簡単です。

• 異なる表領域にオブジェクトを配置することによるパフォーマンス上のメリットはありません。テーブルとインデックスを分離すると、パフォーマンス上のメリットがあるという昔の誤解があります。すべての使用可能なスピンドルでI/Oを広げることは潜在的な利点ですが、Oracleは単一の表領域内に複数のデータ・ファイルを作成し、複数の表領域を使用する方が優れています。すでにI/Oを均等にするために何かをやっている。
• より小さいトランザクション表領域を導入するだけで、データベースの新しいコピーをクライアント・サイトに持ち込むことができるような、静的な検索/履歴表が大量にある場合は、複数の表領域を考慮する必要があります。しかし、この種の設定を持つアプリケーションはごくわずかです。 200 GBをすべて持っていなければならない場合は、テーブルスペースの数は関係ありません。
• 大きな行の読取り専用オブジェクトがある場合は、読取り専用表領域に格納すると、バックアップに必要な時間とスペースが大幅に削減されます。ただし、これは実際にはデータウェアハウス以外ではあまり一般的ではありません。
• アプリケーションがオブジェクトの一部のサブセットなしで実行できる場合は、別の表領域を作成してオフラインにし、表領域レベルのリストアを実行できるという利点があります。ただし、オブジェクトのセットなしで実行できるアプリケーションはほとんどありません。たとえば、索引表領域を失うと、アプリケーションはすべてを失ったように死んでしまう可能性があります。
• 大量の空の表または大部分が空の表および多数の非常に大きな表がある場合、異なるエクステント割当てポリシーを持つ別々の表領域は、領域使用の観点から優先される可能性があります。これは、パッケージ化されたアプリケーションでは、特定のインストールで使用可能なテーブルの割合が比較的低く、空の各テーブルに比較的大きなエクステントが割り当てられないようにする場合があります。ローカル管理された表領域での自動エクステント管理では、これは大きな問題ではない傾向があります。統一エクステントを使用する場合は、さらに重要です。
• 異なるオブジェクトでディスクのパフォーマンスの優先順位が異なり、使用可能なディスクの種類が異なる場合は、別々の表領域を使用して異なるオブジェクトを異なるディスクセットに配置できます。たとえば、データウェアハウスでは、古いデータを低速で安価なディスクに、新しいデータをより高価なディスクに入れることができます。これはOLTPアプリケーションではあまり起こりません。

アプリケーションがこれらの特別なケースのいずれかに該当しない限り、個別の表領域を持つ唯一のメリットは、DBAの組織感覚にアピールすることです。個人的には、私がオブジェクトを作成するたびにテーブルスペース名を指定したり、間違ってデフォルトテーブルスペースに必然的に作成されたオブジェクトを "間違った"テーブルスペースから移動させたりするのを避けることができます。個別のエクステント・サイズが異なる手作業で最適化された表領域セットを使用して、自動エクステント管理を使用してローカル管理の表領域を使用する場合、数十MBの領域が「無駄になる」と個人的には心配しません。一方、優れたDBAは、「ちょうど」整理されていることを非常に心配する傾向があるので、DBAが別のインデックスおよびデータ表スペースを持つことを望んでいれば、私は反論しません。

Answer 2

は は、次のタスクを実行するには、複数の表領域を使用することができますhttp://download.oracle.com/docs/cd/B28359_01/server.111/b28318/physical.htm

を参照してくださいhttp://download.oracle.com/docs/cd/B10501_01/server.920/a96521/tspaces.htm

を参照してください。 データベースユーザ

コントロールオンライン 個々の表領域をとることにより、データの可用性や オフライン

部分データベースのバックアップを実行したり 回復操作

は、パフォーマンスを向上させるための装置 間でデータストレージを割り当て

Answer 3

S. Lottは、なぜそれを複数の表スペースに分割したいのかという、一般的な理由の良いリストをすでに示しています。

状況により具体的な...

今物事を変更するには、特別な理由がある場合、私は自分自身を求めるだろう。そのような構造変化を起こすのは小さな仕事ではありません。パフォーマンスの問題はありますか？あなたはストレージスペースの制限を実行していますか？スペース割り当てを割り当てる必要がありますか？あなたの現在のバックアップとリストア計画はあなたのニーズを満たしていますか？

最初から時間をかけてやり直すことができれば、確実にデータベースを異なる表スペースに分けることを計画したいと思うでしょう。しかしそれは今それの価値があるのですか？

Answer 4

異なる表領域を使用する理由の1つは、データベース間でデータを移動するために表領域移送を使用する必要があることです。データをエクスポートおよびインポートせずに移動したいデータセットが限られている場合、特にデータがソースシステムとまったく同じ物理構造を持つことをテストすることが重要な場合は、表スペーストランスポートが適しています（たとえば、パフォーマンス分析作業のために）。

Answer 5

私はジャスティン洞窟評価に強く同意します。プロダクションDBAは、おそらく非常に異なる意見を持っています。

データベース全体を移動することなく、データベース間でデータのサブセットを移動するためのトランスポータブル表領域機能。

読み取り専用の表領域であり、毎週データベース全体をバックアップしていないため、数時間かかることがあります。また、速度を制限しても、その時間の間はパフォーマンスが低下することはありません。

は、膨大なサイズのため固定された日付で特定の表スペースのみをバックアップしますが、多くの場所でこのような大きなデータベースはありません。上記と同じ理由。

アプリケーションによっては、アプリケーション側で互いに独立して機能するモジュールがあるとします。彼らがそれぞれ独自のテーブルスペースを持っていれば、他のモジュールに影響を与えずに再編成するために、あるアプリケーションのテーブルスペースをオフラインにすることができます。

データとインデックスの分離について：伝統的な理由は、2つのディスクを異なるディスクに配置してパフォーマンスを賢明に競合しなかったためです。本当に同じ記憶領域であるSANのような今日のストレージ機能の問題ではありませんが、が残っています。ローカルの管理された表領域でもファイルヘッダーレベルで競合することを考慮しますテーブルから索引を分離することができない同じ表スペース内のすべてのオブジェクトを取得しました！ 1つの表領域に20のデータ・ファイルを作成しても、表と索引の場所を決めることはできません。ある日、インデックスのある表に対する大量のアクティビティが原因でファイル・ヘッダ・レベルで大きな競合が発生していることがわかります同じデータファイルに存在することになります。実際にそれをスクラップします。あなたが1つのTSしか持っていないならば、はになりますが、間違いなくファイルヘッダーの競合が発生します。

論理的な分離が必要な理由が多いのですが、それはパフォーマンスの大部分ではなく、実稼働環境での管理に関するものです。