DBMotoレプリケーションに必要なOracleユーザ権限

DBMotoで使用するOracleユーザに必要な権限は下記の通りです。
ユーザ名を「dbmoto」とした場合の例となります。
2017/06/29 一部修正しました

●ミラーリング複製元ソース用

// ユーザ作成
>create user dbmoto identified by dbmoto;

// DB接続オープン
>grant create session to dbmoto;

// 参照権限
>grant select any table to dbmoto;

// サプリメンタルロギング設定
>grant alter database to dbmoto;
>grant select on sys.v_$database to dbmoto;

※AWS のRDSでは上記alter databaseの権限を付与できません。
代わりにPL/SQLの下記コマンドをSQL PLUS等で実行します。
exec rdsadmin.rdsadmin_util.alter_supplemental_logging(‘ADD’,’PRIMARY KEY’);
exec rdsadmin.rdsadmin_util.alter_supplemental_logging(‘ADD’,’UNIQUE’);
参考URL:http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.html#Appendix.Oracle.CommonDBATasks.AddingSupplementalLogging

// 最小レベルのサプリメンタルロギングの設定ではさらに下記が必要
※通常はデータベースレベルを推奨しておりますのでその際は下記の設定は不要です。
>grant alter any table to dbmoto;
>grant select on sys.dba_log_groups to dbmoto;
>grant select on sys.dba_log_group_columns to dbmoto;

// Redoログ参照
>grant execute on sys.dbms_logmnr to dbmoto;
>grant select on sys.v_$parameter to dbmoto;
>grant select on sys.v_$log to dbmoto;
>grant select on sys.v_$logfile to dbmoto;
>grant select on sys.V_$logmnr_contents to dbmoto;
>grant select on sys.V_$thread to dbmoto;
>grant select on sys.V_$archive_dest to dbmoto;

// Oracle 10g ・11gR2のみ必要
>grant select any transaction to dbmoto;

// Oracle 12c以降に必要
>grant LOGMINING to dbmoto;

// アーカイブログを参照する場合のみ必要
>grant select on sys.v_$archived_log to dbmoto;

// シンクロナイゼーション使用時
>grant select on sys.aud$ to dbmoto;

●ミラーリング複製先ターゲット用

// ユーザ作成
>create user dbmoto identified by dbmoto;

// DB接続オープン
>grant create session to dbmoto;

// 参照・編集権限
>grant select any table to dbmoto;
>grant insert any table to dbmoto;
>grant update any table to dbmoto;
>grant delete any table to dbmoto;

// TRUNCATE権限
>grant drop any table to dbmoto;

// ターゲットテーブル作成ウィザード使用時のみ必要
>grant create any table to dbmoto;
>grant create any index to dbmoto;

タグ: ,

Amazon Web Service(EC2/RDS)へオンプレミス(自社)データべースをリアルタイムにレプリケーション[DBMoto]

【2015/2/13記事改訂】

DBMotoではAmazon Wev Service(以下AWS)へのレプリケーションも可能です。AWSの中では仮想マシン管理のAmazon EC2とDB管理のAmazon RDSの両方に対応しています。

●Amazon EC2

Amazon EC2は仮想マシンでの管理となるため、VM上にデータベースをインストールすることで、DBMotoがサポートするすべてのDBにてレプリケーション可能です。
対応データベース一覧はこちら

●Amazon RDS

Amazon RDSで使用できるデータベースは下記の3つです。DBMotoはいずれもサポートしております。
・Oracle
・MySQL
・Microsoft SQL Server

DBMotoを利用することでDB2/AS400などの自社データベースからもこの3種類のAmazon RDSデータベースへ災害目的・移行目的・AWSサービスへのデータ連携目的でレプリケーションすることが可能です。

以下がAmazon RDSデータベースを接続先とした場合にどのレプリケーションで利用できるかを示す表です。

レプリケーション種類 Oracle MySQL MS SQL Server
リフレッシュ
(ソース、ターゲット)
ミラーリング
(ソース)

トリガー使用

トリガー使用
ミラーリング
(ターゲット)
シンクロナイゼーション
トリガー使用

トリガー使用

片方向のミラーリング(ソース)や双方向シンクロナイゼーションではトランザクションログを参照する必要があり、通常はOracle RedoログやMS SQL Serverのディストリビュータを利用してレプリケーションを行っています。

