come from http://jibun.atmarkit.co.jp/lskill01/rensai/omsdb04/omsdb01.html
小野寺智子
2004/11/12
DBAの内容も表領域の管理について解説も、ちょうど半ばに差しかかってきました。ここから先は論理的な内容になります。若干ですが、ほかの回と比べて出題される問題が多い部分です。今回は表領域だけを集中的に解説いたします。表領域の構成をしっかり押さえれば、試験でも応用が効くはずです。
Oracleのデータベースには、データ・ファイル、制御ファイル、REDOログ・ファイルの3つのファイルが存在することは前回までに紹介しました。いままで紹介してきたファイルの構成は、OS側からみた物理的な構成です。物理的な構成と対応しながらOracle側からみた構成が論理的な構成です。Oracleでは、データベースに格納されているすべてのデータに対して、「データブロック」「エクステント」「セグメント」といった単位で「表領域」を構成しています。このように、単位ごとに区切って領域を構成することによって、管理者がきめ細かい管理をすることができるのです。
では、表領域の構成を具体的に図で紹介します。
図1 表領域の構成 |
表領域には表や索引といったオブジェクトを格納します。そして、表や索引に使用可能な領域を割り当てます。
表領域は大きく分けると2つに分類できます。
SYSTEM表領域はデータベース作成時に作成され、すべてのデータベースで必要な表領域です。SYSTEM表領域にはデータ・ディクショナリとストアド・プログラム・ユニットが含まれます。データ・ディクショナリが含まれるということは、表が作成されたり、削除されるといったことが発生すると、データ・ディクショナリに情報を書き込むため、頻繁にI/Oが発生します。SYSTEM表領域にユーザーデータを含むことは可能ですが、パフォーマンスの面からみても、SYSTEM表領域にはユーザーデータを格納しないようにしてください(実際は、パフォーマンスだけが原因ではありません。しかし、ほかの原因については各カテゴリにまたがるため、ここでは解説を割愛します)。
もう1つの表領域、非SYSTEM表領域は、データベース作成後に作成します。非SYSTEM表領域はDBAが任意で作成します。ユーザーデータはこの非SYSTEM表領域に格納されます。
表領域は次の方法によって管理されています。
ローカル管理表領域はOracle 8iからの機能で、データ・ファイルのヘッダ部分のビットマップにて管理をする方法です。ビット値で使用可能のエクステントを管理します。ローカル管理の利点は、以下のとおりです。
図2 ローカル管理の仕組み。ローカル管理では、各表領域ごとに空き領域を管理している |
ディクショナリ管理は、エクステントの管理をデータ・ディクショナリで行います。表領域内の各セグメントに、異なるパラメータを指定できます。また、ディクショナリ管理では、表領域のエクステントのサイズを変更することができます。変更後は、新しく作成されたオブジェクトに対して適用されます。ローカル管理では、エクステントの変更はできません。SYSTEM表領域はデータ・ディクショナリ管理で管理されています。
図3 ディクショナリ管理の仕組み。ディクショナリ管理はデータディクショナリで各表領域の空き領域を管理している |
非SYSTEM表領域は、使用目的によって任意に作成することができます。ユーザーデータを格納する表領域のほかに以下の表領域があります。
表領域は、必要に応じてオンライン・オフラインにすることができます。DBAが任意に作成した表領域はオフラインにして、メンテナンスを行うことができます。ただし、以下の表領域は常にオンラインにする必要があります。
表領域をオンライン/オフラインにする構文は以下のとおりです。
表領域のオンライン |
ALTER TABLESPACE data1 ONLINE; |
表領域のオフライン |
ALTER TABLESPACE data1 OFFLINE; |
表領域の削除には注意が必要です。構文は以下のとおりです。
表領域の削除 |
DROP TABLESPACE data1 |
上記の構文だけでは、表領域のセグメントがすべて削除されたという情報だけがデータ・ディクショナリに送られます。ですから、対応するOSファイルまでは削除されません。以下のオプションを使用すると、対応するOSファイルまで削除します。
DROP TABLESPACE data1 |
ほかにも、制約によって参照関係がある表領域を削除する場合は、以下のオプションを使用します(図4も参照のこと)。
DROP TABLESPACE data1 |
図4 削除する表領域が制約によって参照されている場合。表領域data1を削除したいが、表領域data2に存在する表から制約によって参照されている。表領域data1を削除すると表領域data2に存在する表が表領域data1に存在する表を参照できなくなるため、表領域data2に参照されている表から参照関係の制約のみを削除する |
表を削除するときもそうですが、削除したい表がほかの表から参照されていると、参照関係が崩れてしまうので、参照している方の制約を削除するというオプションがあります。
表領域は必要に応じて、表領域のサイズを変更することができます。領域不足によってトラブルが発生することは多くあります。表領域のサイズを変更する方法は以下のとおりです。
データ・ファイルの自動拡張 |
ALTER DATABASE DATAFILE |
データ・ファイルを手動でサイズを変更する |
ALTER DATABASE DATAFILE |
データ・ファイルの追加 |
ALTER TABLESPACE data1 |
SYSTEM表領域と非SYSTEM表領域の違いを理解したうえで、データ・ファイルの移動を紹介します。データ・ファイルの移動方法は次の2種類です。
●ALTER TABLESPACE文を使用して移動
ALTER TABLE SPACE文を使用して移動する場合の手順は以下のとおりです。
(1)移動する表領域をオフラインにする。
ALTER TABLESPACE data1 OFFLINE; |
(2)OSコマンドを利用してファイルを移動またはコピーする。
(3)移動先を指定する。
ALTER TABLESPACE data1 |
(4)表領域をオンラインにする。
ALTER TABLESPACE data1 ONLINE; |
(5)必要に応じてOSコマンドを使用して元ファイルを削除する。
●ALTER DATABASE文を使用して移動
ALTER DATABASE文を使用して移動する場合の手順は、次のとおりです。
(1)インスタンスを停止する。
SHUTDOWN IMMEDIATE; |
(2)OSコマンドを利用してファイルを移動する。
(3)データベースをマウントする。
STARTUP MOUNT; |
(4)移動先を指定する。
ALTER DATABAS |
この2つの違いは、SYSTEM表領域を移動するのか、非SYSTEM表領域を移動するのかという違いです。手順と構文もSYSTEM表領域か非SYSTEM表領域かで、それぞれ移動する手順が異なります。この手順はとても重要なので、構文と手順をしっかり押さえてください。
なぜ、同じ表領域なのにSYSTEM表領域と非SYSTEM表領域では構文も手順も違うのでしょうか。それは、表領域をオフラインにできるかできないかという事がポイントです。SYSTEM表領域にはデータ・ディクショナリが存在しています。データベースがオープンしている間は、常にSYSTEM表領域にあるデータ・ディクショナリにアクセスしています。そのような状態で表領域の移動を行うということは、とても危険です。ですから、SYSTEM表領域は、オフラインにできません。1度、データベースをシャットダウンしてから作業を行います。
非SYSTEM表領域は、データ・ディクショナリのように頻繁にアクセスする事はありません。よって、表領域をオフラインにできます。ですから、データベースをシャットダウンしなくとも、データ・ファイルを移動することができます。
OMFを使用して表領域を作成する場合は、以下のパラメータを使用します。
やり方は、REDOログ・ファイルや制御ファイルの回でも紹介した方法と同じです。
表領域のさまざまな情報を取得する場合は、以下のデータ・ディクショナリ、動的パフォーマンス・ビューを使用します。
|