技術ブログ
目次
Oracle ACEの渡部です。Dbvisit Softwareのサイトに "Scripting vs Dbvisit Standby"という面白い文書がありました。カスタムスクリプト（自作スクリプト）を用いた基本スタンバイの管理・運用とDbvisit Standbyを用いた基本スタンバイの運用を比較した内容です。 Dbvisit Standbyに関するFAQとしても使える内容だったため、質問と回答の骨子のみネタを拝借して、これを下敷きに渡部の考えを書いてみたいと思います。
なお、一部、意味や意図を取りにくい記載については省略しています。
"Scripting vs Dbvisit Standby"には、
We can script this ourselves, can't we?
という疑問が記載されています。私なりに意訳すると、「カスタムスクリプトなら作れそうだけど？」という意味になりますでしょうか。
この疑問に対するDbvisit Softwareの見解は、 "Scripting vs Dbvisit Standby"に記載されている通りですが、これを下敷きに渡部の考えを書いてみます。
Dbvisitが基礎とする技術はOracle Databaseが持つ基本スタンバイ機能です。 逆に言うと、基本スタンバイ機能を使うカスタムスクリプトを作成すれば、Dbvisitのような高可用構成を実現することができます。
しかし、これは一見良いアイディアに見えますが、実際にやってみるとイバラの道です。 ひととおり動作するカスタムスクリプトを作成するのは比較的簡単ですが、 Bugを完全に除去すること、運用を続ける中で遭遇する様々な例外ケースに対応させるには多くの工数がかかります。
これらに、優秀なエンジニアの工数を割くことはあまり生産的な取り組みとは言えません。 Dbvisitという実積のある安定したソフトウェアがあるのですから、これを有効に活用するのが賢い方法です。確かにキャッシュアウト／費用の支払いは発生しますが、優秀なエンジニアはより困難な問題への対処に時間を割くべきだと思います。
Our DBA is looking at another position in another city!
同様に意訳すると、「スクリプトを作ったエンジニアが退職しちゃったけど、どうすればいい？」となるでしょうか。
基本スタンバイに限った話ではありませんが、内製ツールを長期的に面倒をみることはとても大変です。開発者が自社の社員でない場合、その人に長期的に面倒みてもらうことは不可能ですし、 開発者が自社社員であったとしても、ずっと同じ部署にいてくれる保証はありません。
Dbvisitを使用する場合は製品サポートを使えますから、このような心配はありません。 また、Dbvisitのドキュメントやナレッジベースはかなり充実しています。
How will my scripts tell me that the standby database and the refresh process worked flawlessly every time?
DbvisitにはWebベースの管理コンソールとメール通知機能があるため、容易に処理状況を確認できます。
We have to remember to script in the capture and inclusion of every possible table and structure addition, change, etc. to the primary.
プライマリDBにデータファイルや表領域を追加した場合、Dbvisitは自動的にスタンバイDBにそれらを追加してくれます。
Our data structures are very complicated; only our own people know it from end to end.
この疑問は、物理レプリケーション（フィジカルレプリケーション）とロジカルレプリケーションを混同しているために出るものだと考えます。
Dbvisitは基本スタンバイ機能を基礎としています。基本スタンバイ機能は物理レプリケーションに分類されるレプリケーション方法で、プライマリDBと物理的に同一のスタンバイDBを作るものです。
物理レプリケーションでは、データベースの物理的な側面だけを考慮してレプリケーションを行うため、データベースの「中身」であるところの、データベース内のデータ構造の影響は受けません。
なお、ロジカルレプリケーション（論理レプリケーション）の場合、データベース内のデータ構造の影響を受けます。
ただし、繰り返しになりますが、Dbvisitは物理レプリケーションを使いますから、データベース内のデータ構造の影響は受けません。
How hard is it going to be to build and maintain the standby instance(s) in our ASM environment on RAC?
DbvisitはRACに対応しています。もちろん、ASMを使用したRACにも対応しています。
補足ですが、Standard Edition RACはASM必須です。すなわち、DbvisitはStandard Edition RACに対応しています。
We have BIG DATA. What are we going to do to keep our data pipes from getting clogged with the network traffic supporting the refresh of the standby instance?
Dbvisitが基礎とするOracle Databaseの基本スタンバイ機能では、アーカイブログファイルの転送および適用により、プライマリDBからスタンバイDBに変更を伝搬します。
Dbvisitは独自の圧縮アルゴリズムを用いて、アーカイブログファイルのネットワーク転送量を70%以上削減することができます。これにより大幅にネットワーク負荷を削減できます。
なお、アーカイブログファイルのネットワーク転送量に影響するのはデータの変更量であり、データベース全体のサイズではありません。 データベース全体のサイズが大きい場合でも、データの変更量が少なければ、アーカイブログファイルのネットワーク転送量は小さく済みます。
I’m very concerned about data security.
Dbvisitはネットワーク通信を暗号化します。独自の暗号化アルゴリズムとSSHの両方に対応しています。
Our corporate IT standards call for complete documentation of all mission critical systems, and particularly those touching corporate data.
確かに、自作スクリプトだと、ドキュメント化（や引継ぎ、メンテナンス）は悩みのタネですね。 Dbvisitはマニュアルが充実しているため、問題にならないと考えます。
We are required to perform “live” failover drills every 6 months. How am I going to set that up and report on it, in addition to everything else I have to do?
原文では、
“live” failover drills
として"failover"という用語が使われていますが、文意的に「計画的な災害対応リハーサルの実行」と捉えて、Dbvisitの機能としてはスイッチオーバーのことと捉えるべきでしょう。
DbvisitはWeb管理コンソールから簡単にスイッチオーバーを実行できます。 スイッチオーバーの実行状況もWeb管理コンソールから逐一確認できます。
What are we going to do when we need to upgrade our version of Oracle to the next release? What happens to our scripts? How can we be sure they'll work the way we programmed them for the older version?
DbvisitはサポートされるOracle Databaseのバージョンであれば、 バージョンアップしても対応可能です。
最新のOracle Databaseにバージョンアップする場合でも、 その最新のOracle Databaseに対応するDbvisitにバージョンアップすればOKです。
Dbvisitは原則的にすべてのOracle Databaseのバージョンに対応しています。（対応まで若干のタイムラグはありますが） また、Dbvisitのバージョンアップは非常に簡単です。
Dbvisitを使わずに基本スタンバイを使用する際の手順については、以下のエントリに記載しています。
カスタムスクリプトを作成する場合、ここに書かれた処理を実装することになります。 ただし、実運用に使えるレベルにするには様々な例外ケースにも対応する必要があり、簡単ではないのはすでに説明した通りです。 また、文書化や引継ぎ、メンテナンスやBug対応、トラブル発生時の対処を考えると、かけただけのコストがペイできるかは微妙なところだと思います。
個人的には、信頼できる製品がすでに存在する技術分野においては、うまく製品を活用し、かかる労力を削減して、空いた時間を別のより高度なことや、やるべきではあるけれども後回しになっていた改善タスクに労力をかけるべきだと考えます。
Dbvisit Standby は歴史が長く、全世界および日本での導入実績も多数ある製品です。 安心してご利用いただけます。
2021年5月時点で、国内での最新バージョンは 9.0.20 ですが、近日中に新バージョン 10のリリースが予定されています。
バージョン10の主な新機能は以下の通りです。
コーソルはDbvisit Standbyの一次代理店で、Dbvisit Standbyの製品販売を行います。 加えて、Dbvisitの導入およびサポートを行います。
コーソルでは、Dbvisitを用いたOracle Standard Edition向け災害対策環境構築サービスを提供しています。
SIer様、販社様がDbvisit Standbyを販売することも可能です。
コーソルからDbvisit Standbyを購入いただけると、認定資格Dbvisit Standby Certified Associate取得者数12名、ORACLE MASTER Platinum 単年取得者数7年連続No.1(2014年度～2020年度)という指標に裏付けされた高い技術力により責任もって製品を導入いたします。また、導入後も品質の高い製品サポートをご提供いたします。
総勢12名のエンジニアが認定資格Dbvisit Standby Certified Associateを取得
Dbvisitに関わる総勢12名のエンジニアが認定資格Dbvisit Standby Certified Associateを取得しました！
Dbvisitに関する技術的な知見をセミナーおよび技術ブログで発信
Oracle AWS移行セミナー Dbvisit on EC2セッション骨子（2020年7月22日実施）
3/11開催SIOS社共催Oracle SEHA+Dbvisitセミナーのお知らせ
3/3(水) お昼のDbvisit + Insight Qubeウェビナーのお知らせ
11/10-12 db tech showcase コーソル担当セッションのご紹介 #dbts2020
Dbvisit関連ブログ記事を多数公開
Dbvisit Standby Snapshot Option – Dbvisit 9新機能
Dbvisitとカスタムスクリプトによる基本スタンバイ管理・運用の比較
Dbvisit : スイッチオーバーとフェイルオーバーの比較
スタンバイDBを再作成せずにStandby ExpressからDbvisit Standbyへ変更する方法
Oracle ASM RACからシングル構成のスタンバイDBを作成する – Dbvisit
REDO欠落時のブロック破損時のスタンバイDB再作成を回避する / Dbvisitの同期機能
Dbvisit Standbyのアーキクチャと管理コンソール操作
Oracle Database基本スタンバイの各種手順（スタンバイDB構築、ログ転送→適用、スイッチオーバー、フェイルオーバー）
Oracle Database Standard Editionの拠点災害対策ソリューションとは （基本スタンバイとDbvisit）
7年連続ORACLE MASTER Platinum取得者数No.1！ Oracle Certification Award 2020
Dbvisit Standbyと併せて使用される、Oracle Databaseについても製品販売、製品サポート、製品の導入を行います。また、リモート回線経由でスポット的なDBA実務を行うリモートDBAサービス、コンサルティングやベンダコントロールを含めたOracle Databaseプロフェッショナルサービスを時間制で提供する時間制DBAサービスも提供しています。
非常駐型データベース運用サービス
プロフィール
渡部 亮太
・Oracle ACE
・AWS Certified Solutions Architect - Associate
・ORACLE MASTER Platinum Oracle Database 11g, 12c 他多数
カテゴリー
アーカイブ
2024年
2023年
2022年
2021年
2020年
2019年
2018年
2017年
2016年
2015年
2014年
2013年
2012年
2000年