Amazon RDS for OracleではALTER TABLEコマンドが実行できないため、DBMoto画面からサプリメンタルロギングが設定できません。
代わりに、PL/SQLコマンドが用意されていますので、そちらを手動で実行していただければ設定可能です。詳しくは下記弊社ブログ記事をご覧ください。
DBMotoレプリケーションに必要なOracleユーザ権限

しかし、Amazon RDS for MS SQL ServerおよびMySQLでは、使用できる権限が足りないためこの機能が使用できません。そのため、ミラーリング(ソース)やシンクロナイゼーションを行うためには、DBMotoが独自に作成するテーブル、トリガーを利用したログを使用します。

※Amazon EC2に関しては権限の制約がないため、DBMotoがサポートするすべてのDB・レプリケーションモードが使用可能です。

MySQLの場合を例にレプリケーションを作成してみます。

まず、DBMotoからAmazon RDSへ接続できるようDB Security GroupでIPアドレスを許可します。

次に、接続で必要なEnd Pointの情報を確認します。

DBMotoにMySQLを接続先として登録します。データソースには先ほどのEnd Pointの情報を入力します。

この接続を使用して正常にレプリケーションが行えていることがわかります。

タグ: , , , , ,

Amazon Redshiftに対してOracle、AS/400、SQL Server、MySQLなどからデータをリアルタイムにレプリケーション[DBMoto]

Amazon Web Service(AWS)の RedshiftはPostgreSQLベースのデータウェアハウスであり、最低料金は 2 TB データウェアハウスの XL ノード 1 つで 1 時間あたり US$0.85という低価格です。DBMotoでは、PostgreSQLをターゲット(レプリケーション先)としてサポートしており、このRedshiftに対してリアルタイムに各DBのデータをロード(レプリケーション)することができます。これにより既存環境を並列して使用した状態でRedshiftに移行することも可能です。
図 システムCのみ先行してRedshiftに移行し、他のデータはDBMotoを使用してロード

実際にDBMotoのターゲットDBとして指定する方法ですが、まずAWSのコンソールのRedshiftのConfigurationタブからエンドポイント等の情報を取得します。

また、このときにDBMotoサーバがRedshiftへアクセスできるようにするため、Security GroupのCIDR/IP等も設定しておきます。

取得した情報をDBMotoのターゲット接続に設定します。接続設定は基本的にPostgreSQLの場合と同様です。
DBMotoからPostgreSQLへ接続するには・・・Npgsqlと外部接続の設定

※2014/12/22追記
現在のNpgsql最新版2.3にはRedshiftに接続ができない不具合がございます。
バージョン2.0.14.3のNpgsqlをダウンロードし、そちらをご利用いただきますよう、お願いいたします。

https://github.com/npgsql/npgsql/releases/tag/v2.0.14.3

ターゲットの接続ウィザードでServerにエンドポイント名、User、Password、Databaseにデータベース名を入力します。このときPostgreのポート番号はデフォルトで5432ですが、Redshiftのデフォルトは5439であるため、Portの項目も変更する必要があります。

これで登録は完了です。ターゲットDBとして各種DBからデータをレプリケーションできます。

タグ: , , ,

DBMotoのレプリケーション結果比較確認機能で整合性チェック&データ修復

【2014/1/19記事改訂】

DBMotoで正しくレプリケーションが行われているかどうか。
DBMotoの比較確認機能で視覚的に確認することが可能です。

※バージョン8では結果に万が一差異があった際にその場で修復することも可能となりました。

レプリケーション名右クリック⇒「レプリケーション結果を確認する」を選択します。

左上の雷マーク「検証を実行」をクリックすることで、複製元ソースと複製先ターゲットのテーブル比較検証が行われ、その結果が表示されます。
下の図の例では、下記のようになっています。
水色・・・ソースにのみ存在するレコード
黄色・・・ターゲットにのみ存在するレコード
赤色・・・ソースとターゲットで差異のあるレコード

オプション設定では下記のような設定が可能です。
・WHERE句やORDER BY句の条件指定
・BLOB/CLOBやTIMESTAMP型のフィールドをスキップ(DBごとに異なるため)
・最大表示行数(既定は1万レコードのみDBMotoに表示しその単位で切り替えが可能。比較自体は全件に対して行われる)

「データの照合」ボタンでソースのテーブルデータを正としてターゲットに対して修復を行うことが可能です。

