Oracle9i 物理設計

第1部:DB全体の設計

日本オラクル クロスインダストリー本部 OracleDirect SCグループ
中家 裕之

2003年7月11日に行った同様のタイトルのiSeminarが比較的好評だったことから、隔月で全3回予定のiSeminarの内容を、平行してOTNでは毎月全6回の形で連載します。
私は普段はOracleDirectにご相談いただいたお客様のご商談成約のための技術的な支援を担当しております。Oracle製品の購入をご検討される際は、是非OracleDirectにご相談ください。

◆ 第1章 ブロックサイズの決め方

ブロックサイズを決める基本的な指針

ブロックサイズはCREATE DATABASEコマンド実行時に初期化パラメータDB_BLOCK_SIZEに設定します。基本的には2,048・4,096・8,192・16,384・32,768バイトのいずれかから選択することになります。ただし32,768バイトは64bit系の一部のOS版のOracleのみで指定できます。デフォルトはOSにもよりますがほとんどの場合2,048byteです。

どのブロックサイズを指定するかは、システムの特性に依存します。表のブロックサイズの大きさによるDBへの影響を考慮した上で総合的に判断してください。

(表)ブロックサイズの大きさによるDBへの影響
  ブロックサイズ小 ブロックサイズ大
ブロックに納められるレコード数 少ない 多い
ブロックI/Oのコスト 低めになる 高めになる
フルスキャンのI/Oのコスト DB_FILE_MULTIBLOCK_READ_COUNTに依存、同じ値ならブロックサイズ大の方がコストが低い
キャッシュヒット率 高めになる 低めになる
トランザクション競合発生の可能性 小さい 大きい
行連鎖発生の可能性 大きい 小さい
セグメント圧縮の効果 小さい 大きい
適しているシステム形態 OLTP系 DSS/DWH系

一般に、
  • 同一ブロックに対して複数セッションから同時に更新トランザクションが発生する可能性が高い
  • テーブル中のレコードの一部の削除が頻繁に行われる
  • キャッシュヒット率を高めたい
といった場合には小さめのブロックサイズが向いています。一方、
  • LOB型やLONG/LONG RAW型を多く利用している
  • レコード長が長いテーブルが多い
  • テーブルやインデックスの圧縮機能を利用したい
といった場合には大きめのブロックサイズが向いています。表にある特性のどちらにも依存しない、中庸的なケースの場合は8,192バイトを選んでください。


マルチブロックサイズについて

Oracle9iでは表領域ごとにブロックサイズを選択することができます。表領域ごとにブロックサイズを指定するには、

SQL> create tablespace tbs1 datafile … blocksize 16k;

と、CREATE TABLESPACE文で指定します。ALTER TABLESPACE文でブロックサイズを変更することはできません。初期化パラメータDB_BLOCK_SIZEに設定したブロックサイズは、CREATE TABLESPACE文でブロックサイズを指定しなかった場合の、デフォルトのブロックサイズになります。

マルチブロックサイズを採用すると、バッファ・キャッシュがブロックサイズごとに確保されます。ブロックサイズが1種類の場合は初期化パラメータDB_BOCK_BUFFERSあるいはDB_CACHE_SIZEでバッファ・キャッシュの大きさを指定しています。マルチブロックサイズを採用した場合は初期化パラメータDB_CACHE_SIZEはデフォルトのブロックサイズの表領域用のキャッシュとなり、その他のブロックサイズの表領域用のキャッシュは初期化パラメータDB_nK_CACHE_SIZE(nは2/4/8/16/32のいずれかで、ブロックサイズに合わせる)で大きさを指定します。デフォルトのブロックサイズ用のDB_nK_CACHE_SIZEは指定しても無視されます。

このブロックサイズが異なるとバッファ・キャッシュが別になるという特性を利用して、集中してキャッシュしたいセグメントとキャッシュの必要性の薄いセグメントを異なるブロックサイズの表領域に配置し、キャッシュを有効利用するテクニックが利用できます。また、LOBテーブルのようなレコードサイズが長いテーブルを格納する表領域のブロックサイズだけ大きくして、行連鎖の発生を抑えるという対策も取ることができます。


◆ 第2章 キャラクタ・セットの決め方

Oracle9iで利用できるキャラクタ・セット

Oracle9iで日本語を扱う場合、表にあるキャラクタ・セット(Oracle上の文字コード)が選べます。表にあるキャラクタセット以外にもIBM漢字コード(JA16DBCS)、MacintoshのSJIS(JA16MACSJIS)などが選択できますが、利用機会はほとんどないので以降の説明では省略します。

(表)Oracle9iで指定できる、日本語が扱える主要キャラクタ・セット
キャラクタセット 文字コード 備考
JA16SJIS シフトJIS  
JA16EUC 日本語EUC  
JA16SJISTILDE シフトJIS ウェーブ・ダッシュ(〜)問題が起り得る環境で使用。R9.0.1.4以上で指定可
JA16EUCTILDE 日本語EUC
UTF8 UnicodeのUTF-8エンコーディングの緩やかなインプリ Unicodeで古いオラクルとの互換性を重視する場合に利用
AL32UTF8 UnicodeのUTF-8エンコーディングの厳密なインプリ(Oracle9iR1よりサポート) Oracle9iでUnicodeを扱う際の基本


