DBMotoのレプリケーション定義（どのテーブルからどのテーブルに、どのようにレプリケーションするか）の設定は、基本的に1テーブル1定義となります。つまりテーブルが1,000ある場合には、定義の数も1,000になります。1個ずつ設定していったら・・・時間かかって大変です。

そこでDBMotoには「Create Multiple Replications」というレプリケーション定義一括設定機能が用意されています。この機能を使用することで、同一スキーマ・同一ライブラリ内のテーブルに限り、一括で設定が可能です。

●Create Multiple Replicationsの利用手順

Create Multiple Replicationsを選択

レプリケーション名とレプリケーションモードを設定

ソース（ここではMySQL）のソース接続名とデータベースを選択

トランザクションログを取得＆インターバル値設定

ターゲット（ここではOracle）のターゲット接続名とスキーマを選択

レプリケーション対象のテーブルを選択

スケジュールとイニシャルリフレッシュ有無設定

最終確認

ターゲット（ここではOracle）にテーブルがない場合は作成してよいか聞かれる

レプリケーションの作成成功

以上で設定は完了です。

東日本大震災の影響もあり、最近は仮想環境やデータベースのBCP(business continuity plan : 事業継続計画)のニーズがより一層高まっています。

データベースのBCPについてはDBMotoの双方向レプリケーション環境を構築することで実現可能です。

●DBMotoの双方向レプリケーション（シンクロナイゼーションモード）

DBMotoのレプリケーションモードの1つ「シンクロナイゼーション」は双方向レプリケーションをサポートします。

【特徴】
・双方向の差分レプリケーション
・データベースのトランザクションログやトリガーログを参照したリアルタイムレプリケーション
・ソースとターゲットにリアルタイムな増分アップデートが必要なアプリケーションに最適
・コンフリクト回避オプション（ソースDBを優先・ターゲットDBを優先・TimeStampの速い方を優先・ユーザスクリプトによるカスタマイズ）

【対応データベース】
AS/400・Oracle・SQL Server・DB2 UDB・MySQLなど、メジャーデータベースを中心にサポートしております。

●双方向レプリケーションを使用したBCP

双方向レプリケーション環境を構築しておくことにより、一方のデータベースサーバに障害が発生しても、他方のDBが継続されていれば運用を維持可能、かつ復旧も容易に行えます。DBMotoはイントラネット環境だけでなく、インターネット環境による接続も可能なので、例えば東京と大阪などの別々のデータベースサーバで双方向レプリケーション環境を構築することも可能です。

リフレッシュレプリケーションの際に、DBMotoがcommitするタイミングは、リフレッシュのインサートモードによって変わります。

●バルクインサートモード

commitのタイミングはDBMotoの「Block Size」単位となります。この値はレプリケーションオプションで変更可能です。

■シングルインサートモード

1レコード1insertのSQLになるので、1レコード単位でcommitされます。

DBMotoのレプリケーションでレコードの前後に空白があり、この空白を除去（trim）した場合は、Expressionという機能で実現可能です。

レプリケーションオプションにて、「Mapping」ボタンを押下します。

対象のフィールドのマッピング矢印を右クリックし、「Map to Expression」を選択します。

・後方の空白だけを除去したい場合・・・rtrim[(フィールド名)]　と入力します。
・前方の空白だけを除去したい場合・・・ltrim[(フィールド名)]　と入力します。
・前方後方両方の空白を除去したい場合・・・trim[(フィールド名)]　と入力します。

AS/400でジュリアンデートを持つデータは、スクリプトを介してyyyy/MM/dd形式に変換してレプリケーションすることが可能です。

ソース：AS/400（SALDATEがジュリアンデートです）

ターゲット：Oracle（SALDATEがジュリアンデートから変換してyyyyMMdd形式にする予定のフィールドです）

●グローバルスクリプトに下記を記述します

Imports Microsoft.VisualBasic

Imports DBMotoPublic

Imports DBMotoScript

Imports DBRS.GlobalScript

Imports System.Data

