16

私のチームは、約1のOracleデータベースを維持しています。サイズは200GB。すべてのデータ（テーブル、インデックスなど）は、単一の「USERS」テーブルスペース内にあります。これは悪い考えですか？複数のテーブルスペースを持つことにはどのような利点がありますか？また、どのような状況でデータベースにさらに追加したいですか？

ありがとう！

4

5 に答える 5

24

私の偏見（そしてこれは主に個人的な好みの問題です）は、追加の表領域を作成することに説得力のある利点がない場合、単一の表領域で生活が楽になるということです。

  • オブジェクトを異なる表領域に配置しても、パフォーマンス上の利点はありません。テーブルとインデックスを分離するとパフォーマンスが向上するという古い神話があります。使用可能なすべてのスピンドルにI/Oを分散することには潜在的な利点がありますが、OracleはSANがI/Oを均等にするためにまだ何かをしていません。
  • 小さいトランザクションテーブルスペースを持ってくるだけでデータベースの新しいコピーをクライアントサイトに持ってくることができるような大きな静的ルックアップ/履歴テーブルがある場合、それは複数のテーブルスペースを検討する理由になります。しかし、この種の設定をしているアプリケーションはほとんどありません。200 GBをすべて持参する必要がある場合は、テーブルスペースの数は関係ありません。
  • 同様に、大きな読み取り専用オブジェクトがある場合、それらを読み取り専用テーブルスペースに配置すると、バックアップに必要な時間とスペースを大幅に削減できます。繰り返しになりますが、これはデータウェアハウス以外では実際には特に一般的ではありません。
  • オブジェクトのサブセットなしでアプリケーションを実行できる場合は、個別の表領域を作成して、1つをオフラインにして、表領域レベルのリストアを実行できるようにすることでメリットが得られる場合があります。ただし、オブジェクトのセットなしで実行できるアプリケーションはほとんどありません。たとえば、インデックステーブルスペースを失うと、すべてを失った場合と同じようにアプリケーションが停止する可能性があります。
  • 空のテーブルまたはほとんど空のテーブルが多数あり、非常に大きなテーブルが多数ある場合は、スペース使用率の観点から、エクステント割り当てポリシーが異なる個別のテーブルスペースの方が適している場合があります。これは、特定のインストールで使用可能なテーブルの比較的小さな割合を使用していて、空の各テーブルに比較的大きなエクステントを割り当てたくないパッケージ化されたアプリで時折発生します。ローカルで管理されている表領域での自動エクステント管理では、これは大きな問題にはならない傾向があります。均一なエクステントを使用する場合は、さらに問題になる可能性があります。
  • さまざまなオブジェクトのディスクパフォ​​ーマンスの優先順位が異なり、使用可能なディスクの種類が異なる場合は、テーブルスペースを分けることで、さまざまなオブジェクトをさまざまなディスクセットに配置できます。たとえば、データウェアハウスでは、古いデータを低速で安価なディスクに配置し、新しいデータをより高価なディスクに配置することができます。これは、OLTPアプリケーションではあまり起こりません。

アプリケーションがこれらの特殊なケースのいずれかに該当しない限り、個別の表領域を持つことの唯一の利点は、DBAの組織化の感覚に訴えることです。個人的には、オブジェクトを作成するたびにテーブルスペース名を指定することを避けたり、デフォルトのテーブルスペースでオブジェクトが誤って作成されることが避けられない場合に、「間違った」テーブルスペースからオブジェクトを移動するサイクルを費やしたりできることを嬉しく思います。個人的には、異なる均一なエクステントサイズを持つ手動で最適化されたテーブルスペースのセットに対して自動エクステント管理を備えたローカル管理テーブルスペースを使用するときに、数十MBのスペースが「浪費」されるかどうかについてはあまり心配していません。一方、優れたDBAは、「まさしく」整理されていることを非常に心配する傾向があるので、私は

于 2009-08-18T05:36:44.433 に答える
10

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

http://download.oracle.com/docs/cd/B28359_01/server.111/b28318/physical.htmを参照してください

複数の表領域を使用して、次のタスクを実行できます。

データベースデータのディスクスペース割り当てを制御する

データベースユーザーに特定のスペースクォータを割り当てます

個々の表領域をオンラインまたはオフラインにすることにより、データの可用性を制御します

部分的なデータベースのバックアップまたはリカバリ操作を実行します

パフォーマンスを向上させるために、デバイス間でデータストレージを割り当てます

于 2009-08-18T01:15:07.933 に答える
5

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

于 2009-12-17T10:17:38.760 に答える
5

私はジャスティン洞窟の評価に強く反対します。本番DBAは、非常に異なる意見を持っている可能性があります。

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

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

サイズが非常に大きいため、特定のテーブルスペースのみを固定日にバックアップしますが、多くの場所にはこれほど大きなデータベースがありません。上記と同じ理由。

アプリケーションに応じて、アプリケーション側で互いに独立して機能できるモジュールがあるとします。それぞれに独自のテーブルスペースのセットがある場合は、1つのアプリのテーブルスペースをオフラインにして、他のモジュールに影響を与えることなく再編成を行うことができます...通常どおり実行できます。

データとインデックスの分離に関して：従来の理由は、2つを異なるディスクに配置して、パフォーマンスの面で互いに競合しないようにするためでした。SANのように、すべてが実際には同じストレージ領域である今日のストレージ機能にはそれほど問題はありませんが、それでも問題はありません。インデックスをテーブルからローカルに分離できない同じテーブルスペースにすべてのオブジェクトがある場合、ローカルで管理されているテーブルスペースでもファイルヘッダーレベルで競合が発生するという考慮事項!! 1つのテーブルスペースに20個のデータファイルを作成しても、テーブルとインデックスの場所を決定することはできません。ある日、インデックスが存在するテーブルに対する大規模なアクティビティが原因で、ファイルヘッダーレベルで大きな競合が発生していることに気付きます。たまたま同じデータファイルにあります！実際、それをスクラップします。tsが1つしかない場合は、間違いなくファイルヘッダーの競合が発生します。

その論理的な分離を行う理由は他にもあります。いいえ、それはほとんどの場合のパフォーマンスではなく、実稼働環境での管理に関するものです。

于 2013-01-23T15:46:15.097 に答える
1

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

あなたの状況にもっと具体的に...

今、物事を変える特別な理由があるかどうか自問します。そのような構造変更を行うことは簡単な作業ではありません。パフォーマンスの問題はありますか？ストレージスペースの制限に逆らって実行していますか？スペースクォータを割り当てる必要がありますか？現在のバックアップと復元の計画はニーズを満たしていますか？

過去にさかのぼって最初からやり直すことができれば、データベースをさまざまな表スペースに適切に分割することを計画する必要があります。しかし、今はそれだけの価値がありますか？

于 2009-08-18T02:52:50.877 に答える