データ照合後、再度「検証を実行」した結果です。結果に何も表示されていないため、差異がない(整合性がとれた)ことになります。

コメントする -->

レプリケーション時には双方のDBのデータタイプ文字サイズに注意

日本語文字を扱う文字列型データタイプで、複製先ターゲットのテーブル文字コードがUTF-8の場合には注意が必要です。

例えば下記の例で考えてみます。

・複製元ソース:AS/400
フィールド:VARCHAR(10)
文字コード:EBCDIC

・複製先ターゲット:DB2 UDB(Windows/Linux/AIX)
フィールド:VARCHAR(10)
文字コード:UTF-8
※DB2バージョン9.5以降はOSに関係なく既定の文字コードが「UTF-8」に変更されました。

次に実際のデータでバイト数を考えてみます。

・データが「1234567890」の場合
AS/400・・・各文字1バイトなので10バイトです。
DB2 UDB・・・各文字1バイトなので10バイトです。
⇒VARCHAR(10)の範囲内なので問題なしですね。

・データが「あああaa」の場合
AS/400・・・日本語は2バイトなので合計8バイトです。かつAS/400の場合は日本語文字列の前後にはシフトイン(1バイト)、シフトアウト(1バイト)が挿入されるため、合計10バイトです。
DB2 UDB・・・日本語はUTF-8なので3バイトとなり、日本語のみで9バイト+アルファベット2文字で11バイトです。
⇒VARCHAR(10)の範囲に入りません。つまりDBMotoでレプリケーションしても桁あふれエラーとなります。

このため、ターゲットDBのテーブルがUTF-8で日本語を扱うCHARやVARCHAR系のデータイプのサイズには注意する必要があります。単純計算で、ソースDBのサイズの1.5倍を確保しておけば安全です。

コメントする -->

DBMotoからPostgreSQLへ接続するには・・・Npgsqlと外部接続の設定

DBMotoからレプリケーション対象としてPostgreSQLを使用する場合の接続設定:

(1) 接続ドライバのダウンロード

下記よりダウンロード可能です。

・DBMoto8.5、9.0の場合
Npgsql – .Net Data Provider for Postgresql
https://github.com/npgsql/npgsql/releases/tag/v2.2.7

・DBMoto 9.5以上の場合
.NET Framework 4.5.1以上、Npgsql 3.2.7をご利用ください。
https://github.com/npgsql/npgsql/releases/tag/v3.2.7

※Npgsql 4.x以降を使用する場合は、接続設定の拡張プロパティに下記内容を追記する必要があります。
Persist Security info= TRUE

(2) DBMotoマシンからPostgreSQLへの接続を許可する

PostgreSQLは既定ではローカル接続のみで、外部からの接続は許可されていません。
pg_hba.confを編集することで接続可能となります。下記の例ではすべてのマシンからの接続を許可しています(DBMotoマシンのIPのみを指定する方が良いと思われます)

(3) DBMotoからPostgreSQLへ接続する

DBMotoから接続時に接続ドライバであるNpgsql.dllを指定する必要があります。その後はIPアドレス、ユーザID、パスワード、データベース名の指定で接続可能です。

PostgreSQLベースでNpgsql ( .Net Data Provider for Postgresql )が使用可能なデータベース、DWH(データウェアハウス)等に関してもDBMotoでデータ・レプリケーションが可能です。すでにAmazon WebサービスのRedshineの検証が確認しております。

タグ: ,

DBMotoがサポートするログの出力先・・・ファイル、DB、Windowsイベントログ、Apache Log4Net

DBMotoは全部で4つをログ出力先をサポートしています。
Ver8.1より新たにApache Log4Netをサポート開始しました。

●サポートするログ出力先

・ファイル
・データベース
・Windowsイベントログ
・Apache Log4Net

●ファイルの場合

ファイルの場合、きめ細かな設定が可能です。
・ローテーションは日単位、サイズ単位で指定可能
・最大ファイル保持数を指定可能
・履歴ファイル(テーブル単位でのレプリケーション件数結果)も保存可能

●データベースの場合

データベースの場合は、DBMotoマシン以外のDBへログを保存することが可能です。
・DBなので大容量のログを保存可能
・最大ログ数を指定可能
・履歴ファイル(テーブル単位でのレプリケーション件数結果)も保存可能
・保存先DBはメタデータで使用のもの、他のDBどちらでも指定可能
・レプリケーション対象のDB以外も指定可能