Namespace DBRS

    Public Class GlobalScript : Inherits IGlobalScript

      Public Shared globalCounter As Integer

     ‘This function takes a numeric Julian date in the format YYYDDD where

     ‘YYY is the number of years since 1900 and DDD is the day of the year

     ‘and returns a VB.Net date value or Null if the original value was null

     ‘One adds this function to the global script and uses it in a mapping

     ‘expression.  Be sure to set the source column to Use Unmapped

       Public Shared Function JulianToDate(obj as Object) as Object

         ‘If the value is null return null

         If obj Is Nothing Then Return Nothing

         ‘If the value is non numeric return null

         If Not IsNumeric(obj) Then Return Nothing

         ‘Get the year value

         Dim intYears as Integer

         intYears = Int(obj/1000)

         ‘Get the day of the year and subtract 1 because we’ll be adding

         ‘this value to January 1

         Dim intDays as Integer

         intDays = (obj – intYears * 1000) – 1

         ‘Calculate the date

         Dim datDate as Date

         datDate = CDate(“1/1/” & Str(1900 + intYears)).AddDays(intDays)

         ‘Return the date

        Return datDate

      End Function

    End Class

    Public Class MappingRule : Inherits IMappingRule

    End Class

    Public Class GlobalEvents : Inherits IGlobalEvents

    End Class

End Namespace

マッピング画面にて、対象のフィールドでMap to Expressionを開きます。

User functionsから先ほど設定したスクリプトの関数を選択し、引数に対象フィールド名を設定します。

●リフレッシュ結果

●ミラーリング結果

正しく変換してレプリケーションできました。

DBMotoでAS/400からの差分レプリケーション（ミラーリング）を行う場合に、ジャーナルレシーバーを参照してトランザクションを確認します。
このため、予めAS/400側でジャーナルレシーバーを作成し、物理ファイルに対してジャーナルを起動する必要があります。

●ジャーナルレシーバーの作成

CRTJRNRCV　を実行します。

ジャーナル・レシーバー名とライブラリ名、ジャーナル・レシーバーの最大サイズを指定します。

●ジャーナルの作成

CRTJRN　を実行します。

ジャーナル名とライブラリ名、ジャーナル・レシーバー名とライブラリ名を指定します。
レシーバーの管理は「*SYSTEM」の場合はサイズ上限時に自動で切り離し、「*USER」の場合は自動で切り離しません。
レシーバーの削除はレシーバーの管理が「*SYSTEM」の場合に古いレシーバーを削除するかどうか指定します。

●ジャーナルの起動

STRJRNPF　を実行します。

ジャーナル処理する物理ファイル名とライブラリ名、ジャーナル名とライブラリ名を指定します。
レコード・イメージは原則として「*BOTH」を設定してください。
「*AFTER」にした場合は、DBMotoでレプリケーションする際に、AS400のROW IDとのマッピング設定が別途必要となります。

以上で作業は完了です。

DBMotoでOracleを利用したレプリケーションの際に、以下のエラーが発生することがあります。

ORA-12516: TNS: リスナーは、一致するプロトコル・スタックが使用可能なハンドラを検出できませんでした。

■原因

このエラーが発生する原因はいくつか考えられますが、その中の1つとして、DBMotoからOracleへの接続セッション数がOracle側の最大セッション数をオーバーしてしまう際にエラーが発生することがあります。

■対策

Oracle側のセッション数をオーバーしなければいいので、単純に回避方法は下記のどちらかです。

1. Oracle側の最大セッション数を大きくする
2. DBMotoからOracleへの接続セッション数を減らす

1については、Oracle のカーネルの見直しとマシンのメモリを考慮する必要がありますので簡単にはいかない可能性があります。
2については、レプリケーションをまとめて「グループ化」することで効率よくセッション数を減らすことが可能です。

ここでは2の「グループ化」についてご説明します。

■DBMotoのグループ化

DBMotoは、1レプリケーション＝1セッションとなります。
レプリケーション対象テーブルが100あれば、100個のレプリケーションを作成することになります。
同時に100個のレプリケーションを動かした場合、最大で100セッションとなる可能性があります。
これだとOracleに高い負荷をかけてしまうことになりかねません。

そこで「グループ化」です。グループ化とは、複数のレプリケーションを1つにまとめることです。
レプリケーションをまとめれば、その分セッション数を減らすことが可能となります。

例えば、100個あるレプリケーションを10レプリケーション×10グループにすることで、
セッション数は最大10まで減らすことが可能となります。

以下の図をご覧ください。これはレプリケーション設定が3つの例です。
この場合はOracleに対して最大3セッションの接続が発生する可能性があります。

次に以下の図をご覧ください。これもレプリケーションが3つの例ですが、
3つのレプリケーションを1グループにまとめてあるので、セッション数は1つとなります。

このように、テーブル数（レプリケーション数）が多い場合には、グループ化を利用してセッション数を減らす運用が一般的です。

※参考：Oracleの最大セッション数を調べるSQL
select name, type, value
from V$SYSTEM_PARAMETER
where name = ‘processes’ or name = ‘sessions’

