Oracle RAC One Node環境を構成してみました ステップ1 Oracle Linux環境の導入

Oracle RAC One nodeとは、名前の通りアクティブなノードは常に単一ですが、稼働中のノードで障害が発生した場合には、自動的にスタンバイ側のノードで起動されるという、Oracleの高可用性な運用を行うことができるソリューションとなります。

そして、異種データベース間をほぼリアルタイムにレプリケーション可能なソフトウェアSyniti Data Replicationは、Oracle RAC One Node 環境にも対応しており、AS/400(IBM for i)SQL Serverといったデータベースはもちろん、Amazon RDSAzure SQLといったクラウドデータベース環境とのデータ連携や移行目的としても活用できます。

  

今回は、実際にOracle RAC One node環境を構築し、Synitiでどのように連携できるかまでを試してみようと思います。
本ブログではステップ1として、Oracle RAC One node環境構成のためのOracle Linux導入までをご紹介します。

ーーーーーーーーーーーーーーーーーーーーーーーーーー
▽Oracle RAC One node構成関連ブログ

 ステップ1:Oracle Linux環境の導入 ← 今回の記事
 ステップ2:Oracle Grid Infrastructureインストールの準備
 ステップ3:別Oracleノードの構成と共有ディスクの設定
 ステップ4:Oracle Grid Infrastructureの導入

 ステップ5:Oracle RAC One nodeデータベースの作成
ーーーーーーーーーーーーーーーーーーーーーーーーーー

  

1.今回の検証環境について

初めに今回構築するOracle RAC One nodeの全体構成について簡単にご紹介します。

各OracleノードはOracle Linux をインストールした2台のVMware vSphere上の仮想マシンとして構成することにしました。仮想マシンとして作成するため、共有ディスク領域はvSphereのマルチライター機能を使用します。

ネットワークはパブリックアクセス用として100のセグメントを、ノード間接続のためのプライベート(兼ASM)用として111のセグメントの2つを用意しています。
※100のセグメント(パブリック)用にIP6つ、111のセグメント(プライベート)用にIP2つを用意しておきます。

ディスク構成はOracleインストール領域としてローカルに1つずつ共有ディスクは、クラスタ管理領域(RAC)、データ領域(DATA)、Redoログ等の格納領域(RECO)の3つをそれぞれ構成することを想定しました。
※計200GB程度の空き容量があれば検証用としては十分実装できると思います。

 

2.各Oracleソフトウェアのダウンロード

まずは、必要な各Oracleソフトウェアをダウンロードします。今回はOracle Linux 7.9Oracle 19Cの組み合わせで構成したので、下記URLからダウンロードできる各種インストーラファイルを使用しました。
※Oracle 19Cのダウンロードには、Oracleアカウントを作成する必要があります。

●Oracle Linux 7.9インストーラのダウンロードURL
https://yum.oracle.com/oracle-linux-isos.html
ファイル名:OracleLinux-R7-U9-Server-x86_64-dvd.iso

 

●Oracle19c GridのダウンロードURL
https://www.oracle.com/jp/database/technologies/oracle19c-linux-downloads.html
ファイル名:LINUX.X64_193000_grid_home.zip

●Oracle19c DBのダウンロードURL
https://www.oracle.com/jp/database/technologies/oracle19c-linux-downloads.html
ファイル名:LINUX.X64_193000_db_home.zip

  

3.仮想マシン(Oracleノード)の作成

次に、Oracleノードとして利用する仮想マシンを作成します。最終的には2台構成となりますが、2台目の仮想マシンは後からクローンで作成するので、1台の仮想マシンにのみ導入/設定を行っていきます。

最初に上記URLよりダウンロードしたOracle Linux 7.9インストーラvSphereデータストアにアップロードしておきます。

アップロード完了後、Oracle Linuxをインストールするための新規仮想マシンを作成していきます。ゲストOSのタイプとして「Oracle Linux 7」を選択します。
※今回はvSphere7環境で作成していますが、Oracle Linux 7.9がサポ-トされている環境であれば、どのvSphereバージョンでも対応できると思います。

今回は下記のようなハードウェア設定としました。
CPU:2コア
メモリ:10GB
ディスク:50GB
ネットワーク1:100セグメント(パブリック)用のネットワーク
ネットワーク2:111セグメント(プライベート)用のネットワーク
CD/DVDドライブ:アップロードしたOracle Linuxインストーラを指定

  

4.Oracle Linuxのインストール

仮想マシンを起動することで、Oracle Linuxのインストールウィザードが表示されます。最初の画面では「日本語」を選択して進めます。

  

次のインストールの概要ステップで、「ソフトウェアの選択」をクリックし、「サーバ(GUI使用)」と「FTPサーバ」を選択します。
※後ほどFTPを使用してOracleインストーラなどを配置するためです。

  

元の画面に戻り「インストール先」を選択、表示されている「VMware Virtual disk」ディスクを選択します。
※パーティションは今回自動構成のままでインストールしています。ただ、Oracle Gridの要件上、可能であればSwapに8GB以上割り当てることを推奨します。

 

設定後、「インストールの開始」ボタンを押下することで、インストールプロセスが開始されます。本検証環境ではインストール完了までに10分程度かかりましたので、実行中に「Rootパスワード」を選択し、rootユーザのパスワードを指定しておきました。

  

インストール完了後は、再起動が促されますので、実行します。

再起動後、下記のような画面が開かれます。まずは「LICENSE INFORMATION」を選択し、ライセンス条項に同意します。

  

次に「ネットワークとホスト名」を選択し、パブリック用とプライベート用の双方のネットワークを有効化します。その後「設定」ボタンより双方のネットワークの自動接続も有効にしておきます。
※今回のテストではしばらく仮想マシンはDHCP設定のまま進めますが、ここでIPアドレスを明示指定しても問題ありません。

  

元の画面に戻り、「設定の完了」ボタンを押して先に進みます。その後は言語や位置情報、タイムゾーンの設定などを行いますが、基本的にはデフォルトのまま「次へ」を押下していきます、最後に任意のユーザを作成することでOracle Linuxのインストールは完了です。

  

最後にインストール完了後のGUI画面で、「アプリケーション」 > 「システムツール」>「ソフトウェアの更新」よりソフトウェアの更新をしておきます。
※これも10分程度かかりました。

 

次回のブログでは、Oracle Linuxで実施するOracle Gridインストールのための事前設定内容についてご紹介します。

参考ページ:https://docs.oracle.com/en/operating-systems/oracle-linux/7/install/#Oracle-Linux-7

タグ: , , ,

保護中: Syniti Replicate 10.3 リリースノート

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

コメントを読むにはパスワードを入力してください。 -->

SAP HANAデータベース管理者の仕事とはどのようなものか?

新しいシステムを立ち上げるとなると、やるべきことがたくさんあります。最初のシステムのインストールとデータのロードが終わったら、バックアップを取るべきです。このバックアップはデータベースに限らず、オペレーティング・システムも含めて行う必要があります。すべてが稼働したら、次にSAP HANAシステムの健全性を監視する必要があります。SAP HANA cockpitやSAP HANA Studioは、そのための優れたツールです。システムのステータス、アラート、使用状況を監視してください。特に、メモリとCPUが十分であることを確認することが重要です。SAP HANAといえども、リソースが不足すると遅くなります!

また、定期的なバックアップ(毎日のデータバックアップと完全自動のログバックアップ)をスケジュールし、それを検証します。信頼できるバックアップは、データの損失(そして評判の損失、仕事の損失など)に対する主要な防御ラインです。

SAP HANAはメモリベースですが、だからといってディスクのことを忘れていいわけではありません。SAP HANAには永続化レイヤーがあり、すべてのデータはディスク上のデータボリュームと呼ばれるデータファイルに保存されます。これらのデータボリュームがいっぱいになると、利用可能なストレージ容量が拡張されるまで、データベース上のデータボリュームが存在するファイルシステムがフリーズしてしまうため、監視する必要があります。

同様に、データベースのロギングに使用されるディスク容量も監視する必要があります。これには、ログボリュームのファイルシステムだけでなく、ログのバックアップが書き込まれる場所も含まれます。SAP HANAのログファイルシステムが一杯になると、ストレージを拡張するかログのバックアップを取るまでデータベースがフリーズします。

これらの作業に加え、SAP HANAデータベース管理者は利用ユーザ・グループをサポートします。ユーザの追加、削除、変更、権限の割り当てを行います。これは、セキュリティの責任者でもあるため重要です。そのために、データベースのトレースと監査を監視・管理することになります。

物事が計画通りに進まない場合の不測の事態を想定しておくことが重要です。そのために、できれば1年単位で、ディザスタリカバリの演習を計画し、テストします。高可用性は多くの組織で必須であり、実際に障害が発生した場合に従うべき手順は、通常は単純とは言い難いです。ソリューションを定期的にテストすることも強く推奨します。単に技術的に機能するかどうかを確認するだけでなく、ITチームの全員が災害時に何をすべきかを理解し、プレッシャーの中で自信を持って行動できるようにする必要があります。

パワーツールの選択

SAP HANAの管理者として、あなたはシステムを管理するための様々なツールを自由に使うことができます。少なくともSAP社の見解では、SAP HANA 2.0で選択すべきツールはSAP HANA cockpitです。これはSAP Fioriベースのグラフィカルなインターフェースで、SAP HANAのすべてではないが、ほとんどの側面を監視および管理ができます。cockpitの使用には慣れが必要です。特に管理者が中央で階層的に整理された複数レベルの機能メニュー(SAP HANAのcockpitにはない)という従来のモデルに従ったツールに慣れている場合です。必要なものがどこにあるのかが分かれば、安心して使い始められます。

