AWSへのDB移行/連携を行うには? DBMotoが選ばれる理由

簡単にクラウド環境にデータベースを構成することが可能なAWS(Amazon Web Service) のRDSやRDB on EC2。とても便利なサービスですが、実際にオンプレミスDBの移行/連携を行う場合どのように実施すればよいのでしょうか。

エクスポート/インポートによる手動実施や、AWS既存のサービスであるData Migration Service(DMS)の活用なども選択肢として挙げられますが、円滑な移行や連携まで視野に入れた場合、レプリケーションツールDBMotoを使用することで簡単に実現することができます。

以下はDBMotoが選ばれている主な理由です。

・ダウンタイムを最小限に抑えた移行

DBを移行する際、一番問題となるのはダウンタイムです。手動でのエクスポート/インポートによる通常のDB移行の手法では、データの整合性維持のため、データのエクスポート/インポートの実施中もDB停止させている必要があります。これに対し、DBMotoを使用した場合は、移行時のダウンタイムをデータの切り替え時のみとし、ダウンタイムを最小限に抑えることができます。

・IBM DB2 (AS/400)など数多くのDBに、エージェントレスで対応

DBMotoは様々なDBに対応しており、これら全ての異種DB間でレプリケーションすることが可能です。例えば、DB2 for i (AS/400)などAWS DMSで対応していないDBを移行/連携させたい場合でも、DBMotoを使用することで簡単に実現することができます。また、DBMotoは中間サーバとして動作するのでDBにエージェントを導入する必要はありません。これにより導入の手間やDBの負荷を抑えた、異種DB間のレプリケーションを実現します。

・双方向の差分同期によるデータ連携

DBMotoは双方向の差分同期にも対応しています。同一レコードに対しての更新競合が発生した場合でも、どちらを優先するか等、データ不整合を回避するためのオプションを用意しています。これにより下記のようなオンプレミスとAWSの双方のDBで更新が必要な連携システムでも使用可能です。

・データ変換や条件付きのレプリケーション

関数やスクリプトを使用することによる、複雑なレプリケーションもDBMotoで実施可能です。例えば、Trim関数を適用し前後の空白を除去するといった、データ変換を実施したレプリケーションが可能です。他にもオンプレミス側の削除(Delete)オペレーションを同期しない等の、条件付きのレプリケーションも実施できます。これはAWS上には古いデータも含め常に保持しておきたい場合などに活用できます。

タグ: ,

DBMoto差分レプリケーション方式 x 3について

異種DB間を双方向にレプリケーションできるDBMoto。これを実現するための差分レプリケーション方式として、トランザクションログ方式もしくはトリガー方式を提供しています。またDBは限定されますが、トランザクションログを独自の形式で保管し、差分レプリケーションを実施するログサーバエージェント(Log Server Agent:LSA)方式もあります。

まとめた表が下記です。

レプリケーション方式 トランザクションログ方式 トリガー方式 ログサーバエージェント方式
メリット 古くからありシンプルで安定した方式 トランザクションログの制限にかからずレプリケーション可能 DBへの接続数最適化によるパフォーマンス向上
デメリット トランザクションログ側の制限に該当する場合がある ログテーブルによるDBへの追加の負荷や、容量が生じる トランザクションログ(バイナリログ)を保管する容量が必要
DBへの負荷

極小~小

バイナリデータ(Lob型)の対応

不可

それぞれの方式の特徴についてご紹介いたします。

トランザクションログ方式

DBのトランザクションログを直接参照し更新情報を取得する方式です。Lob型等のバイナリデータのレプリケーションはできませんが、DB側のログを利用する非常にシンプルな構成のため、DB側への負荷をかけずに差分レプリケーションを実施することが可能です。

Oracle: REDOログ・アーカイブログ、 SQL Server:ログ(ディストリビュータ経由) MySQL :バイナリログ等

・トリガー方式

