>> 連載トップページに戻る

 

基本からわかる!高性能×高可用性データベースシステムの作り方

第2回 データベースを作成(CREATE DATABASE)するときに考慮しておくこと


著者紹介


日下部 明 (くさかべ あきら)

日本オラクル Oracle Database担当。Oracle GRID Centerのラインマネージャとしてオラクルの持つ最新技術をパートナー各社と共同で検証し、多くのホワイトペーパーを執筆・レビューしてきました。以後、Oracle Databaseのセキュリティ製品のリリースマネージャを担当。これらの経験を元にミッションクリティカルな案件のソリューションデザインの提案などを担当しています。著書に「これは使えるOracle新機能活用術」(翔泳社)。


第2回 データベースを作成(CREATE DATABASE)するときに考慮しておくこと


連載第1回ではオンプレミス環境でのOracle Grid InfrastructureとOracle Databaseのソフトウェアのインストールについて補足しました。第2回ではデータベースを作成(CREATE DATABASE)するときに最低限考慮しておかなければならないことについて解説します。

データベースを作成するには、オンプレミス環境ではDatabase Configuration Assistant(dbca)ツールを使用します。データベースを構成するには様々なパラメータを指定しますが、これらを「変更できるかどうか」という観点で分類してみます。

  • データベース作成後に変更できない要素
  • 変更可能ではあるが手順が煩雑な要素
  • 容易に変更できる要素

1. データベース作成後に変更できない要素

データベース作成後に変更できないパラメータを変更するには、別のデータベースを新たに作成し、Data Pumpなどでデータを移行する必要があります。そのため、この種のパラメータはデータベース作成前によく検討しておく必要があります。変更できないパラメータには以下のものがあります。

  • 標準ブロック・サイズ
  • データベース・キャラクタセット

1.1. 標準ブロック・サイズ

Oracle Databaseは表や索引のデータをデータ・ブロックという単位に分割してデータファイルに格納します。表や索引をOracleインスタンスのデータベース・バッファキャッシュにキャッシュする最小単位はこのデータ・ブロックです。標準ブロック・サイズとは、初期化パラメータDB_BLOCK_SIZEに指定される値であり、CREATE DATABASE文によって作成されるSYSTEM表領域のデータ・ブロックのサイズです。そして、初期化パラメータDB_CACHE_SIZEで指定するデータベース・バッファキャッシュのブロック・サイズにもなります。データ・ブロックのサイズは2048、4096、8192、16384、32768バイトから選択することができます。

データ・ブロックのサイズが小さいと、1回のI/Oにかかる時間が小さくなることが期待できるため、オンライン・トランザクション・システムのように、索引経由で少数の行にアクセスするようなパターンにおいてのランダムI/Oの性能が上がることが期待できます。しかし実際のところは、ストレージ・デバイスのレイヤーでのIOPS上限は小さすぎるI/Oサイズにしても向上するわけではありません。また、ブロック・サイズが表の1行のサイズよりも小さいと、1行が複数のデータ・ブロックにまたがってしまいます。こうなると1行にアクセスするのに複数のデータ・ブロックにアクセスしなければならなくなり、かえって性能が低下します。このようなリスクがあるため、2048バイトのサイズが選択されることはほぼありません。

データ・ブロックのサイズが大きくなると、1つのデータ・ブロックに格納できる表の行数が増えます。また、基本圧縮機能やOLTP表圧縮機能で表を圧縮するとき、1つのデータ・ブロック内で列の同じ値を重複排除するため、データ・ブロックのサイズが大きいと圧縮が効きやすいことが期待されます。そのため、分析系システムのように表フルスキャンを多用するシステムでは大きなサイズのデータ・ブロックを選択する場合があります。しかし、1つのデータ・ブロックに格納される行数が多くなると、多数のセッションから更新される場合にメモリーの排他制御の競合が増える可能性があります。そのため、オンライン・トランザクション・システムではあまり大きなサイズのデータ・ブロックを選択しない傾向があります。

Oracle Databaseは表フルスキャンや索引フルスキャンを実行する場合、OSに対してブロック・サイズ×DB_FILE_MULTIBLOCK_READ_COUNTのサイズのI/Oリクエストを発行します。一般的には、この積が1MBになるように設定します。Oracle Database 10g Release 2からは、DB_FILE_MULTIBLOCK_READ_COUNTの値は自動チューニングされるようになりました。データ・ブロックのサイズにかかわらず、フルスキャンの場合は大きなサイズのI/Oリクエストが発行されます。そのため、大きなブロック・サイズを使用しなくてもフルスキャンは効率的に動作します。

