進化するクエリと PostgreSQLの台頭：そのデータベー スパフォーマンス重要性

投稿日: 2024年5月19日 作成者: climb
Database Performance Analyzer (旧Ignite) Syniti (旧DBMoto) データベース 運用

この何年間、オープンソーステクノロジーの役割と進化は、競争の激しいデータベース管理ソフトウェアの世界を含め、着実に高まっています。データベース管理のオープンソース技術の世界では、MySQL、MongoDB、PostgreSQLなどが有名です。オープンソースのデータベース管理ソフトウェアの典型的な用途は、アプリケーション、データウェアハウス、分析、オンライントランザクション処理です。

特に大量のデータを必要とする企業にとって、オープンソースのデータベース管理システムを使うメリットは明確です。まず、中小規模の企業にとって大きな要因となるのはコストです。大手の商用データベース企業はライセンス契約に制約がある傾向がありますが、PostgreSQLのようなオープンソースのソリューションはベンダーが幅広く、ライセンスやメンテナンスのコストが低くなります。場合によっては、10倍も安いこともあります。しかし、短期的な考え方や節約だけがすべてではありません。考慮すべきは柔軟性と拡張性です。信頼できるオープンソースのソリューションを探している企業にとって、PostgreSQLは柔軟で将来性のある機能を保証しています。PostgreSQLはSQL言語に関するANSI/ISO標準を遵守していますが、コミュニティによる着実で漸進的な改善へのコミットメントによって繁栄しています。

多くの企業向けソフトウェアはまだ伝統的なウォーターフォールモデル（つまり、開発期間が設計によって固定されている）で作られていますが、PostgreSQLのようなエンタープライズグレードのオープンソース技術は、一方的なロードマップの制約からほとんど自由です。PostgreSQLは、容易にアクセス可能なコードベースと熱心なユーザと開発者のコミュニティのおかげで、常に自然な進化を続けてきました。機能からバグの修正まで、ターンアラウンドタイムは迅速です。PostgreSQLは、多くのユーザによる社内での調整を抜きにしても、公式には現在バージョン16.2を数えています。

PostgreSQL： その起源
PostgreSQLの起源は1996年とカリフォルニア大学に遡ります。PostgreSQLがリリースされた当初、一般的なデータベースシステムは複雑なデータ型やリレーションシップを扱うのが苦手でした。PostgreSQLは当初から、まさに従来のデータベースシステムの限界を克服するために、柔軟性、拡張性、コードの品質に重点を置いていました。

PostgreSQLのソースコード（汎用性の高いC言語で書かれています）はオープンソースライセンスの下で利用可能であるため、ユーザは自分の要求や技術仕様に合わせて自由に変更したり実装したりすることができます。そのため、PostgreSQLには、開発者が新しいデータ型とそれに関連する操作を追加するための簡単な仕組みが用意されています。

PostgreSQLの素晴らしい点の1つは、Windows、MacOS、Linuxを含むすべての主要なオペレーティングシステムにインストールできることです。1台のマシンからインターネットに向けた大規模なアプリケーションまで、オンプレミスでもクラウドでもワークロードを処理できる柔軟性があります。要は、PostgreSQLはエンタープライズ・グレードのデータベース管理の世界に完全に適合しているにもかかわらず、オープンソースが提供するすべての利点を備えているため、スケーラブルなデータベース管理のためのスマートな選択肢の1つなのです。

生命のバイタルサイン
残念ながら、基盤となるソフトウェアがいかに柔軟で信頼できるものであっても、データベースの実装が完璧であることはほとんどありません。そのため、データベースの健全性と最適化の機会を監視することが重要です。最高の実装であっても、特にデータ需要が増大するにつれて、必然的にコストのかかるデータベー スパフォーマンスの問題が発生します。

PostgreSQLの台頭に合わせて、SolarWindsのDatabase Performance Analyzer（DPA）の最新リリースでは、DPAの既存のパフォーマンス監視機能をベースに、PostgreSQLのテーブルチューニングとインデックスアドバイザが追加されました。このDatabase Performance Analyzerの最新リリースはEDB、Microsoft Azure、Amazon RDS、Amazon Aurora、Google Cloud SQLを含むPostgreSQLの包括的なデータベースパフォーマンス分析が含まれます。

すでにPostgreSQLを使用している場合、またはOracleやSQL Serverから移行する場合、最新バージョンのDPAには3つの強力なPostgreSQLチューニングアドバイザーが同梱されています：

●クエリアドバイザ：特定のクエリに関する性能情報を提供します。例えば、待ち時間、セッション情報、実行計画などです。
●テーブルチューニングアドバイザ：非効率なクエリがテーブルに対して実行された場合に生成されます。テーブル、非効率なクエリ、既存のインデックスに関する情報を提供します。
●インデックス・アドバイザー: 不足しているインデックスを特定し、提案されたインデックスを追加することで、どれだけの時間を節約できる可能性があるかの見積もりを提供します。

更にSyniti Replicate を活用することでPostgreSQLと他の多くのRDBとリアルタイムにデータをレプリケーションすることが可能です。これによりOracle, SQL Serverなどの汎用商用データベースとPostgreSQLのデータ連携が可能です。そしてそれらにはEDB、Microsoft Azure、Amazon RDS、Amazon Aurora、Google Cloud SQLを含むPostgreSQLが含まれます。

 

タグ: , , ,

Database Performance Analyzer (DPA) 2024.2のリリース

投稿日: 2024年5月2日 作成者: climb
Database Performance Analyzer (旧Ignite)

最新バージョンのDatabase Performance Analyzer (DPA) 2024.2の一般提供が開始されました。このリリースでは、SQL ServerおよびOracle向けのDPAの既存機能である実行プラン収集、インデックスアドバイザ、Table Tuning Advisor(テーブルチューニングアドバイザ)をPostgreSQLにも適用し、PostgreSQLのワークロードを分析します。

Table Tuning Advisor（テーブルチューニングアドバイザ）

どのデータベースにも非効率な問い合わせがあります。言い換えれば、少ないリターンに対して非常に多くの労力を費やしているということです。このような非効率的なクエリは、I/Oの増加、待ち時間の増加、ブロッキングの増加、リソースの競合の増加を招きます。

非効率的なクエリをチューニングするのは難しく、その過程で多くの疑問が浮かびがちです。以下のような疑問です：

●クエリをチューニングすべきか？新しいインデックスを追加すべきか？それとも既存のインデックスに列を追加するのか？
●プランは複雑で分析が難しい。どのステップに注意を払うべきか？
プランのどの述語が非効率的なデータアクセスと大量のリードを引き起こしているのか？
●出発点として使える推奨事項はありますか？
●同じテーブルにアクセスする他の非効率なクエリがあり、インデックスの決定によって影響を受ける可能性はありますか？
●テーブルには現在いくつのインデックスが存在し、それらはどのような構造になっていますか？
●データチャーン（挿入、削除、場合によっては更新）という形で、テーブル内のデータはどの程度トランザクションがあるのか？

Table Tuning Advisorはこれらの疑問を解決するのに役立ちます。