レプリケーション対象テーブルに対してトリガーを作成、ログテーブルを参照し更新情報を取得する方式です。これによりトランザクション方式では実施できないLob型のレプリケーションを実施することが可能ですが、トリガーによるログテーブルの書き込み処理により、トランザクションログを使用する方式と比較するとDBに追加の負荷や容量が生じます。

 

・ログサーバエージェント(LSA)方式

ログサーバエージェント機能により、トランザクションログデータをDBMoto独自のバイナリログ形式として保管し、このバイナリログから更新情報を取得する方式です。バイナリログを保管する領域が必要となりますが、DBMotoから変更点を感知するためのDBへの接続数が最適化されます。現在の対応DBはOracle 、MySQL、IBM Informixです。

※v9.5からはPostgreSQL、AS/400、MS SQLServerも対応しております。

タグ: , ,

SQL Serverアプリケーションをスケールアウトしてワークロードを向上させるオプション

大量の処理負荷を満たすためにデータべースをスケールアウトすることは難しいことです。SQL Serverのスケーラビリティメソッドの詳細は、ここをクリックしてください。

SQL Serverの管理者にとって大きな課題の1つは、より重いデータ処理作業負荷に対応するために、常にデータベースを拡張することでした。問題を複雑にするMicrosoftには、さまざまなSQL Serverのスケーラビリティオプションが用意されていますが、すべての状況に対応できるわけではありません。

まず、SQL Serverアーキテクチャをスケールアウトするかどうかの基本的な質問があります。前者は、より多くのプロセッサ、メモリ、およびデータストレージを備えたより大きなサーバにデータベースを移動することです。後者はSQL Serverアプリケーションを複数のサーバに拡張し、データ処理の負荷を分散し潜在的なデータの冗長性と可用性の利点を提供します。

ここでは、SQL Serverをスケールアウトするさまざまな方法に焦点を当てます。どのスケーラビリティ・メソッドを使用するかを決定する前に、データベース管理者は、データ更新の頻度、異なるデータベース間でデータをパーティション化できるかどうか、SQL Server上で実行されるアプリケーションを変更できるかどうかなどの要素を考慮する必要があります。その答えを手に入れて、彼らは特定のニーズを満たすスケールアウト計画を立てることができます。

これらの回答を見つけるために、一般的に使用されているSQL Serverスケールアウトアプローチの基本的な詳細をMicrosoftが投稿した技術情報から集約しています。

スケーラブルな共用データベース
データベースはデータベースサーバー上に物理的に配置する必要はありません。ストレージエリアネットワーク(SAN)に配置する代わりに、異なるサーバー上で実行されている複数のSQL Serverインスタンスによって同時にデータにアクセスできます。本質的に、SANに接続されている各インスタンスは、同じデータベースコピーから動作します。

このスケーラビリティメソッドは通常、SQL Serverアプリケーションを変更することなく使用できます。しかし、大きな欠点は、静的な日付のワークロードにのみ適していることです。スケーラブルな共有データベースは、複雑なクエリ(データウェアハウスなど)を伴う読み取り集中型アプリケーションでは非常によく機能します。

ただし、スケーラブルな共用データベースは、読み書き操作が混在するアプリケーションには適していません。データを書き込こむときにSQL Serverデータベースにロックが設定されます。データを共有データベースに書き込む場合は、書き込み操作が完了するまで、1つを除くすべてのSQL Serverインスタンスが一時的にデータからデータを取得します。その結果、書き込み操作はデータベースのパフォーマンスに悪影響を及ぼします。

分散パーティションビュー
スケーラブルな共有データベースとは異なり、SQL Serverのワークロードをスケールアウトするこの手法は、頻繁に更新されるデータに対してうまく機能し、オンライントランザクション処理(OLTP)アプリケーションに適しています。欠点を挙げるとすれば、データを分割する必要があることです。 また、データベースアプリケーションでは、すべてのパーティションで処理操作を同期させるための変更が必要になる可能性があります。

分散パーティションビューアプローチの背後にあるコンセプトはシンプルさです。大規模データベースのデータは、いくつかの小さな分散データベースに分類されます。たとえば、請求書を含むデータベースを年ごとに分割することができます.2016年の請求書をあるデータベースに配置し、2017年の請求書を別のデータベースに入れることができます。 関連するデータが含まれているデータベースに対して、更新と照会を実行することができます。