ブロック・サイズには以上のようなトレードオフがあります。現在のデータベース・システムは、索引アクセスによる少数の行にアクセスするSQLと表フルスキャンになるSQLが混在する傾向があります。バランスをとって、多くの場合標準ブロック・サイズは8KBが選択されます。

dbcaでデータベースを作成するとき、データベースのテンプレートを選択する画面があります。ここで、「データ・ウェアハウス」または「汎用またはトランザクション処理」を選択すると、テンプレートからデータファイルをリストアするという特殊な方法でデータベースが作成されます。そのため、標準ブロック・サイズはあらかじめ決まっており変更できません。これらのテンプレートを選択したとき、Oracle Database 12c Release 2のdbcaでは標準ブロック・サイズは8192バイトになっています。

img-1

標準ブロック・サイズを指定するには「カスタム・データベース」を選択します。すると、「サイズ指定」のタブでブロック・サイズが選択できるようになります。

img-2

データベースを作成した後に、追加の表領域を作成するときに表領域ごとにデータ・ブロックのサイズを指定することもできます。しかしこれを行うには、そのブロック・サイズを担当するデータベース・バッファキャッシュの領域を初期化パラメータDB_nK_CACHE_SIZEで確保しなければなりません。また、DB_nK_CACHE_SIZEのメモリー領域は自動調整の対象ではありません。複数のブロック・サイズを混在させると運用管理が煩雑になるため、この構成をとることはほとんどありません。

1.2. データベース・キャラクタセット

データベース・キャラクタセットとは、文字列を扱う型(CHAR、VARCHAR2、CLOB)をどのキャラクタ・セットでデータファイルに記録するかを決めるパラメータです。日本語圏で扱うキャラクタ・セットは、大別するとSJIS系、EUC系、Unicodeに分類できます。これらのキャラクタ・セット間には互換性がないので、一度決定してしまうと他のキャラクタ・セットに変更することはできません。

 

dbcaで指定するキャラクタ・セットのデフォルトは、Oracle Database 12c Release 1までは各プラットフォームで使用される日本語の標準的なキャラクタ・セットを継承していました。たとえばLinuxではEUCであるため、データベース・キャラクタセットの候補に現れるデフォルト設定はJA16EUCでした。Oracle Database 12c Release 2からは、UnicodeであるAL32UTF8がデフォルトとなりました。

img-3

SJIS系やEUC系よりもUnicodeの方が表現できる文字が多いので、特に理由がなければAL32UTF8にします。また、AL32UTF8でなければできないことがあります。Oracle Database 12c Release 2から、キャラクタ・セットの異なるPluggable Databaseをプラグできるようになりましたが、その前提条件はコンテナ・データベースのキャラクタ・セットがAL32UTF8であるということです。 また、各国語キャラクタ・セットとはUnicodeを格納するためのNCHAR、NVARCHAR2、NCLOBのキャラクタ・セットです。AL16UTF16とUTF8が選択できますが、UTF8は過去の互換性のためにのみあるので、実質的にAL16UTF16一択です。dbcaのデフォルトはAL16UTF16です。

2. 変更可能ではあるが手順が煩雑な要素

データベース作成後にも変更可能ですが、操作が煩雑なため、データベース作成時に決定しておくべき要素があります。

  • データベース名/インスタンス名
  • データベースのファイル配置
  • オンラインREDOログ・ファイルのサイズ

2.1. データベース名/インスタンス名

データベース名とインスタンス名もデータベースを作成するときに指定する要素です。Oracle Databaseの文脈で「データベース」というのは、ストレージ上に構成されたオンラインREDOログ、制御ファイル、データファイルの集合のことを指します。これに対し「インスタンス」というのは共有メモリー領域(System Global Area)とバックグラウンド・プロセス群のことを指します。

img-4

データベースを作成するとき、データベースとインスタンスそれぞれに名前をつけます。シングル・インスタンス構成では、多くの場合データベース名とインスタンス名は同じ名前をつけます。dbcaではグローバル・データベース名を指定する箇所がありますが、これはデータベース名(DB_NAME)+データベース・ドメイン名(DB_DOMAIN)を指定しています。データベース名をあらわすパラメータは2階層あり、DB_NAMEとDB_UNIQUE_NAMEがあります。DB_UNIQUE_NAMEのデフォルト値はDB_NAMEを継承します。CREATE DATABASE文で使用するデータベース名はDB_NAMEですが、データベースを作成するディレクトリの名前など、管理上のデータベース名はDB_UNIQUE_NAMEを使用します。