グラフィカルな管理ツールの中で、SAP HANA cockpitの前身は、オープンソースのEclipseプラットフォームをベースとしたSAP HANA Studioです。SAP HANA Studioは現在も存在し、SAPもサポートしていますが、新しい機能は追加されておらず、いずれは非推奨となるでしょう。しかし、SAP HANA Studioは今でも広く使われており(SAP HANA cockpitがまだ同等の機能をすべて提供していないことを考えると、なくてはならないと考えて)、多くのデータベース管理者が使い続けるでしょう。

多くのSAP HANAデータベースは、SAP NetWeaver(ABAPおよびJava)およびSAP S/4HANAシステムで使用されています。SAP S/4HANA、SAP ERP、SAP CRMなどのABAPベースのシステムのコンテキストでは、データベース管理者は、SAP HANA cockpitやSAP HANA Studioのようなスタンドアロン管理ツールの代わりに、組み込みのDBAcockpit(トランザクションDBACOCKPIT)を使用することを選択することができます。

ベテランは古き良きコマンドラインを使います。SQL コマンドを入力して SAP HANA データベースを管理するのは面倒に思えるかもしれませんが、これがすべてを稼働させる機械に最も近づく方法です。グラフィカルツールは、シンプルなインターフェイスを提供することで、その多くを抽象化することを目的としており、高速で効率的ですが、システムがどのように動作するかを理解するのに役立つとは限りません。したがって、コマンドラインを完全に無視しないことを推奨します。SAP HANA cockpitとSAP HANA Studioは、SQLステートメント用の優れたインターフェイスを提供しています(両者では「SQLコンソール」と呼ばれています)。また、HDBSQLコマンドラインプログラムを使ってデータベースホスト上で直接作業することもできます。

タグ: , , ,

SAP HANAで空間(Spatial)データサイエンスを強化する仕組み

SAP HANAは大量のデータを扱うインメモリデータベースであることは知られています。
例えば、タスクを迅速かつ簡単に自動化するために使用できます。SAP HANAには強力な空間機能もあり、データサイエンス用途に最適であることは知られていないかもしれません。

このブログでは、SAP HANAが教育から運輸までの業界でどのように空間データサイエンスを強化しているかを探ります。

空間データサイエンスとは:

空間データサイエンスは、従来のデータサイエンスの手法を地理情報と統合し、現実世界に関する疑問に答えるものです。空間データサイエンティストは、位置情報と、それらが連携を持つ他のすべての情報との関係を理解することで、公衆衛生や交通から物流に至るまで、幅広い分野の問題を解決することができます。


近年、より安価なセンサーによって膨大な量の空間データを収集することが可能になり、機械学習のようなツールによってデータの可能性が最大限に引き出され始めています。この分野が成長を続けるにつれて、空間データサイエンスは私たちの生活や仕事の方法に大きな影響を与えるようになるかもしれません。

SAP HANAとは:

SAP HANAは、デジタル時代における企業のビジネス変革を支援するビジネスデータプラットフォームです。SAP HANAを使用することで、企業はリアルタイム分析を実行し、予測分析を使用してより良い意思決定を行うことができます。さらにSAP HANAは、企業が異なるプラットフォーム間でデータを安全かつ容易に接続する方法を提供します。

SAP HANAを使用することで、企業はより俊敏で効率的になります。これは、ソフトウェアにおける継続的テストのようなものだと考えてください。継続的テストとは何か?ソフトウェアが開発の各段階で迅速かつ自動的にテストされることです。つまり、ミスはできるだけ早く発見され、本番コードに反映されることはありません。

同様に、洗練されたリアルタイムのデータ・プラットフォームによって、企業はKPIを監視し、何かがうまくいっていないとわかったらすぐに軌道修正することができます。世界がますますデジタルトランスフォーメーションに向かう中、SAP HANAは時代の最先端を行く企業にとって不可欠なツールとなるでしょう。

SAP HANAは、オンライン分析処理(OLAP)とオンライントランザクション処理(OLTP)を組み合わせ、メモリ内の列ベースのテーブルにデータを格納するため、現在市場にある他のデータベース管理システムとは異なります。つまり、強力なアナリティクスと非常に高速なトランザクションを同じシステム上で実行できます。

なぜそれが重要なのか?
SAP HANAを使えば、企業は即座にデータを照会し、ほとんど遅延なく膨大な量のデータを分析し、リアルタイムのデータについて十分な情報に基づいた意思決定を行うことができるからです。

SAP HANAは2010年の登場以来、広く利用されています。しかし、単なるデータベースではありません。SAP HANAは、アプリケーションから要求されたデータを保存・取得できるデータベースサーバーとして機能するだけでなく、構造化・非構造化を問わず、あらゆる種類のデータに対して高度な検索、可視化、統合機能を提供します。

SAP HANAは、アプリケーションサーバーとして機能し、リアルタイムデータ、インメモリー処理、機械学習テクノロジーを利用することで、インテリジェントで洞察力に富んだアプリケーションの開発を支援します。これらの機能はオンサイトでもクラウドでも利用できるため、SAP HANAはあらゆるビジネスの要件に柔軟に対応できます。

データ分析のためのSAP HANAのツールには、以下のようなものがあります。

データ変換サービス:
データ変換サービスを使用すると、JSONからCSVへの変換など、形式を超えてデータを変換できます。また、データ変換サービスでは、新しいデータが入ってきたときに自動的に実行されるデータ変換タスクをスケジュールすることもできます。これにより、データがどのような形式で送られてきても、レポートを最新の状態に保つことができます。

データアクセスサービス:
データアクセスサービスを使ってSAP HANAのデータにアクセスできます。SQLクエリの構築と実行、データテーブルの閲覧、Microsoft Excelへのエクスポートなど、いくつかの機能が提供されています。これにより、SAP HANAの使用経験に関係なく、社内の誰もが必要なデータにアクセスできるようになります。

スマートデータ統合:
スマートデータ統合を使用して、複数の多様なソースからのデータをSAP HANAに取り込むことができます。それは、荷物の配送からサプライチェーンのデータ、音声分析を使ってマイニングされたデータまで、何でも可能です。スマートデータ統合により、データポイント間の接続を構築し、ビジネス上の意思決定に役立つ首尾一貫した洞察に合成することができます。

スマート・データ・クオリティ:
スマート・データ・クオリティを使用して、データを自動的にエンリッチすることができます。これにより、データをエンリッチするためのルールを作成し、品質レポートを参照して、データ品質に関する強調表示された問題に対処できます。

データサービス管理コンソール:
データサービス管理コンソールを使用して、SAP HANAのセットアップを管理できます。このコンソールは、セキュリティ設定の調整、ユーザーアカウントと権限の管理、システムのパフォーマンス監視などのルーチンワークを簡単に処理します。

SAP HANAによる空間データサイエンスの強化

これらの機能により、空間データ科学者は膨大な量のデータに対して全文検索や高度なファジー検索を実行できます。Esri GridやGeoTIFFのような空間データフォーマットのサポートが組み込まれており、SAP HANAのグラフデータ処理機能は、テキスト、予測、空間、ドキュメント(JSON)、従来のリレーショナルデータ構造と組み合わせることができます。

また、機械学習を利用して、ストリーミングデータを保存、照会、分析し、時系列での傾向を見つけることもできます。このデータは、時系列フォーマットのセンサー、産業機械、家庭内のスマート家電や配送車両のようなモノのインターネット(IoT)デバイスなど、どこからでも入手できます。

ビジネスインテリジェンス(BI)と分析ツールはSAP HANAを使用しているため、近接、距離、位置に関するクエリに対する迅速な回答を得ることができ、マップ、レポート、チャートで地理的に関連性のある詳細な洞察を作成できます。これらの統合により、チームが日常的に使用しているWebベースのコラボレーションツールと同様に、データ分析が容易になります。

これらの空間分析機能は、ビジネスにおける隠れた収益機会を特定するのに役立ちます。顧客やベンダーにターゲットを絞ったロケーション固有のオファーを提供し、エンゲージメントとリテンションを向上させ、対象ロケーションに関する洞察を即座に得ることで、クロスセルやアップセルの効果を高めることができます。また、ロケーション・インテリジェンスによって、製品、店舗、従業員、設備のパフォーマンスに関する重要な機会を特定することもできます。

SAP HANAは、さまざまな業界の空間データサイエンスを強化します。小売業では、オンライン顧客がどこにいるのかを簡単に把握し、その情報を使って新しい店舗が最も収益性の高い場所を可視化できます。援助や医療の分野では、プロバイダーは地方に広がる人口を調べ、限られたリソースをどのように配置するのが最適かを考えることができます。

また、輸送や物流では、企業は最も効率的なルートをマッピングし、顧客の所在地を利用して新しい倉庫や発送センターを配置することができる。配送を行うeコマース企業がコンタクトセンターでCCaaSを使用している場合、顧客サービスチームがそのデータにアクセスできるようになり、顧客に注文に関する最新情報を提供できるようになる。

空間データサイエンスにおけるSAP HANAの活用法

SAP HANAを使った空間データプロジェクトは、次のようなプロセスを踏むことになります。

準備:

地理空間データは、他の種類のデータと同様に、SAP HANAで保存したりアクセスしたりすることができます。地理空間データは、地理データを利用できるWebサービスやSAP HANAの空間モデルなど、さまざまなソースから取得できます。