データ依存型ルーティング
これは基本的に、大量のOLTPアプリケーション用に設計された分散パーティションビューのバリエーションです。データベースも同様に一連の小さなデータベースに分類されます。 違いは、クエリを正しいデータベースにルーティングするプロセスがどのように管理されるかです。分散パーティションビューでは、SQL Server自体がデータパーティション構造を認識し、要求されたデータにアクセスする場所を決定します。これに対して、データ依存型ルーティングの場合、SQL Serverアプリケーションまたはミドルウェアサービスは、必要なデータがどこにあるかを決定します。

リンクサーバー
SQL Serverは、ローカルデータベースのようにリモートデータベースにアクセスできます。そのため、スケールアウトされたデータベースのコレクションを単一の大きなデータベースのように扱うようにソフトウェアを構成することが可能です。リンクされたサーバーは、既存のSQL Serverアプリケーションを簡単に変更して別のスケールアウト手法をサポートできない場合に実行可能な代替手段を提供します。

ただし、SQL Serverは一連の独立したデータベースに接続するため、SQL Server間の正式な結合はできません。ローカルテーブルとリモートテーブル間の参照整合性の欠如など、SQL Server内のいくつかの制限に加えて、リモートデータベースへのアクセスにはかなりの処理オーバーヘッドがあります。リンクサーバーを必要とするSQLサーバーアーキテクチャーは、特にローカルリモートテーブル間のジョインを介して、リモートデータにアクセスする必要性を最小限に抑えるように設計する必要があります。

ピアツーピアレプリケーション
SQL Serverアプリケーションをスケールアウトするもう1つのメカニズムは、異なるサーバー間でデータをレプリケーションすることです。ピア・ツー・ピアレプリケーションは、本質的に、スケーラブルな共有データベース・メソッドの逆です。複数のデータベースサーバーがデータベースの1つのコピーを共有するのではなく、それぞれ独自のコピーが含まれています。データに動きがあると、その変更はすべてのコピーにレプリケーションされます。

ピア・ツー・ピア・レプリケーションは、比較的大きい数のデータベース書き込みを処理できますが、比較的静的なデータに用いるのが最適です。しかし、レプリケーションプロセスに伴うレイテンシのため、非常に時間に敏感なデータには適していません。また、書き込みよりも多くの読み込みを処理する場合に汎用性が高いのは、スケーラビリティオプションです。

コメントする -->

データベースの外部キーとは何か?

外部キーは、元のテーブルの主キーデータに接続する1つのテーブル内のデータの列です。

外部キーと主キーテーブル間のリンクが壊れていないことを保証するために、外部キー制約を作成して、テーブル間のリンクを傷つけ、誤ったデータが外部キー列に追加されないようにします。

主キーと外部キーの違い

元のテーブルまたは親テーブルの主キーは、他の子テーブルの複数の外部キーの対象となることができます。 しかし、主キーは必ずしも外部キーのターゲットである必要はありません。 主キーは、テーブル内の行を識別する列または列の集合です。 ただし、外部キーは、主キーと一致する必要があるテーブルとは異なるテーブル内にあります。

管理者は、必要に応じて、SQL Serverなどのリレーショナルデータベースの主キーを選択または変更できます。 たとえば、ある町の人々は、あるアプリケーションでは運転免許証番号によって一意に識別されるかもしれませんが、別の状況では、電話番号に従って識別する方が便利かもしれません。 テーブルの主キーが変更されると、関連する外部キーのセットが結果として変更されます。

制約の種類

外部キー制約は、無効なデータが外部キー列に配置されないようにします。これは、それが対象となるテーブルに含まれる値の1つでなければならないためです。 データベース管理者は、SQL Server Management StudioまたはTransact-SQLを使用して、SQL Server 2017の最新モデルで外部キー関係を作成できます。 外部キーは、別のテーブルの主キー制約に特に関連付ける必要はありません。 他の場所でUNIQUE制約の列を参照することもできます。

