PostgreSQL – アイドル・プロセスの終了方法

データベース・サーバ上で稼働するすべての不要なプロセスを強制終了させるクエリー:

タグ: ,

Database Performance Analyzer (旧Ignite)のアラート設定について(実行結果アラート編:Custom Alerts)

Igniteのアラート種類の一つであるCustom Alerts(実行結果アラート)では下記のようにSQLやプロシージャの実行結果(数値、ブール値)にあわせて、アラートを通知可能です。また結果がNORMAL, INFO, LOW, MEDIUM, HIGHといったアラートの値と同じ文字列である場合には、その文字列にあったアラート通知が可能です。

例として「Custom SQL Alert Single Numeric Return:SQL実行結果(一つの値)」のアラート設定を行います。

アラート名、間隔、インスタンス、実行するSQL(今回は表のレコード数)、閾値等を設定します。

このアラートを作成するためには、悪意あるSQLの実行を防ぐために、Igniteの設定ファイルにパスワードを設定し、作成時にはそのパスワードを入力する必要があります。

作成されると、アラート一覧に追加されます。

実際に送られてくる通知は次のようなメールです。

タグ: , ,

Database Performance Analyzer (旧Ignite)のアラート設定について(管理アラート編:Administrative Alerts)

Igniteのアラート種類の一つであるAdministrative Alerts(管理アラート)では下記のようにインスタンスとの接続、エラーによるアラートだけではなく、設定の変更や空き容量の低下に対してもアラート通知が可能です。

例として、「Database Instance Parameter Changes:データベースインスタンスの設定変更」のアラート設定を行います。

アラートの名前、間隔、対象のインスタンスを設定して作成します。

アラート一覧に追加されます。

実際のメール通知ではどのような変更(今回は共有プール領域のサイズ変更)が行われたかが通知されます。

タグ: ,

DPA(Ignite)のアラート設定について(待ち時間アラート編:Wait Time Alert)

Igniteのアラート種類の一つであるWait Time Alert(待ち時間アラート)では下記のようにSQLの実行時間だけではなく、ユーザやプログラム、マシンのI/Oなど、問題点を明確にした状態で、通知を行うことが可能です。

例として「Total SQL Wait Rime for a Single Wait:単一のイベントによる待ち時間の合計」のアラート設定を行います。

アラートの名前や間隔、対象のインスタンス、イベントの種類、閾値を設定します。

イベントの種類はたくさんありますが、Searchボタンから一覧が表示されますので、今回はその中からSelect文の待ち時間を選択します。

この設定を保存しますと、下のようにアラート画面に追加されます。

実際のアラート通知は下のようなメールが送られてきます。

タグ: ,

DPA(Ignite)のアラート設定について

igniteのアラート設定は3つのカテゴリーに分かれています。

・Wait Time Alerts
SQL文などの処理にどれだけ時間がかかったを計測してアラートを通知します。

・Administrator Alerts
データベースインスタンスなどの設定変更や空き容量の低下、エラー出力にあわせてアラートを通知します。

・Custom Alerts
SQLやプロシージャの実行結果からアラートを通知します。

・アラートの通知先について
設定したアラートの通知は作成したContactに対して行います。Contactの種類としてはメールもしくはSNMPを通知先として作成、グループわけすることが可能です。

メールのContact作成画面

SNMPのコンタクト作成画面

 

 

DPA(Ignite)のアラート設定について はコメントを受け付けていません -->

SQL チューニングに役立つコスト情報の表示【DPA:データベースパフォーマンスのモニタ・分析ソリューション】

統計情報を元にして行われるコストベースのチューニングを行う際に、Igniteを用いることで効率的にチューニングが可能です。

各クエリの実行にかかった時間を表すグラフから問題となっているクエリを選択します。

クエリの詳細が表示されます。

ここでPlanタブから実行計画の情報を得ることが可能です。Oracleでは以下のように