なぜデータベース名をあらわすパラメータが2階層あるかというと、Oracle Data Guardのように、データベースのフルバックアップから別のデータベースを構成する場合があるからです。フルバックアップから別のデータベースを構成すると、同じDB_NAMEを持ったデータベースがシステムの中に複数存在することになります。これらのデータベースを管理操作上区別するために、それぞれ一意なDB_UNIQUE_NAMEを指定します。

SID接頭辞というのがインスタンス名の接頭辞です。シングル・インスタンス構成ではこれがそのままインスタンス名になります。

img-5

RACの場合は1つのデータベースを複数のノードの複数のインスタンスがマウントします。RACのインスタンス名はクラスタ内で一意になっている必要があるため、インスタンス名はSID接頭辞に1、2、...というように数字が付加されます。

img-6

データベース名とインスタンス名をもとに、トレース・ファイルを格納するディレクトリやデータベースのファイル配置を構成します。そのため、一度決めた名前を変更しようとすると、ディレクトリに付けた名前と食い違いが発生するため、運用管理上あまりよくありません。また、Oracle Grid Infrastructureをインストールしている環境では、データベースとインスタンスはその名前で監視対象リソースとして登録されます。他のリソースとの依存関係が自動的に設定されるため、データベースとインスタンスの名前を変更する場合はこれら依存関係も修正する必要があります。これらの変更を行う場合、失敗するとOracleインスタンスがデータベースをオープンできなくなる場合があります。人為的ミスが起こりやすいため、データベース名とインスタンス名は複数あるシステムの中でも一意になるようにあらかじめ検討しておくべきです。

また、Oracle Database 12c Release 1からコンテナ・データベースという概念が導入されました。コンテナ・データベースでは1つのコンテナ上に複数のプラガブル・データベースを作成することができます。複数のプラガブル・データベースを作成するにはEnterprise EditionにOracle Multitenantのオプション・ライセンスが必要です。そして、Oracle Database 12c Release 2からは非コンテナ・データベースの構成は非推奨になりました。将来サポートされなくなる可能性があるため、新規で作成するデータベースはコンテナ・データベースとしてください。プラガブル・データベースの名前も複数あるシステムにわたって一意になるように検討してください。

2.2. データベースのファイル配置

CREATE DATABASEを実行すると、表領域を構成するデータファイルと制御ファイル、オンラインREDOログ・ファイルが作成されます。データファイルとオンラインREDOログ・ファイルの位置は制御ファイルに記録されています。そのため、これらのファイルを移動させたい場合、単純にOSのファイル移動コマンドで移動させただけではデータベースをオープンできなくなります。これらのファイルを移動させるには、物理的にファイルを移動させるだけでなく、ALTER DATABASE文で制御ファイルの内容も変更する必要があります。

データベースを構成するファイルを移動させるのは煩雑な手順が必要であるため、データベースを格納するストレージ領域についてはよく検討しておく必要があります。CREATE DATABASEを実行する前に、データベースを格納する領域と、高速リカバリ領域(Fast Recovery Area)となるファイルシステムやASMディスク・グループを構成しておきます。

dbcaでデータベースを作成するとき「データベース・ファイルの位置」を指定します。ここに指定した場所が初期化パラメータDB_CREATE_FILE_DESTになります。DB_CREATE_FILE_DESTとOracle Managed Files(OMF)の仕組みを組み合わせると、このディレクトリの配下にデータベースを構成するファイルのファイル名が自動生成されます。ASMディスク・グループを指定する場合は、ディスク・グループ名の前に”+”記号が付きます。

img-7

この画面で「データベース・ファイルの位置」にDB_UNIQUE_NAMEが含まれています。データベースを構成するファイルの位置はDB_NAMEではなくてDB_UNIQUE_NAMEを基準に構成されます。CREATE DATABASEする時点ではDB_UNIQUE_NAMEはDB_NAMEに一致しています。また「REDOログおよび制御ファイルの多重化」をクリックすると、オンラインREDOログと制御ファイルの作成場所をDB_CREATE_FILE_DEST とは別の場所に指定することができます。これが初期化パラメータDB_CREATE_ONLINE_LOG_DEST_nになります。DB_CREATE_ONLINE_LOG_DEST_nを複数指定すると、オンラインREDOログと制御ファイルがこのディレクトリの配下に多重化されます。

