Oracle データベースからミラーリングまたはシンクロナイゼーション中にDBMoto は
Oracle Redo ログで記録されたソースデータベースでの変更を識別するためにOracle
LogMiner 経由でOracle トランザクションをリードします。すべてのアクティブなredo
ログはレプリケーションするためのトランザクションを読み出すためにそれぞれのミラーリ
ング・セッションでオープンになっています。さらにDBMoto はアーカイブ・ログをロー
ドするための設定を提供します。
Oracle が巡回方式でトランザクションをログし、それは順番にredo ログ・ファイルに使
用されます。現状のファイルが最大値に届いた時、Oracle はステータスをインアクティブ
に設定し、次のファイルへ書き込みを続けます。もし次のファイルがデータを含んでいる時
は、上書きされます。もしすべてのオンライン・ログ・ファイルが1DBMoto リードと次
リード(DBMoto で設定したリード間隔)間でシーケンス番号(例:それぞれで指定した
ログ・ファイルの書き込み順序)を変更された時、ログ・ファイルは容量不足か、ログする
トランザクションの量を再考するか、ログ・ファイルが少なすぎるかです。
通常のガイドラインとしてログのサイズはデータベースで生成されるトランザクション数と
リテンション時間をベースに計算します。例えば72 時間のリカバリーを確実にしたい時、
3 日間に生成されるすべてのトランザクションを含むログ数を定義する必要があります。
Oracle のログ・ファイルはログ・ファイルサイズを増やすか、新たにログ・ファイルを追
加するかのどちらかでサイズ変更が可能です。ログ・ファイルサイズを対応が難しい量
(例:100MB 以上)に増加させるより中規模なログ・ファイルを作成することを考えてく
ださい。もしこの方法でログ・ファイルを編成し、DBMoto を絶えず稼動させて、レプリ
ケーションと連携させることで、アーカイブ・ログのオープンを回避できます。詳しいこと
はOracle のDBA と相談してください。
もし、ログ・ファイルが一杯になるか、上書きを始めることを許している場合にDBMoto
はプロセスする次のトランザクションを見つけことはできません。これが発生した時は、
ミラーリングを再度始める前にフル・リフレッシュ・レプリケーションを実行する必要があります。
DBMoto がアクティブなredo ログをリードした時、LogMiner はログをオープンした時に
ビュー(view)を生成します。(それはフィジカルなテーブルや実際のログはオープンし
ません。)これはOracle のオペレーションには影響を与えませんが、サーバに対して要求
を起すため、Oracle のパフォーマンスに影響を与えます。(特にLogMiner がオープンの
ためにビューを準備した時に、ミラーリング・セッションの最初のフェーズにおいて)
DBMoto でOralce データベース用のソース接続を設定した時に、Oracle サーバには何も
インストールされません。しかしDBMoto は認証キー・ロギング用のSUPPLEMENTAL
LOGS が可能なことを要求し、それはDBMoto 接続ダイアログからインストール・オペレ
ーション中に自動で実行されます。SUPPLEMENTAL LOGS はOracle ログに対してさらに
詳細なログ情報を追加しますが、同時にそれぞれのDML コマンドで、redo ログに書き込
む追加のデータを要求するためサーバのパフォーマンスを低下させます。
OracleDBA が行うログのクリーンアップはレプリケーションがアイドル時のスケジュール
で実行が必要です。しかし、もしログ・ファイルがレプリケーションのプロセス中に削除さ
れた時、DBMoto はエラーからのリカバリーが可能で、次のミラーリング・セッションに
おいて、データを失うことなくレプリケーションを獲得できます。
新たなトランザクションを特定するためにログをアクセスした時、アーカイブredo ログ
に含んでいます。
ソース接続の「Connection Properties」ダイアログから利用可能な「the Setup Info」
ダイアログの「Read Archived Logs」オプションをクリックします。もしOracle データ
ベースがARCHIVELOG モードを使用している場合のみ、この手法は有効です。もし、ト
ランザクションがオンラインredo ログで見つけられない時は、DBMoto はアーカイブ
redo ログを検索することが出来ます。
1. Enterprise Manager ツリーからそれを選択してレプリケーションをディセイブル
(無効)にして、チェックマークを外すようにEnable Replication メニュー・アイテムをクリックします。
2. Enterprise Manager ツリーのソース接続を選択します。
3. マウスの右ボタンメニューから「Connection Properties」を選択します。
4. Connection Properties ダイアログからTransactional Support セクションにスク
ロールします。
5. Transaction Log Type フィールド用の値をクリックします。
6. ボタンをクリックします。
7. Setup Info ダイアログで、Read Archived Logs オプションをクリックします。
8. Setup Info ダイアログを選択し、ok をクリックします。
9. Connection Properties ダイアログを選択し、ok をクリックします。
10. Enterprise Manager ツリーでそれを選択してレプリケーションを可能にして、
チェックマークが表示できるようにEnable Replication メニュー・アイテムをクリックします。
【原文】
During mirroring or synchronization from an Oracle database, DBMoto reads
Oracle transactions through the Oracle LogMiner to identify changes in the
source database recorded in Oracle redo logs. All active redo logs are opened at
each mirroring session to retrieve transactions to replicate. Additionally, DBMoto
provides a setting to load archived logs.
Oracle logs its transactions in circular fashion, that is, it uses the redo log files in
sequence. When the current file reaches its maximum size, Oracle will set its
status to inactive and will keep writing to the next file. If the next file already
contains data, it could be overwritten. If all online log files have changed
sequence number (i.e. the writing sequence of each specific log file) in the period
between one DBMoto read and the next (Read Interval setting in DBMoto), the
log files may be underdimensioned, considering the amount of transactions to
log, or there may be too few log files.
As a general guideline, the size of the log should be based on the number of
transactions generated in the database and based on the retention time. For
example, if you want to be sure you can recover for 72 hours, you should define
your logs to contain all the transactions that can be generated in 3 days. Oracle
log files can be re-dimensioned by either increasing the log file size or by adding
new log files. You may want to consider creating more medium-size log files
rather than increasi
ng log file size to a value that could make it difficult to handle
(i.e. not greater than 100MB.) If you organize your log files in this way, and if
you keep DBMoto constantly running and aligned with the replications you may
be able to avoid opening the archived logs. Contact your Oracle database
administrator for more information. Your DBA has the best understanding of your
Oracle environment.
If you allow the log files to fill up and begin overwriting, DBMoto may not be able
to locate the next transaction to process. If this occurs, you need to perform a
full refresh replication before resuming the mirroring.
When DBMoto reads the active redo logs, the LogMiner actually generates a view
when it opens the log (it does not open a physical table nor the log itself.) This
does not affect Oracle operations, but it can affect Oracle performance in general,
because it is making a demand on the server (especially in the initial phase of
the mirroring sessions, when the log miner prepares the view to open).
When creating a source connection for an Oracle database in DBMoto, nothing is
installed on the Oracle server. However, DBMoto requires that SUPPLEMENTAL
LOGS for identification key logging are enabled and this is performed
automatically during the Install operation from the DBMoto connection dialog.
Supplemental logs add more detailed logging information to the Oracle logs but
at the same time can degrade the server performance by requiring additional
data to be written into the redo logs for each DML command.
Log cleanup operations by your Oracle DBA should be performed at scheduled
times when replications are idle. If, however, a log file is removed while a
replication is in progress, DBMoto should be able to recover from the error and
pick up replication during the next mirroring session with no data loss.
Including Archived Redo Logs when Accessing Logs to Identify New
Transactions
Check the Read Archived Logs option in the Setup Info dialog available from the
Connection Properties dialog of the source connection. This approach is useful
only if your Oracle database uses ARCHIVELOG mode. It enables DBMoto to
search archived redo logs if transactions cannot be found in the online redo logs.
1. Disable the replication by selecting it in the Enterprise Manager tree, and
clicking the Enable Replication menu item to remove the checkmark.
2. Select the source connection in the Enterprise Manager tree.
3. From the right mouse button menu, choose Connection Properties.
4. In the Connection Properties dialog, scroll to the Transactional Support
section.
5. Click on the value for the Transaction Log Type field.
6. Click the ellipsis button.
7. In the Setup Info dialog, check the option Read Archived Logs.
8. Click OK to close the Setup Info dialog.
9. Click OK to close the Connection Properties dialog.
10.Enable the replication by selecting it in the Enterprise Manager tree, and
clicking the Enable Replication menu item so that it displays a checkmark.
See Also
KB Article 1572 Errors in creating dictionary file in Oracle 8.1.7
KB Article 1584 >Handling a Missing Transaction ID in the Oracle Redo Log
http://www.hitsw.com/support/kbase/DBMoto/DBMoto_1641_OracleRedoLogExpl.htm
関連したトピックス
- Oracle Redo Log の Transaction ID取得に失敗する場合【リアルタイムレプリケーションツールDBMoto】
- ミラーリングの復旧で、リフレッシュ後の開始でエラー【リアルタイムレプリケーションツールDBMoto】
- DBMotoが使うスレッド数の算出方法【リアルタイムレプリケーションツールDBMoto】
- Oracleアーカイブログモードの変更
- OracleのRedoログとアーカイブログの参照設定【リアルタイムレプリケーションツールDBMoto】
- Optionに関する解説(Ver6.5から)【リアルタイムレプリケーションツールDBMoto】
- イニシャル・リフレッシュを行った時のリフレッシュとミラーリングでのトランザクション管理【DBMoto】
- Oracle DB起動時にエラーORA-01034・ORA-27101が出て起動しない際の対処法
- レプリケーション設定手順(各DB別)【リアルタイムレプリケーションツールDBMoto】
- データベース接続数の制限設定【リアルタイムレプリケーションツールDBMoto】