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

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によるミラーリング動作 はコメントを受け付けていません -->

主キー(PK)がなくても心配なし!DBMotoから(差分レプリケーションのための)仮想PKを設定可能

DBMotoで差分レプリケーション(ミラーリング・シンクロナイゼーション)を行う場合には、トランザクションログを参照してどのレコードでトランザクションがあったかを識別させるためにデータベースのテーブルに主キー(PK)が必要です。もちろん複合キーでも可能です。

・・・テーブルに主キーがない場合はレプリケーションできないのでしょうか・・・?

いいえ、心配いりません。DBMotoではテーブルに主キーがない場合に、DBMotoで差分レプリケーションを行うためにPKとして扱うフィールドを疑似的に設定することが可能です(仮想PKと呼んでいます)。こちらも複合キーの設定は可能です。その際DBサイドに変更を加えることもありません。

ただし仮想PKとして設定するフィールドの値は一意で重複しない値であることが必要です。1つのフィールドでは重複するようであれば複合キーの設定を検討する必要があります。

手順は下記の通り。

対象のテーブルを右クリックし「主キー設定」を選択します。

テーブルのフィールドが表示されます。

仮想PKとして設定するフィールドを右側に移動します。

以上で設定は完了です。簡単です。

なお、SQLServerのディストリビュータ機能を使用した差分レプリケーションに限り、この仮想PK設定は使用できません。データベースのテーブルにPKが必須となります。

主キー(PK)がなくても心配なし!DBMotoから(差分レプリケーションのための)仮想PKを設定可能 はコメントを受け付けていません -->

[DBMoto]スレッド設定の調整でレプリケーション速度を向上させる方法

DBMotoの性能向上(レプリケーション速度の向上)に影響するパラメータはいくつかありますが、
複数ケースで検証したところ、速度が向上するパラメータは「Thread execution factor」のみです。
こちらを設定することで、レプリケーション処理のチューニングを行えます。

しかし、DBMotoをインストールしたOSのスペックに依存するため、
高スペックなOSでは速度の向上が見受けられない可能性がございます。
あくまで参考程度のものとご認識いただけますと幸いです。

設定は「Data Replicator Options」から変更可能です。
変更自体はレプリケーション動作中でも可能ですが、
反映されるのはDBMotoサービス起動時となりますので、
一度DBMotoサービスを停止⇒値変更⇒サービス起動 の手順でお願いいたします。

実際にどの程度の速度向上が期待できるかについては環境によりますのでご注意ください。
特にDBMotoをインストールしたWindowsOSのマシンスペックに対しての依存が大きいです。

弊社環境では概ね2~10倍の速度向上となりましたが、
OSは「Windows Vista」で実施いたしました。

●「Thread execution factor」について

あるタスクから次のタスクに移るまでどれだけの時間実行するかを決めるパラメータです。
DBMotoはおのおののタスク(reader あるいは writer)に指定された値を乗じたタイム・スライスを割り当てます。
たとえば2倍の場合、DBMoto はおのおののタスクに2倍の時間を割り当てます。
ここでのタスクは、例えばジャーナルから情報を取得する等のことです。

デフォルト値は10となっております。
この値を大きくすることで特にミラーリング・シンクロナイゼーション時に速度向上が見込めます。
ただしCPUの使用率も増加する点はご注意ください。

●関連項目「Max number of concurrent threads」について

CPU の同時実行スレッド数です。
デフォルト値は5となっており、通常は変更する必要がありません。

●関連項目「Thread Delay」

スリープ状態に入るまでに実行するタイム・スライスの数を指定します。
CPU使用率が高すぎるときにCPUリソースを開放する目的のものです。
その動作は、n を指定した場合 n 回タイム・スライスを実行する毎にスリープします。
1 と指定する場合が最もスリープの割合が高くなり、1回実行するごとに1回スリープします。
最もCPUリソースを開放しますが、同時に最もパフォーマンスが低下する設定です。
0 と指定するとスリープが行われません。
デフォルト値は0となっておりますが、遅くするためのパラメータなので、
DBMoto のサーバーが過負荷でなければ0のままで問題ありません。

[DBMoto]スレッド設定の調整でレプリケーション速度を向上させる方法 はコメントを受け付けていません -->

複数の複製元サーバから1つの複製先サーバへの結合レプリケーションもDBMotoで簡単実現

■2015/06/05記事改訂

DBMotoを使用すると、複数の複製元サーバ(ソース)のテーブルを1つの複製先サーバ(ターゲット)へまとめてレプリケーションすることも可能です。

●各複製元サーバのテーブルそのものを複製先サーバに集約したい場合

この場合はテーブル自体を集約するのみとなりますので、設定上はテーブルA同士、テーブルB同士、テーブルC同士でそれぞれレプリケーション定義を作成するキトで簡単に実現できます。

●各複製元サーバのテーブルのレコードを複製先サーバのテーブルに集約したい場合

この場合はテーブルの集約ではなくレコードの集約となりますので、少し設定の工夫が必要です。注意点としては以下の2つが挙げられます。

1. リフレッシュ時に複製先のレコードを削除しないようにする必要がある。
2. 結合時にPKが重複しないように考慮する必要がある。