img-8

また、dbcaで高速リカバリ領域も指定することができます。高速リカバリ領域はアーカイブREDOログ、RMANバックアップ・ファイル、フラッシュバック・ログが格納される領域です。この画面でDB_RECOVERY_FILE_DESTとDB_RECOVERY_FILE_DEST_SIZEを指定します。

img-9

高速リカバリ領域(DB_RECOVERY_FILE_DEST)はデータベースが破損した場合に備えるための領域であるため、データベースを構成する領域(DB_CREATE_FILE_DEST)とは物理的に別のストレージ・デバイスに格納すべきです。

DB_CREATE_ONLINE_LOG_DEST_nを指定しなかった場合、オンラインREDOログと制御ファイルはDB_CREATE_FILE_DESTとDB_RECOVERY_FILE_DESTの両方の領域にまたがって多重化されます。

2.3. オンラインREDOログ・ファイルのサイズ

オンラインREDOログのファイルはCREATE DATABASE時に作成されます。オンラインREDOログは固定サイズのファイルが循環して使用されます。データベースの更新はログ・ライター・プロセスによってオンラインREDOログに記録されます。書き込みが1つのオンラインREDOログ・メンバーのサイズに達すると、次のログ・メンバーに移って書き込みを開始します。オンラインREDOログは循環して使用されるため、ログ・メンバーへの書き込みが1週すると前のREDOログ情報を上書きします。

img-10

アーカイブログ・モードでは、REDO情報が消失しないようにアーカイバ・プロセスによってアーカイブREDOログ・ファイルにコピーされていきます。ここで、アーカイバ・プロセスによってオンラインREDOログのコピーが完了しているかつ、そのオンラインREDOログに含まれる更新情報に該当するデータ・ブロックのチェックポイントが完了するまで、ログ・ライター・プロセスによるそのログ・メンバーへの書き込みはできないようになっています。そのため、REDO生成量が多いシステムでは、ログ・ライター・プロセスのオンラインREDOログへの書き込みが待機させられるということが起こりえます。つまり、更新トランザクションの進行が待機させられる場合があります。このような状況になることを避けるために、オンラインREDOログ・ファイルのサイズを大きくするか、メンバーの数を追加するという対策があります。

dbca でデータベースを作成する場合、オンラインREDOログ・メンバーのサイズは、Oracle Database 12c Release 1までのデフォルト値は50MBになっています。Oracle Database 12c Release 2からは200MBになっています。これらの値は、REDO生成量が多いシステムでは小さすぎる場合があります。Oracle Database Cloud Serviceでは、オンラインREDOログ・メンバーのサイズは1GBでデータベースが作成されます。dbcaでオンラインREDOログ・メンバーのサイズを設定するには「データベース作成オプション」の画面で「記憶域の場所のカスタマイズ」をクリックします。

img-11

「記憶域のカスタマイズ」の画面でRedo Log Groupsを選択するとREDOログのファイル・サイズを変更できます。すべてのREDOログ・グループで同じサイズを指定します。REDOログ・メンバーの追加もここで可能です。

RAC構成の場合、OracleインスタンスごとにオンラインREDOログを持ちます。これをREDOスレッドと呼びます。REDOログ・グループを追加する場合、各REDOスレッドが同じ個数のREDOログ・グループを持つようにしてください。

img-12

CREATE DATABASEを実行して一度作成してしまったオンラインREDOログ・ファイルのサイズは変更することができません。そのため、サイズを変更したい場合は、ALTER DATABASE文でサイズの大きなREDOログ・メンバーを追加し、その後にもとからあったサイズの小さなREDOログ・メンバーを削除するという工程をとります。

3. 容易に変更できる要素

データベース作成後にも容易に変更できるパラメータがあります。これらはALTER SYSTEM文でOracleインスタンスの設定を変更するパラメータです。dbcaでデータベースを作成するときに指定するパラメータには以下のものがあります。

  • SGAとPGAのサイズ
  • 接続モード
  • Oracleインスタンスに接続するプロセス数

3.1. SGAとPGAのサイズ

Oracleインスタンスに割り当てるメモリーのサイズを指定します。大別するとSystem Global Area(SGA)とProgram Global Area(PGA)に分かれます。メモリー管理の手法もバージョンがあがるにつれ自動化されてきました。

img-13