SQL Serverでは以下のように表示されます。

またOracleでは現在のコストを再計算させることや、実際にSQLに変更を加えた場合にどのようなコストになるか計算を行うことも可能です。

この場合はSQL Textに変更を入力し、Live Planを行うことで計算が行われます。

GoからLive Planを開始、ユーザを選択して実行します。

このように、現在の計画が表示されます。

タグ: , ,

DBレプリケーションツールDBMotoはWindows 8とWindows Server 2012を正式サポートします

DBMotoは先日一般販売を開始したWindows 8、及びWindows Server 2012を正式サポートします。

ただし、DBMotoは.NET Framework 2.0 SP2上で動作するアプリケーションです。
Windows 8とWindows Server 2012はデフォルトで.NET Framework 2.0 が有効になっていないため、DBMotoインストール前に予め有効にしておく必要があります。

●Windows 8で.NET Framework 2.0(3.5)を有効にする方法

コントロールパネル→プログラム→「Windowsの機能の有効化または無効化」から.NET Framework 3.5にチェックを入れます。

●Windows Server 2012で.NET Framework 2.0(3.5)を有効にする方法

サーバマネージャー・ダッシュボード→「2. 役割と機能の追加」から.NET Framework 3.5にチェックを入れます。

Windows 8でDBMoto管理ツールManagemet Centerを開いた画面です。

タグ: ,

システムの停止時間を最小限に抑えてデータベースの移行を行うには?

Oracle 9iから11gへの移行など、データベースの移行を行う一般的な方法はExport/Import(エクスポート・インポート)方式です。

ただしこの方法には欠点があります。
それは「システムの停止時間が長くなりがち」なことです。

エクスポート・インポート方式の場合は、概ね下記の手順での移行となります。

1. DBの停止
2. 旧DBからExportで全データをdumpファイルへ抽出
3. 新DBへImport
4. 旧DBから新DBへの切り替え
5. 新DBの稼働

この場合はExport開始から新システムの稼働まで、長時間DBを停止する必要があります。これは、Export開始前にDBを停止しないと、Export作業中に発生したトランザクションをExportできず、データの不整合が発生するためです。

一方でエクスポート・インポート方式に加え、レプリケーションツール「DBMoto」の差分レプリケーション機能を併用することで、システムの停止時間をかなり抑えることが可能となります。
エクスポート・インポートと差分レプリケーション機能を併用した場合は概ね下記の手順での移行となります。

1. 旧DBからのExport開始と同時にDBMotoの差分レプリケーションも開始
2. 新DBへImport
3. DBの停止
4. 旧DBから新DBへの切り替え
5. 新DBの稼働

こちらの場合はExportからImportまでの処理の間にDBを停止させることなく、その間に発生した新たなトランザクションはDBMotoの差分レプリケーションにて転送を行うことが可能です。

これにより、DBの停止する期間は事実上切り替え作業時のみとなり、大幅に短縮することが可能となります。

このようにDBMotoのレプリケーションはDBの移行作業時にもご活用いただけます。

タグ:

AS/400ジャーナル・レシーバー作成手順書、プロシージャ作成手順書を公開しました

DBMoto用ドキュメント「AS/400ジャーナル・レシーバー作成手順書、プロシージャ作成手順書」を公開しました。

カタログ・技術資料のページよりダウンロードいただけます。
//www.climb.co.jp/soft/documentation/

「ジャーナル・レシーバー作成手順」の項では、AS/400からの差分レプリケーションを実現するために必要なジャーナルと、ジャーナル・レシーバーの作成手順を図入りで説明しております。

「プロシージャ作成手順」の項では、DBMotoからAS/400のジャーナルを参照する際に必要なプロシージャの作成手順を図入りで説明しております。
※本手順は通常は必要ありません。通常はDBMotoから1クリックでプロシージャの作成が可能ですが、セキュリティの設定等の理由でDBMotoから作成が行えなかった場合の主導での作成手順となります。

