VisualC++2005Express(kernel32.libuser32.lib)

（現象）
VisualC++2005でコンパイル／リンクを行うと、「'kernel32.libuser32.lib' を開けません。」というエラーが発生。

（原因）
C:Program FilesMicrosoft Visual Studio 8VCVCProjectDefaultscorewin_express.vspropsのAdditionalDependencies「"kernel32.libuser32.lib～」になっている。
「"kernel32.lib user32.lib～」に訂正すればOK。

ソース

Oracle データベースのリカバリ（５）

4. 制御ファイルのリカバリ
制御ファイルが全滅した場合のリカバリ方法には、以下の２つがある。
・制御ファイルを再作成する（create controlfileコマンド）
・バイナリバックアップ制御ファイルをリストアし、リカバリコマンドを使用する。

4-1. 制御ファイルの再作成
制御ファイルの再作成は、制御ファイルのトレースがあれば、スクリプトを実行するだけで完了できるため、簡単に行うことができる。
なお、制御ファイルを再作成した後には、以下の作業を実行する必要がある。
・一時ファイルの追加
・読み取り専用表領域がある場合は、読み取り専用表領域のデータファイルのリネーム

4-2. バックアップ制御ファイルでのリカバリ
読み取り専用表領域がある場合、以下の点に気をつける。
・バックアップ制御ファイルを取得したときも、現在も読み取り専用表領域であれば、読み取り専用表領域のデータファイルをオフラインにする必要がある。
・障害発生時に読み書き可能表領域だった場合は、読み書き可能になった後のバックアップ制御ファイルが必要
・障害発生時に読み取り専用表領域だった場合は、読み取り専用になった後のバックアップ制御ファイルが必要

・以下は、SQLによるバックアップ制御ファイルを利用したリカバリの例である。

shutdown
OSコマンドによる全てのデータファイルのバックアップ
OSコマンドによるバックアップ制御ファイルと全てのデータファイルのリストア
startup mount
recover database until time '2007-01-08:15:30:00' using backup controlfile
*バックアップ制御ファイルによるリカバリの場合は、using backup controlfileを指定する。また、カレントREDOログファイルをリカバリで使用するときは、リカバリセッションで、ファイル名を直接指定する必要がある。

alter database open resetlogs;

・以下は、RMANによるバックアップ制御ファイルを利用したリカバリの例である。

shutdown
rman target /
startup nomount
set dbid データベースID
* データベースIDは、v$databaseビューのdbidやrmanセッションで表示される情報,自動バックアップ制御ファイルの書式化された名前(CONFIGURE CONTROLFILE AUTOBACKUP FORMATコマンドで指定）で確認できる。

run {
restore controlfile from autobackup;
alter database mount;
recover database;
}

alter database open resetlogs;
alter tablespace temp add tempfile 'データファイル名' size...
*一時ファイルの追加が必要

5. RESETLOGSを介したリカバリ
アーカイブREDOログにRESETLOGS識別子情報を含めれば、RESETLOGS以前のバックアップファイルを使用したリカバリが可能になる。アーカイブREDOログにRESETLOGS識別子を含めるには、LOG_ARCHIVE_FORMAT初期化パラメータにて%rを含める。ただし、フラッシュリカバリ領域にアーカイブREDOログファイルを格納する場合は、フラッシュリカバリ領域は、OMFを使用している為、LOG_ARCHIVE_FORMAT初期化パラメータは無視される。

Oracle データベースのリカバリ（４）

3. REDOロググループのリカバリ

REDOロググループの一部のREDOログメンバーに発生した障害の場合は、データベースはオープンできる。
REDOロググループの全てのREDOログメンバーに発生した障害の場合は、データベースをオープンできない。

v$logビューのstatusが「INACTIVE」のREDOロググループの場合は、REDOログファイルのクリアでリカバリ可能。
ex)
アーカイブREDOログファイルが作成済み（v$logビューのarchivedがYES）で、回復処理が必要でない（v$logビューのstatusがinactive）場合は、以下のSQLでクリアする。
alter database clear logfile group グループ番号;

アーカイブREDOログファイルが未作成（v$logビューのarchivedがNO）で、回復処理が必要でない（v$logビューのstatusがinactive）場合は、以下のSQLでクリアする。 ただし、この場合はアーカイブREDOログファイルが欠落してしまうので、バックアップ計画の見直しが必要になる。
alter database clear unarchived logfile group グループ番号;