手動共有メモリー管理はOracle9i Databaseのメモリー構成方法です。SGA内の個別領域のサイズを指定していました。 Oracle Database 10gで自動共有メモリー管理が実装されました。SGA内の個別領域のサイズを指定するのではなく、SGA全体のサイズを指定すればよくなりました。SGA内の各領域の割り当ては自動調整されます。

Oracle Database 11gではSGAとPGAを合算して管理する自動メモリー管理が実装されました。SGAとPGAの割り当てが自動調整されます。

img-14

dbcaではメモリーの割り当て方をこれらの3種類から選択します。

Linuxプラットフォームで自動メモリー管理を使用するためには、Oracleインスタンスを起動する前に/dev/shmをSGAとPGAの合計以上のサイズに構成しておく必要があります。Oracle Linux 6と7のデフォルト構成では/dev/shmは物理メモリーの半分に設定されています。dbcaで物理メモリーの50%以上の領域を割り当てたい場合は、dbcaを起動する前に/dev/shmのサイズを変更してください。しかし、/dev/shmの領域は、OSが扱うメモリーのページサイズを大きくするhugepageの仕組みを使用することができません。数10GB以上の巨大なSGAを構成する場合はhugepageの使用をお勧めします。hugepageを使用する場合は、SGAとPGAを個別に管理する自動共有メモリー管理を使用します。また、hugepageの領域をOracleインスタンスがどのように扱うかは初期化パラメータUSE_LARGE_PAGEで設定します。

3.2. 接続モード

アプリケーション・サーバーなどのOracleクライアントからOracleサーバーに接続しSQLを発行すると、Oracleサーバー・プロセスによってSQLが実行されます。接続モードとは、OracleクライアントからのコネクションとOracleサーバー・プロセスの関係を決める設定です。接続モードには専用サーバーと共有サーバー、そしてDatabase Resident Connection Pool(DRCP)があります。dbcaで設定できるのは専用サーバーと共有サーバーです。

img-15

専用サーバー・モードは、OracleクライアントからのコネクションとOracleサーバー・プロセスが1対1の関係になるモードです。Oracleクライアントからの接続リクエストがOracleリスナー・プロセスに届くと、Oracleリスナー・プロセスはOracleサーバー・プロセスを生成し、コネクションはOracleサーバー・プロセスに接続されます。専用サーバー・モードは最も基本的な接続モードです。

共有サーバー・モードは、OracleクライアントからのコネクションとOracleサーバー・プロセスがm対nの関係になるモードです。あらかじめ生成されたOracleサーバー・プロセスがOracleインスタンスに接続しており、共有サーバー・プロセスと呼ばれます。共有サーバー・プロセスはキューを経由してディスパッチャ・プロセスと接続しています。Oracleクライアントからの接続リクエストがOracleリスナー・プロセスに届くと、コネクションはディスパッチャ・プロセスに接続されます。

img-16

専用サーバー・モードはOracleクライアントとOracleサーバー・プロセスが直結しているため、高いSQL実行性能を示します。Webアプリケーション・サーバーのようにコネクション・プールを持ち、各コネクションから発行されるSQLの間隔が短い場合に適しています。

共有サーバー・モードはクライアント・サーバー・モデルのように各コネクションから発行されるSQLの間隔が長い場合に適しています。多数のコネクションを確立するけれども、各コネクションはアイドルである時間の割合が高い場合、SQLリクエストをキューでまとめることで少数のOracleサーバー・プロセスで処理できます。共有サーバー・モードはOracle初期化パラメータのSHARED_SERVERSとDISPATCHERSを設定することで構成します。

3.3. Oracleインスタンスに接続するプロセス数

Oracleインスタンスに接続するプロセス数とは、バックグラウンド・プロセスとOracleサーバー・プロセスの合計値の上限です。dbcaでは「サイズ設定」のタブで指定します。これが初期化パラメータPROCESSESになります。

img-17

このPROCESSESの値を超えてOracleサーバー・プロセスを生成しようとするとORA-20のエラーとなります。専用サーバー構成の場合、コネクションとOracleサーバー・プロセスが1対1の関係であるため、多数のプロセスが生成される傾向があります。そのため、PROCESSESの値を調整する場合があります。

dbcaで設定する初期化パラメータは全体のごく一部です。ほとんどのパラメータはデータベース作成後にもALTER SYSTEM文で変更できます。

連載第2回は、データベース作成前に検討しておくべきパラメータというテーマで解説しました。次回はネットワーク経由でOracle Databaseに接続するというテーマを扱う予定です。OracleクライアントはOracleサーバーの何を指定して接続しているのでしょうか。その動作原理から解説します。