Table Tuning Advisorは、高価なクエリやプランを分析し、非効率なワークロードが実行されているテーブルを特定するために設計されています。各テーブルについて、アドバイザー・ページにはテーブルと非効率なクエリに関する集約された情報が表示されます。この情報を使用して、データベース・パフォーマンス最適化の機会について情報に基づいた決定を下したり、インデックスを追加する潜在的なコストと利点を検討したりすることができます。

ナビゲーション

アドバイザーのページに進むには2つの方法があります：

●インスタンスをクリックすると、ページ上部に “Tuning “スーパータブが表示されます。これにより、クエリ、インデックス、テーブルのチューニングアドバイザーをまとめたページに移動します。

●特定のクエリ・パフォーマンス分析 (QPA) ページに移動したら、テーブル・チューニング・アドバイザーのセクションにスクロールダウンします。このセクションには、テーブル・レベルに集約されたアドバイスが要約され、アドバイザーの詳細ページへのリンクが含まれています。

アドバイザーページのレイアウト

テーブル・チューニング・アドバイザーのページには、選択したオブジェクトに関連する主要なインテリジェンスがぎっしりと詰まっており、3つのメイン・エリアがあります：

●非効率なSQL – テーブルにアクセスするクエリのリストを相対的な作業負荷でランク付け
●SQLとプランの詳細 – 選択したクエリのSQLとプランの詳細
●テーブルおよびインデックス情報 – 現在のテーブル情報、テーブル上の既存のインデックス、およびテーブルのカラム。

テーブル・チューニング・アドバイザーの例

積極的に何かをチューニングし、大きな影響を与えたいとします。概要レベルでは、チューニングタブは非効率なクエリを持つテーブルを表示し、非効率なワークロードに基づいてランク付けします。このリストには、各テーブルの待ち時間の集計と、そのテーブルの非効率なプランステップを持つクエリの数が含まれています。これらはチューニングの絶好の機会です。

出発点として使用する推奨事項はありますか？「orders 」テーブルをクリックすると、テーブル・チューニング・アドバイザーのページが表示されます。このページには、非効率な使用パターン、統計情報、現在のインデックスの設計など、テーブルについて知っておくべきことがまとめられています。

プランのどのステップが非効率ですか? DPA は独自のアルゴ リ ズ ム を使用 し て非効率な計画ス テ ッ プ を発見 し 、 問題の原因 と な っ てい ます。非効率な「プロデューサ」ステップ（例えば、テーブル/インデックスのフル スキャン）は、後続のコンシューマ プラン ステップが後で処理するデータを読み込みます。コンシューマステップ（
例えば、ソート）は高コストになる可能性がありますが、通常は先行するプロデューサステップのデータ読み込み量が多すぎることが影響しています。DPA は非効率なプ ロ デ ュ ーサープ ラ ン ス テ ッ プ を指摘 し 、 チューニングの焦点 と し ます。

上記の例では、 DPA は使用 さ れてい る 2 つのプ ラ ン と 、 各プ ラ ン内の非効率な ス テ ッ プ を特定しました：

１．SEQ SCAN – ステップ7 – 「customer」テーブルのシーケンシャルスキャン 述語値が、非常に非効率的な類似比較が使用されていることを示していることに注意してください。シーケンシャルスキャンは、一致する電話番号のために150K行の検査を引き起こしました。

手作業によるプラン分析でこの情報を得るには、おそらく何時間もかかるでしょう。プラン分析は難しいので、Table Tuning Advisorに任せます。

このテーブルにアクセスする他の非効率なクエリはありますか？ Table Tuning Advisorページの左ペインには、”customer “テーブルにアクセスする他の非効率的なクエリが相対的な作業負荷でランク付けされて表示されます。このリストの最上位にあるクエリは、テーブルに対する作業負荷が高いので注意してください。逆に、相対的な作業負荷が小さい最下部付近のクエリにはそれほど時間をかけるべきではありません。インデックスの追加や修正のような小さな調整で、多くの非効率なクエリが大きく変わることがあります。

テーブルには現在いくつのインデックスが存在し、それらはどのように設計されていますか？Table Tuning Advisorページの下部には、現在のインデックスとそのカラムが統計情報と使用状況と共に表示されます。その他のテーブルとインデックスのメタデータは、リアルタイムのクエリの後に表示され、最新の情報を反映します。これはいくつかの理由で重要です：

●テーブルのデータ・チャーンが高いか？もしそうであれば、挿入/更新/削除のアクティビティが高いことを意味し、新しいインデックスを作成するとかえって害になる可能性があります。
●述語で呼び出されたカラムを含む既存のインデックスが役に立ちそうか？新しいインデックスを作成するのではなく、このクエリに役立つようにインデックスを変更することができますか？
●オプティマイザの統計は最近作成されましたか？もしそうでなく、解約が多いのであれば、テーブルの統計情報を更新することが良い第一歩かもしれません。
●インデックスが肥大化していないか？インデックスが肥大化しており、それに対してスキャンが実行されている場合、バキューム処理の健全性をチェックしてください。

何が見つかったのか？

開発チームは、DPAを使用してコードのパフォーマンスを確認しています。Table Tuning Advisorを使用したところ、問題のあるテーブルが見つかりました。数時間以内に、簡単な書き換えでクエリをチューニングし、毎晩のクリーニング処理にかかるデータベース時間を数時間節約することができるでしょう。

 

タグ: , ,

テーブル一括作成やマッピングをカスタマイズ：グローバルスクリプト[Syniti Replicate]

投稿日: 2024年4月18日 作成者: climb
Knowledge Base Syniti (旧DBMoto) 運用

Syniti Replicateでは以下のよう特定スキーマ間でレプリケーションを一括で複数作成することができます。

この一括作成時にはソースとターゲットのスキーマを指定すると、どのようにテーブルを対応付けするかといったことも指定できます。

この際に存在しないテーブルに関してはデフォルトですと自動的に、同一の構成でターゲットテーブルも作成、マッピングを行いますが、以下のような対応が必要になる場合があります。

  • ソーステーブルとは異なるデータ型やサイズをターゲットテーブルでは使用したい
  • ソーステーブルにはない、カラムを追加したい
  • ターゲットテーブルへのマッピングをカスタマイズしたい

このようなケースではグローバルスクリプトで独自にルールを定義し、それを上記の右下「テーブルルールを作成」や「マッピングルール」で指定して使用することで対応できます。

ターゲットテーブル作成時にデータ型、サイズ変更など

グローバルスクリプトのICreateTableRuleイベントでテーブル作成時の独自ルールを作成できます。

aTargetFieldsで作成される予定のターゲットテーブル上のフィールド情報（デフォルトではソースと同様）を取得でき、これを変更することでカラム名やデータ型を変更できます。

サンプル：varcharの場合、カラム名末尾に_targetを追加、nvarcharに変更後、サイズを1.5倍に

using System;
using System.Data;
using System.Collections.Generic;
using DBMotoPublic;
using DBMotoScript;

namespace DBRS
{
    public class GlobalScript : IGlobalScript
    {
    }

    public class MappingRule : IMappingRule
    {
    }