●Windowsイベントログの場合

Windowsイベントログの場合は、Windowsサイドでの管理となるため、他の監視ツールと連携しやすいのが特徴です。
ただし履歴ファイルの保存には未対応のため注意が必要です。

●Apache Log4Netの場合

詳細は下記をご覧ください。(英語ページです)
履歴ファイルの保存には未対応のため注意が必要です。
http://logging.apache.org/log4net/release/features.html

【注意】
※トレースファイルはファイル出力のみ対応となっています。

コメントする -->

DBMoto[Syniti]の技術お問合せ時に必要な情報

評価版・製品版のDBMoto[Syniti]をご使用時に技術的なお問合せをしていただく際は、下記の情報のご提供をお願いいたします。

DBMoto[Syniti]バージョン

DBMotoメニュー⇒ヘルプ⇒DBMotoについて から確認可能です。

DBMoto[Syniti]のメタデータバックアップ

メタデータを右クリック⇒バックアップ から取得可能です。

●DBMoto[Syniti]のログファイル、履歴ファイル

既定ではC:\Program Files\HiT Software\DBMoto V9\Log にあります。.logがログファイル、.hisが履歴ファイルです。

※Syniti9.xの場合、C:\Program Files\Syniti\Data Replication V9\Log にあります。
※Syniti10.xの場合、C:\Program Files\Syniti\Syniti Replicate\Log にあります。

また、ログの出力先をデータベースに変更している場合には、メタデータを右クリックし、「ログを表示する」からログを表示、「ファイルにログデータベースをエクスポート」からログファイルをエクスポートできます。

Windowsイベントログへ記録している場合には保存先のノードを右クリック、「すべてのイベントを名前をつけて保存」からevtx形式で保存しご提供ください。

●エラー等の場合どのようなオペレーションによって発生したか

再現性がある場合、具体的な再現手順をご確認ください。
再現性がない場合でも、事象発生時にどのようなオペレーションを行ったかご確認ください。

●レプリケーショントレースに関して

※Log Server Agent使用時はこちら

エラー等の障害が発生した場合により詳細な調査を行うために、再現性がある場合にはトレースの取得をお願いする場合がございます。トレース取得の際はWindowsタスクバー上のDBMoto Service Monitor右クリック⇒トレース開始 からお願いいたします。DBMotoレプリケーション動作中でもトレースを開始することが可能です。

トレース開始後、エラー等の事象が再現しましたら同様の手順にてトレースの停止をお願いいたします。

※注意:トレース停止後、Data Replicatorオプションにて「Data Replicatortトレースの有効」のチェックが外れていることをご確認いただき、万が一チェックが付いたままの場合は手動でチェックを外してください。

20141118-4

Data Replicatorサービス開始直後すぐにエラーが発生する場合など、すぐにトレースを取得される場合には、予めData Replicatorオプション画面にて「Data Replicatortトレースの有効」にチェックを入れたうえで、Data Replicatorを開始してください。
これにより、Data Replicator開始と同時にトレースの取得が可能となります。
トレース取得完了後はチェックを外してください。
※注意:トレースを取得するとトレースファイルのサイズが大きくなります。サイジングの設定もこちらの画面から行えますのでご確認をお願いいたします。

20141118-1

特定レプリケーションのみに絞り込んだトレース収集

通常トレースを取得すると全レプリケーションが対象となります。これを下記手順により、一部レプリケーションのみを対象とすることも可能です。
※下記一部をレプリケーショントレース対象とする設定をする際は、反映のためSyniti Replication Agent (DBMoto Data Replicator)サービスを一時的に停止してから実施願います。

20141118-2
20141118-3

トレースの保存先は既定でC:\Program Files\HiT Software\DBMoto V8\Logです。

■Log Server Agent使用時のトレース取得

(1)Windowsのサービス、またはタスクトレイのアイコンより、Syniti Replication Agent (DBMoto Data Replicator)を停止

(2)レプリケーションジョブをすべて無効化

(3)DBの接続設定を右クリックし、トランザクションセットアップ > 管理をクリック

(4)トレースへチェックを入れ、OKをクリック

(5)Replication Agentオプションを開き、Replication Agentトレースの有効をチェック、設定を開く

(6)選択したレプリケーションのみをトレースを開き、エラーが発生しているレプリケーションのみをトレースの対象に設定