キャラクタ・セットを決める観点

(1)日本語・英語以外の文字を同時に扱う必要があるか?
例えば中国語やポルトガル語などを日本語と同時に扱う必要がある場合、SJISや日本語EUCでは中国語やポルトガル語は扱えません。このような場合にはUnicodeが扱えるAL32UTF8を利用してください。Oracle8i以前からのデータで下位互換性を重視する場合はUTF8を利用します。

(2)DBを作成するマシンのOSに合わせる
WindowsあるいはHP-UX, AIXの場合、OSで扱う基本の文字コードがSJISですので、JA16SJISあるいはJA16SJISTILDEを利用します。その他のOS(Solaris, Linux等)ではOSで扱う基本の文字コードが日本語EUCですので、JA16EUCあるいはJA16EUCTILDEを利用します。
ただし、昨今のシステムはクライアント側がほぼSJISです。Oracle9iはサーバー側とクライアント側のキャラクタ・セットの指定が同じだと文字コード変換しませんので、本来Oracle9iがハンドリング対象外としている外字領域を利用している文字なども無変換で通ります。結果、いわゆる機種依存文字なども扱えるようになります。このことから、Solaris, Linux等でもJA16SJISあるいはJA16SJISTILDEを利用することも多いです。

(3)ウェーブ・ダッシュ(〜)問題を解決する必要はある?
Windows環境でODBC, oo4oなど一部のミドルウェア環境で「〜」が文字化けする問題に遭遇された方は多いかと思います。これは、ODBC, oo4oなど内部で一旦Unicodeに変換するミドルウェアにおいて、「〜」という文字に対するSJISとUnicodeのマッピングがOracleとMicrosoftの間で異なっているためです。この問題への対応として、R9.0.1.4より新しいキャラクタセット「JA16SJISTILDE」「JA16EUCTILDE」を用意し、サーバー・クライアントともにこれらのキャラクタ・セットを指定することで問題解決が可能になります。これらのキャラクタ・セットが使えない、もしくは明確に「〜」の入力の必要のないシステム以外では「TILDE」つきのキャラクタ・セットを使用するようにしてください。


各国語キャラクタ・セットについて

各国語キャラクタセット(create database文のnational character set句で指定するキャラクタセット。NCHAR型やNVARCHAR2型、NCLOB型などで使用される文字コードです)はデフォルトのAL16UTF16を指定して下さい。古いバージョンのOracleではSJISやEUCなどに対応したキャラクタセットを使用出来ましたが、Oracle9i以降では各国語キャラクタセットはUnicodeが前提となります。


◆ 第3章 制御ファイルの作成における考慮事項

多重化の勧め

制御ファイルは1つが壊れればDBが停止してしまいます。多重化した方がリカバリが非常に楽なので多重化して下さい。通常Oracleでは3ファイル以上の多重化を推奨しています。また、耐障害性を高める為、多重化した制御ファイルは可能な限り別々のディスクに配置して下さい。


制御ファイルの容量見積もり

制御ファイルの容量に関しては通常数MBレベルの大きさなので、特に考慮する必要はないでしょう。ただし、バックアップツールのRecovery Managerのリカバリ・カタログ(バックアップに関するデータ)を制御ファイル内に作成する場合は、DB規模やバックアップ方針によっては数百MBレベルまでサイズが膨れることもあります。


◆ 第4章 REDOログファイルの作成における考慮事項

グループとメンバーの違い

DBの変更情報を記録するREDOログファイルにはグループとメンバーが存在します。ある程度DB管理の経験がある人でも混同しているケースが多いので、グループとメンバーの位置付けをまず解説します。

まずグループとは、ある時点で書き込み対象になる、1つないし2つ以上のREDOログファイルの集合です。一方メンバーとは、あるグループに含まれる個々のREDOログファイルのことを言います。REDOログファイルへ変更情報を書き込む際は最初のグループのREDOログファイルから順番に変更情報が書き込まれ、あるグループのREDOログファイルの最後まで変更情報が書き込まれたら、次のグループに切り替わって(ログスイッチ)変更情報が書き込まれます。この際メンバーが複数あると、全メンバーに対して同時に同じ内容の書き込みが行われます。同じグループ内のメンバーは常に同じ内容です。



グループの構成に関する考慮事項

REDOログファイルの初期作成はCREATE DATABASEコマンドで行いますが、この際最低2つのグループを指定する必要があります。アーカイブログ・モードでDBを運用する場合は、アーカイブ中にREDOログが巡回してしまってREDOログファイルへの書き込みがストップするトラブルを防ぐために、最低3つのグループを作成するようにしてください。
アーカイブログ・モードでDBを運用する場合は、各グループを異なる物理ディスクに配置すると、アーカイブと書き込みのI/Oが分散されてパフォーマンスが向上します。


