全てのカテゴリ
閲覧履歴
シリーズ
SQL Server、PostgreSQL、Oracleの災害対策・dr対策ならDbvisit取扱企業
株式会社コーソルカテゴリ
利用シーン
医療業界用 / 製薬・医薬品業界用 / 自動車・輸送用機器業界用もっと見る
作業支援の製品220点中、注目ランキング上位6点
電話番号不要
何社からも電話が来る心配はありません
一括見積もり
複数社に同じ内容の記入は不要です
返答率96%
96%以上の方が返答を受け取っています
平均返答時間が24時間以内の企業の中での注目ランキング
電話番号不要
何社からも電話が来る心配はありません
一括見積もり
複数社に同じ内容の記入は不要です
返答率96%
96%以上の方が返答を受け取っています
| 商品画像 | 品番 | 価格 (税抜) | CPU単位 | 契約年数 | |
|---|---|---|---|---|---|
|
|
Dbvisit Standby Basic |
要見積もり |
1～6 |
1年 / 3年 / 5年 |
|
|
|
Dbvisit Standby Extended |
要見積もり |
7～9 |
1年 / 3年 / 5年 |
|
|
|
Dbvisit Standby Unlimited |
要見積もり |
10以上 |
1年 / 3年 / 5年 |
質問
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/
