web-dev-qa-db-ja.com

大量のdblink /マテリアライズドビューアクティビティを含むイベントログに記録される頻繁なLGWRスイッチイベントの解決

ピアソンが販売している学生情報システムPowerSchoolを使用しています。 PowerSchoolはOracleをバックエンドデータベースとして使用しており、独自のレポートビューをいくつか作成する必要があります。ピアソン氏によると、本番マシンに変更を加えた場合はライセンスが無効になるため、その目的のために、dblinkを介してPowerSchoolデータストアでビューを作成するためにほぼ厳密にOracle 11gR2 Expressを実行しています。また、ODBCおよびOracleでの異種サービスサポートを使用して、SQL Serverマシンと統合します。

PowerSchoolマシンの負荷を軽減するために、よりコストのかかるクエリのほとんどを、1時間ごとに（または必要に応じて）更新されるマテリアライズドビューとして設定しています。以前のグーグル待機イベントから、DBクマとマテリアライズドビューwayを平均的なクマよりも多く使用しているように感じます。

Alert_xeファイルを調べていると、ログが新しいシーケンスに進んでいることを示すイベントが頻繁に発生します。

 LOG
 Sun Mar 18 22:16:22 2012
 Thread 1 cannot allocate new log, sequence 26914
 Checkpoint not complete
 Current log# 1 seq# 26913 mem# 0:      C:\ORACLEXE\APP\Oracle\FLASH_RECOVERY_AREA\XE\ONLINELOG\O1_MF_1_70W1H0SF_.
 LOG
 Thread 1 advanced to log sequence 26914 (LGWR switch)

より長い出力 http://Pastebin.com/m3j5YT0B

research をいくつか実行しましたが、チェックポイントの頻度を変更するか、ログを大きくする必要があるという indicated のアドバイスを見ました。ここdbaで、チェックポイントが完了していないことを確認できる唯一の参照は this でしたが、これは私が見ているものに対応していないようです。

Http://asktom.Oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:1364093900346690427 ">こちらからTomに質問

「同じサイズのログをより多く割り当てるか（そのため、チェックポイントを完了するまでに時間がかかる）、ログファイルを大きくすることができます（実際には、新しい大きなログを作成してから、古い小さなログを削除する必要があります）。しかし、ポイント「新しいログを割り当てることができません」というメッセージが表示されずに、ピーク負荷を処理するのに十分なREDOログを構成する必要があります。」

スレッドの1つで、誰かが次の出力を要求しました。selectgroup＃、bytes/1024/1024 from v $ log;

私のです：

 GROUP#                 BYTES/1024/1024        
 ---------------------- ---------------------- 
 1                      50                     
 2                      50

の出力

 SELECT OPTIMAL_LOGFILE_SIZE FROM V$INSTANCE_RECOVERY;

無効です。

私は走った

 show parameter target

this を読み込んだ後、出力は次のようになります。

 NAME                                               TYPE        VALUE                                                                                                
 -------------------------------------------------- ----------- ---------------------
 archive_lag_target                                 integer     0                                                                                                    
 db_flashback_retention_target                      integer     1440                                                                                                 
 fast_start_io_target                               integer     0                                                                                                    
 fast_start_mttr_target                             integer     0                                                                                                    
 memory_max_target                                  big integer 0                                                                                                    
 memory_target                                      big integer 0                                                                                                    
 parallel_servers_target                            integer     16                                                                                                   
 pga_aggregate_target                               big integer 90M                                                                                                  
 sga_target                                         big integer 272M

したがって、これらすべてから収集したのは、Oracleがリカバリで使用される定期的なチェックポイントを実行しているが、ログが 頻繁に切り替わる であるため、それらのチェックポイントが完了できないことです。これはすべて、alert_xeファイルに記録されます。

Oracle guide から、私のオンラインログREDOファイルのサイズを「システムが生成するREDOの量」に合わせる必要があります。マテリアライズドビューの自動更新が頻繁に行われるため、平均的なクマよりもはるかに多く生成されていると思います。

だから、私の質問：

1）これは問題の正しい診断ですか？

2）私のoptimal_logfile_sizeパラメータがnullであることは問題がありますか？

3）マテリアライズドビューにアクセスする可能性が高い（したがって、多くのやり直しが発生する）可能性がある場合、アラートログに表示されるチェックポイントが完了していない/ LGWRの切り替えを解決するには、どのアクションが適切ですか？これは、REDOログのサイズを増やすだけの問題ですか？

oraclelogs
2
Andrew
  1. 閉じる、私はあなたがそれが引き起こしているログの切り替えではなく、やり直し自体に気を配るべきだと思います。
  2. これはfast_start_mttr_targetはゼロに設定されていますが、これは焦点にすべき問題ではありません。
  3. ここに問題の中心があります：

ソースデータベースを変更してマテリアライズドビューログを作成することはできないため、MVを更新するたびにすべてのレコードを削除してすべて再挿入する必要があり、過剰なやり直しが発生します。この問題には、さまざまなアプローチが考えられます。ここに幾つかあります。

  • REDOログのサイズを増やすだけです。これにより、頻繁な切り替えの影響は減少しますが、REDOは引き続き生成されます。
  • 独自のマテリアライズドビューをロールバックします。これはより多くの作業ですが、おそらく大幅に少ないREDOを生成します。
    • リフレッシュ中にデータが存在しないことを許容できる場合は、リフレッシュによってテーブルが切り捨てられ、追加ヒントを使用して挿入が行われる可能性があります。
    • テーブルを削除し、追加ヒントを使用してソースからCTASを実行することも、速度と再実行回数の削減のために可用性を犠牲にするオプションです。
    • データを利用できるようにする必要がある場合は、実際に変更された内容に基づいて、データを選択的に更新および挿入できます。これにより、ソースデータベースに少し負荷がかかりますが、おそらくREDOが大幅に減少します。
    • データのニーズによっては、最新の既知のシーケンス番号を超える挿入のみを処理したり、特定の重要な列のみが変更された場合に更新を行ったりすることで問題を回避できる場合があります。ソリューションをカスタマイズすればするほど、やり直しが減りますが、維持する作業も増えます。
  • より徹底的なアプローチは、2番目のデータベースに関係するテーブルスペースを定期的に回復することですが、XEを使用しているため、これはおそらくオプションではありません。
3
Leigh Riffel