1番については、リフレッシュの仕様としてレコード登録時にまずは複製先テーブルのレコードを一度削除します。今回のように各複製元サーバからリフレッシュを行う場合、毎回削除するわけにはいかないので、リフレッシュ時にレコードを削除しないように設定します。これはDBMotoのスクリプト機能を利用します。

※設定するスクリプト
[vb]
Imports System
Imports System.Data
Imports Microsoft.VisualBasic
Imports DBMotoPublic
Imports DBMotoScript
Imports DBRS.GlobalScript

Namespace DBRS
Public Class ReplicationScript : Inherits IReplicationScript

Public Overrides Sub Refresh_onBeforeTruncate(ByRef CancelTruncate As Boolean)
CancelTruncate = True
End Sub
End Class
End Namespace
[/vb]

スクリプトを設定する場合は、レプリケーションオプションにてUse Scriptにチェックを入れ、Scriptボタンを押下します。

次にスクリプト記述画面が表示されるので、上記のスクリプトをコピペします。

最後にトランケートを行うレプリケーションを先頭、このスクリプトを設定したレプリケーションを後続にした、レプリケーションのグループを構成してください。
これを行えば、レプリケーションの動作順序が保障されるので、同時にレプリケーションが動作した際に不意にデータの連携を失うといった可能性がなくなります。
DBMotoの各レプリケーションをグループ化する際の利点とは?


2番については、複製元の各テーブルのレコードを結合した際に、PKが重複している可能性を考慮して、必ず重複しないフィールドを別途用意しておきます。

上記の例では、NO・NAMEは複製元・複製先共通のフィールドです。NOがPKの場合、このままだとPK重複エラーが発生してしまいますので、以下のフィールドを複製先テーブルに準備します。

SPIDフィールド・・・重複を認めない値としたいため、オートインクリメント(自動採番)とします。
SERVERフィールド・・・こちらは必須ではありませんが、複製元のどのサーバからのレコードかを識別するためにサーバごとに番号を割り振ります。

これらをもとに、DBMotoのフィールドマッピング画面にて以下の設定を行います。

SERVERフィールドを右クリックし、「Map to Expression」を選択します。

入力画面に識別したい値を入力します。ここでは”1″と設定しています。ここで設定した値は常に固定値としてレプリケーション時に挿入されます。

設定後は以下の表示になります。なお、SPIDに関してはオートインクリメントで自動採番されることを想定しているため、マッピング対象とはしないでおきます。

以上で設定は完了です。

複数の複製元サーバから1つの複製先サーバへの結合レプリケーションもDBMotoで簡単実現 はコメントを受け付けていません -->

保護中: DBMotoでのライセンスファイル変更手順

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

保護中: DBMotoでのライセンスファイル変更手順 はコメントを受け付けていません -->

双方向レプリケーション時のコンフリクト回避オプション【リアルタイムレプリケーションツールDBMoto】

DBMotoでの双方向レプリケーション(シンクロナイゼーション)において、双方のDBで同じレコードをほぼ同時に更新した場合にどちらが優先されるかはDBMotoの「コンフリクトオプション」で以下の4つから選択可能です。

1. ソースDBを優先
2. ターゲットDBを優先
3. タイムスタンプの速い方を優先
4. ユーザスクリプトを使用

通常は1~3のいずれかで十分ですが、これ以外の挙動をさせたい場合はユーザスクリプトで独自設定が可能です。

例えば、3ではタイムスタンプが「速い方」となっていますが、タイムスタンプの「遅い方」を優先したい場合、下記のようなスクリプトを記述することで実現できます。

——————————
Public Overrides Function Replication_onConflict(recSource As IRecord, recTarget As  IRecord) As IRecord

If recSource.GetLogValue(enmLogFields.TransactionTS).ToString() > recTarget.GetLogValue(enmLogFields.TransactionTS).ToString() Then
Return recSource
Else
Return recTarget
End If
End Function
——————————

タグ:

AS/400でのエラー「資源の限界を超えた」 [SQLCODE: -904 SQLSTATE: 57011]

AS/400でのエラー「資源の限界を超えた」 [SQLCODE: -904 SQLSTATE: 57011]
考えられるケースは下記の通りです。

1. ユーザープロファイルの記憶域の制限やマシンのストレージの制限を超過した
2. マシンロックの制限を超過した
3. クエリのリソース制限が超過した
4. ジャーナルのエラーが発生した(最大サイズに達したなど)
5. コミットロックの制限を超過した
6. テーブルの最大サイズに達した
7. プリペアドステートメントの領域の最大サイズに達した

タグ:

レコードを削除するDeleteとTruncateの違い

どちらもテーブルのレコードを削除するわけですが・・・

●Delete

・DML
・削除するレコードをwhere句で絞り込める
・トランザクションとして利用できる
⇒ロールバック(UNDO)が可能
⇒トランザクションログに書き込む
DBMotoでレプリケーション可能

●Truncate

・DDL
・削除するレコードを指定できず全レコードを削除
・トランザクションとして利用できない
⇒ロールバック(UNDO)が不可
⇒トランザクションログに書き込まない
DBMotoでレプリケーション不可

ちなみにDBMotoでの初回レプリケーション(リフレッシュ)では全レコードを転送しますが、その際最初にTruncateによる削除処理が実行されます。

タグ: ,