昨日、弊社テスト環境で発生したOracle DBのアーカイブログ関連のエラー対処法を投稿いたしましたが、
その後、今度は別の内容のエラーが出力され停止しました。その際の対処法について書き記します。

以下の文が出力されたエラー内容です。

このエラー内容が意味するところは、アーカイブログ出力先として指定されているフラッシュリカバリ領域の容量がいっぱいになっており、新たなアーカイブログが書き込めないというものです。

対処法としては、基本的には、フラッシュリカバリ領域の容量を増やすか不要なアーカイブログファイルを削除するということになりますが、今回調べたところ、「空きを確保するためにアーカイブログをエクスプローラー上で手動ですでに削除してある」とのことでした。

そこでOracle DBの仕様を確認したところ、「アーカイブログの削除にはOracle DBのコマンドを使わなければならず、エクスプローラー上でアーカイブログを削除しても、Oracle DBはそれを認識しない（＝領域を開放しない）」という仕様でした。
そのため、あいているはずのスペースが開放されず、結果としていっぱいになってしまった、ということになります。

このような場合、削除されたアーカイブREDOログファイルがすでに存在しないことをOracle DBに認識させる必要があります。
以下がそのコマンドです。
＝＝＝＝＝＝＝＝＝＝＝＝＝
ステップ１：Windowsのコマンドプロンプト（cmd.exe）を開きます。
ステップ２：「RMAN TARGET /」と入力します。
（場合によっては「RMAN TARGET system/password」と打たなければならないかもしれません）
リカバリマネージャに接続します。IDのsystemとパスワードのpasswordの部分は設定に応じて適宜変更してください。
ステップ３：「CROSSCHECK ARCHIVELOG ALL;」と入力します
Oracleがアーカイブファイルの存在を確認しにいきます。
コマンドライン上に進行状況が記録され、すでに存在しないファイルに関してはその旨が表示されます。
ステップ４：「DELETE EXPIRED ARCHIVELOG ALL;」と入力します
Oracleはすでに存在しないアーカイブファイルの情報を削除します。
ステップ５：これで領域が開放されます。これにて作業は完了です。

＝＝＝＝＝＝＝＝＝＝＝＝＝
Oracle DBから行うアーカイブログファイルの削除手順は以下のとおりです。
ステップ１：Windowsのコマンドプロンプト（cmd.exe）を開きます。
ステップ２：「RMAN TARGET /」と入力します。
ステップ３：「DELETE ARCHIVELOG ALL COMPLETED BEFORE ‘sysdate-7’;」と入力します。
BEFORE句は条件式です。上記の例は直近１週間分を残しそれ以前のアーカイブログは削除するというコマンドです。
条件に合わないアーカイブログの削除が実行されます。
ステップ４：「LIST ARCHIVELOG ALL;」と入力します。
条件に沿ったアーカイブログが残っているかを確かめます。

DBMotoで差分レプリケーション（ミラーリング）を行う場合には、
原則複製先のターゲットDB側にPKが必要です。

参考：差分レプリケーションに必要なDBの主キーとDBMotoの仮想PK
//www.climb.co.jp/blog_dbmoto/archives/1114

もしDBにもPKがなく、DBMotoの仮想PKとするための一意の（値が重複しないユニークな）フィールド（またはフィールドの組み合わせ）が存在しない場合でも、差分レプリケーションを行うことが可能な方法があります。

方法は複製元のソースDB側のレコードIDを使用します。
例えば、Oracleの場合はROWIDに該当します。

ただし、この方法をとる場合には、ターゲット側DBに対して、ソースのROWIDとマッピングを行う専用のフィールドを新たに用意する必要があります。

以下設定手順です。

ソーステーブルは下記の3フィールドです。
PKの指定はありません。

一方ターゲットテーブルはソーステーブルの3フィールドに加え、ソーステーブルのレコードIDとマッピングするためのフィールドSP_IDを用意します。
このフィールドはDBのPK又はDBMotoの仮想PKの指定が必要です。

レプリケーション定義作成時のマッピング画面ではデフォルトで下記のように表示されています。
これはソースとターゲットで共通のフィールドのみマッピングされている状態です。

ソースのレコードIDとマッピングするターゲットのフィールドSP_IDを右クリックし、「関数へのマッピング」を選択します。

関数プログラムの画面で入力欄に[!RecordID]と入力します。または、左下ペインから値⇒Log Fieldを選択し、右下ペインから !RecordID をダブルクリックすることで上の入力欄に反映されます。

マッピング画面で下記のように表示されていれば問題ありません。

この状態でレプリケーションを開始しますが、ソースのレコードIDをターゲットのフィールドSP_IDへ反映させるために、初期リフレッシュから実行します。
初期リフレッシュ完了後は下記のように表示されています。

ソース

ターゲット

ソース側に1レコードを追加してみました。正常にミラーリングされていることが確認できます。

ソース

ターゲット

DBMotoでの設定情報はメタデータの形式で、デフォルトではDBMotoインストールマシンにSQL Server CE形式（.sdf）で保存されます。
※DBMotoマシン以外の別マシンのDBに保存することも可能です。

※通常の構成例