データがSAP HANAモデルまたは外部のWebサービスから取得されると、SAP HANAはそれをJSONに変換し、列指向メモリに入力できるように準備します。そこから処理できるようになります。

強化:

生の空間データは、基本的な解釈がなければ意味がありません。そのデータをさらに処理する前に、車両や建物のような実世界のオブジェクトを表すものとして、データを相関させ、ラベル付けする必要があります。

各空間データセットには、点、線、多角形という同じ基本プロパティがあります。そしてSAP HANAは、線の交点や点の近接性、あるいはオブジェクト全体や関心領域が他のオブジェクトの中に含まれているかどうかといった要因に基づいて、これらを関連付けることができます。このような単純な計算によって、未加工のデータを意味のあるオブジェクトに変換し、さらに分析を開始することができます。

可視化と洞察の生成:

SAP HANAのリアルタイム機能は、可視化をその場で調整し、結果を即座に確認できることを意味します。これは、スプレッドシートに埋もれていたら気付かなかったかもしれない洞察を発見し、傾向を明確にするのに適しています。また、強力な可視化ツールにより、最終的なビジネスレポートやライブダッシュボードを、最適な形式で出力できます。

SAP HANAによる空間データサイエンスの強化

空間データサイエンスでは多くの場合、膨大な量のデータを使用します。SAP HANAのリアルタイム機能によって、そのデータにユーザがアクセスできるようになり、即座に可視化できます。センサーが年々安価になり、IoTデバイスがモバイルネットワーク上でも一般的になるにつれて、SAP HANAのような強力なコンピューティングと分析ツールを必要とする空間データサイエンスの需要はますます増えていくでしょう。

Syniti Data Replication を活用することで他のデータベースからSAP HANAにリアルタイムにデータをレプリケーションできます。これによりSAP HANAの活用方法が広がります。

タグ: , ,

データベースのトラブルシュートを加速化させる方法について

データは、企業にとってのレポーティングや分析に不可欠な基盤であり、データを保存するデータベースは、現在、ほとんどのビジネス・アプリケーションを駆動させ、情報を提供しています。したがって、データベースの問題に対するトラブルシューティングを加速化するために組織ができることは多くあります。実際、トラブルシューティングにかかる時間を節約することで、企業はより生産的で収益性の高い業務に投資することができます。継続的なデータベース・パフォーマンス・モニタリングは、トラブルシューティングのハードルを素早く乗り越え、本来の業務に戻ることを支援します。

データベース・パフォーマンス・モニタリングの真価

データベース・パフォーマンス・モニタリングは、組織がデータベース管理システムを最大限に活用するのに役立ちます。これは、MySQL、PostgreSQL、MongoDB、Amazon Auroraなどの広く使われているオープンソースデータベースに特に当てはまりますが、いずれも内蔵ツールやコンソールの実力、使いやすさ、自動化は聞きません。これらのプラットフォームのパフォーマンスを常に監視し、重要なデータへのアクセスを確保するためには、SaaS(Software as a Service)をホストとする強力なツールを導入するほうがはるかに優れています。

データベースの健全性とパフォーマンスを測定するために、よくできた汎用データベースパフォーマンスモニタリングツールを継続的に実行することで、組織はサービスの可用性と応答性を常に可視化することができます。分析機能を備えたデータベース・パフォーマンス・モニターは、過去の指標と現在の値を比較し、これらの値に意味を持たせて傾向を明らかにするため、管理者は現在の測定値が過去の平均値や典型的なベースラインに対してどのように積み上がっているかを評価することができます。

また、優れたデータベース性能監視ツールは、オンプレミス、クラウド、または複数のクラウドとオンプレミスの要素にまたがって実行されるハイブリッド実装など、あらゆる場所で組織のデータベースを監視しています。

データベースのトラブルの根本原因を特定し、対処するためには、時間が非常に重要です。幸いなことに、よくできたデータベース・パフォーマンス・モニターは、本番環境での解決を早めることができます。さらに、このようなツールは、データベースクエリやアプリケーションの開発にも役立ちます。DBAと開発者は、データベースパフォーマンスモニタリングツールを使用して、特定のクエリやデータベースアプリケーションを変更前と変更後で比較することができます。そのため、パフォーマンスやリソース消費の影響を綿密かつ注意深く測定することができます。これにより、最適化された効率的なデータベース設計、重要なデータへの容易で迅速なアクセス、そしてより良いアプリケーションをサポートします。

データベース中心のモニタリング

より深いレベルでは、包括的なデータベースパフォーマンスモニタは、詳細なデータベース監視を使用して、組織がデータベースの問題をトラブルシューティングし、診断することができます。このようなツールは、すでに自動生成されている内部データベースエンジンとOSのメトリクスを使用するため、継続的なデータベースアクティビティにほとんどオーバーヘッドを追加することはありません。さらに、クラウドネイティブのデータベースパフォーマンスモニタは、データの取得と分析に独自のリソースとストレージを使用するため、監視する資産に余分なパフォーマンスのオーバーヘッドを課すことなく、広く分散した本番およびテストデータベースを大規模に監視することができます。

データベースパフォーマンスモニタリングツールの出力は、データベース、ユーザーエクスペリエンス、ホストOSの観点からデータベースの健全性とパフォーマンスを即座に可視化すことができます。データベース性能監視ツールが幅広いオープンソースデータベースを扱える場合、データベースインスタンスがどこに存在しても(オンプレミスまたはクラウド)、この可視性を提供することができます。データベースパフォーマンスモニタは、過去のデータと現在のメトリクスにアクセスすることで、データベースの異常に素早く気づくことができます。これは、利用可能なメトリクス・データの継続的なストリームに現れるパフォーマンスやリソース消費の異常値に対して、平均的または傾向的なシステム動作を比較することによって行われます。

データベース・メトリクスの同じ履歴ビューは、成長および容量計画のための強力な基盤にもなります。このように、分析機能を内蔵したデータベース・パフォーマンス・モニタリング・ツールは、パフォーマンスと、コンピュート、ストレージ、およびネットワーキング・リソースに対する将来のニーズを分析することができます。また、データベース(およびアプリケーション)の移行を計画・監視して、最適な結果を導き出すこともできます。これは、コードの変更に有効なビフォーアフター(before and after)手法が、場所やホスティングの変更にも有効であるためです。

企業は、強力なデータベースパフォーマンスモニタを使用して、さまざまな状況下でコードの展開を追跡することができます。コードの変更がパフォーマンスに与える影響を個々のクエリのレベルで追跡し、特定のクエリの変更がデータベース環境の全体的なパフォーマンス、応答性、およびリソース消費にどのように影響するかを確認することができます。これらのツールは、商用SaaSや同様のアプリケーションにおける潜在的なボトルネックやクエリの問題についての情報を提供し、SaaSクライアントがサービスプロバイダーに提出することで対処できる具体的で実行可能な変更を提供することも可能です。

一般的に、データベースパフォーマンスモニタリングツールは、遅いデータベースクエリを素早く特定できるため、DBAと開発者は、その調査や最適化に集中することができます。実際、優れたデータベースパフォーマンスモニタは、チューニングアドバイスや最適化または改善のベストプラクティスリストを提供し、DBAが効率とリソース消費を改善する方法について有用な指針を得ることができます。時間、待ち時間、リソース消費などの基準によるトップ10リストは、リソースの不足によって必要以上に動作が遅くなるクエリの可能性を明らかにし、管理者に適切なプロビジョニング方法を伝えるのに役立ちます。

DBAと開発者は、個々のデータベースクエリをデータベース全体の活動の文脈に当てはめて、特定の変更がデータベース全体のパフォーマンスと能力に与える影響を観察することもできます。このように、優れたデータベース性能監視ツールは、データベースアプリケーションのランタイムスタックのすべての層にわたるトランザクションのグローバルビューにも結びつきます。これは、データベース、ネットワーク、データセンター、サービスプロバイダーの各スタッフの間で責任のなすりつけ合いを避けるための優れた方法であり、特に、すべてのチームが同じ方向を向いたときに容易に解決できる複雑な状況において有効です。

まとめ

データベースパフォーマンス監視ツールをお探しの場合、Database Performance Monitor (DPM)が前述のすべての機能をリーズナブルな価格で提供していることを思い出してください。

タグ: ,

データ・マネジメントの5つの罪

どの企業もさまざまな理由でデータを必要としていますが、あまりに多くのデータをため込むことは危険な習慣となります。データの過多は、平均的なITプロフェッショナルを溜め込み屋に変え、ROTとも呼ばれる冗長で、時代遅れで、些細な情報(Redundant, Outdated,  Trivial information)を取得しすぎることにつながります。ビッグデータへの欲望は魅力的ですが、企業が思っている以上にダメージが大きいなものとなっています。

欲望、大食漢、貪欲、怠け者、プライドという5つの罪は、セキュリティにとって大きな脅威となりうります。この5つの罪は、一個人が犯すものではなく、複数の異なる従業員が時間をかけて積み重ねていくものです。幸いなことに、企業文化の変化により、このような問題を回避することができます。それではそれら5つの罪を回避する方法について説明しましょう。


データマネジメントの5つの罪

欲望:ビッグデータへの強い欲求から、企業は画期的な発見を期待して多くのデータを集めてしまいます。しかし、大量のデータの中から重要なものを見つけることは、針のむしろのような状況になりかねません。