v$logビューのstatusがactiveやcurrentのREDOロググループの場合は、全てのデータファイルをリストアし、不完全リカバリを行う。
以下は、SQLによるカレントREDOロググループのリカバリの例である。
ex)
shutdown
OSコマンドによるデータファイルのバックアップ
OSコマンドによるデータファイルのリストア
startup mount
recover database until cancel
cansel...カレントREDOロググループのログ順序番号が表示された時に行う。左記以外の場合は、enterキーを入力
alter database open reserlogs;

以下は、RMANによるカレントREDOロググループのリカバリの例である。

shutdown
OSコマンドによるデータファイルのバックアップ
rman target /
startup mount;
run {
set until sequence カレントREDOロググループのログ順序番号 THREAD 1;
restore database;
recover database;
}
alter database open restlogs;

*1 REDOロググループのstatus,archivedは以下のSQLで確認が可能。
selcet group#, sequence#, bytes, status, archived from v$log;

Oracle データベースのリカバリ（３）

2. 不完全リカバリ

REDOログと同時にクリティカルなデータファイルを失った場合（失ったREDOログまでしかリカバリできない。）や、最新の状態でなくある時点まで戻したい時に、不完全リカバリを行う。

不完全リカバリの流れは以下にようになる。

a. リカバリ前のバックアップ
不完全リカバリが失敗した場合に備え、クローズ状態での全体バックアップを行う。全体バックアップが難しいようであれば、現在の制御ファイルとREDOログファイルのバックアップを行う。

b. 全てのデータファイルのリストア
制御ファイルとREDOログファイルは現在のものを使用し、全てのデータファイルのバックアップファイルをリストアする。

c. 不完全リカバリの実行
SQLコマンド、RMAN、Enterprise Managerを使用して不完全リカバリを行う。全てのデータファイルが同じSCNになるまでREDOログ情報を適用する。
不完全リカバリのタイプには時間ベース、変更ベース、取り消しベースがある。
時間ベース...障害発生時刻が明確な場合、使用
変更ベース...戻す時点のSCNが分かっている場合、使用
取り消しベース...アーカイブREDOログやカレントREDOロググループの損失の場合に使用

d. RESETLOGSオプションを使用してデータベースをオープンする。

e. 不完全リカバリの完了の確認

2-1.SQLによる不完全リカバリコマンドの例

shutdown
OSコマンドでのデータファイルのバックアップ
OSコマンドによるリストア
startup mount
recover automatic database until '2007-01-07:13:30:00'
alter database open resetlogs;

2-2.RMANによる不完全リカバリコマンドの例

shutdown
OSコマンドでのデータファイルのバックアップ
rman target /
startup mount
run {
set until time="to_date('2007-01-07:15:30:00','YYYY-MM-DD:HH24:MI:SS');
restore database;
recover database;
}
alter database open resetlogs;

Oracle データベースのリカバリ（２）

■データベースのリカバリ（２）

1-2. RMAN使用
recoverコマンドを使用した場合と大きな流れは変わらない。

データベース全体をリカバリする場合の手順が以下である。
a. データベースを停止する。
ex) shutdown

b. RMANに接続する。
ex) RMAN target /

c. データベースをマウントする。
ex) stratup mount

d. データベースのリストア
ex) restore database;

e. データベースのリカバリ
ex) recover database;

f. データベースのオープン
ex) alter database open;

表領域単位でのリカバリする場合の手順が以下である。
a. RAMに接続する。
ex) RMAN target /

b. 表領域をオフラインにする。
ex) sql 'alter tablespace 表領域 offline immediate';

c. 表領域のリストア
ex) restore tablespace 表領域;

d. 表領域のリカバリ
ex) recover tablespace 表領域 delete archivelog
* delete archivelogを使用すると、バックアップよりリカバリされたアーカイブログをリカバリ後に自動的に削除してくれる。

e. 表領域のオンライン
ex) sql 'alter tablespace 表領域 online';