●参考記事：DBMotoが使うスレッド数の算出方法
http://blog.goo.ne.jp/hitsw/e/fbf02883f9704197af18ac49bf195867

弊社取り扱い製品の異種データベース間リアルタイムレプリケーションツール「DBMoto」は、
Windowsマシン上にインストールしますが、
これは物理マシンはもちろんのこと、ESX(i)上のVM（仮想マシン）でももちろんOKです。

P2V化（Physical to Virtual、物理環境から仮想環境への移行）が急速に進んでおり、
仮想環境のニーズが非常に高まっています。

しかし、仮想環境はコスト削減等のメリットがある反面、運用コストが増大するというデメリットがあります。
このデメリットを解消するために、仮想マシンのバックアップを考慮する必要があります。

そこで、弊社取り扱い製品「Veeam Backip & Replication」の登場です。
Veeam Backup & Replicationは、ESX(i)に特化した仮想マシンのバックアップとレプリケーション機能を統合したツールです。

今回はDBMoto+Veeamの検証として、仮想マシン上にDBMotoをインストールし、
データベースのレプリケーションの真っ最中にVeeam Backup & Replicationでバックアップを取得し、
正しくリストアできているかどうかを確認しました。

■検証手順

1. Windows仮想マシン上でDBMotoのサービス起動
2. 複製元データベースに対して断続的にトランザクションを発生させる
3. トランザクションを発生させている最中にVeeamでバックアップを実行
（あらかじめフルバックアップ済みだったので、ここでは差分バックアップを実施）
4. Veeamでのバックアップが完了後、データーベースに対するトランザクション発生処理を停止
5. ここでDBMotoのトランザクションIDとタイムスタンプを確認
※タイムスタンプがトランザクション発生処理を停止した日時であることを確認

6. Veeamでバックアップしたところまでリストア
7. ここでDBMotoのトランザクションIDとタイムスタンプを確認
※タイムスタンプがバックアップを取得した日時であることを確認

結果、正しくリストアされていることを確認できました。
実際の運用時には、別途データベースのトランザクションを考慮する必要はあります。

Oracle データベースからミラーリングまたはシンクロナイゼーション中にDBMoto は
Oracle Redo ログで記録されたソースデータベースでの変更を識別するためにOracle
LogMiner 経由でOracle トランザクションをリードします。すべてのアクティブなredo
ログはレプリケーションするためのトランザクションを読み出すためにそれぞれのミラーリ
ング・セッションでオープンになっています。さらにDBMoto はアーカイブ・ログをロー
ドするための設定を提供します。

Oracle が巡回方式でトランザクションをログし、それは順番にredo ログ・ファイルに使
用されます。現状のファイルが最大値に届いた時、Oracle はステータスをインアクティブ
に設定し、次のファイルへ書き込みを続けます。もし次のファイルがデータを含んでいる時
は、上書きされます。もしすべてのオンライン・ログ・ファイルが１DBMoto リードと次
リード（DBMoto で設定したリード間隔）間でシーケンス番号（例：それぞれで指定した
ログ・ファイルの書き込み順序）を変更された時、ログ・ファイルは容量不足か、ログする
トランザクションの量を再考するか、ログ・ファイルが少なすぎるかです。

通常のガイドラインとしてログのサイズはデータベースで生成されるトランザクション数と
リテンション時間をベースに計算します。例えば72 時間のリカバリーを確実にしたい時、
3 日間に生成されるすべてのトランザクションを含むログ数を定義する必要があります。
Oracle のログ・ファイルはログ・ファイルサイズを増やすか、新たにログ・ファイルを追
加するかのどちらかでサイズ変更が可能です。ログ・ファイルサイズを対応が難しい量
（例：100MB 以上）に増加させるより中規模なログ・ファイルを作成することを考えてく
ださい。もしこの方法でログ・ファイルを編成し、DBMoto を絶えず稼動させて、レプリ
ケーションと連携させることで、アーカイブ・ログのオープンを回避できます。詳しいこと
はOracle のDBA と相談してください。

もし、ログ・ファイルが一杯になるか、上書きを始めることを許している場合にDBMoto
はプロセスする次のトランザクションを見つけことはできません。これが発生した時は、
ミラーリングを再度始める前にフル・リフレッシュ・レプリケーションを実行する必要があります。

DBMoto がアクティブなredo ログをリードした時、LogMiner はログをオープンした時に
ビュー（view）を生成します。（それはフィジカルなテーブルや実際のログはオープンし
ません。）これはOracle のオペレーションには影響を与えませんが、サーバに対して要求
を起すため、Oracle のパフォーマンスに影響を与えます。（特にLogMiner がオープンの
ためにビューを準備した時に、ミラーリング・セッションの最初のフェーズにおいて）