(7)レプリケーションジョブを有効化し、Syniti Replication Agent (DBMoto Data Replicator)を開始
(8)事象を再現させた後、タスクトレイよりトレース終了をクリック

(9)以下の2種類をサポートまで送付ください。

  • Log Server Agent設定時に指定したフォルダ内のファイル全て
  • [C:\Program Files\Syniti\Data Replication V9\Log]内のトレースファイル(.trc)

●Management Centerトレースに関して

レプリケーション中の問題ではなく、Management Centerでの設定中(ソース・ターゲット接続設定やレプリケーション・グループ設定)の問題については、Management Center のトレース取得をお願いする場合がございます。以下の手順にて可能です。

20141118-5
20141118-6

また、Management Centerトレースに書き込まれる情報を設定から変更できます。有効化時に、すべてTrueになっていることをご確認ください。

有効化、無効化後や設定変更後にはManagement Centerを再起動してください

Management Centerトレースの保存先はデフォルトではインストールフォルダ内のLogフォルダです。

例:
C:\Program Files\HiT Software\DBMoto V8\Log
C:\ProgramData\Syniti Data Replication\Log
C:\Program Files\Syniti\Syniti Replicate\Log

出力されているtrcファイルをご提供ください。
※Management Centerトレースは「DBMotoMC_NNNN.trc」、データベースへのアクセスに関するトレースは「DataAccessMC.trc」という名称で出力されています。

Server Agentトレースについて

Synitiではメタデータというデータベースに構成情報等を記録しています。このメタデータへの接続はServer Agentサービスが担当しています。

このようなメタデータに関連した問題が発生している場合、調査のためにServer Agentのトレースが必要になる場合があります。Server AgentトレースはReplication AgentオプションのトレースタブにてServer Agentトレースの有効化にチェックを入れると収集できます。

この際、設定から以下のオプションもTrueに変更し、より詳細なトレースを収集する必要がある場合があります。

  • メタデータ操作のトレース
  • 診断情報のトレース
  • サーバエージェントへのトレース要求
  • トランザクション情報のトレース
コメントする -->

DBMotoの各レプリケーションをグループ化する際の利点とは?

DBMotoはテーブル単位でレプリケーションジョブを作成します。レプリケーションジョブ単位で下記のことが可能となります。

●レプリケーションジョブ単位で行えること

・レプリケーションモード(片方向か、双方向か、全件か、差分か)
・差分レプリケーションの実行間隔(既定は60秒)
・スケジュール(定期全件リフレッシュ実行、差分ミラーリングの除外設定)


※グループ化を使用していない場合の設定

また重要なポイントは、レプリケーションジョブ単位でDBに対するクライアントアクセスセッションとなることです。つまりテーブル数が1,000ある場合には、レプリケーションジョブも1,000個となるため、DBへのクライアント接続数も最大1,000となります。これは言いかえると、DBへのセッション数が増大してDBへの負荷がかかる恐れがあることを意味します。

では、これらのレプリケーションジョブをグループ化としてまとめた場合にはどのようになるでしょうか?

●グループ化した際の特徴

・レプリケーションジョブ単位で行えた設定はグループで共通設定となる
・DBへのクライアントアクセスセッションもグループ単位となる


※グループ化を使用した場合の設定

グループ化することによって、DBへの接続セッション数を減らすことが可能となります。例えば、レプリケーションジョブが100個を1グループにまとめた場合にはDBへの接続数は1です。レプリケーションジョブが1,000個で1グループ100ジョブ×10グループの場合は、DBへの接続数は10です。このように、DBへの接続数を大幅に減らすことが可能となるため、テーブル数が多い場合にはグループ化の設定は事実上必須となります。

●グループ化した際のレプリケーションの実行順位は?

グループ化によってセッション数が1となるため、各レプリケーションの実行は下記の順で行われます。

・全件リフレッシュの場合⇒グループ化した際に設定する優先順位で実行される
これは1つのテーブルのリフレッシュが完了次第、次のテーブルのリフレッシュが開始されるイメージです。

・差分ミラーリングの場合⇒トランザクションIDの順に実行される
これは複製元ソースで処理されたトランザクションの順番に処理されるイメージです。外部キーを持った親子テーブルをグループ化していた場合にも正しい順番で処理されることを意味します。親子テーブルはグループ化しないと意図した順番にレプリケーションされませんので、グループ化は必須です。


