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への影響
一般に、
マルチブロックサイズについて Oracle9iでは表領域ごとにブロックサイズを選択することができます。表領域ごとにブロックサイズを指定するには、 SQL> create tablespace tbs1 datafile … blocksize 16k;
と、CREATE TABLESPACE文で指定します。ALTER TABLESPACE文でブロックサイズを変更することはできません。初期化パラメータDB_BLOCK_SIZEに設定したブロックサイズは、CREATE TABLESPACE文でブロックサイズを指定しなかった場合の、デフォルトのブロックサイズになります。 マルチブロックサイズを採用すると、バッファ・キャッシュがブロックサイズごとに確保されます。ブロックサイズが１種類の場合は初期化パラメータ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で指定できる、日本語が扱える主要キャラクタ・セット
キャラクタ・セットを決める観点 （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管理の経験がある人でも混同しているケースが多いので、グループとメンバーの位置付けをまず解説します。 まずグループとは、ある時点で書き込み対象になる、１つないし２つ以上のREDOログファイルの集合です。一方メンバーとは、あるグループに含まれる個々のREDOログファイルのことを言います。REDOログファイルへ変更情報を書き込む際は最初のグループのREDOログファイルから順番に変更情報が書き込まれ、あるグループのREDOログファイルの最後まで変更情報が書き込まれたら、次のグループに切り替わって(ログスイッチ)変更情報が書き込まれます。この際メンバーが複数あると、全メンバーに対して同時に同じ内容の書き込みが行われます。同じグループ内のメンバーは常に同じ内容です。
グループの構成に関する考慮事項 REDOログファイルの初期作成はCREATE DATABASEコマンドで行いますが、この際最低２つのグループを指定する必要があります。アーカイブログ・モードでDBを運用する場合は、アーカイブ中にREDOログが巡回してしまってREDOログファイルへの書き込みがストップするトラブルを防ぐために、最低３つのグループを作成するようにしてください。 アーカイブログ・モードで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を利用した場合、表領域を削除した際はデータファイルも同時に削除されます。また、ファイル容量や拡張方法なども自動で以下のように決まります。
SQL> create tablespace tbs1 datafile size 200m autoextend off;
OMFに適したシステム OMFは以下のようなシステムに向いてます。
制御ファイル・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の３つのパラメータを指定し、それぞれ異なるディレクトリを指定すると、制御ファイル・REDOログファイルが３つに多重化されます。このパラメータを指定しなかった場合は初期化パラメータDB_CREATE_FILE_DESTで指定したディレクトリに作成されます。 |
第2部 表領域の設計  |