メンバーの構成に関する考慮事項

メンバーはひとつでも稼動します。ふたつ以上のメンバーを作成すると、あるメンバーが壊れても、グループ中最低ひとつのメンバーが生き残っていればDBは稼動を続けます。ですので障害対策としてメンバーは必ずふたつ以上作成してください。
同じグループに所属するメンバーは同時に書き込みが行われます。I/Oを分散させてパフォーマンスを向上させるために、各メンバーは極力異なる物理ディスクに配置してください。


REDOログファイルの容量見積

REDOログファイルに書かれるデータ量は、対象のSQLや更新量などによって大きく変わるため、事前に正確に見積もることはまず不可能です。ですので小規模システムであれば1〜10MB、中規模システムであれば10〜100MB、大規模システムであれば100MB以上の大きさでまず作成し、実際のREDO書き込み量を見て運用の過程で調整することが多いです。

トランザクション処理中にログスイッチが発生するとそのトランザクションのパフォーマンスが落ちますので、特にOLTP系の処理が中心の場合は、処理のピーク時にはログスイッチが発生しないようにする必要があります。運用でREDOログ更新量に関するデータを集め、ピーク時にログスイッチが発生しない大きさに調整してください。また、一般にREDOログファイルの大きさが大きいほどログスイッチの発生の可能性が少なくなるため、パフォーマンスは向上します。その一方リカバリに要する時間は長くなりがちになりますので、これらのトレードオフも考慮するようにしてください。


◆ 第5章 OMF構成の紹介

OMFとは

OMF(Oracle Managed Files)は指定ディレクトリにまとめて表領域や制御ファイル、REDOログファイルを配置することで、DB管理の手間を大幅に省くことができる、Oracle9iの新機能です。
OMFを利用する場合は初期化パラメータDB_CREATE_FILE_DESTにファイルを配置したいディレクトリを指定します。この設定をすることで、表領域や制御ファイルなどを作成する際にファイル名を指定する必要がなくなります。表領域を作成するSQLは、

SQL> create tablespace tbs1;

と、極限まで単純な指定が可能になります。この際ファイル名はOracleが自動で命名します。OMFを利用した場合、表領域を削除した際はデータファイルも同時に削除されます。また、ファイル容量や拡張方法なども自動で以下のように決まります。
  • ファイル容量:100MB
  • データファイルの拡張:1ブロックサイズずつ無制限に自動拡張
    (もちろんOSやディスク容量による上限はあります)
  • エクステント管理:ローカル管理(AUTOALLOCATE)
ただし、CREATE/ALTER TABLESPACE文でデフォルトを変えて作成・変更することはできます。自動拡張の増分はあまりよくない設定なので、適宜変更するようにしてください。以下はファイル容量は200MBに、自動拡張なしに変更してOMFを利用して表領域を作成する例です。

SQL> create tablespace tbs1 datafile size 200m autoextend off;


OMFに適したシステム

OMFは以下のようなシステムに向いてます。
  • 小規模システム
    ディスクが1つしかないような小規模システムでは物理配置を考える余地がないので、より管理が簡単になるOMFは非常に向いています。
  • パッケージ・ソフトのバックエンドでOracleを利用する場合
    パッケージ・ソフトの場合DBの管理要素をあまり増やせないことが多いので、OMFを利用することでデータファイルの管理要素を減らすことができます。
  • SAME構成を利用する場合
    SAME(Stripe And Mirror Everything)とは、あるディスク装置にあるディスク全部をまとめてストライピングし、1つの巨大なディスクとして扱う考え方です。SAME構成をとると、すべてのディスクに対してI/O負荷が平均して分散されるため、比較的簡単に高いI/Oパフォーマンスを引き出すことが可能になります。また、ディスクが1つになるため、物理配置に関する設計が大幅に楽になります。OMFをSAME構成と併用するとより設計・管理の負荷を減らすことができます。

制御ファイル・REDOログファイルのOMF管理

前述の制御ファイル、REDOログファイルもOMFによる管理が可能です。しかし、制御ファイルやREDOログファイルを多重化しても異なるディスクに分散配置することができなくなります。この問題に対する対策として、初期化パラメータDB_CREATE_ONLINE_LOG_DEST_nが用意されています。このパラメータに制御ファイル・REDOログファイルファイルを配置したいディレクトリを指定します。nは1〜5までの数字が入ります。例えばDB_CREATE_ONLINE_LOG_DEST_1、DB_CREATE_ONLINE_LOG_DEST_ 2、DB_CREATE_ONLINE_LOG_DEST_3の3つのパラメータを指定し、それぞれ異なるディレクトリを指定すると、制御ファイル・REDOログファイルが3つに多重化されます。このパラメータを指定しなかった場合は初期化パラメータDB_CREATE_FILE_DESTで指定したディレクトリに作成されます。

第2部 表領域の設計