タグ: ,

Database Performance Analyzer (旧Ignite)のレスポンス・タイム分析について

レスポンス・タイム分析は何がアプリケーション・エンドユーザに「待ち」を起こしているか – というDBAと開発者がデータベース管理するにあたって最も重要な基準でアプリケーションとデータベースのパフォーマンスを管理する新しいアプローチです。また待ち時間分析と参照することでITチームはITユーザに対して提供するサービス・レベルを改善することができます。

単にサーバの健全状態を確認し、パフォーマンス・インパクトについて想定を行うより、ウェイト(待ち)とレスポンス(応答)タイム手法は要求されたオペレーションが完了するまでの時間を計測します。最適な実装方法は個別に、個々で計測可能なステップに時間を分類し、アプリケーション遅延を起こしているオペレーションで、どのステップかを正確に識別します。データベースでのもっとも重要な使命は結果を応答するということで、レスポンス・タイムはデータベース・パフォーマンス決定を行う上で最も重要な基準です。

レスポンス・タイム=プロセス・タイム+ウェイト・タイム

レスポンス・タイムは実プロセス・タイムとロック、ログ・ファイル、または多くのウェイト・イベントやウェイト・タイプなどの利用可能なリソースの待ちに消費されたセッションの時間の合計です。セッションがCPUをアクセスしている(例:CPUウェイト・タイプ)時にCPUはしばしばI/Oや他のオペレーションがプロセスが続けられる前に完了を待っているいるので、必ずしもアクティブに処理されてはいません。複数のセッションが同じプロセス・リソースを使用して実行している時にはウェイト・タイムは実際のレス分す・タイムに最も大きく影響します。

ウェイト・エベントとウェイト・タイプ

データベースでのレスポンス・タイムを正確に測定するには、時間を蓄積しているステップを個別に識別する必要があります。物理I/Oオペレーション、バッファー操作、ロックによるウェイト、そして他のデータベース・オペレーションに対応するステップはデータベース・ベンダーによって実装されています。SQL Serverではこれらはウェイト・タイプ「Wait Type」と呼ばれ、Oracle, Sybase,DB2ではウェイト・エベント「Wait Event」として参照されます。詳細は各ベンダーごとにユニークですが一般的な考え方は同じです。これらのウェイト・エベント/タイプは各データベース・リソースでのセッション待ちで消費された合計時間を示しています。もしウェイト・エベント/タイプが正確にモニターと分析ができれば、遅延を引き起こすボトルネックとクエリーを正確に判断することができます。

図はレスポンス・タイムのモニター処理を示しています。各SQLクエリー・リクエストはデータベース・インスタンスを通してパスされます。各ウェイト・エベント/タイプ・ステップはSQLパスで黄色の三角マークで示されています。各ステップでの時間を計測することで、総合のレスポンス・タイムを分析することができます。

従来型の統計との違い

一般的なデータベース・パフォーマンス・モニター・ツールはサーバの健全性の計測と実行比率にフォーカスしています。これらの統計の高度なプレゼンテーションでさえもエンドユーザ経験の反映、問題の根源の場所の公開を行っていません。何度オペレーションを行ってもそれが実際にアプリケーションの遅延を起こしたものかどうかは分かりません。

レスポンス・タイム(Ignite) vs. 従来型分析手法とを識別するの主な基準

●リクエストの受付からレスポンスの開始まで実行を起こした時間を計測
●SQLクエリーを個々に分析することでレスポンス・タイムに影響している特定のSQLを分離、評価が可能。有効な情報を提供しないインスタンス全体の合計レスポンス・タイムを計測
●SQLクアリーが処理する個別の内部ステップ(ウェイト・タイプ/イベント)を識別。問題解決には手助けにはならない内部消費時間を無視して、インスタンスをブラック・ボックスとして取扱い。