データファイルのリストアを元の場所に戻せない場合は、リストア直前、リカバリ直前に以下の処理が必要になる。* set newnameはrun{}ブロック内でのみ実行できる。
ex)
run {
set newname for datafile 元のデータファイルのファイル番号 to '新データファイル名'
restore ...
switch datafile 元のデータファイルのファイル番号 to datafilecopy '新データファイル名'
recover ...
}

Oracle データベースのリカバリ（１）

■ データベースのリカバリ（１）
以下の２つのリカバリがある。
「完全リカバリ」...最新のSCN（制御ファイルが認識している最新の状態）までリカバリを行う。
「不完全リカバリ」...最新の状態までリカバリするのではなく、ある時点までのリカバリを行う。

1. 完全リカバリ

1-1. RECOVERコマンド使用
SYSTEM表領域、アクティブなUNDO表領域は、マウントした状態でリカバリを行う必要がある。以下の手順で行う。
a. データベースを停止する。
ex) shutdown

b. データベースをマウントする。
ex) stratup mount

c. 損失したデータファイルをリストアする。（OSコマンド等により。）

d. 損失したデータファイルに対するリカバリを行う。
ex) RECOVER [AUTOMATIC] DATABASE;

e. データベースをオープンする。
ex) alter database open;

SYSTEM表領域、アクティブなUNDO表領域以外の表領域は、オープンした状態でリカバリが行える。以下の手順で行う。
a. 表領域またはデータファイルをオフラインにする。（障害が発生しているデータファイルに対して、不要なチェックポイントを避ける為に、immediate句を指定するほうが良い。）
ex) alter tablespace 表領域名 offline immediate;

b. 損失したデータファイルをリストアする。（OSコマンド等により。）

c. 損失したデータファイルに対するリカバリを行う。
ex) recover [automatic] tablespace 表領域名;

d. 表領域またはデータファイルをオンラインにする。
ex) alter tablespace 表領域名 online;

*1 recover automatic またはリカバリセッションで「AUTO」を入力すると、アーカイブREDOログが自動適用される。もし左記を行わないと、必要なアーカイブログが１つずつ表示され、ENTERキーで確認していく。
*2 制御ファイルが認識している場所にリストアできなかった場合は、リカバリの実行前にリネームを行う。
ex)
オープン時
alter tablespace 表領域名 rename datafile '元ファイル名' to '新ファイル名'

マウント時
alter database rename file '元ファイル名' to '新ファイル名'

Oracle アーカイブログモードの確認方法

SQL PLUSで、
ARCHIVE LOG LIST もしくは、SELECT LOG_MODE FROM V$DATABASEを実行することで可能。

Oracle クリティカルでない消失からのリカバリ

1. 多重化された一部の制御ファイルのリカバリ
多重化された制御ファイルの一部に障害があると、データベースのmountが行えない。
正常な制御ファイルをコピーすることで、回復可能。

2. 多重化された一部のREDOログメンバーのリカバリ
多重化された一部のREDOログメンバーに障害があっても、データベースのオープンも可能であるし、運用上の支障はない。
正常なREDOログメンバーのコピーもしくは、REDOログメンバーの削除、追加で回復可能。
以下のSQL文で、statusがINVALIDと表示されている場合、そのREDOログメンバーがアクセス不能になっている可能性がある。

SELECT group#, status, member FROM v$logfile
ORDER BY group#;

3. 一時表領域のリカバリ
データベースのオープンがおこなえる（アラートログに警告が記録される。）が、ディスクソートなど一時ファイルを使用する必要がある処理のときにエラーになる。
一時ファイルのみの削除、追加もしくは一時表領域の再作成により、回復可能。

4. 索引表領域のリカバリ
索引表領域に障害があってもデータベースは停止しない。
データベースの起動時にはオープンできない。
データファイルをオフラインにすることでオープンできる。（ただしNOARCHIVELOGモードでは削除前提のオフラインにする必要がある。）
索引表領域のリカバリはバックアップファイルからのリストアもしくは、索引表領域の再作成で行う。
NOARCHIVELOGモードでは再作成を行うべきであるが、ARCHIVELOGモードでは、リストアか再作成のどちらが良いか検討する必要がある。
再作成を行う場合は、Data Pumpにて索引定義を抽出するか、独自にSQLスクリプトを保存しておいてそれを利用する。再作成を高速化するのであれば、PARALLEL句もしくはNOLOGGING句を検討する。