    public class CreateTableRule : ICreateTableRule
    {        
	//この属性がGUI上での選択時に表示されます。
        [CreateTableRuleAttribute("ChangeTypeAndSize", "varcharの場合、カラム名末尾に_targetを追加、nvarcharに変更後、サイズを1.5倍に")]
        public bool ChangeTypeAndSize(List<ColumnClass> aTargetFields)
        {
            //カラムの型が、varcharかどうか判定
            for (int i=0; i<aTargetFields.Count; i++)
            {
                if(aTargetFields[i].TypeName=="varchar")
                {
                    //カラム名の末尾に_targetを追加
                    aTargetFields[i].Name=aTargetFields[i].Name+"_target";
                    //nvarcharへ変更
                    aTargetFields[i].TypeName="nvarchar";
                    //サイズを1.5倍に
                    aTargetFields[i].Size=(int)(aTargetFields[i].Size*1.5);
                }
            }
            return true;
        }
    }

    public class GlobalEvents : IGlobalEvents
    {
    }

}

ソーステープルの構成：

ターゲットテーブル作成時に作成したスクリプトのルールを設定した場合：

元々varcharであった「電話番号」のフィールドのみ、フィールド名が「電話番号_target」に、型はnvarcharに、サイズは1.5倍されています。

スクリプトで使用しているColumnClassは以下のようにフィールド（カラム）の定義情報を保持しています。

public class ColumnClass
{
        //カラム名
	public string Name;
        //カラムのCCSID（IBM系の場合）
	public int CCSID;
        //カラムの型名
	public string TypeName;
        //カラムのサイズ
	public int Size;
        //カラムの精度
	public int Precision;
        //カラムのスケール
	public int Scale;
        //nullであれば通常のカラム、数字を指定すると主キー、値が小さい順に主キーとして指定
	public int PrimaryKeyPos;
        //TrueならばNullを許可
	public bool AllowNull;
        //カラムのデフォルト値
	public string Default;
}

ターゲットフィールド側のColumnClassを変更することで、自動作成されるターゲットテーブルの定義を変更しています。

カラムの追加

同様にICreateTableRuleでColumnClassで定義を作成し、aTargetFieldsにInsertまたはAddしてカラムを追加できます。

using System;
using System.Data;
using System.Collections.Generic;
using DBMotoPublic;
using DBMotoScript;

namespace DBRS
{
    public class GlobalScript : IGlobalScript
    {	
    }

    public class MappingRule : IMappingRule
    {
    }

        [CreateTableRuleAttribute("Audit Table New", "監査用のカラムを追加")]
        public bool MyCustomAuditTable (List<ColumnClass> aTargetFields)     
        {         
            ColumnClass colClass;
            //レプリケーションされたトランザクションのIDを記録するカラムを作成
            colClass = new ColumnClass();
              colClass.Name = "TID";
              colClass.AllowNull = true;
              colClass.TypeName = "varchar";
              colClass.Size = 50;
            //2番目に追加
            aTargetFields.Insert(1,colClass);

            //レプリケーションされたトランザクションのタイムスタンプを記録するカラムを作成
            colClass = new ColumnClass();
             colClass.Name = "TTS";
              colClass.AllowNull = true;
              colClass.TypeName = "datetime2";
            //最後に追加
            aTargetFields.Add(colClass);

            //レプリケーションされたトランザクションのユーザIDを記録するカラムを作成
            colClass = new ColumnClass();
              colClass.Name = "UserID";
              colClass.AllowNull = true; 
              colClass.TypeName = "varchar";
              colClass.Size = 20;
            //最後に追加
            aTargetFields.Add(colClass);

            return true;
        }


    public class GlobalEvents : IGlobalEvents
    {
    }
}

ソーステープルの構成：

ターゲットテーブル作成時に作成したスクリプトのルールを設定した場合：

マッピングのカスタマイズ

カラムを追加した場合などには、それに合わせてマッピングも調整する必要があります。これも自動化する場合には以下のようにIMappingRuleで独自ルールを作成します。

using System;
using System.Data;
using System.Collections.Generic;
using DBMotoPublic;
using DBMotoScript;

namespace DBRS
{
    public class GlobalScript : IGlobalScript
    {	
    }