大食漢: データへの過度の依存や、目的もなくできる限り多くのデータを消費することは、満腹になってから食べることに匹敵します。アーカイブのプロセスがなければ、企業はより多くのデータに飢え、時代遅れの無駄なデータを溜め込んでしまうのが普通です。

貪欲:データをため込むのは、貪欲さがきっかけになることもあります。残念なことに、データを分類し、アーカイブし、削除するプロセスを見つけるよりも、消費するデータを処理し、保存するために最新のハードウェアをより多く購入することにつながるのが普通です。

怠け者: 怠け者は怠惰(だいだ)と同じ意味かもしれませんが、データ管理においては、大量のデータのためにクエリやプロセスが遅くなることを怠け者と呼びます。データ量が多ければ多いほど、データ処理やバックアップに時間がかかることがあります。

プライド: 企業は大量のデータを持つことで安心感を持つかもしれませんが、実はデータが蓄積されればされるほど、より多くの懸念が必要になります。大量のデータを持っていても、それが正しく使われなければ何の意味もなく、多くの企業が誤った安心感や誇りを持つことにつながります。

意図することを設定する

復旧時点目標(RPO)と復旧時間目標(RTO)を設定することが、この5つの罪を避けるための第一歩となります。RPOは、企業が復旧できなくなるまでのデータ損失の許容量を示し、RTOは、企業が危機的状況や回復不能な状態に陥ることなくデータを復旧するためにデータ専門家が必要とする時間を示します。データログのバックアップはRPOの延長に役立ちますが、大量のデータをバックアップすると、バックアップ時間が長くなり、全体としてバックアップの回数が減ってしまいます。目的を詳細に説明することで、チームに事業継続のための計画を与えることができます。

最初にリカバリーを計画する

リカバリープランをバックアッププランとは別物です。リカバリープランを先に作成し、バックアッププランはその後に作成する必要があります。バックアップ計画はRTOとRPOの目標に対応し、リカバリ計画はディザスタリカバリと高可用性の目標に対応します。ディザスタリカバリと高可用性は同じものではありません。

目的を持ってアーカイブする

データの余剰は、アーカイブ計画の失敗、またはその欠如を明確に示すことがあります。欲望、貪欲、大食漢は、不必要なデータの蓄積を増やし、本当の意味での方向性のないアーカイブ・プロセスを引き起こす可能性があります。管理可能な量の受信と処理を行うことで、データ専門家はより簡単に、目的を持ってデータをアーカイブすることができます。

セキュリティを最優先する

一見、後回しになりがちですが、データを保護するためには、セキュリティを第一に考えなければなりません。企業にとって必要なデータのみを保管することは、手元にある情報がより価値を持つことを意味し、何としてでも保護されるべきです。従業員の安全対策や日常業務など、社内のあらゆる場面でセキュリティのベストプラクティスを実践してください。データの盗難は、ハッカーによるものだけでなく、さまざまな形で発生する可能性があります。


構築と購入のどちらを選ぶか

信じられないかもしれませんが、お金ですべてが解決できるわけではありません。新しいハードウェアを購入することは良い解決策のように思えるかもしれませんが、それはあなたの会社が既存のリソースや他の解決策を十分に掘り下げていないことの表れかもしれません。データ問題の根源を知ることで、通常、豪華な(しかし不必要な)ハードウェアに費やされる時間と費用を節約することができるかもしれません。

タグ: , ,

データベース性能の低下がもたらす金銭的なものだけではない、その高いコストとは!

今日、企業にとってデータベースの性能にかかるコストとは何でしょうか?実際、ほとんどの経営者は、この質問に含まれるすべてのことを理解し始めるとは言えません。

筆者は、システムが経営者のやりたい仕事は速すぎるという理由で、私に連絡してきたことはありません。しかし、インデックスのチューニングと簡単なコードの変更で重要なボトルネックを取り除き、システムを壊したと非難されたことはあります(24時間以上かかっていた処理を1分未満で実行できるようにした)。

問題は、SQL Serverやその他のツールがパフォーマンス低下の原因となっていることを、殆どの経営者が知らないことです。では、データベースのパフォーマンス低下の実際のコストはどれくらいなのでしょうか?

コストといえば、金銭的な影響がまず思い浮かぶのは間違いないでしょう。しかし、データベースのパフォーマンス問題のコストは、金銭的な側面だけでは済まないことがあります。

データベースの設計によってパフォーマンスが制限され、その結果、新しい機能を実装する柔軟性が失われるとしたらどうでしょう。データ品質の低下やデータの重複による影響はどうでしょうか。パフォーマンスの問題が続くことで、ビジネスにとって最も重要な資産の一つである、絶え間ない消火訓練にうんざりしている社員が持つビジネス知識を失う危険性もあります。データベースのパフォーマンスは、クエリの実行にかかる時間をはるかに超えており、不十分な設計とアーキテクチャに内在する非効率のコストは、驚異的です。

データベース・パフォーマンスの低下によるコストの計算

これまで、筆者はシステムの可用性に関連するコストを定量化できる企業で働いたことが一度だけあります。コスト計算の基本は、顧客サービスのコールセンターへの影響を測定することでした。当然、ダウンタイムが発生すると、自動化されたシステムによるセルフサービスが利用できないため、コール数が増え、顧客の日常的な要望をサポートする機能が阻害されることになります。

しかし、この計算方法には、問題解決にかかる時間や、手作業のプロセスを維持するために失われる時間が考慮されていないことが問題でした。システムの脆弱性という総合的なコストは考慮されていなかったのです。

また、このシステムには本当の意味でのデータベース管理者がいませんでした。せいぜい「障害対応DBA」と呼ばれる、自分が一番上だからという理由で責任を負う人がいる程度だった。そのため、この会社のIT開発部門には、複数の負荷の高いプロセスが互いに影響し合ってシステムが停止することがないように、手作業でバランスを取るためだけの新しい役職が設けられました。

データベースパフォーマンスの低下の原因を特定する

では、何が問題だったのでしょうか。ハードウェアの性能が低いのか?ストレージの問題か?コードやデータベースの設計に問題があったのでしょうか?見方によっては、そうかもしれません。

SQL Server のパフォーマンスチューニングにおいて、インデックスが重要であるという貴重な教訓を早くから学んだのは、まさにこのシステムでした。これはSQL Server 6.5、そしてSQL Server 2000の頃の話ですが、データベースエンジンはインデックスの欠落のようなものを追跡することはありませんでした。以前は24時間もかかり、その間ずっとサーバのCPUは最大値でした(しかも、変更後の実行時にはCPU使用率がほとんど上がりませんでした)。

問題はすべてデータベースの設計にあったと言えるのでしょうか?そうとも言えるし、そうでないとも言えます。なぜ、その両方が同時に起こるのでしょうか?インデックスを持たない同じデータベースは、少なくともそれが再び問題となるまでに助長するには、今日のハードウェアではおそらく問題なかったでしょう。

インデックスなしでテーブル全体をスキャンするコストは、システム性能の最大の問題でした。請求項目、会計台帳、請求書履歴、ガス使用履歴テーブルなど、データベースの中で最も大きなテーブルに数個のインデックスを追加することで、システムに関連する頭痛の種は本質的にすべて解消されました。また、システムのプロセスが重なって問題が発生しないか、手動で監視する必要もなくなりました。当時のハードウェアは、既存の32ビットプラットフォームの制限と同様に、パフォーマンスに対する大きな制限となっていました。システムをどのように見るかによって、パフォーマンスの問題は、前述の可能性のどれかになっていたかもしれません。

データベース性能の低下がビジネスに与える真の影響を理解する

筆者の場合、インデックスが作成された結果、2つの興味深いことが起こりました:

1.システム性能の新しい基準ができた:システム・パフォーマンスに関する新しい基準ができたのです。今後行われるすべての変更は、この新しい基準に照らし合わせて、パフォーマンスへの影響、さらにはQAマネージャーが「停止」と判断した場合の1分あたりのコストまで、ベンチマークされることになりました。

2.開発者は、大きなテーブルを何度もスキャンする高いコストに追われるシステムを子守する代わりに、実開発ができるようになりました。開発者は、突発的なDBAの役割や消火活動に追われることなく、新しい機能に集中できるようになったのです。

このことは、ビジネスにとってどんな意味があったのでしょうか?つまり、規制緩和に伴い、新しいガスサービス市場を開拓し、顧客ベースを拡大することができたのです。また、規制緩和された市場で、当初のプロジェクト計画よりも1年早く電気サービスを開始することもできました。このようなパフォーマンスの問題を長期的に解決せず、成長に集中することなく、物事をうまく進めるために人々を忙しくさせることのコストを想像してみてください。

これは、データベースのパフォーマンスが金銭的な問題だけでなく、ビジネスに大きな影響を与えた例の1つです。ある会社では、開発者の離職率が非常に高かったのですが、その主な理由は、新入社員がコードを書くよりも監視に追われたり、問題のトラブルシューティングに追われたりすることでした。彼らの唯一の頼みの綱は、偶然居合わせたDBAを呼び寄せることでしたが、そのDBAもまた、辞めるに辞められない状態だったにもかかわらず、居座り続けていました。このようなパフォーマンスの問題が長く続くと、ビジネスにとって最も重要な資産の1つである、創業当時からの社員が持つビジネス見識を失う危険性がありました。データベースのパフォーマンス低下による新たな高コストが発生したのです。

ビジネス・ナレッジ:最も貴重なコスト