5. 読み取り専用表領域のリカバリ
バックアップ時と状態が変更されていない場合は、バックアップファイルをリストアするだけである。
バックアップ時と状態が変更されている場合は、リストアとリカバリが必要。

データベースの診断ソース Oracle

BACKGROUND_DUMP_DEST初期化パラメータによって制御されるファイルは、
・アラートファイル
・バックグラウンドプロセスのトレースファイル

アラートログに格納される情報は、
・エラー関連情報
・管理操作（Oracleサーバの起動・停止、初期化パラメータの変更、Oracleデータベースの構造を変更するCREATE,ALTER,DROPコマンド等）
・デフォルト値以外の初期化パラメータ

SQLトレースを有効化／無効化する方法は、
・インスタンスレベルの設定は、SQL_TRACE初期化パラメータを設定（データベースの再起動が必要）
・セッションレベルの設定を行うには、現行セッションであれば、ALTER SESSIONコマンドで、SQL_TRACE初期化パラメータを設定
・リモートセッションの設定を行うのであれば、DBMS_MONITOR.SESSION_TRACE_{ENABLE | DISABLE}プロシージャを使用

データベースのバックアップ Oracle

1. RMAN
RMANのバックアップタイプには、バックアップセットとイメージコピーの２種類がある。
またバックアップセットでは圧縮を行うことも可能。
デフォルトのバックアップタイプは、CONFIGUREコマンドで設定する。

データベースがオープン中の場合は、RMANでは、
ARCHIVELOGモード時：表領域／データファイルがオンラインでもバックアップ可能。
NOARCHIVELOGモード時：表領域／データファイルがオフラインであれば可能。

増分バックアップも行える。増分バックアップとは、レベル0という元のバックアップに対する差分のみバックアップ（レベル1）を行うことで、バックアップの時間とデータサイズを少なくするものである。
差分増分バックアップ（前回の増分バックアップからの差分）と累積増分バックアップ（最後のレベル0バックアップからの差分）がある。
レベル0はイメージコピー、バックアップセットのいずれでも行えるが、レベル1はバックアップセットしか行えない。
・レベル0のバックアップ BACKUP INCREMENTAL LEVEL 0 DATABASE;
・レベル1のバックアップ BACKUP INCREMENTAL LEVEL 1 [CUMULATIVE] DATABASE;
*CUMULATIVE指定時は、累積増分バックアップを意味する。

ブロック変更追跡機能とは、CTWRバックグラウンドプロセスにより専用のブロック変更追跡ファイルにブロック変更（物理位置）を記録しておくことで、増分バックアップの高速化を図る機能である。有効化されていれば、RMANが自動的に使用する。
・ブロック変更追跡の有効化は以下のSQL文で行う。
ALTER DATABASE ENABLE BLOCK CHANGE TRAKING USING FILE ファイルパス;
・ブロック変更追跡の無効化は以下のSQL文で行う。
ALTER DATABASE DISABLE BLOCK CHANGE TRAKING;

Oracle推奨のバックアップは、最初のバックアップ時に全データベースのイメージコピーを作成し、日々のバックアップでは、以下のようなイメージになる。
RECOVER COPY OF DATABASE;（前日までの増分バックアップをイメージコピーに適用）
BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;（イメージコピーに対するレベル１の増分バックアップを適用）

REPORT OBSOLETE～：不要となったバックアップを表示
REPORT NEED BACKUP～：バックアップが必要なデータファイルを表示

CROSSCHECKコマンドにより、RMANリポジトリのバックアップ情報に対応したバックアップファイルが正しく存在しているかどうか（期限切れかどうか）を確認できる。

DELETEコマンドにより、不要なバックアップファイルや期限切れのバックアップファイを削除できる。

2. ユーザ管理のバックアップ
NOARCHIVELOGモード時：オープン時では行えない。ABORT以外のオプションでデータベースを停止し、OSコマンドで全てのデータベースファイルをバックアップする。
ARCHIVELOGモード時：オープン時でも行える。以下の手順で行う。
ALTER [DATABASE/ TABLESPACE 表領域名 BEGIN BACKUP;
OSコマンド等でバックアップ
ALTER [DATABASE/ TABLESPACE 表領域名 END BACKUP;