異なる制約には、UNIQUE、CHECK、DEFAULTが含まれます。 UNIQUE制約は、主キー内にない特定の列に重複値が入力されないようにします。 CHECK制約は、複数の列で受け入れられる値を制限します。 DEFAULT制約は、NULL値が適切でない場合に適用されるため、管理者はたとえば、デフォルトの数値列としてゼロを設定できます。

外部キーの問題

多くのデータベースユーザーは、参照整合性の問題のために、外部キーエラーに遭遇します。 外部キーが存在しなくなったデータを指しているか、外部キーのデータ型が主キーデータ型と一致せず、参照整合性を侵食している可能性があります。

これは、外部キーが主キーのすべてのデータを参照していない場合にも発生します。 会社名、部門名、住所の主キーで構成されるSalesの親テーブルがある場合、Customersの子テーブルは親テーブルのすべての属性を参照する必要があります。

タグ:

SQL Server for Linuxがすぐそこに! – WindowsデータベースがHA機能を追加

一般的な可用性を向上するために、SQL Server 2017へ機能の一部として、SQL Server for Linuxを追加しました。
一方、兄弟となるSQL Server for Windowsは、高可用性の質を上げています。

先日、MicrosoftがSQL Server 2017 Release Candidate 1を発表したことで、Linux向けSQL Serverの正式リリースが現実のものに近づきました。このリリースには、SQL Server for Linuxポートに対応する要素が含まれています。オペレーティングシステムは、Microsoftのレドモンドワシントンキャンパス内はではかつてないほどのものでした。

SQL Serverの究極の開発者ガイド

SQL Serverデータベースのパフォーマンスを向上させるためのヒント:テーブルと列を最適に作成する方法、データベース正規化を復元する方法、エイリアスを構成する方法について説明します。

リリース候補ソフトウェアは、コミュニティ技術のプレビューの数に沿って、今年予想される一般的な可用性への道のりで、いくつかのチェックボックスをチェックします。

SQL Server 2017 RC1は、Active Directory認証、ネットワーク経由でのクライアント/サーバー通信の暗号化に対する透過的なレイヤーセキュリティー、およびクラスタノードの設定に対する調整をサポートしています。

WindowsとLinuxバージョンのSQL Serverの間には1対1の機能がありますが、すぐに利用できるわけではありませんが、新しいLinuxバージョンは、SQL Server for Windowsでよく見られる機能のかなりの部分を提供します。

いくつかの高度なソフトウェア開発の裏には、Linuxへの移行があります。同社はMicrosoft ResearchプロジェクトDrawbridgeにプラットフォーム抽象化レイヤー(PAL)を提供し、既存のSQL Serverエンジンにいくつかの限定的な変更を加え、既存のSQL Server forWindowsをLinuxでそのまま使用できるようにしました。

コンテキストでのLinux用SQL Server

SentryOneのマイクロソフトMVPとプロダクトマネージャーであるJohn・Martin氏は次のように述べています。「WindowsとAzureですでに見たことがあるため、SQL Server for Linuxの安定性、スケーラビリティ、機能にはかなりの自信があります」。Microsoft SQL Serverおよび他のプラットフォーム用のパフォーマンス監視および最適化ソフトウェアです。

Martin氏は、SQL Server for Linux用のSQL ServerコードベースのポートとしてMicrosoftがPALを使用したことを認めています。同氏によると、SQL Server for Linuxは多くの追加作業が行われているという。

「フェールオーバクラスタインスタンスや可用性グループのようなティア1の機能は、これが深刻な動きであること」と示しています。マーティン氏によると、スタンダード版とエンタープライズ版のSQL Serverの機能比較は、プラスだという。

SearchServerServer.comの執筆者であり寄稿者でもあるMicheal Otey氏によると、
「SQL Server 2016のすぐあとにSQL Server 2017の登場ですが、機能強化はそこまで多くはない。
オープンソフトウェアのサポートを拡大するための他のマイクロソフトの取り組みによって、Linuxのサポートが重要であり、異種混在の大規模な組織では特にそうだ」 とOtey氏は述べています。

