SQL Server、PostgreSQL、Oracleの災害対策・dr対策ならDbvisit
株式会社コーソル
この製品について
■Dbvisit Standbyとは
Dbvisit Standbyは、Oracle Database SE (SE1、SE、SE2) 、SQL Server (Standard、WEB、Personal、Express) 、PostgreSQLの為に作られた、遠隔地とのDBデータ同期 (ディザスタリカバリ／災害対策) ソリューションです。 Dbvisit Standbyを構成した環境では、データセンター障害、クラウド障害などの障害が発生してもコンソール上から数クリック、数分で同期先データベースが利用できるようになります。 ハードウェア障害やネットワーク障害、災害による拠点障害、クラウド障害など、障害はある日突然発生します。 障害がが発生すると、長時間にわたってサービスや業務が利用できず、企業にとって大きなマイナスとなってしまいます。 これらの障害に備えるには遠隔地にBCP (事業継続計画) サイトを準備し、メインサイト-BCPサイト間でデータを定期的に同期する仕組みも必要です。 Dbvisit Standbyを利用すると、メインサイト-BCPサイト間のデータ同期を安全・確実・簡単 に行うことができます。 操作はブラウザベースの管理コンソールから実施しますので、非常に簡単です。 メインサイトに障害が発生してメインサイトが復旧できない場合には、Dbvisitの管理コンソールからフェイルオーバー操作(災対側データベースをアプリケーションから利用できる状態にする操作)を行うことで、 数分で災対側データベースが利用できる状態になります。■Dbvisit Standbyを使うとこのような 課題を解決
・Dbvisit Standbyでは Standby Expressと同等以上の機能を提供しています ので、安心してStandby Expressの代替製品としてご利用いただけます。 ・Dbvisit StandbyではData Guardと同様のアーキテクチャを利用、かつOracle Database SE2で利用可能です。 ・BCPサイトはメインサイトと同一であり、メインサイトのバックアップという位置づけです。 ・Oracle Database Enterprise Edition Data GuardをOracle Database Standard Edition2 + Dbvisit Standbyに置き換えることで最大72%のコスト削減が可能です。 ・Dbvisit Standbyを使うとメインサイトで障害が起きても、コンソール上から たった 4クリックでBCPサイトに切り替えることができます。 ・クラウド環境でのリージョン間データ同期にもご利用いただけます。■導入実績
全世界：120ヵ国以上、1650以上の販売実績 コーソル：90本以上の販売実績■システム要件
対応OS Windows：Windows Server 2012 ～ Windows Server 2022 (64bitのみ) Linux：Oracle Linux6～9、Redhat Enterprise Linux6～9、SUSE Linux11～15*1、Rocy Linux8～9*2、CentOS6～7*2、Fedora*2、Ubuntu *1：Oracle / MS SQL Serverのみ *2：PostgreSQLのみ 対応DB Oracle Database：10gR2(10.2.0.5)以降のバージョン MS SQL Server：SQL Server 2012～SQL Server 2019 PostreSQL：10～16 ※詳細なシステム要件はお問い合わせください。-
シリーズ
SQL Server、PostgreSQL、Oracleの災害対策・dr対策ならDbvisit
-
取扱企業
株式会社コーソル
-
カテゴリ
-
利用シーン
医療業界用 / 製薬・医薬品業界用 / 自動車・輸送用機器業界用
作業支援注目ランキング
もっと見る
作業支援の製品116点中、注目ランキング上位6点
電話番号不要
何社からも電話が来る心配はありません
まとめて見積もり
複数社に同じ内容の記入は不要です
返答率96%以上
96%以上の方が返答を受け取っています
作業支援注目ランキング (対応の早い企業)
平均返答時間が24時間以内の企業の中での注目ランキング
電話番号不要
何社からも電話が来る心配はありません
まとめて見積もり
複数社に同じ内容の記入は不要です
返答率96%以上
96%以上の方が返答を受け取っています
SQL Server、PostgreSQL、Oracleの災害対策・dr対策ならDbvisit 品番3件
各品番毎の詳細は品番をクリックしてください
| まとめて問合せ・見積 | 商品画像 | 品番 | 価格 (税抜) | CPU単位 | 契約年数 |
|---|---|---|---|---|---|
|
|
Dbvisit Standby Basic |
要見積もり | 1～6 | 1年 / 3年 / 5年 | |
|
|
Dbvisit Standby Extended |
要見積もり | 7～9 | 1年 / 3年 / 5年 | |
|
|
Dbvisit Standby Unlimited |
要見積もり | 10以上 | 1年 / 3年 / 5年 |
のついている項目名や値は、Metoreeの自然言語処理アルゴリズムを用いて自動生成された値です。各メーカーの製品を横断して比較しやすくするための参考としてご利用ください。自動生成データは黒色の文字、元データは灰色の文字です。
よくあるご質問 (FAQ)
質問
Dbvisit Standbyはどのようなアーキテクチャなのですか？
回答
[Oracle Database]
標準機能のバックアップ／リカバリおよび基本スタンバイをベースにしたアーキテクチャです。
具体的には、メインサイトにある本番系Oracleデータベース（プライマリDB）が出力したアーカイブログファイルを、遠隔地（スタンバイサイト）の待機系Oracleデータベース（スタンバイDB）に転送および適用することで、プライマリDBに適用された変更をスタンバイDBに随時反映します。
なお、アーカイブログファイルには、プライマリDBに加えられたすべての物理的な変更が記録されているため、プライマリDBとスタンバイDBを物理的に同一な状態に維持できます。
[SQL Server]
標準機能のログ配布をベースにしたアーキテクチャです。
SSMSを利用してログ配布を構成する場合でも非常に多くの作業ステップを経なければなりませんが、Dbvisit Standbyを利用すると、画面上で選択とクリックを中心とした操作で非常に簡単にスタンバイDBを作成可能です。
[PostgreSQL]
標準機能のWAL streaming、WAL file archiving、WAL file shippingを利用したアーキテクチャが選択可能です。
PostgreSQLでレプリケーションを構成する場合、構成するアーキテクチャによって操作が異なりますし、作業ステップもそれなりにありますが、Dbvisit Standbyを利用すると、画面上で選択とクリックを中心とした操作で非常に簡単にスタンバイDBを作成可能です。
質問
Dbvisit Standbyの実績を教えてください。
回答
世界120ヵ国以上、1500以上の導入実績があります。
質問
Dbvisit Standbyのライセンス体系を教えてください。
回答
Dbvisit Standbyはサブスクリプションライセンスです。
サブスクリプション価格には製品使用権、製品サポートの権利が含まれます。
サブスクリプションライセンスは3つあり、メインサイトとスタンバイサイトの搭載CPU合計数によって変化します。
・CPU合計数 1～6 ：Dbvisit Standby Basic
・CPU合計数 7～9 ：Dbvisit Standby Extended
・CPU合計数 10以上：Dbvisit Standby Unlimited
あくまでCPUの数が対象であり、CPUのコア数はいくつでも影響しません。
また、Dbvisitでの同期対象DB数が複数あった場合でもライセンスや価格に影響いたしません。
詳しくはDbvisit Standbyライセンスページ 02.ライセンスをご参照ください。
https://cosol.jp/license/dbvisit/
質問
メインサイトとスタンバイサイトでOSバージョン違いはサポートされますか？
回答
利用しているOracle Database、Dbvisit Standby双方で利用している(予定の)バージョンが動作保証しているOSならどの組み合わせ(RHEL6～RHEL9など)でもサポートされます。
質問
サービスを停止させずにDbvisit Standbyの導入はできますか？
回答
一部の要件を満たしていれば、メインサイトでのサービスを停止させずに導入可能です。
一部の要件とは、メインサイトのデータベースがアーカイブログモードであることです。
質問
管理コンソールは日本語対応していますか？
回答
管理コンソールはDbvisit Standby Ver9以降から多言語対応しており、日本語にも対応しています。
質問
メインサイト/スタンバイサイト間の同期間隔（変更の伝搬間隔）は調整できますか？
回答
Dbvisit Standbyのパラメータで同期間隔（変更の伝搬間隔）を調整できます。
最小同期間隔は60秒、秒単位で設定可能す。
同期間隔を小さくするとプライマリDBに与える負荷が高くなるため、極端に短い時間に設定することはお勧めできません。
弊社案件の多くでは、600秒を設定しています。
質問
スイッチオーバーとは何ですか？
回答
スイッチオーバーとは、本番系データベース（プライマリDB）が動作するサーバを切り替えることです。
スイッチオーバーを実行すると、スタンバイサイトの待機系データベース（スタンバイDB）が本番系データベース（プライマリDB）に昇格し、メインサイトのプライマリDBが新しいスタンバイDBになります。
なお、スイッチオーバー実行するためには、正常にDbvisit Standbyの同期が行われている必要があります。
スイッチオーバーの特徴は以下の通りです。
・スイッチオーバーの実行中はデータベースにアクセスできません。
・スイッチオーバーに伴う更新のロスはありません。スイッチオーバーの実行中はデータベースにアクセスできないため、更新を実行することができませんが、スイッチオーバー前後で正常終了した処理による更新は失われません。
・スイッチオーバーの実行後、アプリケーションの接続先データベースを変更する必要があります。
質問
フェイルオーバーとは何ですか？
回答
フェイルオーバーとは、何らかの障害により本番系データベース（プライマリDB）の継続使用が難しい場合に、スタンバイサイトの待機系データベース（スタンバイDB）を新しいプライマリDBに強制的に昇格させることです。
フェイルオーバーの特徴は以下の通りです。
・スタンバイDBのプライマリDBへの昇格は強制的に実行されるため、フェイルオーバーは短時間で実行できます。
・フェイルオーバーを実行すると更新ロスが発生する可能性があります。Dbvisit Standbyではアーカイブログファイルを用いて、ファイル単位でプライマリDBの変更をスタンバイDBに伝搬します。このため、プライマリDBに加えられた変更がまだアーカイブログファイルとして出力されていない場合は、更新が失われます。しかし、アーカイブログファイルの出力間隔を小さくするように、Dbvisit Stanbyを設定することで、障害発生時に失われる更新の量を減らすことができます。
・フェイルオーバーの実行後、アプリケーションの接続先データベースを新プライマリDB（旧スタンバイDB）へ変更する必要があります。
質問
スイッチオーバー、フェイルオーバーに必要な時間はどれくらいですか？
回答
フェイルオーバーは1分～3分程度、スイッチオーバーは5分～10分程度の時間を要します。
※記載の時間は参考値であり、必ずこの時間を保証するものではございません。
環境、構成により時間が前後する場合がございます。
質問
本番データを開発環境にコピーする用途でDbvisit Standbyを使えますか？
回答
Dbvisit StandbyはスタンバイDBまたはスナップショットを読み取り専用モードまたは読み書き可能モードでOPENできますので、これにより本番データを開発環境へコピーすることが可能です。ただし、本番環境と開発環境のネットワーク通信が可能である必要があります。
なお、1つの本番系データベースに対して複数のスタンバイDBを作成できます。
また、スタンバイDBからさらにスタンバイDBを作成することもできます。
質問
障害発生時、自動でフェイルオーバーさせることはできますか？
回答
Dbvisit Standby Ver9から自動フェイルオーバー機能が実装されています。
自動フェイルオーバー機能を利用すると、管理者のオペレーションを必要とせず、メインサイトに障害が発生した場合には自動でフェイルオーバーが実行され、スタンバイサイトの待機系データベースが強制的に本番系データベースに昇格されます。
質問
Dbvisit Standbyを導入／実装するサービスはありますか？
回答
弊社ではDbvisit Standby導入／実装サービスとして、Dbvisit環境構築サービスを用意しています。
サービスの詳細は以下をご参照ください。
https://cosol.jp/service/service009/