人という体は交換できても、ビジネスやプロセスについて知っていることは交換できません。クライアントの問題を解決するために別のコンサルタントを雇うことができるのは間違いありません。筆者がガス会社の仕事を辞めたとき、クライアントはビジネスに関する知識を大きく失うことになりました。筆者は、課金システムのおそらく4分の3の仕様を書き、さらに開発者としてその背後にある膨大な量のコードを書き換えていました。私は、「なぜ」そうなのかというビジネス知識をたくさん持っていたので、会社は私コンサルタントとして雇い直し、知識の移転、さらなるドキュメントの提供、コーディングの問題の解決に当たらせました。

このブログを読んでいる人の中には、パフォーマンスが常に争点となるシステムの中で、一貫して消火活動を行うことで生じる燃え尽き症候群に共感している人が絶対にいるはずです。しかし、私たちの仕事の性質上、私たちは一般的には山林火災対応部隊のようなもので、ホットスポットに飛び込み、他の人が戦い続けるための息抜きを作るようなものです。

 

データベースのパフォーマンス低下によるコスト負担は?

データベース・パフォーマンスの問題がビジネスにもたらすコストをご存知ですか?データベースのパフォーマンス問題に関連する高率の消火活動や燃え尽き症候群のために、従業員を失ったことがありますか?データベースのパフォーマンスがビジネスの成長を制限し、ライセンスやハードウェアのコストを長期にわたって段階的に増加させることについて、何らかの洞察が得られたらいいと思いませんか?

Database Performance Analyzer(DPA):監視・最適化ソリューションは、データベースの健全性についてより深い洞察を提供し、オンプレミスからクラウドまで、データベースがどこにあっても通常数分でパフォーマンスの問題を突き止めることができるように設計されています。

 

ある熟練データベース・コンサルタントの経験話から

タグ: ,

保護中: Syniti Replicate 10.xにおけるメタデータ取り扱いとメタデータ入れ替えについて

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

タグ:

MySQL トリガーベースのレプリケーションセットアップについて

Syniti(旧DBMoto)では、異種DB間で差分レコードを取得しレプリケーションするための方式として、大きく3つの方式をご用意しています。

今回は、MySQLでトリガー方式を利用する際の手順をご紹介します。
※ MySQL環境にて、シンクロナイゼーションモードを利用する場合、トリガー方式を利用する必要があります
※ MySQL環境においてバイナリログベースでレプリケーションする場合は、こちらの記事を参照してください。

手順としては、まずSynitiのソース/ターゲット接続に登録されたMySQL接続を右クリックし、トランザクションセットアップ > 有効化をクリックします。

トランザクションレプリケーションの有効化ウィザードが起動されるため、次へをクリックします。

トリガー方式を利用するため、Triggersのラジオボタンを選択し、次へをクリックします。

この画面では、トリガーのログテーブルに関する設定を行います。
マスターテーブル項目の右端のボタンをクリックし、どのスキーマにマスターテーブルを生成するか指定します。

この他、保持時間項目にてトリガーによってログテーブルへ書き込まれた変更レコードを保持する時間や、ブロック削除のサイズ項目にて、上記保持時間を経過した変更レコードを単一のSQLクエリで削除する最大単位を指定します。
保持時間については、ソーステーブルに発生するトランザクション量によって、必要に応じて増減させます。

次へをクリックします。

完了ボタンをクリックすることで、トリガーベースのトランザクションセットアップが完了します。

トリガーベースのトランザクションセットアップが完了した後、改めてMySQL接続を右クリック > トランザクションセットアップ > 管理をクリックすると、

トリガーベースのパラメータが確認でき、必要に応じて設定を編集も可能です。

タグ: , , , , ,

保護中: Syniti Replicate 10.2 リリースノート

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

コメントを読むにはパスワードを入力してください。 -->

多様な変更追跡で様々環境、要件に対応、Oracleトランザクションセットアップ[Syniti Data Replication]

Syniti DRではOracleデータベース上の変更を追跡するため複数のアプローチを提供しています。今回はこれらのアプローチに関して、それぞれを紹介していきます。

ログリーダー方式

もっとも古くから使用されている方式であり、構成としてもシンプルです。ソースとなるOracleデータベースサーバ上のログマイナーに対してSyniti DRのレプリケーションエージェントから直接クエリを実行し、REDOやアーカイブログ上のトランザクションログを参照、それをターゲットデータベースへレプリケーションします。



青色の矢印は、ソースから読み取り/送信するデータを表します。
灰色の矢印は、アプリケーションからターゲットに書き込むデータを表します。

シンプルであるため、構成しやすいというメリットがありますが、レプリケーションジョブまたはグループ単位でログマイナーにリクエストを行うため、対象のテーブル数が多い環境などでは、ログマイナーへのリクエストが過多となり、ソースデータベースからの変更トランザクション読み取りでボトルネックとなるケースもあります。

ログサーバエージェント方式

WindowsサービスとしてSyniti Data Replicationサーバ上で実行されるログサーバエージェントを使用して、Oracleログマイナーへクエリを実行、変更されたデータをSyniti Data Replicationサーバ上のバイナリログに記録します。それをレプリケーションエージェントが参照してターゲットデータベースへレプリケーションすることで、大量のデータを扱う際のパフォーマンスを向上させます。このオプションは、Oracleデータベースバージョン11以降でサポートされています。

ログリーダーでネックとなっていた、ログマイナーへのリクエストをログサーバエージェントに一本化し、調整することで、変更追跡を最適化した方式です。

ただし、Syniti DRサーバのローカルでバイナリログを保持しますので、その分の容量が必要になるといったデメリットもあります。また、バイナリログはレプリケーションエージェントから繰り返し参照されることになりますので、高速なSSDなどのストレージに配置いただく構成が推奨されます。

ログサーバエージェント+リモートログサーバ方式

リモートログサーバ(RLS)は、Oracleデータベースが存在するシステムにインストールし、ログファイルを直接読み取るためのJavaアプリケーションです。

Syniti DR ログサーバエージェントからの要求に応じて、RLSはredoおよびアーカイブログファイルから変更レコードを読み取り、それらをログサーバエージェントに返します。取得された情報はすべて返され、リモートログサーバ側に情報が保存されることはありません。RLSは、TCP/IPポートをリッスンし、接続を受け付けます。ログサーバエージェントはこのポートに接続し、RLSに対して変更されたレコードの読み取りを要求します。

ログマイナーの代わりにリモートログサーバがREDOまたはアーカイブログを直接参照するため、ログマイナーの利用を避けたい場合などに利用いただく方式です。

もっとも新しく追加されたものであり、リモートログサーバの構成は手動でOracleデータベースサーバ上にJavaアプリケーションを配置する必要があります。

構成を検討される際には、クライムまでお問い合わせください。

トリガー方式

Oracleデータベース上にSyniti DRから構成したトリガーを使用して、変更をログテーブルに記録します。レプリケーションエージェントはこのログテーブルを参照して、ターゲットデータベースへレプリケーションします。

データベーストリガーは、データベーステーブル上の特定のイベントに応答して自動的に実行されるコードです。トリガーベースのレプリケーション(ミラーリングまたはシンクロナイゼーション)を定義するには、レプリケーションのためにテーブルの変更を記録するトリガーを作成できるように、ソースおよび/またはターゲット接続ウィザードに情報を提供する必要があります。

レプリケーションに関与する各テーブルについて、Syniti DRはソーステーブルに3つのトリガーを作成し、レコードに特定のイベントが発生したときに起動します:

  • テーブルに新しいレコードが挿入されるときに起動するINSERTトリガー
  • レコードが変更されるときに起動するUPDATEトリガー
  • レコードが削除されるときに起動するDELETEトリガー

OracleデータベースネイティブのREDOまたはアーカイブログにアクセスできなくても変更追跡が行えるため、権限が限られているような一部のクラウドデータベースでも利用できるアプローチです。

ただし、ソースDB上にトリガーが作成され対象テーブルへの変更があるたびにログテーブルに記録されますので、その分のリソース(トリガー負荷と容量)をソースDBサーバで確保いただく必要があります。

まとめ

このようなアプローチを用いてOracleプラガブルデータベース(PDB)や、マテリアライズドビューなど、Oracle特有の環境のレプリケーションも対応しています。Oracle RACでクラスタを構成している環境や、Oracle Exadataなどの大規模な環境でもSyniti DRであればデータ連携を実現することが可能です。

PDBやRACなどOracle特有の環境、構成にも対応

ご興味ありましたら是非、弊社までお問い合わせください。

また、詳細なセットアップガイドは弊社ドキュメントサイトをご参照ください。

コメントする -->

PostgreSQLがエンタープライズレベルのデータベースの選択しであるかどうか?

エンタープライズレベルのデータベースというと、市場にはいくつかの選択肢がありますが、PostgreSQLも人気があり信頼できる選択肢の1つといえるかもしれません。PostgreSQLは、1990年代半ばから存在するフリーでオープンソースのオブジェクトリレーショナルデータベース管理システム(ORDBMS)です。

PostgreSQLは長年にわたり、他のデータベース管理システムと比較するといくつかの利点を提供する、堅牢で機能豊富なデータベースへと進化してきました。ここでは、PostgreSQLがエンタープライズレベルのデータベースの有力候補である理由をいくつか考査します。

オープンソースでフリー

●PostgreSQLはオープンソースのデータベースです。つまり、使用、配布、変更が自由です。
●このため、あらゆる規模の企業、特に高価なデータベース管理システムに投資する予算がない新興企業や中小企業にとって、魅力的な選択肢となります。
●PostgreSQLは、その開発、サポート、文書化に貢献する開発者の大規模なコミュニティに支えられています。