「LinuxバージョンのSQL Serverは、Windows版に比べていくつかの分野で遅れている。
SQL Server for WindowsとSQL Server for Linuxを対照して、サポートされていない機能の一覧には、Strechデータベース、PolyBase、Analysi Services、およびMaster Data Servicesがあります。
それでも、MicrosoftがLinux凌駕していないという事実だけが重要です。」

「Microsoft SQL Server for Linuxはフル機能ではありませんが、最初のリリースであると考えて本当に期待しています」とOtey氏は語りました。

Linuxのポートを越えて

昨年のSQL Server 2016リリース時の更新よりも華やかさありませんが、多くの場合、Linuxのサポートが強調されています。

特にミッションクリティカルな実装に重点を置いているSQL Serverのコンサルティング会社であるSQLHA LLCの管理下にあるAllan Hirtにとって、新しいLinux版のSQL Serverへの関心は、Windows版のデータベースの進歩を邪魔するものではありません。

Microsoftの分散トランザクションコーディネータを使用するためのアプリケーションのために、高可用性に特に役立つ進歩は、SQL Server 2017のAlways On Availability Groups機能を完全にサポートしているという。

同氏によると、可用性グループのクラスタータイプの導入、可用性グループ内の同期レプリカのための機動性の制御、およびLinuxの主要な可用性機能のサポートなど、可用性の他の改善もあります。

Hirt氏によると、これは価値があると言われています。あらゆる規模のITショップが、そのプラットフォームに関係なく、データの可用性を重視しているためです。

可用性を高めたHAは、「SQL Serverに関するすべてではありません。」と彼は付け加えています。これらの新しい機能は、ソリューション全体が連携して機能して可用性を確保する必要があるため、ストーリーの一部にすぎません。

彼は、「SQLサーバのDBAは、Linuxで高可用性のデータベースをWindows 上で構築をするには、さまざまな課題に直面するだろう」と言った。

いずれの場合も、可用性グループは可用性グループであり、フェールオーバはフェイルオーバであり、Windows ServerやLinux上で稼働しているかどうかは、その核となるだけです。

それでも、SQL Server for Linuxは重要なステップであり、Microsoftのサポートレベルは重要です。
Hirtの言葉では、「二流の市民ではない」

タグ:

[DBMoto]「未マッピング使用」機能によるマッピング外のデータを活用したレプリケーション

異種DB間でレコードデータを連携できるDBMoto。スクリプトを使用して条件付きレプリケーションを実施できる機能も搭載されております。

DBMotoではマッピング対象以外のカラムもスクリプトで使用できる「未マッピング使用」という機能も搭載しております。レプリケーション対象ではないが、フィルタリングするデータとしては使用したい時などに活用できます。

設定例

以下のようなマッピング設定とします。左側ソーステーブルの「C2」はターゲットテーブルにはないフィールドであり、マッピング対象外となっています。

ソーステーブルには適当な2件のレコードが入っており、ターゲットテーブルは空データです。

そしてレプリケーションスクリプトに下記のような「C2」の値が1の場合、レプリケーションをスキップするスクリプトを設定します。

[vb]
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, ByRef DisableReplication As Boolean)
‘C2が1のレコードはスキップ
If recSource.GetValueAfter("C2") = "1" Then
AbortRecord=True
   End If
End Sub
End Class
End Namespace

[/vb]

通常ですとマッピング対象外の「C2」のデータを取得できずレプリケーションが実施できません。

マッピング設定画面からソーステーブルの「C2」フィールドを右クリックし、「未マッピング使用」を選択してみます。

「C2」のデータをスクリプトで使用できるため、1の値のレコードのみスキップする想定通りのレプリケーションが実施できました。

コメントする -->

カスタムリストアを用いて、別サーバにレプリケーション設定を流用: DBMoto