※全件リフレッシュに限り優先順位を指定可能


※親子テーブルをリフレッシュする場合にはリフレッシュ前のTRUNCATEによる複製先ターゲットのテーブルのレコードの削除は設定した優先順位とは反対の順番で行う必要があるが、DBMotoではそのオプションも用意されている

●まとめ(グループ化の利点)

まとめると下記の通りです。

・レプリケーションの設定を1つにまとめられる
・DBへの接続セッション数を減らすことができる
・外部キーを持つ親子テーブルも安全にレプリケーションできる

タグ:

Oracle用SQL開発ツール「SQL Developer」は検証開発用に最適

2013/12/12にOracle公式のSQL開発ツール「SQL Developer」の最新バージョン4がリリースされました。
SQL Developerは検証・開発目的で簡単にOracleのSQL管理をすることができる大変便利なツールです。
動作にはJDKが必要ですが、最新版ではJDKが同梱されたものもインストール可能となっています。 また最新版ではJDK7を正式サポートしています。

●ダウンロード

下記からダウンロード可能です。
http://www.oracle.com/technetwork/jp/developer-tools/sql-developer/downloads/index.html

●インストール

インストールは特に必要ありません。ダウンロードしたzipを展開するのみです。起動は「sqldeveloper.exe」から行えます。

起動時に下記のダイアログが表示されます。前バージョンがインストールされている場合は設定を引き継げるようです。

●実際に使用してみる

起動した画面です。

Oracleへの接続設定画面です。設定はシンプルで、接続先IP、ユーザ名、パスワード、SID名(又はサービス名)ですぐに接続可能です。

SQL Developerの便利なところは、直接IP指定する方法に限らず、tnsnames.oraの接続文字列を選択することでも接続できることです。

接続が完了したところです。ここではローカルのOracleへ接続しています。テーブルデータに限らず、ビュー・トリガー・順序オブジェクト等の管理も行えるようになっています。

これは実際にテーブルデータを表示しているところです。もちろんその場で編集することも可能です。

複数のOracleへ接続して一元管理することももちろん可能となっています。

タグ: ,

レプリケーションされるレコードをフィルタリングするスクリプト【DBMoto】

弊社のDBMotoでは異なるデータベース間でのデータレプリケーションが可能です。
レコード全件を片方からもう片方へコピーするリフレッシュ、変更したレコードを検知して反映するミラーリング、変更を互いに反映するシンクロナイゼーションの3種類があります。
これらのレプリケーションジョブには必要に応じ、スクリプトにより対象とするレコードを限定するような条件をつけることができます。

本記事ではミラーリング時にフィルタリングをするスクリプト3つ、シンクロナイゼーション時にフィルタリングをするスクリプト1つを紹介いたします。

  1. 指定したカラムで特定の範囲の値を取っているレコードのみをリフレッシュ・ミラーリングする。その後ソース側で削除があってもターゲット側で特定の範囲の値を取っているレコードは削除しない。
    サンプルスクリプト:filtering_1.txt 

    ●スクリプトの内容
    ソース側の、id1というint型のカラムの値が3より大きいとき、リフレッシュ及びミラーリングを停止する(=3以下はリフレッシュ・ミラーリングを行う)。
    ソース側でレコードの削除があっても、id1の値が3より大きいレコードに関しては、ミラーリングしない。

  2. 指定したカラムで特定の条件に当てはまるレコードの削除をミラーリングしない
    サンプルスクリプト:filtering_2.txt 

    ●スクリプトの内容
    ソース側でレコードの削除があっても、id1の値が3より大きいレコードに関しては、ミラーリングしない。
    (1つ目のスクリプトから削除のミラーリングに関わる部分を抜き出したものです。)

  3. ソース側でのレコードの削除をミラーリングしない
    サンプルスクリプト:filtering_3.txt 

    ●スクリプトの内容
    ソース側でレコードの削除があっても、その変更を一切ミラーリングしない。
    (2つ目のスクリプトから条件を問わず削除のミラーリングをしないように編集したものです。)

  4. シンクロナイゼーションで相手方に対し反映するレコードのデータをフィルタリングする
    サンプルスクリプト:filtering_4.txt 

    ●スクリプトの内容
    ソース側のレコードのうち、DataTime型のカラムの値が指定期間の間に収まっているレコードのみをターゲット側に反映。
    ターゲット側にあるデータで、同じ指定期間内にあるレコードが挿入・更新・削除された場合はソース側に反映する。