高度な機能

PostgreSQLは、エンタープライズレベルのデータベースの最有力候補となる、幅広い先進的な機能を備えています。注目すべき機能には、以下のようなものがあります:

●JSONおよびXMLデータ型のサポート
●全文検索機能
●レプリケーションと高可用性を内蔵
●カスタムデータ型、関数、演算子をサポートする拡張可能なアーキテクチャ
●外部キーと参照整合性制約のサポート
●ACID (Atomicity, Consistency, Isolation, Durability)に準拠したトランザクション


スケーラビリティ

●PostgreSQLは、成長するビジネスに合わせて拡張できるように設計されています。大規模なデータセットや複雑なクエリを簡単に扱うことができ、水平方向にも垂直方向にも簡単に拡張することができます。
●PostgreSQLは、データを複数のサーバに分散させるシェアリングをサポートしており、トラフィックの多いWebサイトやアプリケーションに最適です。

信頼性

●PostgreSQLは、その信頼性と安定性で知られています。堅牢なトランザクションシステムを備えており、高トランザクション環境においても、データの整合性と一貫性を確保します。
●また、大量のデータやトラフィックの多いウェブサイトを処理する実績があります。PostgreSQLはMVCC(Multi Version Concurrency Control)システムを採用しており、複数のユーザが同時に同じデータにアクセスしても、競合やデータの損失がないことを保証します。
●また、複数の同時ユーザーをサポートし、ダウンタイムやデータ損失なしに複雑なデータベース操作を処理することができます。このため、高可用性を必要とするミッションクリティカルなアプリケーションに最適な選択肢です。

柔軟性

PostgreSQLは高い柔軟性を備えており、開発者が特定のニーズに合わせてカスタマイズすることが可能です。JSONを含む幅広いデータ型をサポートし、複雑なデータ構造も扱うことができます。また、機能を強化するための拡張機能やプラグインも充実しており、本番用のデータベースとして多用途に使用できます。

セキュリティ

PostgreSQLは、不正なアクセスからデータを保護するために、堅牢なセキュリティ機能を備えています。安全な通信のためのSSL暗号化をサポートし、LDAP、Kerberos、GSSAPIを含む様々な認証方法を提供します。また、ロールベースのアクセスコントロールをサポートしており、開発者はユーザーレベルでデータへのアクセスを制御することができます。このため、機密性の高いデータを扱う企業にとって理想的な選択肢となります。

他のツールやテクノロジーとの統合

PostgreSQLは、エンタープライズレベルのアプリケーションで一般的に使用されている他のツールやテクノロジーとシームレスに統合されています。Java、Python、PHPなどのプログラミング言語用のコネクタがあり、 BIツールなどの一般的なデータ可視化ツールとの統合も可能です。また監視ツールのDatabase Performance Analyzer (DPA)を活用してパフォーマンス・チューニングも可能です。さらにPostgreSQLと他のRDBとのリアルタイムなレプリケーションではSyniti Replicateが有効な手段です。

まとめ

PostgreSQLは、その拡張性、信頼性、柔軟性、セキュリティ、コミュニティサポートにより、本番用データベースの有力候補となっています。その特徴から、堅牢で汎用性の高いデータベースシステムを必要とする企業にとって、選択肢となります。エンタープライズレベルのアプリケーション用のデータベースシステムとしてPostgreSQLは検討する価値がありますが、フリーソフトウェアゆえにしっかりとしたサポートができる会社を予め見つけることも重要です。

タグ: , ,

Oracleトランザクションセットアップ例(Log ReaderまたはLog Server Agent)[Syniti Data Replication]

Oracle Databaseをソースとしてトランザクションログを参照したレプリケーションを実施するための構成手順例を紹介します。トリガーを使用した場合の設定についてはこちらをご参照ください。

事前準備

Syniti DRが利用する.Netプロバイダをインストールするために、Syniti DRサーバにOracle Clientをインストールします。この際にOracle Data Provider for .NET(ODP.NET)を含んでいることを確認してください。

接続ユーザの構成

Oracleに接続するためのユーザを構成します。以下ではユーザの作成から権限割り当て等まで例を紹介しています。ここではレプリケーション対象のテーブル個別に設定可能な項目もanyで権限割り当てしていますのでご注意ください。

非コンテナデータベースの場合

この例では非コンテナデータベースで、sdruserを作成し、それに対して必要な権限を割り当てる手順を紹介しています。<Password>は任意の文字列に置き換えてください。

--ユーザ作成
create user sdruser identified by <Password>;

--セッションの作成を許可
grant create session to sdruser;

--カタログ参照権限
grant select on SYS.ALL_USERS to sdruser;
grant select on SYS.ALL_TABLES to sdruser;
grant select on SYS.ALL_TAB_COMMENTS to sdruser;
grant select on SYS.ALL_OBJECTS to sdruser;
grant select on SYS.ALL_VIEWS to sdruser;
grant select on SYS.ALL_TAB_COLUMNS to sdruser;
grant select on SYS.ALL_COL_COMMENTS to sdruser;
grant select on SYS.ALL_CONSTRAINTS to sdruser;
grant select on SYS.ALL_CONS_COLUMNS to sdruser;
grant select on SYS.USER_CONSTRAINTS to sdruser;
grant select on SYS.USER_CONS_COLUMNS to sdruser;
grant select on SYS.ALL_IND_COLUMNS to sdruser;

--テーブル参照権限
grant select any table to sdruser;

--テーブル作成、更新権限(任意、ターゲットの場合、必須)
grant unlimited tablespace to sdruser;
grant create any table to sdruser;
grant insert any table to sdruser;
grant update any table to sdruser;
grant delete any table to sdruser;

--テーブル削除、構成変更権限(任意、ターゲットの場合、必須)
grant alter any table to sdruser;
grant drop any table to sdruser;

--サプリメンタルロギング設定権限
grant alter database to sdruser;

--サプリメンタルロギング(最小レベル)での設定権限
grant alter any table to sdruser;

--ディクショナリファイルの構築権限
grant execute on sys.dbms_logmnr_d to sdruser;

--トランザクションログ参照権限
grant execute on sys.dbms_logmnr to sdruser;
grant select on sys.v_$parameter to sdruser;
grant select on sys.v_$log to sdruser;
grant select on sys.v_$logfile to sdruser;
grant select on sys.V_$logmnr_contents to sdruser;
grant select on sys.V_$thread to sdruser;
grant select on sys.V_$archive_dest to sdruser;
grant select on SYS.AUD$ to sdruser;

--アーカイブログも参照する場合に必要
grant select on sys.v_$archived_log to sdruser;

--10g以降の場合
grant select any transaction to sdruser;

--12c以降の場合
grant select on cdb_pdbs to sdruser;
grant logmining to sdruser;
grant select on sys.v_$database to sdruser;
grant select on sys.v_$containers to sdruser;
grant select on DBA_LOG_GROUPS to sdruser;
grant select on DBA_LOG_GROUP_COLUMNS to sdruser;
grant EXECUTE_CATALOG_ROLE to sdruser;

ルチテナント・コンテナ・データベースの場合

この例ではマルチテナント・コンテナ・データベースで、共通ユーザアカウントとしてcdb$rootにc##sdruserを作成し、それに対して必要な権限を割り当てる手順を紹介しています。<Password>は任意の文字列に置き換え、<PDB name>は環境に合わせて変更をお願いします。

--セッションをcdb$rootに変更
alter session set container = cdb$root;

--ユーザ作成
create user c##sdruser identified by <Password>;

--セッションの作成を許可
grant create session to c##sdruser container=ALL;

--サプリメンタルロギングを設定(最小/テーブルレベルの場合)
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

--サプリメンタルロギングを設定(データベースレベル)
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE INDEX) COLUMNS;

--サプリメンタルロギングの変更権限
grant alter database to c##sdruser container=ALL;

--トランザクションログ参照権限
grant execute on sys.dbms_logmnr_d to c##sdruser container=ALL;
grant select on sys.v_$parameter to c##sdruser container=ALL;
grant select on sys.v_$log to c##sdruser container=ALL;
grant select on sys.v_$logfile to c##sdruser container=ALL;
grant select on sys.V_$logmnr_contents to c##sdruser container=ALL;
grant select on sys.V_$thread to c##sdruser container=ALL;
grant select on sys.V_$archive_dest to c##sdruser container=ALL;
grant select on sys.v_$archived_log to c##sdruser container=ALL;
grant select any transaction to c##sdruser container=ALL;
grant select on cdb_pdbs to c##sdruser container=ALL;
grant logmining to c##sdruser container=ALL;
grant select on sys.v_$database to c##sdruser container=ALL;
grant select on sys.v_$containers to c##sdruser container=ALL;
grant select on DBA_LOG_GROUPS to c##sdruser container=ALL;
grant select on DBA_LOG_GROUP_COLUMNS to c##sdruser container=ALL;
grant EXECUTE_CATALOG_ROLE to c##sdruser container=ALL;
grant select on sys.aud$ to c##sdruser;
alter user c##sdruser set container_data=ALL container=current;

--セッションをPDBに変更
alter session set container = <PDB name>;


--セッションの作成を許可
grant create session to c##sdruser;