こちらの記事ではDBMotoのデータベースへの接続やレプリケーションなどの設定情報(メタデータ)のバックアップ/リストアを用いたDBMotoサーバの移行方法について記載しております。

これに加えてDBMotoでは、レプリケーション単位で設定情報を復旧できるカスタムリストアという機能も搭載しています。

カスタムリストアではレプリケーション対象のDBやテーブルを再マッピングできます。これにより、例えば検証環境のレプリケーション設定情報を、同一構成である本番環境でも流用したい場合などに活用できます。

カスタムリストア実施時は以下の点にご注意ください。

  • カスタムリストアではグローバルスクリプトはリストアされません。
  • データベース側でなく、DBMoto側で定義したPK(擬似PK)の設定は引き継がれません。これはレプリケーションで指定するのではなく、テーブルで指定する設定のためです。
  • 差分レプリケーションをリストアする場合は、流用先DBでトランザクションログの設定が有効となっている必要があります。
  • テーブルのマッピング時、流用元と流用先のフィールドの型やサイズといった構造が一致している必要があります。

下記流用例では、以下の設定で実施しております。
・元のソースデータベース/スキーマ:Test_Oracle/STUDY
・元のターゲットデータベース/スキーマ:Test_AS400/STUDY
・先のソースデータベース/スキーマ:Product_Oracle/KOBAYASHI
・先のターゲットデータベース/スキーマ:Product_AS400/KOBAYASHI

 

カスタムリストアを使用したレプリケーションの流用例

流用元のサーバで行う作業

1) DBMotoレプリケーターサービスを停止します。


2) メタデータのバックアップを実行し、流用元DBMotoサーバの設定情報をバックアップします。


3) バックアップ時に指定したパスにxmlファイルが作成されます。流用先のローカル等参照できる場所にファイルを移動させます。

 

流用先サーバで行う作業

1)流用先DBMotoサーバにてマッピング先とするソース、ターゲットDB、スキーマ登録を行います差分レプリケーション流用時はトランザクションログの設定も行っておきます。
※流用元でグローバルスクリプトを使用している場合は、流用先に事前にコピーしておきます。


2)DBMoto管理画面のメタデータを右クリックし、リストアを選択します。


3) リストア方式として「カスアムリストア」を選択します。
ウィザードの最初のステップでは、先ほどバックアップしたxmlファイルを指定します。


4) レプリケーションの選択ステップで、リストアするレプリケーションを指定します。
流用元のトランザクションポイントや、主キー、CCSID情報を維持するかどうかも選択できます。


5) 接続のマッピングステップで、事前に登録していたDB、スキーマを指定します。

6) レプリケーションの詳細設定ステップで、マッピングするテーブルを指定します。
デフォルトでは流用元と同一名のテーブルにマッピングされています。


7) グループのマッピングステップで、レプリケーショングループ設定をマッピングすることもできます。


8) サマリーステップで「開始」ボタンをクリックすると、指定したレプリケーションのカスタムリストアが実施されます。


コメントする -->

設定情報(メタデータ)を用いてDBMotoサーバを楽々移行

DBMotoではデータベースへの接続やレプリケーションなどの設定情報(メタデータ)を、GUIの画面から簡単にバックアップリストアすることが可能です。障害発生時に備え設定情報の保護を実施する用途以外にも、DBMotoサーバを移行する目的としても活用できます。

メタデータのバックアップ/リストアを使用した移行

現在のサーバで行う作業

1) DBMotoレプリケーターサービスを停止します。


2) DBMoto管理画面のメタデータを右クリックしバックアップを選択、バックアップ先のパスとファイル名を指定します。


3) バックアップ時に指定したパスにxmlファイルが作成されます。新規サーバのローカル等参照できる場所にファイルを移動させます。

 

新規サーバで行う作業

1) 新規サーバにDBMotoをインストールします。

2) DBMoto管理画面のメタデータを右クリックし、リストアを選択します。

3)リストア方式として「標準リストア」を選択し、先ほどバックアップしたxmlファイルを指定します。
※カスタムリストアはレプリケーション情報を個々にリストアできる機能です。詳細はこちらをご参考ください。


