Oracle データベースを使用する
Oracleデータベースを使用する流れについて解説します。
Oracle データベースを使用するには以下の手順の作業を実施する必要があります。
- Oracleソフトウェアをインストールする
- Oracleデータベースを作成する
- アプリケーション用のユーザーを作成する
- ユーザーに権限を付与する
- 表を作る・データを読み書きする
Oracleデータベース管理者のタスク
システム運用前、もしくは運用中にOracleデータベースの管理者が行う管理タスクについて解説します。
主なタスクは以下の通りです。
障害の種類から、必要な復旧を考える
「データベースが使えない」という症状だけでは、復旧方法は決まりません。接続中の一つの処理が終了したのか、インスタンスが停止したのか、保存先のファイルが壊れたのかを分けて考えます。
| 障害の種類 | 状況の例 | 復旧の考え方 |
|---|---|---|
| プロセスやセッションの障害 | ある利用者の接続が途中で切れた。 | 関連するプロセス群が資源を回収し、未完了のトランザクションを取り消します。他の利用者の処理まで、必ず停止するわけではありません。 |
| インスタンス障害 | サーバーの停止などでメモリー上の状態を失ったが、データベース・ファイルは残っている。 | 再起動時にREDOとUNDOを使って整合性を回復する、インスタンス・リカバリを行います。 |
| メディア障害 | ディスク故障や誤削除で、必要なデータファイルを失った。 | 失ったファイルをバックアップから戻し、必要な変更を適用するメディア・リカバリを行います。 |
| 利用者の操作ミス | 必要な行を削除してCOMMITした。 | インスタンスを再起動するだけでは元に戻りません。保持された情報や対象に応じて、フラッシュバックや過去時点へのリカバリなどを検討します。 |
問題文に「ファイルは失われていない」「データファイルを削除した」「誤った変更を確定した」といった条件があれば、それが復旧方法を選ぶ手掛かりになります。インスタンス・リカバリとメディア・リカバリを、どちらも単に「再起動すること」と覚えないようにします。
リストアとリカバリは別の作業
バックアップが昨夜の時点のものなら、そこには今日の更新は含まれていません。まずバックアップからデータファイルを取り出す作業がリストアです。そのファイルに、バックアップ以降の変更をREDOなどから適用する作業がリカバリです。
例えば、午前0時にバックアップを取得し、午前9時に注文を登録してCOMMITし、正午にデータファイルを失ったとします。午前0時のバックアップをリストアしただけでは、午前9時の注文は戻りません。必要なREDOがそろっていれば、リカバリでその変更を適用できます。
| 用語 | 行うこと | 注意する点 |
|---|---|---|
| バックアップ | 復旧に使用するファイルなどのコピーを確保します。 | コピーを持つことと、どの時点まで復旧できるかは別の問題です。 |
| リストア | バックアップからファイルを戻します。 | バックアップ後の変更は、これだけでは反映されません。 |
| リカバリ | REDOなどを適用し、必要な状態まで進めます。 | 必要なログなどが欠けていると、希望する時点まで進められないことがあります。 |
このため、バックアップ対象のデータファイルだけでなく、そこから復旧するために必要なログの保存も運用に含めます。復旧できる範囲は「バックアップがあるか」だけで判断できません。
REDOを上書きする前に残すARCHIVELOGモード
オンラインREDOログは、複数のグループを順に使用し、最後まで進むと再利用します。再利用された領域では古い変更記録が上書きされます。バックアップ後の変更を長い期間さかのぼって適用するには、その変更記録を別に残す必要があります。
ARCHIVELOGモードでは、使用済みオンラインREDOログの内容をアーカイブREDOログとして保存します。通常はARCnプロセスがアーカイブを行い、必要なアーカイブが完了するまで、そのオンラインREDOログを再利用しません。同じグループのメンバーには同じREDOが記録されるため、アーカイブはグループ内の一つのメンバーの内容をコピーして作成します。
| 比較 | NOARCHIVELOG | ARCHIVELOG |
|---|---|---|
| 使用済みREDOの保存 | 再利用前のアーカイブを行いません。 | アーカイブREDOログとして保存します。 |
| 通常のバックアップ運用 | 正常に停止したデータベース全体の、一貫性バックアップを取得します。 | 一貫性バックアップに加え、データベースをOPENしたままのバックアップも可能です。 |
| メディア障害からの復旧 | 基本は、一貫性のあるデータベース全体のバックアップ時点に戻します。 | バックアップと必要なREDOがそろえば、バックアップ後の変更も回復できます。 |
| インスタンス・リカバリ | 可能です。 | 可能です。 |
NOARCHIVELOGでもオンラインREDOログは記録され、インスタンス・リカバリに使われます。「アーカイブしない」と「REDOを生成しない」は違います。また、ARCHIVELOGであることだけで任意の時点への復旧が保証されるわけではなく、必要なバックアップとログがそろっていることが前提です。
モードの確認と変更時の状態
SQL*Plusでは、管理権限で接続してARCHIVE LOG LISTを実行すると、現在のログ・モードなどを確認できます。モードの変更は、データベースをMOUNTし、まだOPENしていない状態で行います。次はARCHIVELOGへ変更する基本的な順序です。
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;これは停止を伴う管理作業です。運用では、変更前のバックアップ、アーカイブ先と容量の準備、変更後の新しいバックアップ取得までを一組で計画します。OPENしたまま変更する手順や、NOMOUNTのまま変更する手順と取り違えないことがポイントです。
高速リカバリ領域で復旧用ファイルを管理する
高速リカバリ領域（FRA）は、アーカイブREDOログやRMANのバックアップなど、復旧に関係するファイルをまとめて管理するための領域です。アーカイブ先の一つとして使用できますが、ARCHIVELOGモードを使うためにFRAが必須というわけではありません。
| 初期化パラメータ | 指定するもの |
|---|---|
| DB_RECOVERY_FILE_DEST | FRAの保存場所。ファイルシステムのディレクトリやASMディスク・グループなど。 |
| DB_RECOVERY_FILE_DEST_SIZE | FRAに使用できる容量の上限。 |
FRAを新たに有効にするときは、容量の上限を設定してから保存場所を設定します。容量を指定しても、その大きさの物理ディスクが新しく用意されるわけではありません。実際のストレージに十分な空きが必要です。
FRAでは、バックアップの保持方針などに基づいて不要になったファイルを管理できます。ただし、空きが不足すれば必要なファイルを何でも自動的に削除してくれる、という意味ではありません。削除できるファイルがなく、アーカイブ先が満杯になると、REDOログを再利用できずデータベースの処理が進まなくなる場合があります。使用量と保持方針を合わせて管理します。
RMANで取得するバックアップ
Recovery Manager（RMAN）は、Oracle Databaseのバックアップ、リストア、リカバリを行うためのツールです。バックアップ対象となるデータベースをターゲット・データベースと呼びます。実行にはSYSDBAまたはSYSBACKUPなど、対応する管理権限が必要です。
RMANでは、データファイル、制御ファイル、サーバー・パラメータ・ファイル（SPFILE）、アーカイブREDOログなどを扱います。オンラインREDOログそのものはRMANのバックアップ対象ではありません。また、パスワード・ファイルやネットワーク設定ファイルなどまで、データベースのバックアップ一回で自動的にすべて保存されるわけではありません。
データベースとログを組み合わせて保存する
次は、制御ファイルの自動バックアップを有効にし、データベースとアーカイブREDOログをバックアップするRMANの例です。アーカイブREDOログを扱うため、ARCHIVELOGモードが前提です。
CONFIGURE CONTROLFILE AUTOBACKUP ON;
BACKUP DATABASE PLUS ARCHIVELOG;制御ファイルの自動バックアップでは、SPFILEを使用している場合はSPFILEも保存します。PLUS ARCHIVELOGは、データファイルのバックアップと、その復旧に必要となるアーカイブREDOログのバックアップを組み合わせるための指定です。BACKUP DATABASEという指定だけを見て、保存済みのアーカイブREDOログもすべて含まれると判断しないようにします。
一貫性バックアップと非一貫性バックアップ
| 種類 | 取得時の考え方 | 復旧時のポイント |
|---|---|---|
| 一貫性バックアップ | NORMAL、IMMEDIATE、TRANSACTIONALなどで正常に停止した状態をもとに取得します。RMANでは停止後にMOUNTし、OPENする前に取得できます。 | 各ファイルの整合性がそろっているバックアップです。NOARCHIVELOGの通常の全体バックアップでは、この方法を使います。 |
| 非一貫性バックアップ | データベースをOPENしたまま取得する場合など、更新が進む状態で取得します。 | 復元したファイルの整合性をそろえるためにリカバリが必要です。OPEN中のバックアップにはARCHIVELOGモードが必要です。 |
「非一貫性」は、失敗したバックアップという意味ではありません。必要なREDOを使って整合性を回復する前提のバックアップです。一方、SHUTDOWN ABORTは正常終了時の処理を完了しないため、「停止したのだから一貫性がある」とは判断できません。
バックアップ・セットとイメージ・コピー
バックアップ・セットはRMAN独自の形式で、不要な未使用ブロックを省略したり、設定により圧縮したりして保存できます。イメージ・コピーは、データファイルなどを元のファイルと同じ形式でコピーしたものです。いずれもバックアップですが、ファイル形式と復旧時の扱いが異なります。
Data Pumpのダンプ・ファイルは表などのオブジェクトを移すための論理的なデータです。データファイルの障害に備えるRMANの物理バックアップとは目的と単位が異なります。「表を別環境に移したい」のか「失ったデータファイルを復旧したい」のかを分けて判断します。
完全リカバリと不完全リカバリ
| 種類 | 目指す状態 | 選ぶ状況の例 |
|---|---|---|
| 完全リカバリ | 必要なREDOを適用し、障害前の最新の状態まで回復します。 | データファイルを失ったが、必要なバックアップとREDOを利用できる場合。 |
| 不完全リカバリ | 指定した過去の時点などでREDOの適用を止めます。時点リカバリとも呼ばれます。 | 誤った変更の直前に戻す場合や、ログが欠けて最新状態まで回復できない場合。 |
不完全リカバリでは、指定時点より後の正しい更新も、その復旧結果には含まれません。「復旧処理が途中で失敗した」という意味ではなく、どの状態を復旧のゴールにするかの違いです。
例えば午前10時に誤って一括更新し、午前10時5分に別の正しい取引を登録したとします。データベース全体を午前9時59分へ戻すなら、午前10時5分の取引もその状態にはありません。対象が一部の表や行であれば、利用できる情報に応じて、より対象を限定した復旧方法も検討します。
公式資料：バックアップとリカバリの実行、アーカイブREDOログの管理、RMANと高速リカバリ領域の構成、RMANバックアップの概念、RMANによるバックアップ、RECOVERコマンド
- Oracle ソフトウェアのインストール
- データベースの作成
- Oracle Network環境の構成
- リスナーの管理（起動/停止）
- インスタンスの管理（起動/停止）
- 表領域の管理
- ユーザーの管理
- スキーマオブジェクトの管理
- データのロード
- パフォーマンスの監視
- バックアップとリカバリの実行
これらのタスクについては、それぞれの詳細を後続の各レッスンで詳細を解説していきます。