レスポンス・タイプ分析での実務的な考慮

パフォーマンス・モニターへのレスポンス・タイム・アプローチはそれがパフォーマンスが重要視される環境で効果的に導入されれば、問題解決能力の高いものとなります。Igniteはこの要求に合致する、パフォーマンス・インパクトの低い、エージェントレスな技術を使用しています。エージェントレス・アーキテクチャはプロセスを別システムに行わさせ、実務データベースへの影響は1%以下です。

●エージェントレス・データベース・オペレーション:本番サーバ上でのソフトウェアのテスト、インストール、保守の必要性を除外
●本番データへのパッシブなモニタリング:本当の本番セッションをモニターし、テスト・トランザクションでのシミュレーションを行わない
●24/7の継続したモニタリング:すべてのオペレーションがいつでも詳細に分析できるようにすべてのサーバでのすべてのセッションを継続的にモニタリング。不定期なトレース・ファイルは継続的なカバーはできません。

タグ:

Database Performance Analyzer : データベースの状態を定期的にメールレポーティング【Ignite:DBパフォーマンス・モニター、レスポンス分析ソフト】

Igniteにメールアドレスを登録しますと、そのアドレスに対して下のようなデータベースの状態やどのようなSQLが処理されたかを表すレポートを定期的に送るよう設定可能です。

このメールでは、どのSQLにどれだけの時間がかかったかをグラフで表示し、時間のかかった上位のいくつかのSQLについては実際にSQL文を表で記載してあります。

SQLに関するレポート以外にも、どのユーザやアプリケーション、マシンからのアクセス、SQL以外のマシンのI/O(メモリやCPU)による待ち時間、オブジェクト単位(テーブルやインデックス)での待ち時間をレポートすることが可能です。

各レポートに対する詳細設定も下のように可能です。

上位の何位まで表示するか、ユーザが指定したSQLステートメントの表示といった設定や、期間の設定を行えます。

タグ: , ,

Database Performance Analyzer (旧Ignite) for SQL Severの主な機能: SQL Serverパフォーマンス・モニター、レスポンス分析ソフト

●SQL Serverのパフォーマンスにフォーカス
SQL Server 2012のサポートと169の新規ウェイト・タイプの追加で、Igniteはウェイト・タイムの合計だけでなく、問題をできるだけ早く解決するための特定のサーバ・パフォーマンスの詳細を他ではできない可視化でユーザに提供します。

●パフォーマンス・ダッシュボード
Confio独自の応答時間分析で、Igniteはパフォーマンス・ボトルネックを取り除く最も早いルートを提供することで、最も重要な問題に焦点を当てることができます。

Igniteは最もパフォーマンスにインパクトのある問題に焦点を当てて、ターゲットを絞った豊富な情報を提供します。Oracle, Sybase, DB2同様にSQL Serverを含むデータベース・インスタンスはダッシュボード・ベースで単独のWebブラウザ内にすべてが表示されます。

カスタムな測定基準

専門者が決定した測定基準に追加して、Igniteはカスタムな計測基準を簡単に追加できる新規ユーザ・インターフェイスを持っています。この制限のない拡張性によりユーザはSQL Query経由でデータベース・インスタンスからアクセス可能な測定基準をモニターすることができます。

●実行プラン表示とアドバイス
Igniteには詳細な計画分析が追加されているので、任意の時点で使用される正確な実行計画の明確なビューを提供しています。この機能はSQL Server2005 SP2以降で利用可能です。低応答時間に大きなインパクトを与えるプランにユーザの注意度に焦点を合せた実行計画レポートを取得する機能が含まれます。

Igniteには専門者がベスト・プラクティスをまとめたクエリー・アドバイスが追加されています。このアドバイスは実行計画のIgnite分析の基礎となっていて、インデックスの紛失、インデックスの不一致、計画変更の検知、フル・テーブル・スキャン検出など隠れたパフォーマンス危険性を特定します。他の分析ツールとは違い、Ignite はアプリケーション待ち時間の観点からそれらの問題でのインパクトを識別し、定量化します。