4) 上書きの確認ウィザードがポップアップされるので「はい」を選択します。


5) リストア完了後、メタデータを選択してポップアップされる画面で「はい」を選択します。既存のDBMotoサーバの設定情報が表示されることを確認します。


6) タスクバーより、DBMotoレプリケーターサービスを起動し、正常にレプリケーションが実施できることを確認します。

注意点としてメタデータのリストアでは接続DBやレプリケーション情報以外は移行されません。例えば、アラートやメール通知設定などは別途設定する必要があります。

コメントする -->

保護中: DBMoto 9.0.7.6 リリースノート

このコンテンツはパスワードで保護されています。閲覧するには以下にパスワードを入力してください。

保護中: DBMoto 9.0.7.6 リリースノート はコメントを受け付けていません -->

Log Server Agent for Oracleの設定手順【DBMoto9.x】

DBMoto v9.0以降では、Oracleの差分レプリケーションを、DBMoto独自の機能であるLog Server Agent (LSA)を使用して実施することが可能です。

Log Server AgentはLog Serverと呼ばれるWindowsサービスから実行するサーバーアプリケーションを使用し、レプリケーションを実施するモードです。Oracleのログマイナーを使用し、単一の接続で全てのレプリケーションの変更点を読み取ります。読み取った変更点はDBMoto独自の形式のバイナリログとして指定したフォルダに保存し、DBMotoは保存したバイナリログからレプリケーションを実行します。従来のLog Readerを使用する方式と比較して、Log Server Agentはバイナリログを保存する領域が必要となりますが、データベースへの接続数が最適化されることにより、効率的なレプリケーションを実現できます。

Log Server Agentを使用するには以下の要件を満たす必要があります。

<DBMoto>
・DBMoro ver9.o以降

<Oracle DB>
・Oracle11g、Oracle12c
・サプリメンタルロギングが有効になっている(DBMotoの設定画面から有効にできます)
・アーカイブログモードが有効になっている

<Log Server Agent 使用領域>
・バイナリログや格納情報を保存する領域
※DBMOTO Data Replicatorサービス、Log Serverサービスが接続できる必要があります。

以下、実際の手順です。

1.DBMotoをインストールしたマシンから接続できるパスに、下記フォルダを新規に作成します。
ログフォルダ : Log Serverによって書き込まれるバイナリログファイルを保存するフォルダです。
ログサーバフォルダ :DBへの接続やログを格納するフォルダの情報を保存するフォルダです。

2.DBMotoを起動し、ソースDB接続作成ウィザードを開きます。
通常のセットアップ時と同様に、”接続文字列を設定”画面でOracle DBの接続情報を入力します。

3.“セットアップ情報”画面で、トランザクションを使用の欄で”Log Server Agent”を選択し、1で作成したフォルダを指定します。”接頭語”項目に適当な文字を入力します。(接頭語はバイナリログファイル名に含まれます)
Oracle12Cのマルチテナントを使用している場合は、”Useログコンテナ”の欄にCDBへの接続情報を入力します。
その後”確認”を押し、”インストール”ボタンをクリックします。
※サプリメンタルロギングが有効になっていない場合は、インストールボタンを押下時に自動的に有効になります。

4.接続ウィザードを完了し、DBMoto画面の左側にあるメタデータエクスプローラーから作成したOracle DBを右クリックしプロパティを選択します。

5.“トランザクションの種類”を選択し、セットアップ情報画面の開始をクリックし、Log Serverを開始させます。

6.DBMoto画面からターゲットDB、レプリケーションを作成し、DBMoto Data Replicatorを起動することでLog Server Agentを用いた差分レプリケーションを実行できます。

*DBMoto Ver9.5ではLog Server AgentをIBM i (AS/400), MS SQLServerでもサポート予定です。

タグ: ,

エラー「トランザクションの読み取りポイントは、Oracleのログに含まれていません。」への対処法

本エラーはDBMotoが保持しているREDO LogのトランザクションIDがOracleへの接続参照時にすでに存在しない場合に発生します。詳細はこちら