    public class MappingRule : IMappingRule
    {
        [MappingRuleAttribute("Map For Audit Table", "監査用のカラムにマッピングを追加")]
        public bool AuditTableMapping (bool bIsForth, string sSourceName, int iSourceOrdinal, 
        string sSourceType, bool bIsSourcePrimaryKey, bool bIsSourceNullable, 
        int iSourceSize, short sSourcePrecision, short sSourceScale, string sTargetName, 
        int iTargetOrdinal, string sTargetType, bool bIsTargetPrimaryKey, bool bIsTargetNullable,
        int iTargetSize, short sTargetPrecision, short sTargetScale, 
        ref System.Text.StringBuilder sExpression)
        {
            //カラム名がTTSの場合、関数でトランザクションタイムスタンプを指定
            if (String.Compare(sTargetName, "TTS", true) == 0)
            {
                sExpression.Append("[!TransactionTS]");
                return true;
            }
            //カラム名がTIDの場合、関数でトランザクションIDを指定
            else if (String.Compare(sTargetName, "TID", true) == 0)
            {
                sExpression.Append("[!TransactionID]");
                return true;
            }
            //カラム名がUserIDの場合、関数でユーザIDを指定
            else if (String.Compare(sTargetName, "UserID", true) == 0)
            {
                sExpression.Append("[!UserID]");
                return true;
            }
            //上記以外の場合、ソースのカラム名と一致するカラム名にマッピング
            else
            return String.Compare(sSourceName, sTargetName, true) == 0;
        }
    }
...

このルールを使用してマッピングすると自動的に監査用カラムが関数にマッピングされます。

この状態でレプリケーションを行うと以下のようにミラーリングで連携されたものはその際のトランザクションのID、タイムスタンプ、ユーザIDが記録されます。

このように、ICreateTableRuleでテーブル作成のルールをIMappingRuleでカラムのマッピングルールを定義することで、同一構成でなくともまとめてレプリケーションを設定するといった対応も可能です。

また、デフォルトで使用するルールはデータベース接続に対して設定でき、これを変更することで、いちいち選択しなおさなくともルールを適用できます。

タグ: , , ,

Oracle RAC One Node環境を構成してみました ステップ3 別Oracleノードの構成と共有ディスクの設定

投稿日: 2024年4月10日 作成者: climb
Syniti (旧DBMoto)

前回までの記事では、Oracle RAC One nodeを構成するために、Oracle Linuxを導入し、Oracle Grid Infrastructureインストールの下準備を行いました。今回は別Oracleノードと、共有ディスクの構成を行います。
※特に記載がない限り、本記事でのOracle Linuxでの各種コマンドはrootユーザで実行しています。

ーーーーーーーーーーーーーーーーーーーーーーーーーー
▽Oracle RAC One node構成関連ブログ
　ステップ１：Oracle Linux環境の導入
　ステップ２：Oracle Grid Infrastructureインストールの準備
　ステップ３：別Oracleノードの構成と共有ディスクの設定 ←今回の記事
　ステップ４：Oracle Grid Infrastructureの導入
　ステップ５：Oracle RAC One nodeデータベースの作成
ーーーーーーーーーーーーーーーーーーーーーーーーーー

仮想マシンのクローンを使用した別Oracleノードの作成

今まで構成したOra01仮想マシンのクローンを作成することで、Ora02仮想マシンを構成します。仮想マシンのクローンはvSphereの機能で簡単に作成することが可能です。

手順としては、vSphere Client画面から、Ora01仮想マシンを右クリック > クローン作成 > 仮想マシンにクローン作成 を選択します。

仮想マシンのクローン作成ウィザードで、仮想マシン名を「ora02」とし、構成先とする任意のESXiホストやデータストアを指定します。(今回は「ora01」と同一のESXiホスト、データストアを指定しています。)　その他の設定はデフォルトのままウィザードを進め、クローンを作成します。

クローンタスクが完了し、「ora02」仮想マシンが作成されました。

ホスト名とネットワークの指定


各Oracleノードのホスト名とネットワークを指定します。まずは「Ora01」マシンから設定します。ホスト名に関しては下記「hostnamectl」コマンドで設定します。

hostnamectl set-hostname 【ホスト名】

　

ネットワークに関しては、Oracle LinuxのGUI画面の設定 > ネットワークより設定します。今回の環境ではOra01に対して、100のセグメント「192.168.100.131」を、111のセグメント「192.168.111.31」のIPアドレスをそれぞれ設定しました。

　　

「Ora02」マシンに関しても同様の手順で、ホスト名とネットワークを設定します。今回の環境ではOra02に対して、100のセグメント「192.168.100.132」を、111のセグメント「192.168.111.32」のIPアドレスをそれぞれ設定しました。

共有ディスクの設定(マルチライター)

各Oracleノードから参照可能な共有ディスク領域を作成します。今回はvSphereのマルチライター機能を使用して、共有ディスクを構成してみます。


初めに、Ora01仮想マシンに対して、設定の編集画面から、新規仮想ディスクを下記設定で追加します。
ディスクプロビジョニング：シックプロビジョニング(Eager Zeroed)
共有：マルチライター
ディスクモード：独立型:通常

同設定で、ディスク容量「5GB」、「30GB」、「20GB」の3つの仮想ディスクを作成します。

　

作成完了後は、Ora02仮想マシンの設定の編集画面から、「既存」ハードディスクの追加画面を開き、先ほどOra01仮想マシンに対して作成した３つの各仮想ハードディスク(.vmdkファイル)を指定します。

Ora02仮想マシンに追加した各仮想ディスク設定を、下記内容に変更します。
共有：マルチライター
ディスクモード：独立型:通常

これにより、Ora01とOra02に追加した各仮想ディスクが共有ディスク領域として使用可能となります。

共有ディスク領域のパーティション作成

構成した各共有ディスク領域に対して、パーティションを作成します。パーティション作成作業は、Ora01マシンでのみ実施します。

まずは、下記「fdisk -l」コマンドで共有ディスクのデバイス情報を確認します。今回はそれぞれ「/dev/sdb」「/dev/sdc」「/dev/sdd」となっていました。

fdisk -l

それぞれのデバイスにパーティションを作成します。パーティション作成は下記「fdisk 【デバイス名】」コマンドで実施します。実施後は「n」コマンドを押下、デフォルト設定のままEnterを押していき、パーティションを新規作成後、「w」コマンドで終了します。

fdisk 【デバイス名】

これを「/dev/sdb」「/dev/sdc」「/dev/sdd」のすべてのデバイスに対して実行します。再度「fdisk -l」コマンドを実行すると、各デバイスに「/dev/sdb1」「/dev/sdc1」「/dev/sdd1」パーティションが作成されていることを確認できます。

ASM共有ディスクの設定

Oracle ASMLIBを使用し、Orace ASMを構成します。まずは、Ora01マシンで下記「oracleasm configure -i」コマンドを実行し、ASMLIBの構成を行います。設定パラメータに関しては下記です。
Default user to own the driver interface：grid
Default group to own the driver interface：asmadmin
Start Oracle ASM library driver on boot：y
Scan for Oracle ASM disks on boot：y

oracleasm configure -i

　

Ora02マシンにおいても同コマンド、同パラメータ設定で、ASMLIBを構成します。

　

双方のOraマシンの再起動を実行後、双方のOraマシンで「oracleasm status」コマンドを実行し、ステータスが「yes」となっていることを確認します。

oracleasm status

　

次にOra01仮想マシンにおいて、ASM共有ディスクを作成します。ASMディスクは下記「oracleasm createdisk 【ラベル名】 【パーティション】」コマンドより作成できます。今回は各ディスクを下記のように構成しました。
・/dev/sdb1(容量５GB)：クラスタデータ共有領域、ラベル名OCR
・/dev/sdc1(容量30GB)：Oracleデータ領域、ラベル名DATA
・/dev/sdd1(容量20GB)：Oracleリカバリ領域、ラベル名RECO

oracleasm createdisk OCR /dev/sdb1
oracleasm createdisk DATA /dev/sdc1
oracleasm createdisk RECO /dev/sdd1

　

ASMディスク作成後は、双方のOraマシンで「oracleasm scandisks」コマンド実施後、「oracleasm listdisks」コマンドを実行し、設定したラベル名でASMディスク情報が出力することを確認します。

oracleasm scandisks
oracleasm listdisks

　

最後に共有ディスク領域に対してのパーミッションを設定します。双方のOraマシンで下記viコマンドから、UDEVルールファイルを作成します。

vi /etc/udev/rules.d/99-oracle.rules

KERNEL=="sdb1", ACTION=="add|change",OWNER="grid", GROUP="asmadmin", MODE="0660"
KERNEL=="sdc1", ACTION=="add|change",OWNER="grid", GROUP="asmadmin", MODE="0660"
KERNEL=="sdd1", ACTION=="add|change",OWNER="grid", GROUP="asmadmin", MODE="0660"

　

双方のOraマシンの再起動を実行後、「ls -la /dev | grep asm」コマンドよりgridユーザやasmadminグループに対してパーミッションが設定されていることを確認します。

ls -la /dev | grep asm

　

これで別Oracleノードと共有領域の構成が完了しました。
次回のブログでは、いよいよOracle Grid Infrastructureのインストールを行っていきます。

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

タグ: , , ,

GlueSyncでNoSQL活用を加速：通知アラート、ログ、モニタリング

投稿日: 2024年3月14日 作成者: climb
GlueSync MOLO17

GlueSyncはログ、アラートをLogbackで実装しています。これにより、ログをコンソールのみでなくファイルとして出力、エラーレベルのものはメール通知するといった対応が可能です。

また監視についてはPrometheus 互換のメトリクスをサポートしていますので、/metricsエンドポイント介してPrometheus で監視できます。

今回はそれぞれの構成を具体的に紹介していきます。

続きを読む →
タグ: , , , , , , ,

GlueSyncでNoSQL活用を加速：データモデリング編

投稿日: 2024年2月16日 作成者: climb
GlueSync MOLO17

前回はRDBMSからNoSQLへの連携を行うためにGluesyncのデプロイと単純なレプリケーションを構成しました。

GlueSyncでNoSQL活用を加速：導入編

しかし、RDBMSからNoSQLにデータを連携する際の大きな課題はそのデータ形式の違いです。テーブル構造でデータを保持しているRDBMSからNoSQLのJSON形式にどのように落とし込んでいくかといった点が課題になります。

