株式会社コーソル

コーソルDatabaseエンジニアのブログ

技術ブログ

Dbvisitとカスタムスクリプトによる基本スタンバイ管理・運用の比較

Dbvisitとカスタムスクリプトによる基本スタンバイ管理・運用の比較

渡部です。Dbvisit Softwareのサイトに "Scripting vs Dbvisit Standby"という面白い文書がありました。カスタムスクリプト(自作スクリプト)を用いた基本スタンバイの管理・運用とDbvisit Standbyを用いた基本スタンバイの運用を比較した内容です。 Dbvisit Standbyに関するFAQとしても使える内容だったため、質問と回答の骨子のみネタを拝借して、これを下敷きに渡部の考えを書いてみたいと思います。

なお、一部、意味や意図を取りにくい記載については省略しています。

Scripting vs Dbvisit Standby

カスタムスクリプトなら作れそうだけど?

"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ベースの管理コンソールとメール通知機能があるため、容易に処理状況を確認できます。

プライマリDBの構成変更に追従してくれるか?

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にそれらを追加してくれます。

データ構造が複雑でもOKか?

Our data structures are very complicated; only our own people know it from end to end.

この疑問は、物理レプリケーション(フィジカルレプリケーション)とロジカルレプリケーションを混同しているために出るものだと考えます。

Dbvisitは基本スタンバイ機能を基礎としています。基本スタンバイ機能は物理レプリケーションに分類されるレプリケーション方法で、プライマリDBと物理的に同一のスタンバイDBを作るものです。

物理レプリケーションでは、データベースの物理的な側面だけを考慮してレプリケーションを行うため、データベースの「中身」であるところの、データベース内のデータ構造の影響は受けません。

なお、ロジカルレプリケーション(論理レプリケーション)の場合、データベース内のデータ構造の影響を受けます。

ただし、繰り返しになりますが、Dbvisitは物理レプリケーションを使いますから、データベース内のデータ構造の影響は受けません。

ASM RACへの導入は難しい?

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管理コンソールから逐一確認できます。

Oracle Databaseのバージョンアップにはどうやって対応すればよいか?

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の販売および設計、導入、製品サポートを行っています。Dbvisit Standbyをご検討の際はぜひコーソルにお声がけください。

プロフィール

On7tWW6m1Ul4

渡部 亮太

・Oracle ACE
・AWS Certified Solutions Architect - Associate
・ORACLE MASTER Platinum Oracle Database 11g, 12c 他多数

68LD3LWce1j8

守田 典男

・新しもの好きな Oracle Fighter。
・保有資格 : ORACLE MASTER Platinum Oracle Database 11g, 12c 他多数

カテゴリー

アーカイブ