11gリリース1（11.1）
E05765-03
 目次 |
 索引 |
| Oracle Database 概要 11gリリース1（11.1） E05765-03 |
|
この章では、Oracleデータベース・インスタンスおよびデータベースの起動と停止に関連する手順を説明します。
この章の内容は、次のとおりです。
稼働中のすべてのOracle Databaseは、Oracleデータベース・インスタンスに対応付けられます。データベース・サーバー上で（コンピュータの種類に関係なく）データベースを起動すると、Oracle Databaseによってシステム・グローバル領域（SGA）と呼ばれるメモリー領域が割り当てられ、1つ以上のOracle Databaseプロセスが開始されます。このSGAとOracle Databaseプロセスを組み合せて、Oracle インスタンスと呼びます。インスタンスのメモリーとプロセスは、対応付けられたデータベースのデータを効果的に管理し、データベースを使用する1人以上のユーザーのために機能します。
図12-1にOracleデータベース・インスタンスを示します。
この項の内容は、次のとおりです。
インスタンスを起動した後、Oracle Databaseは指定されたデータベースにインスタンスを対応付けます。これはマウントされたデータベースです。これでデータベースをオープンできるようになり、許可されたユーザーがアクセスできるようになります。
複数のインスタンスを同時に同じコンピュータ上で実行し、それぞれ専用の物理データベースにアクセスさせることができます。大規模クラスタ・システムでは、Oracle Real Application Clustersにより、複数のインスタンスが1つのデータベースをマウントできます。
データベース管理者のみが、インスタンスを起動してデータベースをオープンできます。データベースがオープンされている場合、データベース管理者はそのデータベースを停止してクローズできます。データベースがクローズされている場合、ユーザーはそのデータベース内のデータにアクセスできません。
データベースの起動と停止のセキュリティは、管理者権限を使用してOracle Databaseに接続することによって制御されます。一般のユーザーは、Oracleデータベースの現在の状態を制御できません。
データベースの起動と停止は強力な管理オプションであり、管理者権限を使用してOracle Databaseに接続するユーザーのみがこれを行うことができます。ユーザーの管理者権限を確立するには、オペレーティング・システムに応じて、次のいずれかの条件が必要です。
SYSDBAまたはSYSOPER権限を付与されており、データベースがパスワード・ファイルを使用してデータベース管理者を認証していること
SYSDBA権限で接続すると、ユーザーはSYSが所有するスキーマ内に置かれます。SYSOPERとして接続すると、そのユーザーはパブリック・スキーマ内に置かれます。SYSOPER権限は、SYSDBA権限のサブセットです。
|
関連項目
|
インスタンスを起動するには、Oracle Databaseは初期化パラメータ・ファイルまたはサーバー・パラメータ・ファイルを読み取る必要があります。これらのファイルには、インスタンスおよびデータベースの構成パラメータのリストが格納されます。Oracle Databaseでは従来より、初期化パラメータはテキスト形式の初期化パラメータ・ファイルに格納されます。また、サーバー側のバイナリ形式のサーバー・パラメータ・ファイル（SPFILE）に保持するように選択することもできます。
サーバー・パラメータ・ファイルに格納されている初期化パラメータは永続的です。つまり、インスタンスの実行中に行われたパラメータへの変更は、インスタンスを停止して起動しても残ります。
初期化パラメータは、基本と拡張という2つのグループに分かれています。ほとんどの場合、妥当なパフォーマンスが得るには、基本パラメータのみを設定およびチューニングする必要があります。ただし最適なパフォーマンスを得るために、拡張パラメータの変更が必要になる場合があります。
ほとんどの初期化パラメータは、次のグループのいずれかに属しています。
初期化パラメータは主に、Oracle Databaseに次のことを指定ます。
この項の内容は、次のとおりです。
オラクル社のHardware Assisted Resilient Data（HARD）initiativeは、データ破損を未然に防ぐよう設計された包括的なプログラムです。Oracle Databaseでは、ストレージ・デバイス内にOracleのデータ検証アルゴリズムを実装することにより、破損データが永続ストレージに書き込まれるのを防ぐことができます。Oracle Database 11gから、HARDに準拠したストレージ・システムで使用可能な新しい形式でサーバー・パラメータ・ファイルを作成できます。データベースは、新旧どちらの形式でも、サーバー・パラメータ・ファイルを読み取りおよび書き込みできます。
データベース管理者は、データベース・システムのパフォーマンスを改善するために、可変パラメータを調整できます。どのパラメータがシステムに最も強い影響を与えるかは、データベースの様々な特性や変数によって異なります。
一部のパラメータは、インスタンスの実行中にALTER SESSION文またはALTER SYSTEM文を使用して動的に変更できます。サーバー・パラメータ・ファイル（SPFILE）を使用していないかぎり、ALTER SYSTEM文を使用して行われる変更は、現行インスタンスにのみ有効になります。次回のインスタンス起動時に変更内容を確認するには、テキスト初期化パラメータ・ファイルを手動で更新する必要があります。
サーバー・パラメータ・ファイルの使用時には、ALTER SYSTEM SET文を使用してメモリーまたはディスク内（あるいはその両方）のパラメータ値を変更できます。データベースにより、新しい値と古い値（存在する場合）がアラート・ログに出力されます。基本的なパラメータを変更すると、不正な値がサーバー・パラメータ・ファイルに書き込まれるのを防ぐため、予防策として、データベースにより検証ステップが実行されます。
Oracle Databaseは、データベース・ソフトウェアで提供される最初の初期化パラメータ・ファイル、またはDatabase Configuration Assistantにより作成される最初の初期化パラメータ・ファイルに値を提供します。構成、オプションおよびデータベースのチューニング計画に応じて、これらのOracle提供の初期化パラメータを編集し、他のパラメータを追加できます。該当する初期化パラメータが初期化パラメータ・ファイルに特に組み込まれていない場合には、Oracle Databaseによりデフォルトが指定されます。データベースを初めて作成する場合は、パラメータ値の変更数を最小限に抑えることをお薦めします。
Oracleデータベースを起動して、システム全体で使用可能にするには、次の3つの操作を行います。
データベース管理者は、SQL*PlusのSTARTUP文やEnterprise Managerを使用してこれらの手順を実行できます。
この項の内容は、次のとおりです。
Oracle Databaseは、インスタンスを起動するときに、サーバー・パラメータ・ファイル（SPFILE）または初期化パラメータ・ファイルを読み取って、初期化パラメータの値を決定します。その後、データベース情報用の共有メモリー領域であるSGAを割り当てて、バックグラウンド・プロセスを作成します。この時点では、これらのメモリー構造とプロセスにデータベースは対応付けられていません。
インスタンスが起動されると、明示的に設定されたすべてのパラメータは、パラメータの有効な構文でアラート・ログに書き込まれます。必要な場合には、このテキストをコピーして新しいパラメータ・ファイルに貼り付け、インスタンスを再起動できます。
この項の内容は、次のとおりです。
インスタンスを制限モードで起動したり、既存のインスタンスを制限モードに変更できます。これにより、接続はRESTRICTED SESSIONシステム権限を付与されているユーザーのみに制限されます。
異常な状況では、直前のインスタンスが正常に停止していないことがあります。たとえば、インスタンスのプロセスのいずれかが正常に終了していないことがあります。そのような状況では、次回インスタンスを通常起動するときにデータベースからエラーが戻されます。この問題を解決するには、前のインスタンスからの残留Oracle Databaseプロセスをすべて終了してから、新しいインスタンスを起動する必要があります。
インスタンスは、データベースをマウントして、データベースをそのインスタンスに関連付けます。データベースをマウントすると、そのインスタンスはデータベース制御ファイルを見つけてオープンします。制御ファイルは、インスタンスの起動に使用されるパラメータ・ファイルのCONTROL_FILES初期化パラメータで指定します。Oracle Databaseは、制御ファイルを読み取って、データベースのデータファイルとREDOログ・ファイルの名前を取得します。
マウント直後のデータベースはまだクローズされているため、データベース管理者のみがそのデータベースにアクセスできます。データベース管理者は、特定のメンテナンス操作を完了するまでの間、データベースをクローズしたままにしておくことができます。ただし、データベースに対して通常の操作を行うことはまだできません。
この項の内容は、次のとおりです。
Oracle Databaseで、複数のインスタンスが同じデータベースを同時にマウントすることが可能な場合、データベース管理者は、複数のインスタンスがデータベースを利用できるように、CLUSTER_DATABASE初期化パラメータを使用できます。CLUSTER_DATABASEパラメータのデフォルト値はfalseです。Oracle RACをサポートしないOracle Databaseのバージョンでは、CLUSTER_DATABASEをfalseにのみ設定できます。
データベースをマウントする最初のインスタンスのCLUSTER_DATABASEパラメータがfalseの場合は、最初のインスタンスのみがデータベースをマウントできます。このCLUSTER_DATABASEパラメータがtrueに設定されていると、他のインスタンスもCLUSTER_DATABASEパラメータがtrueに設定されている状態でデータベースをマウントできます。データベースをマウントできるインスタンスの数は、データベースの作成時に指定した最大数によって決まります。
クローン・データベースは、表領域のポイント・イン・タイム・リカバリに使用できる、データベースの特殊コピーです。表領域のポイント・イン・タイム・リカバリを実行する場合は、クローン・データベースをマウントし、表領域を目的の時点までリカバリします。次に、クローンからプライマリ・データベースにメタデータをエクスポートし、リカバリされた表領域からデータファイルをコピーします。
マウントされたデータベースをオープンすると、そのデータベースで通常のデータベース操作を実行できるようになります。有効なユーザーは、オープン状態のデータベースに接続して、データベースの情報にアクセスできます。通常、データベース管理者は、データベースをオープンして一般に使用できる状態にします。
Oracle Databaseでは、データベースをオープンするときに、オンライン・データファイルとREDOログ・ファイルをオープンします。データベースを前回停止したときに表領域がオフラインであった場合は、データベースを再オープンしたとき、その表領域と対応するデータファイルはオフラインのままです。
データベースをオープンするとき、データファイルまたはREDOログ・ファイルが欠如していると、Oracle Databaseからエラーが戻されます。そのデータベースをオープンするには、破損または欠落したファイルのバックアップからリカバリする必要があります。
この項の内容は、次のとおりです。
SGAのバッファ・キャッシュ内のデータベース・バッファは、最低使用頻度（LRU）アルゴリズムを使用して、必要な場合にのみディスクに書き込まれます。このアルゴリズムがデータベース・ライター・プロセスで使用され、データベース・バッファがデータファイルに書き込まれる方法により、データファイルにはコミットされていないトランザクションにより変更されたデータ・ブロックや、コミット済トランザクションからの変更が欠落しているデータ・ブロックが含まれている場合があります。
インスタンス障害が発生すると、次の2つの問題が発生する可能性があります。
データベース管理者によるインスタンスの終了や停電などの理由から、前回のデータベースのクローズが正常に行われていない場合、Oracle Databaseでは、データベースを再びオープンするときに、インスタンス・リカバリまたはクラッシュ・リカバリが自動的に実行されます。
クラッシュ・リカバリは、シングル・インスタンス・データベースの障害時、またはOracle Real Application Clustersデータベースの全インスタンスの障害時のリカバリに使用します。インスタンス・リカバリでは、障害の発生していないインスタンスがOracle Real Application Clustersデータベース内で障害インスタンスをリカバリする場合について説明します。
クラッシュ・リカバリとインスタンス・リカバリを行う目的は、終了したインスタンスのキャッシュ内にあるデータ・ブロックの変更をリストアし、オープン状態になっていたREDOスレッドをクローズすることです。インスタンス・リカバリおよびクラッシュ・リカバリでは、オンラインREDOログ・ファイルと現行のオンライン・データファイルのみが使用されます。Oracle Databaseでは、終了したインスタンスのREDOスレッドも同時にリカバリされます。
暗号化された表領域を持つデータベースをリカバリする場合（たとえば、SHUTDOWN ABORTやデータベース・インスタンスを停止させるような致命的なエラーの後）、リカバリ・プロセスがデータ・ブロックとREDOを復号化できるように、データベースのマウント後、データベースをオープンする前に、Oracle Walletをオープンする必要があります。
クラッシュ・リカバリとインスタンス・リカバリは、2つの異なる操作を伴います。1つはオンラインREDOレコードに含まれるコミット済トランザクションとコミットされていないトランザクションの両方を適用し、現行のオンライン・データファイルをロールフォワードすることです。もう1つは、コミットされていないトランザクションで行われた変更を元の状態までロールバックすることです。
クラッシュ・リカバリとインスタンス・リカバリには、次の共通する特性があります。
SHUTDOWN ABORTの後もディスクに残っている）オンライン・データファイルを使用して変更をREDOします。
Oracle Databaseでは、次の2つの場合にこのリカバリが自動的に実行されます。
重要な点は、クラッシュ・リカバリでもインスタンス・リカバリでも、Oracle Databaseによって自動的にREDOが適用されることです。REDOログを提供するためにユーザーが介入する必要はありません。ただし、データベース・サーバーでパラメータを設定して、インスタンスの存続期間とクラッシュ・リカバリのパフォーマンスをチューニングできます。また、インスタンス・リカバリのロールフォワード・フェーズとロールバック・フェーズを別々にチューニングすることもできます。
このジレンマを解決し、システム障害から正常にリカバリするために、Oracle Databaseでは通常、2つの個別のステップが使用されます。1つはREDOログを使用したロールフォワード（キャッシュ・リカバリ）、もう1つはロールバック・セグメントまたはUNDOセグメントを使用したロールバック（トランザクション・リカバリ）です。
この項の内容は、次のとおりです。
このジレンマを解決し、システム障害から正常にリカバリするために、Oracle Databaseでは通常、2つの個別のステップが使用されます。1つはREDOログを使用したロールフォワード（キャッシュ・リカバリ）、もう1つはロールバック・セグメントまたはUNDOセグメントを使用したロールバック（トランザクション・リカバリ）です。
オンラインREDOログは、データ、索引およびロールバック・セグメントなどのデータベース・ブロックに対する変更をすべて記録する、オペレーティング・システム・ファイルの集合です。変更がコミット済かどうかは問いません。Oracle Databaseブロックに対する変更は、すべてオンライン・ログに記録されます。
インスタンス障害またはメディア障害からリカバリする最初のステップを、キャッシュ・リカバリまたはロールフォワードと呼びます。このステップでは、REDOログに記録された変更すべてをデータファイルに再適用する必要があります。REDOログにはロールバック・データも記録されているため、ロール・フォワードでは対応するロールバック・セグメントも再生成されます。
ロールフォワードでは、必要に応じて多数のREDOログ・ファイルをたどり、データベースを後の時点まで進行させます。通常、ロールフォワードにはオンラインREDOログ・ファイルが含まれ（インスタンス・リカバリまたはメディア・リカバリ）、アーカイブREDOログ・ファイルが含まれる場合（メディア・リカバリのみ）もあります。
ロールフォワード後のデータ・ブロックには、コミット済の変更がすべて含まれています。また、障害発生前にデータファイルに保存されていたか、REDOログに記録されてキャッシュ・リカバリ時に取り込まれた、コミットされていない変更も含まれることがあります。
ロールフォワード後は、コミットされなかった変更を取り消す必要があります。Oracle DatabaseはUNDOブロックを適用して、障害発生前に書き込まれたか、キャッシュ・リカバリ中にREDOの適用により取り込まれたデータ・ブロック内の、コミットされていない変更をロールバックします。このプロセスをロールバックまたはトランザクション・リカバリと呼びます。
図12-2に、ロールフォワードとロールバックを示します。この2つは、どのタイプのシステム障害からのリカバリにも必要なステップです。
Oracle Databaseは、必要に応じて同時に複数のトランザクションをロールバックできます。障害時点でアクティブになっていたトランザクションすべてに、終了マークが付けられます。終了したトランザクションがSMONによりロールバックされるのを待たずに、新規トランザクションでは阻止しているトランザクション自体をリカバリし、必要な行ロックが取得されます。
|
関連項目
|
データベースをオープンするときに、インスタンスによりUNDO表領域の取得が試行されます。複数のUNDO表領域が存在する場合には、使用するUNDO表領域をUNDO_TABLESPACE初期化パラメータで指定できます。このパラメータが指定されていない場合、データベース内で使用可能な最初のUNDO表領域が選択されます。
場合によっては、データベースが異常にクローズし、1つ以上の分散トランザクションがインダウト（コミットもロールバックもされない状態）になることがあります。データベースを再オープンし、リカバリが完了すると、RECOバックグラウンド・プロセスがただちに自動的に実行されて、インダウト分散トランザクションが矛盾のないように解決されます。
データベースは、ユーザー・トランザクションによってデータが変更されるのを防ぐために、読取り専用モードでオープンできます。読取り専用モードでは、データベース・アクセスは読取り専用トランザクションに限定され、データファイルやREDOログ・ファイルに書き込むことはできません。
制御ファイル、オペレーティング・システムの監査証跡、トレース・ファイルおよびアラート・ログなど、他のファイルへのディスク書込みは、読取り専用モードでも実行できます。データベースを読取り専用モードでオープンしても、ソート操作用の一時表領域には影響しません。ただし、データベースを読取り専用モードでオープンしている間は、永続表領域はオフライン化できません。また、読取り専用モードでは、ジョブ・キューを使用できません。
データベース・リカバリや、REDOデータを生成しないでデータベースの状態を変更する操作には、制限はありません。たとえば、読取り専用モードでは、次の操作を実行できます。
読取り専用モードの利点の1つは、スタンバイ・データベースが一時レポート用データベースとして使用できることです。
EXPLAIN PLANの実行またはDDLの実行時にデータベース・オブジェクトが作成されます。DBMS_SCHEDULERなどのOracle提供PL/SQLパッケージにあるファンクションやプロシージャの多くは、データベース・オブジェクトを作成します。アプリケーションで、これらのファンクションおよびプロシージャが呼び出されるか、前述の操作が実行されると、データベース・オブジェクトが書き込まれ、読取り専用ではなくなります。
SELECT文を実行する場合にも該当します。
REMOTE_DEPENDENCIES_MODE=SIGNATUREを使用します。
データベースとそれに対応付けられたインスタンスを停止するには、次の3つの操作を行います。
データベース管理者は、これらの手順をEnterprise Managerを使用して実行できます。Oracle Databaseでは、インスタンスの停止時にこの3つの手順が自動的に実行されます。
この項の内容は、次のとおりです。
データベースをクローズすると、Oracle DatabaseによりSGAにあるすべてのデータベース・データとリカバリのためのデータが、それぞれデータファイルとREDOログ・ファイルに書き込まれます。次に、Oracle Databaseがすべてのオンライン・データファイルとREDOログ・ファイルをクローズします。（オフライン表領域のオフライン・データファイルは、すでにクローズされています。オフラインになっていた表領域とそのデータファイルは、この後でデータベースを再オープンしたとき、それぞれオフラインでクローズされたままになっています。）この時点でデータベースはクローズされているため、通常の操作は実行できません。データベースがクローズされても、まだマウントされていれば、制御ファイルはオープンされたままになります。
万一の非常時には、オープン状態のデータベースのインスタンスを終了させて、データベースをクローズし、ただちに完全に停止させることができます。SGAのバッファにあるすべてのデータをデータファイルとREDOログ・ファイルに書き込む操作が省略されるため、このプロセスは高速に実行されます。次にデータベースを再オープンするときに必要なリカバリは、Oracle Databaseで自動的に実行されます。
データベースがクローズされると、Oracle Databaseはデータベースをアンマウントしてインスタンスから切り離します。この時点ではインスタンスはコンピュータのメモリーに残っています。
データベースをアンマウン卜すると、Oracle Databaseでは、データベースの制御ファイルがクローズされます。
データベース停止の最後の操作は、インスタンスの停止です。インスタンスを停止すると、SGAがメモリーから削除され、バックグラウンド・プロセスが停止します。
異常な状況では、すべてのメモリー構造がメモリーから削除されない、またはバックグラウンド・プロセスの1つが終了されないなど、インスタンスが正常に停止しないことがあります。前のインスタンスの一部が残っていると、その後にインスタンスを起動しようとしても、ほとんどの場合に失敗します。このような状況では、データベース管理者は、まず残っている前のインスタンスを削除してから新しいインスタンスを起動するか、SQL*PlusまたはEnterprise ManagerでSHUTDOWN ABORT文を発行することで、新しいインスタンスの起動を強制実行できます。
|
 Copyright © 1993, 2008 Oracle Corporation. All Rights Reserved. |
|