  • 不要カラムの除外
  • 長すぎるカラム名などの変更
  • 複数カラム、複数テーブルにわたるデータの結合
  • ネストしたJSONへの連携

このような課題をGluesyncのデータモデリングは解決します。また、データモデリングはローカル キャッシュや Gluesync 内のいかなる形式の永続化も必要とせずにオンザフライで実行されるため、プロセス全体がより高速で、安全で、一貫性のあるものになります。

続きを読む →
タグ: , , , , , ,

GlueSyncでNoSQL活用を加速：導入編

投稿日: 2024年1月29日 作成者: climb
GlueSync MOLO17

GlueSyncはデータレプリケーションツールですが、既存のソフトウェアと大きく異なり、以下の点に特化しています。

  • クラウドネイティブでステートレスなコンテナとして動作
  • NoSQLやビッグデータへのデータ連携

コンテナで動作し、DockerやKubernetes環境で簡単に実行できるという点で実装を容易にしつつ、RDBMS上のテーブルに格納されているデータをどのようにNoSQL上のJSON形式に落とし込んでいくかといった点に柔軟に対応したツールです。

今回は実際にこのGlueSyncをDocker環境で実行してみたいと思います。

続きを読む →
タグ: , , , , , ,

Entrust KeyControl Vault for Oracle

投稿日: 2023年12月23日 作成者: climb
Entrust(旧Hytrust） Oracle

Entrust（旧HyTrust) KeyControl とOracle Database TDE暗号化鍵(キー)によるデータの保護

概要

セキュリティ侵害の際、攻撃者の主な目的は、一見保護されているように見えるデータベースにアクセスし、大量の情報を盗み出すことにあります。。ネットワークの保護、データベースへのアクセス制御の確保、テーブルに保存されたデータの暗号化など、徹底した防御が必要なのです。

オラクル・データベース・ソリューションは、Transparent Data Encryption (TDE) として知られるネイティブ暗号化機能を提供します。TDEは、データベースとログファイル全体を暗号化します。TDEは、データベース全体のバックアップとデータポンプ・エクスポートを暗号化し、Oracle Recovery Manager (RMAN)およびData Pump Export/Importと統合します。

強固なデータ・セキュリティを確保するためには、PCI DSS（Payment Card Industry DataSecurity Standard）などのコンプライアンス要件を満たすために、鍵を頻繁にローテーションし、安全に保管する必要があります。TDEと外部暗号鍵管理の組み合わせは、PCI DSSやその他のコンプライアンス基準の「職務分離」要件に貢献します。

Entrust KeyControl Vault for Databases を使用することで、企業は暗号鍵を容易に大規模管理することができます。米国情報処理標準規格（FIPS）140-2認定のプラットフォームを使用したVaultは、鍵の保管、バックアップ、配布、ローテーション、鍵の失効など、暗号化鍵のライフサイクルを自動化することで、Oracleデータベースの暗号化を簡素化します。

主な特徴

– FIPS 140-2認定保証を使用したTDEキーの保護

– テーブルスペースとカラムレベルの暗号化をサポート

– 自動ログインウォレットのサポート

– Oracle Real Application Clusters (Oracle RAC)のサポート

– オンデマンドの鍵（キー）ローテーション

– 仮想アプライアンスとして展開

– アクティブ・アクティブ・クラスタによる高可用性（HA）のサポート

– 簡単なセットアップと統合

– 職務分離、最小権限、マルチテナントをサポート

– （オプション）FIPS 140-3 レベル3のハードウェア鍵保護

– (オプション) NIST 800-130およびその他の標準に対応した自動コンプライアンスエンジン標準

ユーザの利益

最高レベルの保証でデータベースを保護

Oracle TDEは、オペレーティング・システム管理者がデータベース・ファイルの内容を読み取ることで、機密性の高いデータベース情報に直接アクセスすることを防ぎますが、他の暗号化ソリューションと同様に、データを暗号化する鍵が適切に保護されていることが、システム全体のセキュリティにとって極めて重要な要素となります。

KeyControl Vault for Databasesは、暗号鍵をデータとは別に安全なプラットフォームに保管することで、暗号鍵を安全に保護します。

さらに、KeyControlは、ロールベースの権限を要求し、セキュリティとデータベース管理を分離することで、内部セキュリティ・ポリシーを強化します。

鍵のライフサイクル管理の簡素化

データベース・ベンダーは鍵管理を提供しているますが、この機能はそのベンダーの特定のデータベースにしか対応していません。データベースの数が増え、データベース・ベンダーが多様化するにつれて、鍵管理はより複雑になっています。

管理者は複数のベンダーが提供する多種多様なデータベースの暗号化キーを管理するという、複雑でコストのかかるタスクに直面しています。

Entrust KeyControl は鍵のローテーションを自動化し、鍵の管理をさらに簡素化します。オンプレミス環境とクラウド環境のすべてのデータベースに対して1つの統一された鍵管理ソリューションを持つことで、鍵管理プロセスを合理化し、エラーや不正行為のリスクを低減することができます。

KeyControl Compliance ManagerとHSMを使用した規制要件へのコンプライアンスの促進

サイバー脅威だけでなく、複雑化する規制環境も企業にリスクをもたらしています。

法的要件や標準へのコンプライアンスを確保することは、データベース暗号化管理ツールだけでは現実的でないことが多くなっています。

Entrust KeyControl Compliance Managerは、NIST 800-57 などの標準への準拠をサポートする自動的なアプロー チを提供することで、データ保管庫の鍵管理機能を拡張します。さらに、Entrust KeyControl は、暗号化鍵の高度な保証保護機能を提供します。FIPS 140-3レベル3のnShield HSMは、PCI DSSやHIPAA（Health InsurancePortability and Accountability Act）などの標準や規制への準拠を容易にします。KeyControlは、どこでどのような規制が適用されようとも、コンプライアンスの達成と維持を支援し、セキュリティの向上とユーザのリスク管理を実現します。

どのように機能するのか？

Oracle TDE は、列レベルまたは表領域レベルでの暗号化を可能にします。オラクルは、以下のような2層のキー・アーキテクチャを実装しています。

• データベース用KeyControl Vaultに保存された単一のマスター暗号化キー（MEK：Master Encryption Key）

• オラクル・データベース内に保存されている複数のデータ暗号化キー（DEK：Data Encryption Key）

MEKとDEKを分離することで、セキュリティレベルを高め、マスターキーのローテーションを容易にします。

MEK は、データベースが生成する DEK を暗号化します。DEK は列や表領域のデータを暗号化します。これらの MEK は、KeyControl Vault で一元管理され、鍵へのアクセス制御を実施します。

 

 

  

 

 

 

 

 

ハイレベルな観点から、表領域の暗号化は次のように行われます：

1. セキュリティ管理者は、Oracle Database Server Configuration を変更することで、外部鍵管理による TDE を有効にします。TDE が有効になると、管理者は TDE MEK を生成するコマンドを実行します。

2. デー タ ベース エン ジ ンは、 KeyControl デー タ 保管庫か ら MEK の生成を要求します。こ の鍵は DEK を暗号化す る ために使用 さ れ、 Oracleデー タベース の外のデー タ 保管庫に格納 さ れます。

3. データベース管理者は、データベース内に暗号化された表領域を作成します。デー タ ベース エン ジ ンは表領域を暗号化する対称 DEK を生成 し ます。

4. データベース・エンジンは、KeyControl Vault にある、以前に生成された MEK を使用した DEK の暗号化を要求します。

5. データベース・エンジンは暗号化された DEK を受け取り、データベースに格納します。


MEKがローテートされた場合、すべてのデータを再暗号化する必要はありません。DEKだけ
がMEKによって再暗号化されます。

技術仕様

対応データベース：

• Oracle 11g R2、Oracle 12c、Oracle18c、Oracle 19c

対応暗号アルゴリズム：

• 対称型 – AES 128ビット、192ビット、256ビットの鍵長を含む

管理と監視：

•Web UIとRest APIによる一元管理
• SyslogとSplunkの統合

対応プラットフォーム：

• プライベートクラウドプラットフォーム：vSphere、vCloud Air（OVH）、VCE、VxRail、NetApp、Nutanix
• パブリッククラウドプラットフォームAWS、IBM Cloud、Microsoft Azure、VMware Cloud (VMC) on AWS、Google Cloud Platform (GCP)
• ハイパーバイザーのサポートESXi、KVM

認定：

• FIPS 140-2レベル1認定
• FIPS 140-2レベル3またはeIDAS CC EAL4+構内またはサービスとしてのEntrust
nShield HSMによるコンプライアンス

Entrust KeyControlプラットフォーム

Entrust KeyControl Vault for Databasesは、オンプレミス、マルチクラウド、ハイブリッドの仮想化環境において、暗号化ワークロードの鍵ライフサイクルを大規模に管理するために設計された製品群の一部です。

この件に関するお問い合わせはこちらへ

タグ: , , , , , , , , ,

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

投稿日: 2023年12月11日 作成者: climb
Syniti (旧DBMoto) リリースノート

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

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

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

投稿日: 2023年12月11日 作成者: climb
Syniti (旧DBMoto) リリースノート

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

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

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

投稿日: 2023年12月11日 作成者: climb
Syniti (旧DBMoto) リリースノート

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

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

ドキュメント・データベースは何か？

投稿日: 2023年11月26日 作成者: climb
MOLO17 データベース

ドキュメント・データベースは、柔軟性の高いNoSQLタイプのデータベースです。JSONのようなドキュメントにデータを格納し、様々なサイズや構造を持つことができるため、複雑なデータを格納するのに適しています。

ドキュメント・データベースは、大量のデータのクエリーと保存を必要とするアプリに便利です。このようなデータは、ゲームアプリケーション、ソーシャルメディアアプリケーション、ウェブアプリケーションなど、半構造化または非構造化であることがあります。このようなタイプのデータベースは、非リレーショナル（またはNoSQL）データベースとも呼ばれます。

NoSQL（非リレーショナル）データベース

NoSQLデータベースには、従来のリレーショナル・データベースとは大きく異なる点がいくつかあります。リレーショナル・データベースは通常、行と列が固定されたテーブルにデータを格納します。行はレコード全体を表し、列はレコードの属性を表します。一方、NoSQLデータベースでは、データをグラフ、キーと値のペア、ドキュメントに格納することができます。

ドキュメント・データベースの利点

ドキュメント・データベースには、以下のような利点があります：

●柔軟性： さまざまなサイズや構造のデータを格納できるため、複雑なデータの格納に適している。
●拡張性： アプリケーションの要件に合わせて簡単に拡張できる。
●パフォーマンス： これらのデータベースは、特に大量のクエリを処理する際に非常に高いパフォーマンスを発揮します。
●使いやすさ： 特にSQLに不慣れな開発者にとっては、リレーショナル・データベースよりも使いやすいことが多い。

ドキュメント・データベースの利点を考慮すると、その人気と使用量は増加の一途をたどっています。

ドキュメントデータベースの例

人気のあるドキュメントデータベースには以下のようなものがあります：

●Amazon DocumentDB: MongoDBをベースとしたフルマネージドのドキュメントデータベースサービス。高可用性、スケーラビリティ、セキュリティを提供。
●MongoDB: 開発者に広く利用されているオープンソースのドキュメントデータベース。高い柔軟性とスケーラビリティで知られている。
●CouchDB：分散可能でフォールトトレラントなオープンソースのドキュメントデータベース。
●DynamoDB：フルマネージドのNoSQLデータベースサービスで、高いパフォーマンスと低レイテンシーを実現するように設計されている。1秒間に大量のリクエストを処理できる。

これらのデータベースはすべてNoSQLであるため、SQLデータベースとは大きく異なる点があります。

SQLデータベースとの比較
ドキュメント・データベースとSQLデータベースの主な違いは、データの保存方法にあります。ドキュメント・データベースはデータをドキュメントに格納し、SQLデータベースはデータをテーブルに格納します。このため、両者の間にはいくつかの顕著な違いがあります。

以下は、ドキュメント・データベースとSQLデータベースの比較表です。

Feature Document database SQL database
Data storage Documents Tables
Data structure Flexible Rigid
Queries JSON-like queries SQL queries
Performance Very performant for handling complex queries Less performant for handling complex queries
Ease of use Easier to use for developers who are not familiar with SQL Harder to use for developers who are not familiar with SQL

JSONライクなドキュメントに格納されるデータ

ドキュメント・データベースにドキュメントを格納するのは、JavaScript Object Notation（JSON）オブジェクトを使うのと似ています。JSONは軽量なデータ交換フォーマットで、読み書きも簡単です。この類似性により、ドキュメント・データベースは、人間にとって読みやすいデータを保存する必要があるアプリケーションに適した選択肢となります。ここでは、JSONのような特性を持つドキュメントデータベースを使用するメリットをいくつか紹介します。

人間がデータをモデル化する方法に自然に対応する

ドキュメントは、ユーザープロファイル（名前、電子メールアドレス、電話番号など）のような複雑で構造化されていないデータをモデル化するための自然な方法です。

Example data showing product info

柔軟なスキーマとインデクシング

ドキュメント・データベースは柔軟なスキーマを持っている。データベースを再作成することなくデータ構造を変更できるため、進化するアプリケーションに適したソリューションです。固定されたスキーマがないため、コードでリレーションシップを定義する柔軟性があり、テーブル定義の制限に縛られることがありません。

Example data for a customer purchase

インデックスの作成とデータの保存方法は、クエリーのスピードとパフォーマンスの最適化を実現します。特定のデータ型は、このフォーマットと構造に最適です。

表現力豊かなクエリー言語

ドキュメント・データベースは通常、表現力豊かなクエリ言語を備えており、ユーザーはさまざまな方法でデータをクエリできます。これにより、複雑なデータや構造化されていないデータも簡単に見つけることができます。

Query and retrieval for unstructured data example

非構造化データのクエリーと検索はSQLデータベースとは異なり、固定されたスキーマや一連の関係に縛られない、非常に柔軟で表現力豊かなクエリーが可能だからです。

タグ: ,

Oracle RAC One Node環境を構成してみました ステップ2 Oracle Grid Infrastructureインストールの準備

投稿日: 2023年10月23日 作成者: climb
Syniti (旧DBMoto)

前回の記事では、Oracle RAC One nodeを構成するためのOracle Linuxの導入までを行いました。今回はOracle LinuxにOracle Grid InfrastructureやOracle DBを導入するための準備を行っていきます。
※最後の環境変数の作成以外は、rootユーザで作業を行います。

ーーーーーーーーーーーーーーーーーーーーーーーーーー
▽Oracle RAC One node構成関連ブログ
　ステップ１：Oracle Linux環境の導入
　ステップ２：Oracle Grid Infrastructureインストールの準備 ← 今回の記事
　ステップ３：別Oracleノードの構成と共有ディスクの設定
　ステップ４：Oracle Grid Infrastructureの導入
　ステップ５：Oracle RAC One nodeデータベースの作成
ーーーーーーーーーーーーーーーーーーーーーーーーーー

yumコマンドによる必要なパッケージの導入

下記yumコマンドを実行し、必要なソフトウェアパッケージを導入します。

yum install -y bc*
yum install -y binutils*
yum install -y compat-libcap1*
yum install -y compat-libstdc++*
yum install -y elfutils-libelf*
yum install -y fontconfig-devel*
yum install -y glibc*
yum install -y ksh*
yum install -y libaio*
yum install -y libXrender*
yum install -y libXi*
yum install -y libXtst*
yum install -y libstdc++*
yum install -y python*
yum install -y targetcli*
yum install -y gcc*
yum install -y oracleasm
yum install -y oracleasm-support

カーネル設定の変更

下記viコマンドから、Oracle用のsysctl.confファイルを作成し、カーネルパラメータを変更します。

vi /etc/sysctl.d/97-oracle-database-sysctl.conf

fs.aio-max-nr = 1048576
fs.file-max = 6815744
kernel.shmall = 2097152
kernel.shmmax = 5368709120
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
net.ipv4.ip_local_port_range = 9000 65500
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048576
kernel.panic_on_oops = 1

その後、下記コマンドを実行し、設定を反映させます。

/sbin/sysctl --system
/sbin/sysctl -p

SE Linuxやファイアウォール、時刻同期の無効化

各種OS側の既存設定を無効化していきます。

まずは、下記コマンドでSE Linuxを停止させます。

setenforce 0

下記viコマンドから、configファイルを開き、「SELINUX=disabled」に変更し、自動起動を無効化させます。

vi /etc/selinux/config

SELINUX=disabled

下記コマンドからFirewalldとavahi-daemonを停止させます。

systemctl stop firewalld
systemctl disable firewalld
systemctl stop avahi-daemon
systemctl disable avahi-daemon

下記コマンドから、時刻同期を無効化します。

systemctl stop chronyd
systemctl disable chronyd
mv /etc/chrony.conf /etc/chrony.conf.org

名前解決のためのhostsファイルの記載

名前解決のため、hostsファイルへの記載を行います。今回の環境では100のセグメントをパブリック用、VIP用、SCAN用に、111のセグメントをプライベート(ASM)用に構成しているため、下記の用に設定しました。

vi /etc/hosts

### Oracle Public IP
192.168.100.131 ora01
192.168.100.132 ora02

### Oracle VIP
192.168.100.133 ora01-vip
192.168.100.134 ora02-vip

### Oracle SCAN
192.168.100.136 ora-scan
192.168.100.137 ora-scan

### Oracle Private IP
193.168.111.31 ora01-pr
193.168.111.32 ora02-pr

OSグループの作成

下記コマンドより、OSグループを作成します。

groupadd -g 54321 oinstall
groupadd -g 54322 dba
groupadd -g 54323 backupdba
groupadd -g 54324 oper
groupadd -g 54325 dgdba
groupadd -g 54326 kmdba
groupadd -g 54327 asmdba
groupadd -g 54328 asmoper
groupadd -g 54329 asmadmin
groupadd -g 54330 racdba

gridユーザとoracleユーザの作成

下記コマンドより、Oracle Grid Infrastructureインストールに使用するgridユーザと、Oracle DBインストールに使用するOracleユーザを作成します。

useradd -u 1500 -g oinstall -G  dba,asmdba,backupdba,dgdba,kmdba,racdba,asmadmin grid
useradd -u 1600 -g oinstall -G dba,backupdba,oper,dgdba,kmdba,asmdba,racdba oracle

作成後、下記コマンドより各ユーザに対してパスワードも設定します。

passwd grid
passwd oracle

各ユーザのリソース制限と、ディレクトリの作成

下記viコマンドより、各ユーザのリソース制限値を設定します。

vi /etc/security/limits.conf

oracle               soft    nofile  1024
oracle               hard    nofile  65536
oracle               soft    nproc   2047
oracle               hard    nproc   16384
oracle               soft    stack   12040
oracle               hard    stack   32768
oracle               soft    memlock   3145728
oracle               hard    memlock   3145728
grid                 soft    nproc   2047
grid                 hard    nproc   16384
grid                 soft    nofile  1024
grid                 hard    nofile  65536
grid                 soft    stack   12040
grid                 hard    stack   32768
grid                 soft    memlock   3145728
grid                 hard    memlock   3145728

下記コマンドより、各ユーザの作業ディレクトリも作成します。

mkdir -p /u01/app/19.0.0/grid
mkdir -p /u01/app/grid
chown -R grid:oinstall /u01
mkdir -p /u01/app/oracle
chown -R oracle:oinstall /u01/app/oracle
chmod -R 775 /u01

各ユーザの環境変数の作成

各ユーザの環境変数を設定します。
まずは、gridユーザの設定を行うため、suコマンドでgridユーザに変更した後、下記viコマンドで設定していきます。

su - grid
vi .bash_profile

umask 022
export LANG=C
export NLS_LANG=American_America.UTF8
export ORACLE_BASE=/u01/app/grid
export ORACLE_HOME=/u01/app/19.0.0/grid
export ORACLE_SID=+ASM1
export PATH=$ORACLE_HOME/bin:$ORACLE_HOME/OPatch:$PATH
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH

次に、oracleユーザの設定を行うため、suコマンドでoracleユーザに変更した後、下記viコマンドで設定していきます。

su - oracle
vi .bash_profile

umask 022
export LANG=C
export NLS_LANG=American_America.UTF8
xport ORACLE_BASE=/u01/app/oracle
export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1
export PATH=$ORACLE_HOME/bin:$PATH
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH
export ORACLE_SID=orcl_1
export ORACLE_UNQNAME=orcl

これでOracle Grid InfrastructureやOracle DBを導入するための前準備は完了です。次回のブログでは、２台(ノード)目のOracle Linuxの構成と、共有ディスク設定を行っていきます。

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

タグ: , , ,

データベース監視の将来 – 今後におけるAIOpsの役割

投稿日: 2023年10月21日 作成者: climb
データベース

IT先任者は、より効率的なITシステムをサポートするために、大量のデータを取り込み、データソース間のイベントを相関させ、問題を検出し、新しいテクノロジーで解決するように設計されたツールを絶えず必要としてています。これがAIOpsの機能にあたります。AIOps（Artificial Intelligence for IT Operations：IT運用のための人工知能）とは、人工知能（AI）と機械学習（ML）テクノロジーを使用して、ITのさまざまな側面を強化し、自動化することです。現代のITインフラと環境の複雑さを考えると、AIOpsは自動化を推進し、生産性を向上させ、効率を拡大する上で重要な役割を果たします。大企業が扱う規模のデータベースを運用するには、システムの可用性、パフォーマンス、スケーラビリティを確保するために、より高度なインテリジェンスを適用する必要があります。

データベースの監視における”AIOps”

まず、AIOpsがミッションクリティカルなデータベースのモニタリングにどのような影響を与えるか、最も基本的な例から考えてみます。eコマース・サイトに深刻なサービス停止が発生し、毎分数百万ドルの収益が失われているとします。根本的な原因はクエリのレスポンスタイムの変化にあると突き止めることができましたが、その結果、監視ソフトウェアがアプリケーションとインフラストラクチャ全体の複数のレベルからものすごい数のアラート（アラートストーム）を生成することになります。AIOpsは、スタックのさまざまな部分で異常を特定し、トポロジー分析と時間分析によって懸念されるアラートを絞り込むことで、アラートノイズを低減します。その後、イベントを相関させて根本原因を特定し、組織の平均応答時間（MTTR）を大幅に短縮します。

AIOpsが役立つもう1つの例は、将来のインシデントを予測し、修復を自動化することです。データが増大するにつれ、ストレージ要件も増大します。データベースのパフォーマンスは、ストレージ・レイヤーの容量とパフォーマンスに大きく依存します。機械学習予測モデルによるストレージ予測により、データベース管理者は停止やパフォーマンスへの影響を防ぐことができます。

データはあらゆるアプリケーションのイニシアチブの中心であるため、あらゆるアプリケーションはデータベース・アプリケーションであると言っても過言ではありません。現代の技術インフラは分散化が進み、データ量は驚異的な速度で増加しているため、データベースの問題の根本原因分析は複雑です。AIOpsは、このような問題の検出、分離、解決までの平均時間を短縮する上で大きな役割を果たすでしょう。

アラートノイズとストレスの軽減

AIOpsは、機械学習と分析を使用して、さまざまなソースから収集された膨大な量のデータを分析します。正常な動作と異常な動作を区別し、誤検知を減らし、不要なアラートを排除します。そうすることで、AIOpsは監視ツールに関連するノイズを減らし、IT管理者が重要な問題に集中できるようにします。AIOpsはまた、重大性と潜在的な影響に基づいてアラートに優先順位を付けることができます。これにより、ノイズを削減し、重要な問題が直ちに注意を受けるようにすることで、アラートによる疲労を防止します。

異常検知と予測

AIOpsは、パフォーマンスの根本的な問題を示す可能性のある異常なパターンや動作を特定することに優れています。季節性や基準しきい値とともに過去のデータから学習し、将来の傾向を正確に予測します。異常は、ユーザ・アクティビティの突然の急増、リソース競合、非効率的なクエリ、ハードウェア障害など、さまざまな要因によって引き起こされる可能性があります。リソースの使用率、クエリの応答時間、およびその他のパフォーマンス指標を予測することにより、ITチームはリソースを積極的に割り当て、潜在的なボトルネックを防ぐことができます。

根本原因の分析

パフォーマンス問題の根本原因を特定することは、多くの場合、時間がかかり複雑です。AIOpsは、高度な相関技術とトポロジー情報を採用して、さまざまなメトリクス、ログ、イベント間の関係を分析します。これにより、根本原因の分析が迅速化され、より迅速な問題解決が可能になります。

自動化とインシデント対応

AIOpsは、データベースの可観測性によってスマートなインシデントを作成することで、インシデントの検出と対応を自動化します。これにより、相関するイベントをリアルタイムで特定し、自動応答や通知をトリガーすることができます。このプロアクティブなアプローチにより、ITチームはエンドユーザに影響が及ぶ前に潜在的な問題を解決することができます。さらに、AIOpsは自動化されたインシデント・トリアージを促進し、適切なチームに迅速にアラートが送られるようにします。さらに、インシデント対応のワークフローをオーケストレーションすることで、適切なエンジニア・チームが関与し、インシデントを迅速に解決するために必要な手順が踏まれるようにします。AIOpsは、繰り返し発生するインシデントを特定し、過去の修復を相関させることで、パフォーマンス最適化の機会に関する洞察をさらに深めることができます。

データベース管理のライフサイクル観察における優位性

AIOpsは、環境全体のさまざまなメトリクス、ログ、イベントを監視することで、データベース・パフォーマンスの観察を支援します。期待される動作からの逸脱を特定し、パフォーマンス低下につながる可能性のある異常を検出します。

チューニング

AIOpsを使用すると、ITチームは予測的な洞察に基づいてデータベースの構成とリソース割り当てを微調整できます。これにより、リソースを過剰にプロビジョニングすることなく、最適なパフォーマンスを実現します。

管理

AIOpsは、負荷分散、クエリの最適化、インデックスのチューニングなどのルーチン管理タスクを自動化します。また、リソース要件を正確に予測することで、キャパシティ・プランニングを支援します。

拡張性

データベースはダイナミックに拡張する必要があるため、AIOpsは追加リソースが必要になるタイミングを予測する上で重要な役割を果たします。これにより、過剰利用を防ぎ、シームレスなユーザ・エクスペリエンスを実現します。

安全性

AIOpsは、セキュリティ侵害を示す異常なパターンを特定することでセキュリティを強化します。データの完全性を損なう可能性のある不正アクセスの試行や異常な動作の検出に役立ちます。

タグ: , , , ,

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

投稿日: 2023年9月21日 作成者: climb
Syniti (旧DBMoto)

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

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

　　

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

ーーーーーーーーーーーーーーーーーーーーーーーーーー
▽Oracle RAC One node構成関連ブログ
　ステップ１：Oracle Linux環境の導入 ← 今回の記事
　ステップ２：Oracle Grid Infrastructureインストールの準備
　ステップ３：別Oracleノードの構成と共有ディスクの設定
　ステップ４：Oracle Grid Infrastructureの導入
　ステップ５：Oracle RAC One nodeデータベースの作成
ーーーーーーーーーーーーーーーーーーーーーーーーーー

　　

１．今回の検証環境について

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

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

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

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

　

２．各Oracleソフトウェアのダウンロード

まずは、必要な各Oracleソフトウェアをダウンロードします。今回はOracle Linux 7.9とOracle 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

　　

３．仮想マシン(Oracleノード)の作成

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

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

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

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

　　

４．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

タグ: , , ,