--カタログ参照権限
grant select on SYS.ALL_USERS to c##sdruser;
grant select on SYS.ALL_TABLES to c##sdruser;
grant select on SYS.ALL_TAB_COMMENTS to c##sdruser;
grant select on SYS.ALL_OBJECTS to c##sdruser;
grant select on SYS.ALL_VIEWS to c##sdruser;
grant select on SYS.ALL_TAB_COLUMNS to c##sdruser;
grant select on SYS.ALL_COL_COMMENTS to c##sdruser;
grant select on SYS.ALL_CONSTRAINTS to c##sdruser;
grant select on SYS.ALL_CONS_COLUMNS to c##sdruser;
grant select on SYS.USER_CONSTRAINTS to c##sdruser;
grant select on SYS.USER_CONS_COLUMNS to c##sdruser;
grant select on SYS.ALL_IND_COLUMNS to c##sdruser;

--テーブル参照権限
grant select any table to c##sdruser;

--テーブル作成、更新権限(任意、ターゲットの場合、必須)
grant unlimited tablespace to c##sdruser;
grant create any table to c##sdruser;
grant insert any table to c##sdruser;
grant update any table to c##sdruser;
grant delete any table to c##sdruser;

--テーブル削除、構成変更権限(任意、ターゲットの場合、必須)
grant alter any table to c##sdruser;
grant drop any table to c##sdruser;

--サプリメンタルロギングが最小/テーブルレベルの場合の追加権限
grant alter any table to c##sdruser;

クラウドDBの設定(Amazon RDSの例)

クラウド上でサービスとして提供されているデータベースの場合、データベースの変更をalter databaseでは実施できず、独自のコマンドを使用しなければいけない場合があります。

例えばサプリメンタルロギングを有効化するといったケースです。Amazon RDSのOracle DBインスタンスでデータベースレベルでサプリメンタルロギングを有効にする場合には以下のように実行します。

exec rdsadmin.rdsadmin_util.alter_supplemental_logging(‘ADD’,’PRIMARY KEY’);
exec rdsadmin.rdsadmin_util.alter_supplemental_logging(‘ADD’,’UNIQUE’);

詳細は下記をご参照ください。

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.html#Appendix.Oracle.CommonDBATasks.AddingSupplementalLogging

シンクロナイゼーション(双方向)での追加設定

シンクロナイゼーション(双方向)のレプリケーションを実施する場合、参照するトランザクションログをどのユーザが実行したかという監査情報が必要になります。

この監査証跡を設定するためには、以下を実施します。

1.以下をデータベース(CDB$ROOT)で実行します。

ALTER SYSTEM SET audit_trail=DB SCOPE=SPFILE;

2.データベースインスタンスを再起動します。

3.再起動後、セッションを記録するように以下を実行します。

AUDIT SESSION;

または、以下のように個別のユーザで有効化することもできます。

AUDIT SESSION BY sdruser;

このコマンドはデータベースの再起動後も有効です。監査をオフにする場合、オフにするAUDITステートメントごとにNOAUDITステートメントを実行します。

NOAUDIT SESSION;
NOAUDIT SESSION BY sdruser;

ソース接続設定

ODP.NETがインストール先WindowsのGACに登録されている場合、自動的にそれがアセンブリとして読み込まれます。GACに登録されていない場合、明示的にアセンブリOracle.DataAccess.dllファイルを指定する必要があります。

データベースへの接続情報を指定します。

  • シンクロナイゼーションを実施する場合、指定するユーザIDはSyniti DR固有のものにする必要があります。Syniti DRはこのユーザIDが実行したトランザクションをレプリケーションしません。
  • マルチテナント・コンテナ・データベースの場合、レプリケーション対象のテーブルが存在するPDBを指定します。

トランザクショナルレプリケーションの有効化

この記事ではLog ReaderまたはLog Server Agentでトランザクショナルレプリケーションを実施する場合の設定を紹介しています。

Log Readerの場合

トランザクションログの参照に関する設定を行います。

  • マルチテナント・コンテナ・データベースの場合、[…]から接続設定を編集し、CDB$ROOTに接続するように設定を変更します。
  • Oracle 19c以降の場合、Oracle側でCONTINUOUS_MINEオプションがサポートされなくなったため、アーカイブログ参照設定のCOUTINUOUS_MINEオプションを使用のチェックを外す必要があります。

Log Server Agentの場合

ログサーバエージェントのコンポーネントを配置するパスと、取得したトランザクションログを保存するフォルダ、またそれの保持設定を行います。

  • マルチテナント・コンテナ・データベースの場合、[Use ログコンテナ]にチェックを入れて接続設定を編集し、CDB$ROOTに接続するように設定を変更します。
  • [Remote LSAの使用]はOracleデータベースサーバ側にログサーバエージェントを構成する場合に使用します。構成が必要な場合には、サポートまでお問い合わせください。
コメントする -->

SQLパフォーマンスチューニングとは何か? その重要性

データベース管理者や開発者は、SQLクエリやデータベースをチューニングする方法を知っておく必要があります。SQLクエリやデータベースのチューニングは、可能な限り最高のパフォーマンスを実現するための最も強力なツールの1つです。

このブログでは、SQLのチューニングについてより深く理解するのに役立ちます。まず、SQLのパフォーマンスチューニングとは何かを説明します。次に、Microsoft SQL Server、OracleでSQLのパフォーマンスチューニングを行う方法について説明します。最後に、SQLパフォーマンス・チューニングのメリットについてまとめます。

SQLパフォーマンスチューニングとは?

SQLパフォーマンスチューニング、またはパフォーマンスチューニングは、SQLデータベースの効率に影響を与える可能性のある問題をチェックし、解決することです。優れたパフォーマンスの鍵は、最小限のリソースでクエリを迅速に実行できるようにすることです。
外部ツールの利用は、SQLパフォーマンスチューニングを始めるための1つの方法です。Database Performance Analyzer (DPA)を例として挙げます。これらのプラットフォームを使用すると、クエリとパフォーマンスをより深く理解でき、データベースをより効果的にチューニングできます。しかし、それ以外にもできる対策があります。

クエリのパフォーマンスをチューニングするための最初のステップは、パフォーマンスを最適化できるように、どのメトリクスを測定すべきかを知ることです。重要な指標は3つあります。CPU使用率、ディスクI/O、そしてメモリ使用率です。CPU の使用率やディスク I/O の待ち時間が急増した場合は、常にクエリを監視する必要があります。

チューニングプロセスのもうひとつのポイントは、CPU使用率が高い、ディスクI/Oが高い、メモリ負荷が高いなど、どのクエリがチューニングの候補になるかを特定することです。クエリ候補を特定したら、クエリをチューニングするために従う一般的なルールがあります。これらのルールは、MySQL、Microsoft SQL Server、Oracleのいずれを使用しているかによって異なります。


Microsoft SQL Server パフォーマンスチューニング

Microsoft SQL Server のチューニングを始めるにあたり、必要不可欠なコンポーネントをいくつか紹介します。

パフォーマンスモニター

パフォーマンスモニターは、クエリのパフォーマンス問題をトラブルシューティングする際に非常に重要なステップです。どのクエリに時間がかかっているかを特定し、その最適化に注力することができます。さらに、I/O に関連する問題(ディスク容量不足など)を特定することもできます。

パフォーマンスモニターは、遅いクエリや最適化されていないインデックスなどの問題を特定するのに役立ちます。また、各クエリの実行時間、使用ディスク数、使用メモリ量、ロック数など、データベースシステムの性能に関する詳細な情報を提供することができます。

プロファイラ

SQL Server Profiler は、Microsoft SQL Server のパフォーマンスを監視するために設計された、使いやすいツールです。実行中のクエリの数、各クエリの実行時間、実行に使用したリソースなど、システムの運用に関するさまざまなデータポイントを収集することができます。これらの情報は、システムを改善できる領域を特定するために使用できます。

特定のクエリに割り当てられたリソースを理解することで、システムがパフォーマンスを向上できる領域を特定することができます。

クエリプラン

クエリオプティマイザはクエリを受け取り、そのクエリと基礎となるデータを分析し、最も効率的に実行する方法を決定します。これには、最適なインデックス作成戦略の選択、最も効率的な結合順序の決定、その他の最適化が含まれます。クエリオプティマイザは、クエリの実行計画を生成します。この計画には、要求されたデータを取得するためにクエリが実行する詳細なステップのセットが含まれています。

Database Engine Tuning Advisor

Database Engine Tuning Advisor (DTA) は、Microsoft SQL Server のユーザーがデータベースのパフォーマンスを向上させるために設計されたツールです。DTAは、インデックスの作成と削除、インデックスで使用されているデータの種類の特定、ストアドプロシージャとテーブルの改善方法などを提案することができます。

DTAは、インデックスの作成と削除の他に、データベースのストアドプロシージャとテーブルの変更の実装を支援します。

Oracle SQLパフォーマンス・チューニング

Oracleのチューニングを始めるには、提供されている自動チューニング機能を利用することができます。それぞれについて見ていきましょう。

Automatic Workload Repository(自動ワークロードレポジトリ)

OracleのAutomatic Workload Repository(AWR)は、パフォーマンス・チューニングに役立ちます。AWRは、データをスナップショット・レポートとして保存し、潜在的な問題の発見に役立つパターンや傾向を特定します。また、このリポジトリは、さまざまなクエリーやグループのパフォーマンスを監視することができます。さらに、問題についてのレポートやアラームを生成することもできます。

Automatic Database Diagnostic Monitor(自動データベース診断モニター)

パフォーマンスのボトルネックを特定・分析する機能は、Automatic Database Diagnostic Monitor (ADDM) の重要なコンポーネントです。これにより、適切な修正を推奨し、アプリケーションとデータベースのパフォーマンスを向上させることができます。Add-On Performance Monitor の助けを借りて、データベース管理者は手動チューニングの実行の複雑さを軽減することができます。