DBMoto でOralce データベース用のソース接続を設定した時に、Oracle サーバには何も
インストールされません。しかしDBMoto は認証キー・ロギング用のSUPPLEMENTAL
LOGS が可能なことを要求し、それはDBMoto 接続ダイアログからインストール・オペレ
ーション中に自動で実行されます。SUPPLEMENTAL LOGS はOracle ログに対してさらに
詳細なログ情報を追加しますが、同時にそれぞれのDML コマンドで、redo ログに書き込
む追加のデータを要求するためサーバのパフォーマンスを低下させます。

OracleDBA が行うログのクリーンアップはレプリケーションがアイドル時のスケジュール
で実行が必要です。しかし、もしログ・ファイルがレプリケーションのプロセス中に削除さ
れた時、DBMoto はエラーからのリカバリーが可能で、次のミラーリング・セッションに
おいて、データを失うことなくレプリケーションを獲得できます。
新たなトランザクションを特定するためにログをアクセスした時、アーカイブredo ログ
に含んでいます。

ソース接続の「Connection Properties」ダイアログから利用可能な「the Setup Info」
ダイアログの「Read Archived Logs」オプションをクリックします。もしOracle データ
ベースがARCHIVELOG モードを使用している場合のみ、この手法は有効です。もし、ト
ランザクションがオンラインredo ログで見つけられない時は、DBMoto はアーカイブ
redo ログを検索することが出来ます。

１． Enterprise Manager ツリーからそれを選択してレプリケーションをディセイブル
（無効）にして、チェックマークを外すようにEnable Replication メニュー・アイテムをクリックします。
２． Enterprise Manager ツリーのソース接続を選択します。
３． マウスの右ボタンメニューから「Connection Properties」を選択します。
４． Connection Properties ダイアログからTransactional Support セクションにスク
ロールします。
５． Transaction Log Type フィールド用の値をクリックします。
６． ボタンをクリックします。
７． Setup Info ダイアログで、Read Archived Logs オプションをクリックします。
８． Setup Info ダイアログを選択し、ok をクリックします。
９． Connection Properties ダイアログを選択し、ok をクリックします。
１０． Enterprise Manager ツリーでそれを選択してレプリケーションを可能にして、
チェックマークが表示できるようにEnable Replication メニュー・アイテムをクリックします。

【原文】
During mirroring or synchronization from an Oracle database, DBMoto reads
Oracle transactions through the Oracle LogMiner to identify changes in the
source database recorded in Oracle redo logs. All active redo logs are opened at
each mirroring session to retrieve transactions to replicate. Additionally, DBMoto
provides a setting to load archived logs.
Oracle logs its transactions in circular fashion, that is, it uses the redo log files in
sequence. When the current file reaches its maximum size, Oracle will set its
status to inactive and will keep writing to the next file. If the next file already
contains data, it could be overwritten. If all online log files have changed
sequence number (i.e. the writing sequence of each specific log file) in the period
between one DBMoto read and the next (Read Interval setting in DBMoto), the
log files may be underdimensioned, considering the amount of transactions to
log, or there may be too few log files.
As a general guideline, the size of the log should be based on the number of
transactions generated in the database and based on the retention time. For
example, if you want to be sure you can recover for 72 hours, you should define
your logs to contain all the transactions that can be generated in 3 days. Oracle
log files can be re-dimensioned by either increasing the log file size or by adding
new log files. You may want to consider creating more medium-size log files
rather than increasi
ng log file size to a value that could make it difficult to handle
(i.e. not greater than 100MB.) If you organize your log files in this way, and if
you keep DBMoto constantly running and aligned with the replications you may
be able to avoid opening the archived logs. Contact your Oracle database
administrator for more information. Your DBA has the best understanding of your
Oracle environment.
If you allow the log files to fill up and begin overwriting, DBMoto may not be able
to locate the next transaction to process. If this occurs, you need to perform a
full refresh replication before resuming the mirroring.
When DBMoto reads the active redo logs, the LogMiner actually generates a view
when it opens the log (it does not open a physical table nor the log itself.) This
does not affect Oracle operations, but it can affect Oracle performance in general,
because it is making a demand on the server (especially in the initial phase of
the mirroring sessions, when the log miner prepares the view to open).
When creating a source connection for an Oracle database in DBMoto, nothing is
installed on the Oracle server. However, DBMoto requires that SUPPLEMENTAL
LOGS for identification key logging are enabled and this is performed
automatically during the Install operation from the DBMoto connection dialog.
Supplemental logs add more detailed logging information to the Oracle logs but
at the same time can degrade the server performance by requiring additional
data to be written into the redo logs for each DML command.
Log cleanup operations by your Oracle DBA should be performed at scheduled
times when replications are idle. If, however, a log file is removed while a
replication is in progress, DBMoto should be able to recover from the error and
pick up replication during the next mirroring session with no data loss.
Including Archived Redo Logs when Accessing Logs to Identify New
Transactions
Check the Read Archived Logs option in the Setup Info dialog available from the
Connection Properties dialog of the source connection. This approach is useful
only if your Oracle database uses ARCHIVELOG mode. It enables DBMoto to
search archived redo logs if transactions cannot be found in the online redo logs.
1. Disable the replication by selecting it in the Enterprise Manager tree, and
clicking the Enable Replication menu item to remove the checkmark.
2. Select the source connection in the Enterprise Manager tree.
3. From the right mouse button menu, choose Connection Properties.
4. In the Connection Properties dialog, scroll to the Transactional Support
section.
5. Click on the value for the Transaction Log Type field.
6. Click the ellipsis button.
7. In the Setup Info dialog, check the option Read Archived Logs.
8. Click OK to close the Setup Info dialog.
9. Click OK to close the Connection Properties dialog.
10.Enable the replication by selecting it in the Enterprise Manager tree, and