タグ: , , ,

DBMoto設定情報を簡単にバックアップ・リストア

DBMotoではデータベースへの接続情報やレプリケーション設定などをメタデータの形式で保存しています。デフォルトではこの情報はDBMoto SQL Server CE形式(.sdf)で保存されますが別マシンのデータベースを保存先にすることでDBMotoの構成を冗長化することができます。
DBMotoの設定情報(メタデータ)を冗長化構成にして、より安全に運用する

このメタデータはXMLファイル形式でバックアップとして保存でき、問題発生時の設定情報のリストアや、DBMotoインストールサーバの移行に使用できます。また、トラブル発生時に弊社にてサポートさせていただく場合にも設定情報の確認のため、このファイルのご提供をお願いする場合もあります。

また、メタデータのリストア時には上書きでのリストアの他に、一部のレプリケーションのみのリストアも行えます。このリストアではレプリケーションの設定をカスタマイズしてリストアできますので、検証環境で作成したメタデータをお客様の環境に合わせてリストアする際などに活用できます。
レプリケーションの選択         スキーマ等への接続のマッピング

接続DBや詳細設定            グループのマッピング

コメントする -->

Google Cloud SQL と オン・プレミス・データベース間でのデータ・レプリケーション【DBMoto】

Google Cloud SQLはGoogle Cloud Platform上でホストされている完全に管理された MySQLサービスです。Google Cloud Platformはユーザに次のようなソリューションを提供します。 ネイティブなMySQL接続のサポートによりGoogleユーザはツール、技術、アーキテクチャの選択の幅を広げることができるようになりました。

●Google App Engine と Google Cloud SQLを使用したmobile apps と social appsなどのCloud app ソリューション

●Google Cloud Storageを使用したハイエンドのバックアップ・リカバリとアクティブ・アーカイブなどのCloudストレージ・ソリューション

● Google Compute Engineを使用したバッチとデータ処理などの大規模計算ソリューション

●Google BigQuery と Google Prediction APIを使用したインタラクティブ・ツールとトレンド検出などのビッグデータ・ソリューション

DBMotoはGoogle Cloud SQLへのリアルタイムなレプリケーションをサポートします。これによりオンサイトとGoogle Cloudアプリケーション間でリアルタイムなデータ移動を簡単に管理するために、Google Cloud プラットフォームでのリレーショナル・データべースのサポートが必要な企業をサポートします。

DBMotoのデータ・レプリケーションとCDC(change data capture)は異機種データベース間での重要なデータ・アップデートの設定とプロセスを提供することで開発者とIT部門に開発努力と時間の短縮を提供し、クラウドを含む企業内のどんな場所からでも重要な分析、オペレーション、データ・ハウジング・システムの最新データを素早く提供することができます。

*DBMoto の開発元のHiT SoftwareはGoogle Cloud Platform Partner ProgramのTechnology Partnerです。

タグ: , ,

レプリケーション検証機能(Validate)によるトランザクション情報取得チェック

DBMoto8では「レプリケーション検証機能」(英語名称:Replication Validate)が搭載されています。

これを使用すると、レプリケーションジョブ単位、すなわちテーブル単位で、正しくトランザクション情報をDBから取得できるかどうかを一括で確認することが可能です。

最初にジョブ作成を行う際にトランザクション参照設定も行いますので通常は問題ありませんが、何らかの理由でDB側に変更を加えてトランザクションが参照できなくなった場合、本機能によってすぐに確認可能です。

以下、検証機能によるトランザクション情報取得確認手順です。

1. 「レプリケーションを検証する」をジョブ名右クリックから選択します。

2. 「検証」をクリックします。

3. 検証結果が表示されます。今回はEMPLOYEEというジョブ名でエラーとなっており、EMPLOYEE2では問題なしとなりました。つまり、EMPLOYEEにおいてはトランザクション情報をDBから取得できないことを意味します。

4. 実際にエラーの詳細を表示したところ、「Table is not journaled」と表示されています。これは、AS/400の物理ファイルに対して、ジャーナルが起動していないことを意味します。

コメントする -->

Oracle DB起動時にエラーORA-00257が出て起動しない際の対処法

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

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

ORA-00257:archiver error. Connect internal only, until freed.

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

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

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

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

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

コメントする -->