対処法としては以下の2通りの方法があります。

1. 初期リフレッシュを実行

2. トランザクションIDを手動で更新

 

1. 初期リフレッシュを実行

初期リフレッシュを実行することで、最新のトランザクションIDに自動で更新されますので、リフレッシュ後、そのままミラーリングが実行されます。

レプリケーションを選択し右クリック、初期リフレッシュを実行を有効化します。Data Replicatorが実行されると、リフレッシュが開始されます。


 

2. トランザクションIDを手動で更新

最新またはREDO Logに存在する任意のトランザクションIDを手動で取得します。時間での指定も可能です。

a. レプリケーションを選択し右クリック、プロパティを開きます。


b. 優先 > トランザクション読み込みポイント-ソース > トランザクションIDが、現在DBMotoに保存されているトランザクションIDです。


c. トランザクションIDに任意の値を入力するか、右のメニューを開き、いずれかの方法でトランザクションIDを更新します。

現在のシーケンス:最新のトランザクションIDに更新

日付(yyyy/mm/dd)又は時刻:任意の時間のトランザクションIDに更新



タグ: , , , ,

保護中: DBMoto 9.0.5.6 リリースノート

このコンテンツはパスワードで保護されています。閲覧するには以下にパスワードを入力してください。

保護中: DBMoto 9.0.5.6 リリースノート はコメントを受け付けていません -->

保護中: DBMoto 9.0.3.7 リリースノート

このコンテンツはパスワードで保護されています。閲覧するには以下にパスワードを入力してください。

保護中: DBMoto 9.0.3.7 リリースノート はコメントを受け付けていません -->

Netezza (現IBM PureData System) DWH&分析アプライアンスをサポート追加【リアルタイムレプリケーションツールDBMoto】

DBMoto7ではNetezza DWH&分析アプライアンス(TwinFin)を正式にサポートします。
レプリケーションモードは、Netezzaへのミラーリング、及びNetezzaからのリフレッシュに対応しております。これにより他のデータベースからNetezzaへのリアルタイムなレプリケーションが可能になりました。さらにDBMotoからNetezzaにデータを高速に転送するための機能が組み込まれています。(NetezzaはIBM PureData Systemに名称が変わっています。)

▼前提条件

あらかじめDBMoto専用マシンに、Netezza ODBCをインストールしておく必要があります。

▼DBMotoコネクション設定例

DBはNetezzaを選択します。

赤い箇所をクリックすると・・・

Netezza ODBCドライバの設定画面が開きますので、必要な接続情報を設定し、「Test Connection」を押下して接続に問題がないことを確認します。

日本語データを扱う場合はDriver Optionsタブの「Optimize for ASCII character set」にはチェックを入れないようにします。

▼DBMotoのCreateウィザードを使用してNetezzaにテーブルを作成する場合の注意点

・Primary Keyが設定されないため、DBMotoからSet Primary Keyする必要があります。

・日本語データを扱うフィールドは必ず「NVARCHAR」にする必要があります。

タグ: ,

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

DBMotoで使用するPostgreSQLユーザに必要な権限は下記の通りです。
ユーザ名を「dbmoto」とした場合の例となります。

●ターゲット:初期リフレッシュ+ミラーリング

>GRANT SELECT, UPDATE, INSERT, DELETE, TRUNCATE ON <スキーマ>.<テーブル> TO dbmoto;

●ターゲット:リフレッシュのみ

>GRANT SELECT, INSERT, TRUNCATE ON <スキーマ>.<テーブル> TO dbmoto;

●ソース:リフレッシュのみ

>GRANT SELECT ON <スキーマ>.<テーブル> TO dbmoto;

●ソース:ミラーリング

>ALTER ROLE dbmoto WITH SUPERUSER;
他WALログの設定変更など、詳細はこちら

●ターゲットでテーブル作成を行う場合のみ必要(任意)

>GRANT CREATE ON SCHEMA <スキーマ> TO dbmoto;

コメントする -->