このメタデータは冗長化の構成を取ることが可能で、メインのメタデータから最大2つのバックアップメタデータを取ることが可能です。
すなわちメインのメタデータを含めると、最大3つのメタデータを冗長化することが可能となります。

※メタデータを冗長化した構成例。
この場合メインのメタデータをDBMotoマシンに、バックアップ用のメタデータをターゲットDBと、さらに別マシンのDBに保存している。

メインのメタデータの内容が変更されると、同時にバックアップ用のメタデータにもリアルタイムで反映されます。
万が一のDBMotoマシンの予期せぬ障害（災害等）対策に便利な機能です。

設定はメタデータのプロパティから行えます。
1つ目のバックアップは「プライマリバックアップ」、2つ目のバックアップは「セカンダリバックアップ」の項目で設定します。
「バックアップの有効」をTrueにすることでバックアップが有効になります。

DBMotoはデフォルトでは管理ツールであるManagement Centerのすべての機能を使用可能です。
しかし、DBMotoでユーザ権限を設定することで各ユーザに対して認証を要し、必要な権限のみを付与することも可能です。

ユーザ権限は「DBMoto認証」と「Windows認証」の2種類から選択可能です。
DBMoto認証の場合には、DBMoto専用のユーザ認証を使用し、Windows認証の場合には、Windowsログインユーザの認証機能を使用します。

権限も下記のようにきめ細かに設定が可能です。

・全機能を使用可能なユーザ
・設定情報は作成できないが運用監視のみ行えるユーザ
・ライセンス管理やユーザ管理のみ行えるユーザ　等

権限設定後は、DBMoto Management Center起動時に下記のようにログイン画面が表示されます。

DBMotoインストール直後、metadataを開く際にマシン環境によっては下記エラーが表示されて開くことができない場合があります。

An error was generated while creating database

●原因

下記の条件をすべて満たす際に発生します。
・DBMoto 64bit版がインストールされている
・SQL Server Compact Edition 32bit版がインストールされている。

DBMotoはデフォルトでmetadataの保存をSQL Server Compact Edition形式で行います。
DBMotoが64bitマシンの場合、metadata保存用のSQL Server Compact Editionも64bit版を使用します。

その際、マシンに32bit版のSQL Server Compact Editionがインストールされていると32bit版のSQL Server Compact Editionを参照しようとして本エラーが発生します。

●対処法

下記のどちらかの対応をお願いいたします。
・SQL Server Compact Edition 32bit版をアンインストールする　又は
・SQL Server Compact Edition 64bit版を新規インストールする
⇒http://www.microsoft.com/ja-jp/download/details.aspx?id=17876

Oracleからの差分レプリケーション（ミラーリング）の際に、下記のエラーが発生した場合の原因と対処法です。

●エラー内容：
ORA-01291: ログ・ファイルがありません

●原因：
DBMotoが保持している（最後にレプリケーションした）Redo IDがOracleへ接続参照時に既になくなっている場合に本エラーが発生します。

DBMotoが保持しているRedo IDはDBMotoのレプリケーションプロパティから確認できます。下記画面例では73348299となります。

次にOracleサイドでのRedo IDを確認します。
クエリselect * from v$logにて確認可能です。

上記例のケースでは、SEQUENCE#が693がRedoの一番古いグループです。
このレコードのFIRST_CHANGE#を確認するとIDが75885340となっており、これがその時点での一番古いIDとなります。

DBMoto側でのIDが73348299、Oracleの一番古いIDが75885340ということで、このケースでエラーとなります。

●対処法：

まず既になくなってしまったIDの範囲のレプリケーションを行うことはできませんので、レプリケーションデータを復旧するにはイニシャルリフレッシュを実行する必要があります。

次に、このエラーを発生させないようにするには、DBMotoからOracleへ参照するIDが確実に残っている必要がありますので、下記対応を検討する必要があります。
・Redoログサイズやグループ数を増やして余裕を持たせる
・アーカイブログ運用にする（DBMotoはアーカイブログの参照も可能）

なお、Oracle側にIDが残っているにも関わらず本エラーが発生してしまう場合にはお問い合わせください。

DBMotoの差分レプリケーション（ミラーリング）は、ソースDBのトランザクションログをデフォルトで1分間隔で参照し、更新対象があればターゲットDBへ反映する手法を取っています。

DBMotoは常に下記の流れで最新のトランザクションIDを保持しているため、データの整合性をとったレプリケーションが可能となります。

・ソースDBのトランザクションを参照
↓
・更新対象があればターゲットDBへ反映
↓
・DBMoto内でトランザクションIDを最新にする
↓
（以下繰り返し）

※この流れは、言い換えるとターゲットDBへ反映しなければDBMotoのトランザクションIDを更新しないことになります。
つまり、万が一ネットワーク障害等で一時的にDBMotoからDBにアクセスできない状態になった場合でもDBMoto内部のトランザクションIDは保持され続けますので、障害復旧後から正常通りレプリケーションが再開され、データの不整合は発生しません。

DBMoto内で保持されている現在のトランザクションIDはレプリケーションプロパティから確認することができます。

また、諸事情によりトランザクションIDを任意の位置に戻したり、特定の日時の位置に戻してレプリケーションをやり直すことも可能です。