Add-On Performance Monitorは、待機イベント、インデックスステートメント、SQLステートメントなど、パフォーマンスの問題に関する詳細な情報を提供します。また、データベースのパフォーマンスを向上させるためのアクションを推奨することができます。

SQL Tuning Advisor(チューニングアドバイザー)

SQL Tuning Advisorは、ライブラリキャッシュ内のステートメントまたは直接送信されたステートメントを評価し、そのパフォーマンスを向上させることができる推奨事項を生成します。これらの変更には、データベース・オブジェクトの追加や修正が含まれます。

また、SQL Tuning Advisorは、AWRを使用して最近のワークロードをレビューし、推奨事項を生成し、システム全体のパフォーマンスを向上させることができます。

SQLパフォーマンスチューニングの利点とは?

SQLクエリーとデータベースのチューニングの基本的な方法を説明しましたが、SQLパフォーマンスのチューニングがなぜ重要なのか、もう一度要約します。

●SQLクエリをチューニングすることで、データベースに保存されているデータの正確性と信頼性を向上させることもできます。これにより、エラーを防止し、データベースのデータ整合性を向上させることができます。
●SQLクエリを適切にチューニングすることで、クエリのパフォーマンスを向上させ、データの取得にかかる時間を短縮することができます。これにより、意思決定を迅速化し、より速いレスポンスタイムを可能にすることができます。
●データベースのパフォーマンスとサーバーリソースの使用率を最適化することで、オンプレミスおよびクラウドのデータベースサーバーインフラストラクチャをライトサイジングし、コストを削減することができます。
●SQLクエリーをチューニングすることで、サーバーの負荷を軽減します。これにより、作業負荷が増加した際のパフォーマンスとスケーラビリティを向上させることができます。SQLクエリーをチューニングすることで、データベースに保存・取得されるデータ量を向上させることができます。これにより、使用するディスク容量を減らし、データベースの全体的なパフォーマンスを向上させることができます。
●SQL クエリをチューニングする最大のメリットは、SQL クエリの開発時間を短縮できることです。これにより、貴重なリソースを他のタスクに解放することができます。
●SQLパフォーマンスのチューニングは、データベースがクエリに結果を返すまでの時間を短縮することで、ユーザーエクスペリエンスを向上させるのに役立ちます。これは、高速なロード時間が優れたユーザーエクスペリエンスを提供するために重要である、Webアプリケーションで特に重要になる場合があります。さらに、ロード時間の増加は、Webアプリケーションの検索エンジンランキングを向上させ、SEOのインデックスを改善することになります。

まとめ

SQLパフォーマンスチューニングは、最適な速度とパフォーマンスを得るためにデータベースクエリを改良するために不可欠です。データベーススキーマ、クエリプラン、リソースとインデックスの使用状況、その他の要因を時間をかけて分析することで、改善の機会を特定し、最適なパフォーマンスを確保するのに役立てることができます。データベースのパフォーマンスを綿密に監視することで、問題を迅速に特定して対処し、データベースのパフォーマンスを維持または向上させることができます。

Database Performance Analyzer (DPA)はクエリ最適化ウィザード、動作の遅いクエリの高度な強調表示、CPU使用率監視などのツールを提供して、データベースの完全な最適化を支援します。

タグ: , , , , ,

MySQLパフォーマンスチューニングのさらに詳細へ

 

MySQLパフォーマンス・チューニングとは何ですか?

MySQL パフォーマンス・チューニングとは、データベースの効率性、有用性、正確性を維持するために設計された一連の保守プロセスのことを指します。

エンド・ユーザーによって日々生成される情報量は、データベースに含まれる情報の量と程度を一定期間にわたって大きく変化させ、データベースの容量と負荷、システム・パフォーマンス、およびリソースの可用性に影響を及ぼす可能性があります。MySQLデータベースのチューニングを定期的に行うことで、ネットワーク管理者は、変化するワークロード、データ量の増加、およびアクセス性とサービスの維持の必要性に対応するために、データベースを適切にプロビジョニングし、準備することができます。

MySQL パフォーマンスの最適化は、組織内の他の部門にも良い影響を与えます。MySQLのアップデート・パフォーマンスのチューニングと最適化を優先的に行うことで、組織のリソースや財務に負担をかけることなく、インフラストラクチャ全体が企業のニーズを満たすようになり、最終的に企業のコスト削減に貢献します。

MySQLのパフォーマンスチューニングはどのように行われるのか?

MySQLデータベースのパフォーマンスを効果的に最適化するには、いくつかのステップが必要です。最初のステップは、対象となるデータベースのベースラインメトリクスを収集することです。効果的な分析には適切なデータ収集が必要なため、これはいくつかの理由で不可欠です。まず、MySQLクエリなどの処理にかかる時間、および理想的な状況でクエリが実行される時間について、期待値を確立することができます。

管理者がベースラインメトリクスを確立すると、データベースパフォーマンスが異なる場合や発散する場合の検出が非常に容易になり、MySQLパフォーマンスチューニングの必要性を示唆することができます。システムブロック、統計情報の計算、データの送信、その他のプロセスなど、待ち時間やスレッドの状態に関する情報を収集することで、MySQLデータベースのチューニングに特別な注意が必要な箇所を特定することができます。

さらに、実行プランの調査やMySQLチューニング結果のモニタリング、潜在的なボトルネックの特定と対処など、他のステップも含まれます。このため、MySQLパフォーマンス・チューニング・ツールを使用してこれらのプロセスを自動化することは、多くの組織、ビジネス、企業にとって、よりコスト効率の高い選択肢となります。

MySQL パフォーマンスチューニングはなぜ重要なのか?

MySQL のパフォーマンスを最適化することが重要である理由は主に 2 つあります。

●信頼性の高いエンドユーザ体験とサービス品質を確保することができます。
●ネットワークコンピューティング環境におけるインフラストラクチャのコストを削減することができる。

クエリの実行計画をレビューすることによってMySQLのパフォーマンスを調整することは、管理者が潜在的なボトルネックや不十分なオペレーションをより迅速に特定するのに役立ちます。これは、データ量が増大したり、組織で使用される技術が複雑化したりした場合に、特に重要です。

MySQLサーバーおよびデータベースのパフォーマンスを最適化することで、サービスおよびアクセスに必要なリソースを決定することもできます。オーバー・プロビジョニングを避けることで、管理者はサーバーとデータベースを正常に機能させるために必要なハードウェアの運用・保守コストを削減することができ、不要なタスクの負荷を軽減しながらデータ取得の速度を向上させることもできます。MySQLのパフォーマンス・チューニングは、サーバー容量の追加やフラッシュ・ストレージへの移行が、投資に見合うだけのパフォーマンス向上につながるかどうかの判断材料にもなります。

MySQL パフォーマンスチューニングツールは何をするのですか?

MySQLチューニングツールは、データベース管理者および開発者がパフォーマンスチューニングのプロセスを容易にすることができます。手動で行う場合、MySQLのチューニングはいくつかの理由で困難な場合があります。

まず、実行計画を理解し、SQL文やクエリを正しく更新または書き換えるには、ある程度の経験が必要です。細部にまで注意を払う必要があるため、MySQLのチューニングは専門的で時間のかかる作業となり、手作業で効率的に行えるのは一部の人だけとなります。多くのIT部門にとって、これはリソースと工数の非効率的な使用であることが証明されています。

MySQLパフォーマンス・チューニング・ツールは、サーバーおよびデータベースのパフォーマンスをわかりやすく可視化し、統合されたレポートとアラートによりSQLステートメント、I/Oアクティビティ、その他のパフォーマンス指標に関する洞察を提供することで、このプロセスを合理化することが可能です。また、開発者はMySQLパフォーマンス・チューニング・ツールを利用して、SQLクエリの最適化方法とエンドユーザーのデータ・アクセス方法をよりよく理解することができます。

MySQLパフォーマンス・チューニング・ツールが提供する知見を活用することで、管理者および技術サポートスタッフは、エンドユーザーが必要な日常業務を遂行できるよう、また顧客がサービスやアクセスに支障をきたさないよう支援することができます。

Database Performance Analyzer(DPA)でMySQLのパフォーマンスチューニングはどのように行われるのですか?

Database Performance Analyzerは、登録されたすべてのデータベースを24時間体制で監視し、直感的なダッシュボードに指標を表示して、現在のパフォーマンスと潜在的な問題を迅速に理解できるように設計されています。DPAは、データベース・パフォーマンスの正確かつ迅速な分析を行うために構築されており、管理者は特定された問題の根本原因を迅速に掘り下げることができ、迅速かつ効果的なMySQLパフォーマンス・チューニングを支援することができます。

DPAは、データベース管理者がMySQLクエリの応答時間をパフォーマンスベースラインに対して過去およびリアルタイムで調査し、いずれかの要素が異常なパフォーマンスになっていないかどうかを確認できるようにします。DPAは、データベースとサーバーのパフォーマンスの異常を検出する機械学習機能により、MySQLサーバーを最適化し、パフォーマンス低下の原因を明確かつ客観的に評価します。

また、カスタマイズ可能なアラートとレポートにより、データベースパフォーマンスの重大な問題について常に情報を提供します。DPAはエージェントレスアーキテクチャを採用しているため、監視対象のデータベースのパフォーマンスに影響を与えることなく、問題解決のための強力な洞察力と実用的なインテリジェンスを提供できる軽量な監視・分析システムとなっています。

タグ: ,