[DBMoto/SynitiDR]Ritmoトレース取得手順(AS/400, z/OS, Linux, AIX, Windows向けDB2)

DB2(AS/400, z/OS, Windows, Linux, AIX)関連でDBMotoにてエラーが発生した場合には、詳細調査のために接続ドライバであるRitmoのトレース取得を依頼させていただく場合があります。

●AS/400用DB2向けRitmo/iトレース取得手順

1. DBMoto Data Replicator を停止し、DBMoto Management Centerを閉じます。
※Synitiの場合には、Syniti Replicate Agentを停止し、Syniti Management Centerを閉じる

2. C:\Program Files\HiT Software\DBMoto V8\Ritmo_i\Ritmo_i.xmlを開きます。
※上書き禁止で開けない場合はデスクトップ等へコピーしてから開きます。
※Synitiの場合には、C:\Program Files\Syniti\Data Replication V9\Ritmo_i\Ritmo_i.xmlを開く
20150514-01

3. traceflagをTrueに変更し保存します。2にてコピー先のファイルを編集した場合は元の場所へ上書きします。
20150514-03

4. 問題の事象を再現させることで、トレースファイルC:\Sql400.trcが記録されます。
20150514-05

5.トレースの取得後は、トレースを無効化します。(traceflagをFalseへ戻します)

●z/OS, Linux, AIX, Windows用DB2向けRitmo/DB2トレース取得手順

1. DBMoto Data Replicator を停止し、DBMoto Management Centerを閉じます。

2. C:\Program Files\HiT Software\DBMoto V8\Ritmo_DB2\lib\RitmoDb2.xmlを開きます。
※上書き禁止で開けない場合はデスクトップ等へコピーしてから開きます。
20150514-05

3. traceflagをtrueに変更し保存します。2にてコピー先のファイルを編集した場合は元の場所へ上書きします。
20150514-04

4. 問題の事象を再現させることで、トレースファイルC:\sqldb2_trace_****.txtが記録されます。
20150514-06

5.トレースの取得後は、トレースを無効化します。(traceflagをfalseへ戻します)

コメントする -->