●Ignite for SQL Serverのライセンス体系
Ignite for SQL Serverのライセンスは、モニターする SQL Server インスタンス・ベースになります。個々のインスタンス・ライセンスはサイズ、データベース・ユーザ数にはには依存しません。

タグ: , ,

CURRENT_DATE と SYSDATE の違いについて @ Oracle

●CURRENT_DATE:セッションのタイムゾーンでの、現在の日付を返します。

●SYSDATE : データベースが稼働するオペレーティングシステムの現在の日付と時刻を返します。

ソース: https://blogs.oracle.com/ecmarch/entry/be_aware_of_the_difference

タグ:

Oracleアーカイブログモードの変更

Oracleでのトランザクション処理は通常Redoログに記録されますがRedoログはローテーション管理のため、指定のサイズに達し、Redoログのグループが切り替われば古いログは消えてしまいます。

このログをずっと残しておくのがアーカイブログとなります。アーカイブログモードをONにすることで、カレントのRedoログが切り替わった際にそのログをアーカイブログとして出力されます。

●アーカイブログモードの変更手順

1. まずは現在のアーカイブログモードの設定を確認するため、下記コマンドを実行します。
SQL> select log_mode from v$database;
NOARCHIVELOGとなっていればOFF、ARCHIVELOGとなっていればONです。

2. アーカイブログモードの変更を行うために、下記コマンドを実行してデータベースを停止し、マウント状態にします。
SQL> shutdown immediate;
SQL> startup mount;

3. アーカイブログモードをON・OFFにするために、下記コマンドを実行します。
・ONにする場合
SQL> alter database archivelog;

・OFFにする場合
SQL> alter database noarchivelog;

4. 最後にデータベースをオープンします。
SQL> alter database open;

以上で設定は完了です。

データベースレプリケーションツール「DBMoto」はOracleからの差分レプリケーションの際、LogMinerを使用してRedoログを参照しますが、アーカイブログを参照することも可能です。その際は下記のように設定画面で「Read Archived Logs」にチェックを入れる必要があります。

タグ:

AS/400でのレコード全消去時における、DBMotoによるミラーリング動作

DBMotoでは通常、DDL文であるTRUNCATEなどによる変更はミラーリングを行いません。
しかしAS/400において、CLRPFMやCPYFをREPLACEオプションつきで実行した場合などにはミラーリング先のデータベースに対してTRUNCATEを使用した操作を行います。
※ただし、レプリケーション対象であるAS/400物理ファイルのメンバー名とファイル名が異なる場合は、TRUNCATEが実施されません。

・AS/400でCLRPFMを実行した場合
ミラーリング先データベースではTRUNCATEを実行し、AS/400と同様にレコードを全て消去します。

・AS/400でCPYFをREPLACEオプションつきで実行した場合
ミラーリング先データベースではTRUNCATEを実行した後に、コピーされた内容をINSERTにより反映します。

このAS/400側に行った操作をミラーリング先データベースに反映したくない場合は下記のスクリプトを記述する必要があります。
————————————
Namespace DBRS
Public Overrides Sub Record_onBeforeMapping(recSource As IRecord, ByRef AbortRecord As Boolean)

if (recSource.OperationType = enmOperationType.Clear) Then

AbortRecord = True
End if

End Sub
End Class
End Namespace
————————————

このスクリプトを追加するとミラーリング時の動作は次のようになります。

・AS/400でCLRPFMを実行した場合
ミラーリング先のデータベースには何も操作を行いません。

・AS/400でCPYFをREPLACEオプションつきで実行した場合
コピーされた内容をINSERTにより追加します。

AS/400でのレコード全消去時における、DBMotoによるミラーリング動作 はコメントを受け付けていません -->