clicking the Enable Replication menu item so that it displays a checkmark.
See Also
KB Article 1572 Errors in creating dictionary file in Oracle 8.1.7
KB Article 1584 >Handling a Missing Transaction ID in the Oracle Redo Log

http://www.hitsw.com/support/kbase/DBMoto/DBMoto_1641_OracleRedoLogExpl.htm

DBMotoでは複雑なレプリケーションを実現するためにVBスクリプトを使用することが出来ますが、
他にもユーザ様が作成した外部DLLを使用することも可能です。

これを使用することで、レプリケーション時にレコードを変換することが可能となります。

●外部DLLの準備

Visual Studio等で下記のようなDLLを準備します。

※サンプル1（小文字を大文字にする関数、DBMoto⇒DBMOTOなど）

※サンプル2（大文字を小文字にする関数、DBMoto⇒dbmotoなど）

準備したDLLはDBMotoインストールディレクトリに格納します。
※DBMotoインストールディレクトリ以外では動作しませんのでご注意ください。

●DBMoto側の準備

予めソース、ターゲット、レプリケーションの設定は済ませておきます。

レプリケーション名を右クリックし、Replication Propertiesを押下します。

Use Scriptにチェックを入れ、Scriptボタンを押下します。

スクリプト画面が開きますので、下記赤枠のボタンを押下します。

References画面が開きますので、配置したDLLのパスを入力し、Addを押下します。

今回は準備した2つのDLLを追加しました。

スクリプト画面にて、下記のスクリプトを使用します。

Imports System
Imports System.Data
Imports Microsoft.VisualBasic
Imports DBMotoPublic
Imports DBMotoScript
Imports DBRS.GlobalScript

Namespace DBRS
    Public Class ReplicationScript : Inherits IReplicationScript
        Public Overrides Sub Record_onAfterMapping(recSource As IRecord, recTarget As IRecord, ByRef AbortRecord As Boolean)
       If recSource.OperationType = enmOperationType.Insert Then
       if Not recTarget.GetValueAfter(2) Is Nothing Then
        recTarget.SetValueAfter(2, ClimbDBMoto.Class1.getUpperCase(recTarget.GetValueAfter(2).ToString))
       End if
        if Not recTarget.GetValueAfter(1) Is Nothing Then
        recTarget.SetValueAfter(1, ClassLibrary1.Class1.getLowerCase(recTarget.GetValueAfter(1).ToString))
       End if
       End If
        End Sub
    End Class
End Namespace

スクリプト画面にて、下記赤枠のボタンを押下し、コンパイルチェックします。

●レプリケーション実行

実際にレプリケーション（リフレッシュ）を実行し、DLLの関数が使用されているか確認します。

※ソース側は下記のテーブルです。

※レプリケーション（リフレッシュ）実行後

赤枠のレコードは、大文字が全て小文字に、青枠のレコードは小文字が全て大文字になっていますので、
正しくDLLを使用していることが確認できました。

このようによく使用する関数をDLLにしておくことで、DBMotoから簡単にスクリプトを記述するだけで
複雑なレプリケーションが実現可能となります。

今回は単純に大文字や小文字にするシンプルな関数を使用しましたが、
他にもいろいろなことができ、その可能性は無限大です。