[DBMoto]API(C#, VB, C++)の開発環境構築手順 ~APIを使用してバッチからジョブを制御~

DBMotoではC#, VB, C++の各APIを利用可能です。
APIを使用しない場合でも、グラフィックユーザインターフェースのGUI管理ツールを使用することで簡単に設定・運用が可能です。

さらにAPIを使用することで以下のことが実現可能となります。
・外部からバッチでジョブを制御
・外部の別システムとの連携
・既存アプリケーションへの組み込み
repli_api[1]

ここではAPIで開発を行うための環境構築手順をご紹介します。

1. Visual Studioをダウンロード・インストールします。ExpressのWindows Desktop版もCommunity版もどちらでも開発可能です。
https://www.visualstudio.com/downloads/

2. Visual Studioを起動し、「新しいプロジェクト」を選択します。
20150416-1

3. C#で開発(推奨)する場合、Visual C#のコンソールアプリケーションを選択します。
20150416-2

4. ソース編集画面が開きます。
20150416-3

5. DBMotoのAPIライブラリを追加するため、「参照設定」⇒「参照の追加」を選択します。
20150416-4

6. “C:\Program Files\Syniti\Data Replication V9\APILibrary.dll”を追加します。
20150416-5

7. “プロジェクト名\bin\Debug”内に”C:\Program Files\Syniti\Data Replication V9\DBMoto.server.config”をコピーします。
※レプリケーションの実行件数や結果を取得したい場合には、”C:\Program Files\Syniti\Data Replication V9\providers.xml”もコピーします。
20150416-6

8. ソースコードを記述して保存後、デバッグ開始をクリックします。
20150416-7

9. コンソール画面が立ち上がるので動作を確認します。
20150416-11

10. コンソール画面が閉じ、正常終了を確認します。
20150416-8

11. バッチファイル等から直接実行する場合はプロジェクト名\bin\Debug内のexeファイルを実行します。
20150416-9

12. 上記のexeファイルを”C:\Program Files\Syniti\Data Replication V9\”内にコピーして実行することも可能です。
20150416-10

タグ:

保護中: Log Server for Oracle設定【DBMoto8.5】

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

保護中: Log Server for Oracle設定【DBMoto8.5】 はコメントを受け付けていません -->

[DBMoto API]外部からレプリケーションやグループを開始・停止するサンプルC#プログラム

DBMoto APIを使用することで、GUIツールであるDBMoto Management Centerからの操作ではなく、バッチを実行することで外部からDBMotoの操作を制御することが可能です。

ここではDBMotoのレプリケーションジョブやグループジョブを外部から制御するプログラムをご紹介します。
これらを使用することで、任意のタイミングでジョブを実行・停止したり、他アプリケーションとの連携が可能となります。

●レプリケーションを有効化・無効化するサンプルC#プログラム

[csharp]
using System;
using System.Collections.Generic;
using System.Text;
using HiTSoftware.DBMoto.Application;
using HiTSoftware.DBMoto.ObjectModel;

namespace APISamples
{
public class SampleReplicationAsynch
{
public static void Main()
{
DBMotoApplication dbmApp = null;
IServer dbmServer = null;
IMetadata currentMetadata = null;

try
{
// 初期設定、サーバ接続
dbmApp = DBMotoApplication.Instance;
dbmServer = dbmApp.Servers["local"];
dbmServer.Connect();

// カレントメタデータのロード
currentMetadata = dbmServer.Metadatas.DefaultMetadata;
currentMetadata.Load(true);

// レプリケーション名
IReplication repl = currentMetadata.Replications["Replication"];

// レプリケーション有効化
if (repl.ReplStatus == ReplStatus.Disabled)
repl.AsynchEnable();

// 待機
System.Threading.Thread.Sleep(3000);

// レプリケーション無効化
if (repl.ReplStatus != ReplStatus.Disabled)
repl.AsynchDisable();

// 待機
System.Threading.Thread.Sleep(3000);
}
catch (Exception e)
{
Console.WriteLine(e.Message);
}
finally
{
if (currentMetadata != null)
currentMetadata.Unload();
if (dbmServer != null)
dbmServer.Disconnect();
if (dbmApp != null)
dbmApp.Dispose();
}
}

}
}
[/csharp]

●グループを有効化・無効化するサンプルC#プログラム

[csharp]
using System;
using System.Collections.Generic;
using System.Text;
using HiTSoftware.DBMoto.Application;
using HiTSoftware.DBMoto.ObjectModel;

namespace APISamples
{
public class SampleGroupAsynch
{
public static void Main()
{
DBMotoApplication dbmApp = null;
IServer dbmServer = null;
IMetadata currentMetadata = null;

try
{
// 初期設定、サーバ接続
dbmApp = DBMotoApplication.Instance;
dbmServer = dbmApp.Servers["local"];
dbmServer.Connect();

// カレントメタデータのロード
currentMetadata = dbmServer.Metadatas.DefaultMetadata;
currentMetadata.Load(true);

// グループ名
IGroup group = currentMetadata.Groups["Group"];

// グループ有効化
if (group.ReplStatus == ReplStatus.Disabled)
group.AsynchEnable();

// 待機
System.Threading.Thread.Sleep(3000);

// グループ無効化
if (group.ReplStatus != ReplStatus.Disabled)
group.AsynchDisable();

// 待機
System.Threading.Thread.Sleep(3000);
}
catch (Exception e)
{
Console.WriteLine(e.Message);
}
finally
{
if (currentMetadata != null)
currentMetadata.Unload();
if (dbmServer != null)
dbmServer.Disconnect();
if (dbmApp != null)
dbmApp.Dispose();
}
}

}
}
[/csharp]

コメントする -->

Amazon AWSクラウド上でのアプリケーションとデータベースのパフォーマンス問題

クラウド上でのスケーラブルなリソースのため、データベース・パフォーマンスの改善に対しては保証がないのが現状です。データベースは複雑で、CPU,メモリー, 最新の高スピード・ストレージを追加してもデータベースのアプリケーション・パフォーマンスに対するボトルネックにならないとの保証はありません。

Database Performance Analyzer (DPA、旧Ignite)は多重次元のパフォーマンス分析を提供する唯一のソリューションで、ヒストリカルなパフォーマンス傾向だけでなく、Amazon AWS EC2 仮想マシン上にディプロイされたOracle, SQL Server, DB2, Sybaseインスタンスの内部構造に対するすぐ使用可能なアドバイスを提供します。

パフォーマンスを理解するキーは最低のパフォーマンスを起こしているSQLステートメント、それらのSQLステートメントのレスポンス・タイム、ウェイト・イベントまたはウェイト・タイプとして知られているリレーショナル・データベース管理システム(RDBMS)内での特殊なステップを含む3重の組み合わせに焦点を合わせる必要があります。

AWS-Performance-Analyzer

今日のRDBMSは数多くのウェイトを含み、現在そしてヒストリカルなウェイト・ベースの分析が無く、ユーザのパフォーマンス改善変更で模範的な手法をとることは不可能です。ウェイト・ベースの分析があればストレージ、ネットワーク、テーブル・ロック、メモリーの遅延のような一般的な問題、さらにパラレル・スレッドのクラスタ・フェイルオーバとシンクロナイゼーションに原因する遅延のような特別な問題を簡単に見つけ出すことは不可能です。

Database Performance Analyzer (DPA)はAmazon EC2上で稼働するSQL Server、 Oracleのようなデータベースのパフォーマンスの分析が可能です。

・アプリケーションが原因しているトータルな「ウェイト・タイム」を日、時間、分単位で可視化できます。
・データベース・パフォーマンス改善へリソースのプロビジョンを相関させることで過度のプロビジョンを回避できます。
・リソースのプロビジョンに係らずデータベース・パフォーマンスを劣化させるロッキングによるクエリー・ブロックの検知できます。
・チューニング・アドバイザは明確で、実行可能なアドバイスを提供します。
・スローダウンの原因であるSQLステートメント、レスポンス・タイム、ウェイト・イベント間で直接な相関性を監視します。

DPAはAmazonクラウドで稼働するデータベースの最適なパフォーナンスを確実にするように必要な可視化を提供します。

AWSクラウドへのDPAのディプロイ

DPAはEC2インスタンス、物理サーバ、仮想マシンにインストール可能です。
ignite8_instll

タグ: , ,

DBMoto独自のLog Serverを用いたOracle差分レプリケーション ~BLOB対応、パフォーマンス向上~【DBMoto Ver8.5新機能②】

Oracleデータベースからミラーリングまたはシンクロナイゼーションを行う際、DBMoto Ver8.5では、従来のLog Miner経由でOracle トランザクションをリードする手法に加え、Oracle Log Server経由で差分レプリケーションを実行できるようになりました。

Oracle Log Serverの処理

このOracle Log Serverとは、Javaを用いてOracleデータベースからログの変更を読み取り、ローカルのフォルダにトランザクションログを格納するコンポーネントです。

DBMotoマシンはOracle Log Serverにより格納されたログに基づいてレプリケーション、つまりソースデータベースの更新や削除をターゲットのデータベースに反映します。

下記が、Oracle Log Serverの主な特徴です。

<メリット>

・Log Miner経由と比べて多くのレプリケーションを処理する際のパフォーマンスが向上

・BLOB型カラムの差分レプリケーションが可能

<対応DB>

・Oracle11g、Oracle12c

試しに弊社環境のDBMotoでミラーリングを行っている間に、ソースのOracleデータベースのBLOB型のカラムを更新しました。

ソースDBのBLOB型更新

ミラーリングが実行され、更新されたバイナリデータがターゲットのデータベースに正しく反映されていることを確認できます。

BLOB型ミラーリング結果

 

 

タグ: , , , , ,

PostgreSQLに対してバルクインサートが可能に【DBMoto Ver8.5新機能①】

DBMoto ver8.5 からPostgreSQLへのバルクインサートが使用可能になりました。これによりDBMotoを使用してPostgreSQLへリフレッシュを行う際に、大幅に時間を短縮できます。
PosgreSQlへの接続設定については下記ブログをご参考ください。

◇DBMotoからPostgreSQLへ接続するには・・・Npgsqlと外部接続の設定
https://www.climb.co.jp/blog_dbmoto/archives/1675

またAmazon Redshiftに対しても基本的にPostgreSQLと同様の接続設定でレプリケーション可能です。
※現在のNpgsql最新版2.3にはRedshiftに接続ができない不具合がございます。
バージョン2.0.14.3のNpgsqlをダウンロードし、そちらをご利用いただきますよう、お願いいたします。
※Amazon Redshiftに対してはバルクインサートはできず、シングルorシミュレートバルクインサートで実施します。

Amazon Redshiftを指定する方法については下記ブログをご参考ください。
◇Amazon Redshiftに対してOracle、AS/400、SQL Server、MySQLなどからデータをリアルタイムにレプリケーション
https://www.climb.co.jp/blog_dbmoto/archives/1707

コメントする -->

保護中: DBMoto 8.5.0.11 リリースノート

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

保護中: DBMoto 8.5.0.11 リリースノート はコメントを受け付けていません -->

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

Oracle RACはデータベースソフトの追加機能の一つで、複数のコンピュータに処理を分散するクラスタリングを実現できます。

Oracle RACを導入することのより、一貫性を保ちながら一つのデータベースを複数のコンピュータで並列に操作できるようになり、負荷分散を図ることができるようになりました。

Rac

RAC ウェイト・イベント

パフォーマンス(性能劣化)問題へのトラブルショートではシステム、ネットワーク等の後に確認するのはウェイト(待ち)・イベントです。シングル・インスタンス・データベースではユーザのレスポンス・タイムが増加したり、データベースでの時間が高比率であれば、原因は見極められます。RAC環境ではGCウェイト・イベントやGlobal Cacheウェイト・イベントの特別なウェイト・イベントがあります。Oracleウェイト・イベントは要求の正確な結果を反映したイベントに起因しています。例えばインスタンスでのセッションがグローバル・キャッシュ内のブロックを探している場合には他のインスタンスでのデータ・キャッシュか、ディスクからリードしたメッセージを受け取っているのか判りません。ウェイトに関連するグローバル・キャッシュ用のイベントはグローバル・キャッシュ・ブロックやメッセージ上の正確な情報を伝えます。クラスタの状況を見るための1ウェイトが必要な時にはウェイト情報は「Cluster Wait Class」という広範なカテゴリにあります。ここにクラスタ用のウェイト情報が集約されます。

Oracle RACでの最も重要なウェイト・イベントは4つの大きなカテゴリに分けられます。

ブロック・オリエンテッド:ブロックが2-way,または3-wayメッセージの結果として受け取っているか:ブロックが1メッセージ、1転送を要求しているリソース・マスターから送られたのか、2メッセージと1ブロック転送を要求して送られたものから3つ目のノードに転送されたのかを示します。また、これらのウェイトはビジー、ピン、ログ・フラッシュ要求が無くても送信されたリモート・キャッシュ・ブロックも示します。

メッセージ・オリエンテッド:インスタンス内でのキャッシュから受け取ったブロックが無いことを示します。代わりにグローバル・グラントはディスクからブロックをリードするためのインスタンスへの許可を与えられます。この時間が長ければ、頻繁に使用されているSQLが大量のディスクI/Oを起こしているか、ワークロードで大量のデータをインサートしていて、新規ブロックのフォーマットが必要な場合です。

コンテンション(Contention)・オリエンテッド:gcカレント・ブロック・ビジーとgc crブロック・イベントが、多くの場合にログ・フラッシュが原因のリモート・インスタンス・処理遅延後のブロックを受け取ったことを示します。高い同時並行性はリモート・インスタンスのセッションによるブロックがピンか妨げられていることを示すgcバッファー・ビジー・イベントによることを証明しています。また同じインスタンスでのセッションがすでにブロックを要求しているとも示しています。

ロード・オリエンテッド:これはブロック・コンテンション(競合)の無い状況で最も頻繁で、GCS内で発生した遅延を示しています。有効なウェイト・タイムとトータルなウェイト・タイムはこれらのイベントが高い場合にパフォーマンス問題の警告時として考慮すべきです。通常は大きな作業セットに対してのインターコネクト、ロード問題、SQL実行が根本的な原因として考えられます。これらのイベントでウェイト・タイムはセッション・スタートからブロックが完了までの全体の往復時間を含みます。

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

RACインスタンスで長時間稼働しているウェイトを分析する手法はシングル・インスタンスと変わりはありませんが、いくつかのRAC専用のステップとスクリプトがあります。

スクリプトにはOracle Supportからダウンロードできる「racdiag.sql」というものがあります。

パフォーマンス問題をトラブルシュートするためのもう1つの信頼できるソースは「v$views」です。RAC環境では確認するべき別のビューとしてgv$views (例 GV$SESSION_WAIT)があります。

●SQLチューニング
SQLチューニングはRAC環境では非常に重要で、しばしばパフォーマンス・ツーニング問題の根本原因となります。80%のパフォーマンス問題はSQLに関連すると云われています。ある資料ではRACデータベースを使用する時にバルク・ロードではサービスか、インスタンス・グループで稼働させるべきとあります。

また他のSQLチューニングの役割としてもっとRACにフレンドリーなコードを開発者はデザインすべきとしています。例えば計画ではデータの分割化と並列化された大容量を大規模テーブルに戻すようなクエリーでは、ロードがインスタンスをまたがって個別に起こるかどうかを判断するテストが必要です。

●クラスター・チューニング
相互接続による遅延とその取戻しに役立つと認識すべきCRSとGRIDに密着して関連する2つの項目があります。もしユーザがOracle 10Gを使用しているならdiagwaitパラメータを13に設定する必要があります。これはcrsd.logのロッギングを増やし、RAC問題のトラブルシュートを手助けします。もう1つはCRSパラメータでCSSミスカウント・パラメータを増加させます。CSSミスカウント・パラメータは相互接続遅延を指摘します。注意してこれを増やしてください。それはユーザはクラスタを望んでいるが失敗する可能性が高いミスカウントがあるケースがあります。これらはあくまでもシステムに依存するので注意ください。

ソース:Oracle RAC Tuning Tips(Kathy Gibbs, Confio Software)

Oracle RACのチューニングを可能とするデータベースのレスポンス分析ツール「Database Performance Analyzer」

タグ: , , , , ,

Oracle Exadataのパフォーマンス Part3: 更なるモニターとクエリーによるチューニング

●チューニングが必要な時に何を確認するか?

Exadataのステートメントをチューニングする時の最初のステップはレスポンス・タイムを確認し、モニターすることです。最初にフォーカスするのは高レスポンス・タイム・クエリーと高から低ウェイト・タイムからの状況です。次はデータベース・レイヤーで利用度と効率性にフォーカスします。チューニングが終わるか、大きな問題が無ければExadataに特化した高度な測定基準とモニターを使用します。多くのオプションからv$views, CELLCLI, OSWatcherで確認します。Exadataでは特定のウェイト・イベントがあります。Exadataのデータベース・コードには追加のウェイト・イベント・ビルドが無いことが重要です。すべてのウェイト・イベントはすべてのデータベース・コードにあり、それはExadata特有を他のシステムではタイム(時間)が割り当てられていません。

Exadataでパフォーマンス問題があった時には、タイム問題があります。OracleはExadataに移行する時はすべてのインデックスを削除するように記述しています。OLAPシステムではそれがうまく行き、クエリーがスピードアップするケースが多くありますが、やみくもにインデックを削除したことでパフォーマンスがが急激に落ちることがあります。OLAPに特化したクエリーをチューニングした場合にExadataの恩恵を全く受けない場合もあります。1つのクエリーで痛い目に合う例もあります。

結論:
Exadataは、Oracleデータベースを同梱しています。チューニングが必要な時は必ず「cell offloading」からスタートしてください。多くの利点が確認できます。次にDBRM, IORM, flash cacheを確認して下さい。設定には少し時間がかかるかもしれませんが、最終的には調査する価値があります。Exadataは常に調整する必要があることを忘れないでください。

タグ: ,

Oracle Exadataのパフォーマンス Part2: DBRM/IORM と Smart Flash Cache

DBRM/IORM

Oracle Exadata取り組みを複雑にしている問題の1つにアプリケーションが単一なハードウェアから統合型のハードウェア・プラットフォームへ移行しているということです。ユーザは1ホストで使用していたアプリケーションは統合型のハードウェア・プラットフォームでは遅くなるという間違った印象を持っています。DBRM(Database Resource Manager)とIORM(I/O Resource Monitor)はこのパフォーマンスに関する懸念を解決する手法です。このリソース・マネージャを使用しなければすべてのセッションは均等になり、単一の高活性のベータベースがリソースを独占し、Exadataインプリメンテーションに非常に重要になります。

DBRMはユーザが現在も使用している同じリソース・マネジャーです。Oracle 11GR2での新機能はデータベース・レベルでCPU使用率をプロビジョンするインスタンス・ケージです。これはデータベースの個別インスタンスでCPU使用をケージ、コントロールできるものです。問題があれば「Resmgr: cpu quantum」ウェイト・イベントを確認できます。もしこのイベントが高ければDBRMがアクティブにCPUの消費量を絞っています。リソース·プランがユーザの望むように使用されていることを確認するためには、モニターするためのV$RSRCビューがあります。

IORMはExadata専用でデータベース・ロードを分離手助けする方法が2つあります。インターデータベースIORMは優先順位との組み合わせで、データベース名で複数のデータベース間での優先順位を管理します。2つ目はIORMカテゴリで、これは新規アトリビュートですが、データベース名で分離することで利用されます。例えばユーザは「oltp_category_batch」と呼ぶカテゴリーを作成することができ、これは2CPU用です。次にこれに1対複数のデータベースをアサインすることができます。3つ目のオプション、設定はイントラデータベースです。ExadataではDBRMプランが有効になった時にデータベースはストレージ・グリッド内のすべてのセルにこのプランの記述を転送します。DBRMが最初に作成される限り、これはデフォルトです。どのオプションをユーザが使用しようともIORMはストレージセル・レベルで管理されます。各セルディスクで「cellsrv」はセルにアサインされた各データベース用の各コンシューマ・グループと各バックグラウンド・プロセス用のIORMキューを保持します。

DBRM_IORM

Smart Flash Cache(スマート・フラッシュ・キャッシュ)

Smart Flash CacheはOracle11GR2から利用可能になったFlash Cacheとは別のものです。フルラックのExadataでSmart Flash Cacheは追加の5TBデータベースを提供し、2つの方法で使用されます。1つ目はキャッシュをより推奨された構成で構成します。2つ目はSmart Flash CacheはASMが使用できるソリッド・ステート・ディスクとして分割します。これはこのストレージ用としての推奨使用方法ではありませんが、設定方法インストラクションはあります。多くの場合、これはredoやテンポラリー・テーブルスペースに使用されていますが、追加キャッシュとしてのSmart Flash Cacheと対比してパフォーマンスを最小限に抑えられます。これを使用するにはイニシャル・パラメータ「cell_flash_cache=keep」を設定する必要があります。「Cellcli」はv$sysstat同様にフラッシュ・キャッシュ使用をモニターに使用できます。

タグ: , , , ,

Oracle Exadataのパフォーマンス Part1:Cell Offloading

Oracle Exadataのパフォーマンスは次のサブセットに分割されます。

●Cell Offloading
  ・Smart Scan
  ・Storage Indexes
  ・HCC(Hybrid Columnar Compression)
●DBRM/IORM
●Smart Flash Cache
●更なるモニターとクエリーによるチューニング

Cell offloading (またはoffloading)はExadataの前にデータベース段階で行われたであろうものがストレージ段階で行われているものを記述するための一般的な用語です。これはおそらく、Exadataを選択する最大の利点です。

Smart Scanでは、Exadataマシン・オペレーションの一部はデータベースにより少ないデータを戻し、I/Oを減少させます。ユーザは「Cell Smart Table Scan」と 「Cell Smart Index Scan」の2つのウェイト・イベントで、Smart Scanをモニターすることができます。Smart Scanからのデータ・フローはSGAプールにバファーできないので、これがデータを高速にリターンする理由の1つです。

SmartScan

ストレージ・インデックス(Storage index)はSmart Scanと連携しています。ストレージ・インデックスの目的はデータ量を削減することではなく、データをリードする時間を削減するようにデザインされたいます。ストレージ・インデックスは物理セル・ストレージの特定領域内のデータについて情報を保持するイン・メモリー構造です。これらはストレージ・サーバへクエリー述語を受け渡し、ストレージ・インデックスは各1MBストレージ領域の値のマップを保持しているのでプレ・フィルターとして考えてください。一致する行を含めることができない任意の領域はリードすることなく除外することができます。またストレージ・インデックスはパーティションのタイプの1つと考えられます。ディスクI/ Oは、パーティション除去に類似した方法で除去されます。パーティションは関連するレコードを含むことができないなら、パーティションのブロックはリードされません。同様にストレージ領域が関連するレコードを含んでいなければ、ストレージ領域はリードされません。これはよくOLAPシステムに使用されます。本質的にユーザはストレージ・インデックスを作成することはできません。ストレージ・セルが繰り返しリクエストを受け取った後に自動的に作成されます。これらのインデックスはメモリーに保存されるので、Exadata のリブート後には消えて、再構築する必要があります。

HCC (Hybrid Columnar Compression)は保存したデータの行と列順序方式の両方を組み合せを利用した技術です。HCC行のセットに保存された「compression unit」と呼ぶロジカル構成を作成することで行われます。データがロードされた時に行セット用の列バリューは一緒にグループ化され、圧縮されます。行セット用の列バリューは圧縮後に圧縮ユニットにストアーされます。ローディングのスピードを最大化するためにはユーザは「DW」ローディング技術を使用する必要があります。従来型のDML (Data Manipulation Language)オペレーションを愛用することもできますが、ロードは遅くなります。3つのタイプのHCCがあります。最初のQuery LowはLZO圧縮アルゴリズムを使用し、4x圧縮率が想定されています。2番目がQuery Highでzlibまたは gzipを使用し、6x圧縮率があります。3番目がArchive Lowで、gZipを使用し、高圧縮レベルです。この3つ目のオプションはロードが難しく、パーティションまたはデータセットがアップデートされない後にロードしなければ使用されません。

タグ: , , ,

オラクルのExadataを最大限に活用するためのベスト・プラクティス

Exadataのベスト・プラクティスに関してすでに多くの情報があるので、ここでは「Must Have」と「Don’t do」リストといくつかのベスト・プラクティスをリストアップします。
注:これらの内容は変化しますので、最終的には最新のオラクル・ドキュメントを確認ください。

●Must have Bundle Patch 5. (See Note: 888828.1 for latest patch.)
●Must have ASM to use Exadata; Automatic Storage Management (ASM) serves as the filesystem and volume manager for Exadata.
●Must have the correct data center cooling! This is very important (I suggest doing some research on this).
●Must have three floor tiles on a raised floor (must support 2219 lbs./964 kg) with holes (cooling) for a full rack (between 1560 CFM and 2200 CFM front to back). You don’t want to melt it! All of this is subject to change so please check the latest specifications.
●Must have the correct power needs.
●Must have Oracle Linux 5.3 (x86_64) and Oracle DB 11.2 (currently).
●Must have RMAN for backups.
●Consider StorageTek SL500 Tape backup (many positive reviews but pricey).
●Don’t add any foreign hardware or … no support!
●Don’t change BIOS/firmware or … no support!

他のベスト・プラクティス

●Use an ASM allocation unit (AU) size of 4M (currently).
●“CREATE ALL” celldisk and griddisks.
●Use DCLI to run on all storage servers at once (this is both helpful and saves time).
●Use IORM for resource management.
●Decide your Fast Recovery Area (FRA) and MAA needs before you install.
●Use Database 11.2.0.1+ (11.2.1.3.1) and ASM 11.2.0.1+ (minimums currently).
●Must be compatible with 11.2.0.1+ (current minimum).
●Has a logfile size of 32G (Whoa!).
●Use Locally Managed Tablespaces (LMT) with 4M uniform extents.
●Move data with Data Pump (usually, but you have many other options).
●Start with the default initialization parameters for tuning and then adjust as needed for your workload.

by Richard Niemiec (LogicalRead)

タグ: , ,

SAP HANA で、他RDBからのレプリケーション(AWSとDBMotoで検証編)

異種DB間対応レプリケーションツールDBMotoを使用してRDBからSAP HANAへのレプリケーションを検証します。今回複製元ソースをOracle、複製先ターゲットをSAP HANAとしています。

※事前にSAP HANA on the AWSでDBレプリケーション(AWS準備編)にてSAP HANAの構築が完了し、SAP HANA on the AWSでDBレプリケーション(クライアント準備編)にてDBMotoマシンにSAP Clientがインストールされていることが前提となります。

まず予め複製元ソースのOracle接続設定を済ませておきます。
20140922-20

続いて複製先ターゲット接続ウィザードにてSAP HANAへの接続を行います。
DBはSAP HANAを選択します。接続ドライバはODBCを使用します。
20140922-20-2

Connection Stringの欄のボタンをクリックします。
20140922-21

SAP HANAへ接続するサーバ名とDBユーザ名・パスワードを入力します。サーバ名にはポート番号が必要な点に注意してください。※Developer Editionの場合は30015。
20140922-22

テストボタンを押下し・・・
20140922-23

テスト成功と表示されればDBMotoからSAP HANAへの接続が行えたことになります。
20140922-24

今回はDBMotoの機能でテーブルを作成するため、下記のテーブル選択画面では何もせずに画面を進めます。※SAP HANA Studioで作成したスキーマ(カタログ)が表示されていることを確認します。
20140922-25

完了ボタンを押下し、接続設定は完了です。
20140922-26

続いてDBMotoのターゲットテーブル作成機能にてSAP HANAにテーブルを作成します。テーブル情報はソースのOracleのテーブルを元にします。
20140922-27

データタイプ等はDBMotoが適切なものを選定しますが自由に変更することも可能です。
20140922-28

Create文が自動で生成されます。
20140922-29

テーブル作成が完了するとDBMotoのmetadataでは下記のように表示されます。
20140922-30

念のためSAP HANA Studioにてテーブルが作成されていることを確認します。
20140922-31

※【重要】SAP HANAへのレプリケーション時には全件のリフレッシュ(バルクインサート使用時)と差分のミラーリング時は共にSAP HANAが稼働しているOS上でのFTP設定が必要となります。DBMotoの接続プロパティにてFTPの情報を忘れずに入力してください。
20140922-32

最後にレプリケーションジョブを作成し、実際にレプリケーションを開始します。
下記のように14レコード成功と表示されています。
20140922-33

実際に正しくレプリケーションされているか、SAP HANA Studioでも確認しました。
20140922-34

このようにDBMotoを使用することでOracleやSQL ServerなどのRDBから簡単にSAP HANAへレプリケーションすることが可能です!

タグ: ,

Database Performance Analyzer(旧Ignite)画面のDBやSQLの表示名変更方法

Database Performance Analyzer(DPA :旧Ignite)では監視DBのデフォルトの表示名は、サーバ名やインスタンス名で、SQLの表示はハッシュ値やSQL IDでそれぞれ表示されています。

Instance表示 SQL表示名

登録しているインスタンスや複数の監視DBがある場合や、頻繁に使用するSQL文を確認する際には、任意の名前表示に変更し監視や確認をスムーズに行うことが可能です。

SQLの表示名を変更する場合は、変更したいSQLをクリックし”NameSQL“をクリックすることで任意の名前に変更できます。

SQL表示変更 SQL表示変更後

DBの表示名を変更する場合ははDPAの画面から、Options > Support tab > Database Query Tool を選択し、リポジトリDBに対してクエリ”select id, name from cond“を実行します。

Instance表示名確認

監視DBの表示名と、DBのID一覧が表示されます。表示名を変更したいDBインスタンスのIDを確認した後、下記クエリを実行します。

update cond set name= ‘<変更後の表示インスタンス名>’ where id=<対象DBのID>

Instance表示変更

最後に、Options > Support tab > Refresh Ignite Alert Cache  を選択しアラートのキャッシュを削除します。

AlertCache削除

20~30秒後にDBの表示名が変更されていることが確認できます。

Instance表示変更後

タグ: ,